S : severity.
s1 : top severity

P : prioroty
P1: top priority

both are diff.
S : Effect on the appln
P : Impact on the appln

This is possible in some cases only,but not possible in all 
cases.As per my exp all the S1 bugs go under P1 
only.Sometimes S1 bugs found in our software go under low 
priority due to business needs and the end-users 
benificiaries.  

Ex:
-----
Suppose you find a bug in one page,which page is not   
accessing by the end user frequently,but that bug is 
leading to system hanging.As we know all ,this is a S1 
bug,but here we have to consider above two things, while 
assigning priority.

1.Business needs. 
2.End-users benificiaries.

yes there are chances where the s1 comes under p1.it 
depends on the bussiness need.
severity is how that paricular bug is impacting the 
bussiness.
priority is the how important is that bug.
say the login feature...if there is a bug in that it is 
obviously a high severity and naturally we have to give a 
high priority.

another ex is in the account transfer case,if the amount is 
transfered to the non existing account no.,that is the high 
severity and so we have to give a high priority.so in these 
type of cases s1 comes under p1.

S1 need not always be P1 though S1 happens to be P1 more often.

Marking S1 bugs as P1 depends on the following factors:

1. Impact on the business needs
2. Is it a showstopper or test-stopper ? If not, it could be
set to medium priority in the initial phases of project.
3. Probability of customer coming across(executing) that
scenario
4. In case bug is reproducible in previous releases, has
customer reported that bug?

It may happens in the case like if the application
requirement and client requirement matches.

Bcz S1 is in terms of application where as P1 is in terms of
client requirement.