Bug 38077

Summary: strict aliasing is not controllable via the option pragma
Product: gcc Reporter: Andrew Pinski <pinskia>
Component: otherAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: enhancement CC: gcc-bugs, jakub, sandra
Priority: P3 Keywords: documentation
Version: 4.4.0   
Target Milestone: 5.5   
Host: Target:
Build: Known to work: 5.5.0, 6.1.0
Known to fail: 5.4.0 Last reconfirmed: 2008-11-11 20:34:48

Description Andrew Pinski 2008-11-11 01:23:52 UTC
When I was helping someone with a strict aliasing issue, I noticed that since the fix for PR 37106, the option pragma cannot control strict aliasing.  This is not documented at all but I think it would be a good idea to be able to control this option also.
Comment 1 Richard Biener 2008-11-11 20:34:48 UTC
Confirmed.
Comment 2 Bernd Edlinger 2013-11-10 15:59:26 UTC
As of current 4.9 trunk, that may have changed a bit.
but it still does not do what one would expect:

struct s
{
   int x:8;
   int y:24;
};

#pragma GCC push
#pragma GCC optimize ("strict-volatile-bitfields")
int foo(volatile struct s *x)
{
  return x->x;
}
#pragma GCC pop

#pragma GCC push
#pragma GCC optimize ("no-strict-volatile-bitfields")
int bar(volatile struct s *x)
{
  return x->x;
}
#pragma GCC pop


Both foo and bar are compiled as if -fno-strict-volatile-bitfields
was used on gcc-invocation. Whatever pragma is used last, wins...
push/pop are ignored, and does not restore the original settings.
Comment 3 Andrew Pinski 2024-04-11 01:56:55 UTC
(In reply to Bernd Edlinger from comment #2)
> As of current 4.9 trunk, that may have changed a bit.
> but it still does not do what one would expect:

That is a different issue ...
Comment 4 Andrew Pinski 2024-04-11 02:12:47 UTC
This was fixed for GCC 5.5.0 by r5-10168-g26736ac3d17699 and GCC 6.1.0+ by r6-5413-g9dc39706b4afc3 .
Comment 5 Andrew Pinski 2024-04-11 02:15:05 UTC
(In reply to Andrew Pinski from comment #3)
> (In reply to Bernd Edlinger from comment #2)
> > As of current 4.9 trunk, that may have changed a bit.
> > but it still does not do what one would expect:
> 
> That is a different issue ...

That was fixed in GCC 5.1.0 (I have not looked into what fixed it though).
Comment 6 Andrew Pinski 2024-04-11 02:19:02 UTC
(In reply to Andrew Pinski from comment #4)
> This was fixed for GCC 5.5.0 by r5-10168-g26736ac3d17699 and GCC 6.1.0+ by
> r6-5413-g9dc39706b4afc3 .

I should say that was the last patch which was needed to fix this, there was most likely others that happened beforehand.