public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/25152]  New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
@ 2005-11-29 13:28 frederic dot devernay at m4x dot org
  2005-11-29 13:30 ` [Bug c++/25152] " frederic dot devernay at m4x dot org
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: frederic dot devernay at m4x dot org @ 2005-11-29 13:28 UTC (permalink / raw)
  To: gcc-bugs

the attached program generates wrong code with -O -fstrict-aliasing (-O works),
although -Wstrict-aliasing doesn't issue a warning.

The bug was not present in gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
(the generated code was OK even with -O3).

The bug is present in :
- gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
- gcc 4.0.2
- gcc version 4.1.0 20051128 (prerelease) gcc-4_1-branch

gcc version 4.2.0 20051128 (experimental) issues the warning, and generates the
right code with -O2 -fstrict-aliasing, though it breaks with -O3. My conclusion
is that gcc 4.2 doesn't have this bug.

IMHO this is critical, since it's a regression from 3.3, and gcc generates
wrong code without the user being warned.

Fred


-- 
           Summary: -fstrict-aliasing generates wrong code, but no warning
                    from -Wstrict-aliasing
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: frederic dot devernay at m4x dot org
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
@ 2005-11-29 13:30 ` frederic dot devernay at m4x dot org
  2005-11-29 15:12 ` pinskia at gcc dot gnu dot org
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: frederic dot devernay at m4x dot org @ 2005-11-29 13:30 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from frederic dot devernay at m4x dot org  2005-11-29 13:30 -------
Created an attachment (id=10361)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10361&action=view)
test case

this source generates wrong code without issueing a warning, using:
g++ -DMAIN -O -Wstrict-aliasing -fstrict-aliasing cxcopy-preproc.cpp -o
testcase
it generates the right code with:
g++ -DMAIN -O cxcopy-preproc.cpp -o testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
  2005-11-29 13:30 ` [Bug c++/25152] " frederic dot devernay at m4x dot org
@ 2005-11-29 15:12 ` pinskia at gcc dot gnu dot org
  2005-11-29 17:42 ` frederic dot devernay at m4x dot org
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-11-29 15:12 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-29 15:12 -------
4.2 warns:
t.cc: In function 'CvStatus icvSet_8u_C4MR(int*, int, const uchar*, int,
CvSize, const int*)':
t.cc:21: warning: dereferencing type-punned pointer will break strict-aliasing
rules


Because the warning was not in 4.1.0 at all for C++.
This is invalid as:
CvStatus
icvSet_8u_C4MR (int *dst, int step, const uchar * mask, int step2,
                  CvSize size, const int *scalar)
{
  int s0 = scalar[0];
  for (; size.height--; mask += step2, (char *&) dst += step)
    {

"(char *&) dst += step" is equaliant to *((char**)&dst) += step
so we are accessing dst as a "char*" which violates alaiasing rules.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
  2005-11-29 13:30 ` [Bug c++/25152] " frederic dot devernay at m4x dot org
  2005-11-29 15:12 ` pinskia at gcc dot gnu dot org
@ 2005-11-29 17:42 ` frederic dot devernay at m4x dot org
  2005-11-29 17:47 ` pinskia at gcc dot gnu dot org
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: frederic dot devernay at m4x dot org @ 2005-11-29 17:42 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from frederic dot devernay at m4x dot org  2005-11-29 17:42 -------
I know it breaks aliasing rules, but this problem was not present in gcc-3.3.

Most gcc users consider "-O2" as being a safe optimizing option, (e.g. redhat
RPMs are compiled with gcc -O2), and generating wrong code from proper ISO C++
source without even a warning looks like a regression to me.

FYI, this bug came out when compiling OpenCV (maintained and distributed by
Intel) on Fedora Core 4.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
                   ` (2 preceding siblings ...)
  2005-11-29 17:42 ` frederic dot devernay at m4x dot org
@ 2005-11-29 17:47 ` pinskia at gcc dot gnu dot org
  2005-11-29 17:55 ` bonzini at gnu dot org
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-11-29 17:47 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from pinskia at gcc dot gnu dot org  2005-11-29 17:47 -------
(In reply to comment #3)
> I know it breaks aliasing rules, but this problem was not present in gcc-3.3.

So ...

GCC 4.1 includes more optimization than 3.3 did which takes advantage of the
aliasing rules.

Note this is only undefined behavior.  There are lots of undefined behavior
which we don't warn about.  An example is signed overflow, if we warned about
that it would show up in the simple i++ or i = a + b example.

The warning was a bug which was filed a long time ago and was just only fixed.

Also I should note different targets would show up aliasing violating
differently.  PPC will show more than x86 since the scheduler uses the
information and PPC relies more and than the shceduler than x86 does.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
                   ` (3 preceding siblings ...)
  2005-11-29 17:47 ` pinskia at gcc dot gnu dot org
@ 2005-11-29 17:55 ` bonzini at gnu dot org
  2005-11-30 16:02 ` drow at gcc dot gnu dot org
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: bonzini at gnu dot org @ 2005-11-29 17:55 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from bonzini at gnu dot org  2005-11-29 17:55 -------
Frederic, "-Wstrict-aliasing" is only working for C up until 4.1 (included). 
Your code, rewritten to C, would issue a warning with 4.1 and earlier compilers
as well.  Also note that -Wstrict-aliasing does not prevent the compiler from
using aliasing relationships that it has warned about.

GCC 4.2 has the same behavior as earlier versions, just does not expose it by
generating wrong results, maybe because it finds some more interesting
optimization to do.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
                   ` (4 preceding siblings ...)
  2005-11-29 17:55 ` bonzini at gnu dot org
@ 2005-11-30 16:02 ` drow at gcc dot gnu dot org
  2005-11-30 16:06 ` [Bug c++/25152] [4.0/4.1 only] " pinskia at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: drow at gcc dot gnu dot org @ 2005-11-30 16:02 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from drow at gcc dot gnu dot org  2005-11-30 16:02 -------
However, I think this is a convincing reason for the patch to merged to at
least 4.1.0.


-- 

drow at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] [4.0/4.1 only] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
                   ` (5 preceding siblings ...)
  2005-11-30 16:02 ` drow at gcc dot gnu dot org
@ 2005-11-30 16:06 ` pinskia at gcc dot gnu dot org
  2005-12-08 12:30 ` [Bug c++/25152] [4.0 only] no warning from -Wstrict-aliasing for C++ code jakub at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-11-30 16:06 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from pinskia at gcc dot gnu dot org  2005-11-30 16:06 -------
(In reply to comment #6)
> However, I think this is a convincing reason for the patch to merged to at
> least 4.1.0.

If you reopen the bug at least mark this as 4.0/4.1 only so that people know
that it only effects the release branches.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
            Summary|-fstrict-aliasing generates |[4.0/4.1 only] -fstrict-
                   |wrong code, but no warning  |aliasing generates wrong
                   |from -Wstrict-aliasing      |code, but no warning from -
                   |                            |Wstrict-aliasing
   Target Milestone|---                         |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] [4.0 only] no warning from -Wstrict-aliasing for C++ code
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
                   ` (6 preceding siblings ...)
  2005-11-30 16:06 ` [Bug c++/25152] [4.0/4.1 only] " pinskia at gcc dot gnu dot org
@ 2005-12-08 12:30 ` jakub at gcc dot gnu dot org
  2005-12-08 15:43 ` [Bug c++/25152] [3.4/4.0 " pinskia at gcc dot gnu dot org
  2006-01-15 22:50 ` mmitchel at gcc dot gnu dot org
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu dot org @ 2005-12-08 12:30 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #8 from jakub at gcc dot gnu dot org  2005-12-08 12:30 -------
-Wstrict-aliasing backport has been committed today to gcc-4_1-branch:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108226

For 4.0, it is IMHO a bad idea to backport this, there are tons of programs
built with -Werror and if we suddenly start issuing a huge amount of new
warnings (and this warning has sometimes many false positives), we'd force
people to change packages a lot.  People are used to do this kind of things
when porting to a newer major GCC version, but e.g. when upgrading from
x.y.z to x.y.z+1 it is not expected.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0/4.1 only] no warning   |[4.0 only] no warning from -
                   |from -Wstrict-aliasing for  |Wstrict-aliasing for C++
                   |C++ code                    |code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] [3.4/4.0 only] no warning from -Wstrict-aliasing for C++ code
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
                   ` (7 preceding siblings ...)
  2005-12-08 12:30 ` [Bug c++/25152] [4.0 only] no warning from -Wstrict-aliasing for C++ code jakub at gcc dot gnu dot org
@ 2005-12-08 15:43 ` pinskia at gcc dot gnu dot org
  2006-01-15 22:50 ` mmitchel at gcc dot gnu dot org
  9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-12-08 15:43 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #9 from pinskia at gcc dot gnu dot org  2005-12-08 15:43 -------
(In reply to comment #8)
> For 4.0, it is IMHO a bad idea to backport this, there are tons of programs
> built with -Werror and if we suddenly start issuing a huge amount of new
> warnings (and this warning has sometimes many false positives), we'd force
> people to change packages a lot.  People are used to do this kind of things
> when porting to a newer major GCC version, but e.g. when upgrading from
> x.y.z to x.y.z+1 it is not expected.

They might not be expecting this.  The warning has very few false warnings.

Actually they are broken (in fact they don't know what hit them in 4.0.x).  In
fact 4.0.x already uses strict aliasing information more than 3.4.0.  I also
have seen 3.4.x use strict aliasing more than 3.3.3 did too.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-12-08 15:43:23
               date|                            |
            Summary|[4.0 only] no warning from -|[3.4/4.0 only] no warning
                   |Wstrict-aliasing for C++    |from -Wstrict-aliasing for
                   |code                        |C++ code
   Target Milestone|4.1.0                       |4.0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c++/25152] [3.4/4.0 only] no warning from -Wstrict-aliasing for C++ code
  2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
                   ` (8 preceding siblings ...)
  2005-12-08 15:43 ` [Bug c++/25152] [3.4/4.0 " pinskia at gcc dot gnu dot org
@ 2006-01-15 22:50 ` mmitchel at gcc dot gnu dot org
  9 siblings, 0 replies; 11+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2006-01-15 22:50 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #10 from mmitchel at gcc dot gnu dot org  2006-01-15 22:50 -------
I think it's unwise to backport -Wstrict-aliasing for C++ to 4.0.  As Jakub
says, this is going to break -Werror builds for some packages, and, contrary to
Andrew's claim, there are relatively common situations where you will get false
positives.

If you disagree with this conclusion, please start a thread on the GCC mailing
list and get consensus there that we should in fact backport the patches,
rather than following up in this PR.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2006-01-15 22:50 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-29 13:28 [Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing frederic dot devernay at m4x dot org
2005-11-29 13:30 ` [Bug c++/25152] " frederic dot devernay at m4x dot org
2005-11-29 15:12 ` pinskia at gcc dot gnu dot org
2005-11-29 17:42 ` frederic dot devernay at m4x dot org
2005-11-29 17:47 ` pinskia at gcc dot gnu dot org
2005-11-29 17:55 ` bonzini at gnu dot org
2005-11-30 16:02 ` drow at gcc dot gnu dot org
2005-11-30 16:06 ` [Bug c++/25152] [4.0/4.1 only] " pinskia at gcc dot gnu dot org
2005-12-08 12:30 ` [Bug c++/25152] [4.0 only] no warning from -Wstrict-aliasing for C++ code jakub at gcc dot gnu dot org
2005-12-08 15:43 ` [Bug c++/25152] [3.4/4.0 " pinskia at gcc dot gnu dot org
2006-01-15 22:50 ` mmitchel at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).