[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[fw at deneb dot enyo dot de]

--- Comment #5 from fw at deneb dot enyo dot de  2010-01-31 09:38 ---
Isn't this a wrong-code bug?  Or is the information used for the diagnostic not
used by the optimizers?


-- 

fw at deneb dot enyo dot de changed:

   What|Removed |Added

 CC||fw at deneb dot enyo dot de


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

[Bug c++/42911] New: another compiler hang for -g -O2

[dcb314 at hotmail dot com]

I just tried to compile the package kile-2.1beta2-3.19 with the GNU
C++ compiler version 4.5 snapshot 20100128 and the compiler seemed
to take a long time over the compilation.

It ran for over 20 minutes on an idle 2.7 GHz AMD Athlon without
finishing.

Preprocessed source code attached. Flags -g -O2 required.

I am not sure if this bug report is the same or different to #41371.


-- 
   Summary: another compiler hang for -g -O2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/42911] another compiler hang for -g -O2

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2010-01-31 10:56 ---
Created an attachment (id=19762)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19762&action=view)
gzipped C++ source code


-- 


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

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-31 11:17 ---
(In reply to comment #5)
> Isn't this a wrong-code bug?  Or is the information used for the diagnostic 
> not
> used by the optimizers?

The diagnostics are independent on the optimizers, the one diagnostic that
isn't (that is emitted from the optimizer itself) causes the optimizer to
not optimize (well, because it saw the problem and thus there is no point
in breaking things just because we can).

The general problem is that alias analysis is hard, thus follows that proper
warnings are equally hard.  All warnings we emit are either possible false
positives or if they are not the optimizers will not miscompile your code
because they know there is an alias even though type-based analysis says
there is not (well, this is exactly the case you want to warn about, but
as analysis is hard once you can tell you can as well not exploit the
mis-optimization opportunity).


-- 


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

[Bug fortran/42912] New: BLOCK: C1278 - wrongly accepts SAVE in pure procedure

[burnus at gcc dot gnu dot org]

C1278 A local variable of a pure subprogram, or of a BLOCK construct within a
pure subprogram, shall not have the SAVE attribute.

However, the following is accepted:

pure subroutine foo()
  block
integer, save :: i
integer :: j = 5
  end block
end subroutine foo


Expected:

integer, save :: i
 1
Error: SAVE attribute at (1) cannot be specified in a PURE procedure

integer :: j = 5
1
Error: Initialization of variable at (1) is not allowed in a PURE procedure


-- 
   Summary: BLOCK: C1278 - wrongly accepts SAVE in pure procedure
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug middle-end/39193] Internal compiler error during FreeBSD 7.1 kernel compilation

[cyberleo at cyberleo dot net]

--- Comment #11 from cyberleo at cyberleo dot net  2010-01-31 11:21 ---
Created an attachment (id=19763)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19763&action=view)
Preprocessed source

Seems to exist on 8.0-RELEASE-p2, but only when -Os and certain -march are
used.

cc (GCC) 4.2.1 20070719  [FreeBSD]

(ec575ad3)[cyber...@x86 /usr/src/sys/modules/scsi_low]$ cc -Os -march=c3-2
-fno-strict-aliasing -Wno-error -D_KERNEL -DKLD_MODULE -nostdinc  
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/srcs/RELENG_8_0/src/sys/VITANI-MINIMAL/opt_global.h -I. -I@
-I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -g
-I/usr/obj/usr/srcs/RELENG_8_0/src/sys/VITANI-MINIMAL -mno-align-long-strings
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3
-ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
-fformat-extensions -c
/usr/srcs/RELENG_8_0/src/sys/modules/scsi_low/../../cam/scsi/scsi_low.c
/usr/srcs/RELENG_8_0/src/sys/modules/scsi_low/../../cam/scsi/scsi_low.c: In
function 'scsi_low_disconnected':
/usr/srcs/RELENG_8_0/src/sys/modules/scsi_low/../../cam/scsi/scsi_low.c:4194:
internal compiler error: in unify_nodes, at tree-ssa-structalias.c:1231
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Although adding -save-temps rids me of the crash.


-- 


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

[Bug middle-end/39193] Internal compiler error during FreeBSD 7.1 kernel compilation

[steven at gcc dot gnu dot org]

--- Comment #12 from steven at gcc dot gnu dot org  2010-01-31 11:31 ---
GCC 4.2 is no longer maintained, and the code that ICEs had been almost
completely rewritten. Does this also fail with newer compilers?


-- 


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

[Bug fortran/38324] Wrong lbound given to allocatable components

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2010-01-31 12:05 ---
Subject: Bug 38324

Author: pault
Date: Sun Jan 31 12:05:22 2010
New Revision: 156399

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156399
Log:
2010-01-31  Paul Thomas  

PR fortran/38324
* expr.c (gfc_get_full_arrayspec_from_expr): New function.
* gfortran.h : Add prototype for above.
* trans-expr.c (gfc_trans_alloc_subarray_assign): New function.
(gfc_trans_subcomponent_assign): Call new function to replace
the code to deal with allocatable components.
* trans-intrinsic.c (gfc_conv_intrinsic_bound): Call
gfc_get_full_arrayspec_from_expr to replace existing code.

2010-01-31  Paul Thomas  

PR fortran/38324
* gfortran.dg/alloc_comp_basics_1.f90: Remove option -O2.
* gfortran.dg/alloc_comp_bounds_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/alloc_comp_bounds_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90


-- 


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

[Bug fortran/42912] BLOCK: C1278 - wrongly accepts SAVE in pure procedure

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2010-01-31 12:21 ---
Mine.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-31 12:21:21
   date||


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

[Bug c++/42911] another compiler hang for -g -O2

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-31 13:51 ---
I think it is related.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||41371
Summary|another compiler hang for -g|another compiler hang for -g
   |-O2 |-O2


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

[Bug fortran/38324] Wrong lbound given to allocatable components

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2010-01-31 14:57 ---
Subject: Bug 38324

Author: pault
Date: Sun Jan 31 14:57:13 2010
New Revision: 156401

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156401
Log:
2010-01-31  Paul Thomas  

PR fortran/38324
* expr.c (gfc_get_full_arrayspec_from_expr): New function.
* gfortran.h : Add prototype for above.
* trans-expr.c (gfc_trans_alloc_subarray_assign): New function.
(gfc_trans_subcomponent_assign): Call new function to replace
the code to deal with allocatable components.
* trans-intrinsic.c (gfc_conv_intrinsic_bound): Call
gfc_get_full_arrayspec_from_expr to replace existing code.

2010-01-31  Paul Thomas  

PR fortran/38324
* gfortran.dg/alloc_comp_basics_1.f90: Remove option -O2.
* gfortran.dg/alloc_comp_bounds_1.f90: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/alloc_comp_bounds_1.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/expr.c
branches/gcc-4_4-branch/gcc/fortran/gfortran.h
branches/gcc-4_4-branch/gcc/fortran/trans-expr.c
branches/gcc-4_4-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90


-- 


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

[Bug fortran/38324] Wrong lbound given to allocatable components

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2010-01-31 15:00 ---
Fixed on trunk and 4.4

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/42850] [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2010-01-31 16:32 ---
The failure was introduced by my change to the libgcc_s so version.  With
the change, the array dwarf_reg_size_table is no longer initialized.  It
appears that glibc has an implicit dependence on libgcc_s:

Breakpoint 4, __gxx_personality_v0 (version=1, actions=10, exception_class=0, 
ue_header=0x40002408, context=0xbff01630)
at ../../../../gcc/libstdc++-v3/libsupc++/eh_personality.cc:361
361 {
(gdb) bt
#0  __gxx_personality_v0 (version=1, actions=10, exception_class=0, 
ue_header=0x40002408, context=0xbff01630)
at ../../../../gcc/libstdc++-v3/libsupc++/eh_personality.cc:361
#1  0x400c6028 in _Unwind_ForcedUnwind_Phase2 (exc=0x40002408, 
context=0xbff01630) at ../../../src/libgcc/../gcc/unwind.inc:175
#2  0x400c6170 in _Unwind_ForcedUnwind (exc=0x40002408, 
st...@0x401a83a6: 0x4019e838 , stop_argument=0xbff011d0)
at ../../../src/libgcc/../gcc/unwind.inc:207
#3  0x401a1eec in _Unwind_ForcedUnwind (exc=0x40002408, 
st...@0x401a83a6: 0x4019e838 , stop_argument=0xbff011d0)
at ../ports/sysdeps/unix/sysv/linux/hppa/nptl/unwind-forcedunwind.c:133
#4  0x4019e7d8 in *__GI___pthread_unwind (buf=0x0) at unwind.c:130
#5  0x40193994 in __do_cancel (value=) at pthreadP.h:265
#6  __pthread_exit (value=) at pthread_exit.c:30
#7  0x00010784 in main ()
at /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/abi/forced.C:13

The problem is two copies of libgcc_s.

Breakpoint 5, main ()
at /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/abi/forced.C:13
13pthread_exit (0);
Current language:  auto
The current source language is "auto; currently c++".
(gdb) info shared
>FromTo  Syms Read   Shared Object Library
0x402673c0  0x4027fef0  Yes (*) /lib/ld.so.1
0x4039a350  0x40420c6c  Yes
/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
0x404c4658  0x404fd5a8  Yes (*) /lib/libm.so.6
0x4014fa40  0x4015c330  Yes /home/dave/gnu/gcc/objdir/gcc/libgcc_s.so.6
0x4018f8e0  0x401a405c  Yes (*) /lib/libpthread.so.0
0x40921e00  0x40a2d1f0  Yes (*) /lib/libc.so.6

(gdb) enable 6
(gdb) c
Continuing.

Breakpoint 6, 0x401a1ee4 in _Unwind_ForcedUnwind (exc=0x40002408, 
st...@0x401a83a6: 0x4019e838 , stop_argument=0xbff011d0)
at ../ports/sysdeps/unix/sysv/linux/hppa/nptl/unwind-forcedunwind.c:133
133 ../ports/sysdeps/unix/sysv/linux/hppa/nptl/unwind-forcedunwind.c: No
such file or directory.
in ../ports/sysdeps/unix/sysv/linux/hppa/nptl/unwind-forcedunwind.c
Current language:  auto
The current source language is "auto; currently c".
(gdb) info shared
>FromTo  Syms Read   Shared Object Library
0x402673c0  0x4027fef0  Yes (*) /lib/ld.so.1
0x4039a350  0x40420c6c  Yes
/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
0x404c4658  0x404fd5a8  Yes (*) /lib/libm.so.6
0x4014fa40  0x4015c330  Yes /home/dave/gnu/gcc/objdir/gcc/libgcc_s.so.6
0x4018f8e0  0x401a405c  Yes (*) /lib/libpthread.so.0
0x40921e00  0x40a2d1f0  Yes (*) /lib/libc.so.6
0x400bca70  0x400c98dc  Yes (*) /lib/libgcc_s.so.4
(*): Shared library is missing debugging information.
(gdb) bt
#0  0x401a1ee4 in _Unwind_ForcedUnwind (exc=0x40002408, 
st...@0x401a83a6: 0x4019e838 , stop_argument=0xbff011d0)
at ../ports/sysdeps/unix/sysv/linux/hppa/nptl/unwind-forcedunwind.c:133
#1  0x4019e7d8 in *__GI___pthread_unwind (buf=0xbff011d0) at unwind.c:130
#2  0x40193994 in __do_cancel (value=) at pthreadP.h:265
#3  __pthread_exit (value=) at pthread_exit.c:30
#4  0x00010784 in main ()
at /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/abi/forced.C:13

This is with LD_LIBRARY_PATH set as follows:

export
LD_LIBRARY_PATH=.:/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/gcc:.:/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/gcc

I looked all the application and all the libraries used by the application,
and none has a dependence on /lib/libgcc_s.so.4.


-- 


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

[Bug fortran/42913] New: Should gfc_conv_expr_descriptor be setting bounds correctly?

[pault at gcc dot gnu dot org]

See the TODO in trans-expr.c(gfc_trans_alloc_subarray_assign):

Quite a lot of correction has to be done to the bounds of array descriptors
produced by gfc_conv_expr_descriptor. These concern full array references of
variables and array references where conversion is applied implicitly.  The fix
to PR38324 required that this be done in gfc_trans_alloc_subarray_assign.

Paul


-- 
   Summary: Should gfc_conv_expr_descriptor be setting bounds
correctly?
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: FIXME
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org


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

[Bug fortran/42913] [FIXME] Should gfc_conv_expr_descriptor be setting bounds correctly?

[pault at gcc dot gnu dot org]

-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-31 16:47:36
   date||
Summary|Should  |[FIXME] Should
   |gfc_conv_expr_descriptor be |gfc_conv_expr_descriptor be
   |setting bounds correctly?   |setting bounds correctly?


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

[Bug target/42850] [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test

[carlos at systemhalted dot org]

--- Comment #4 from carlos at systemhalted dot org  2010-01-31 16:54 ---
That is correct, all glibc targets must provide the current version if
libgcc_s.so. The NPTL implementation of pthread_cancel_init will dlopen that
current version of libgcc_s.so and use the unwinder implementation from that
library.


-- 


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

[Bug middle-end/42898] [4.3/4.4/4.5 Regression] volatile structures and compound literal initializers

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-31 17:01 ---
Subject: Bug 42898

Author: rguenth
Date: Sun Jan 31 17:01:38 2010
New Revision: 156404

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156404
Log:
2010-01-31  Richard Guenther  

PR middle-end/42898
* gimplify.c (gimplify_init_constructor): For volatile LHS
initialize a temporary.

* gcc.dg/torture/pr42898.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr42898.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/42898] [4.3/4.4/4.5 Regression] volatile structures and compound literal initializers

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-01-31 17:04 ---
Subject: Bug 42898

Author: rguenth
Date: Sun Jan 31 17:04:29 2010
New Revision: 156405

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156405
Log:
2010-01-31  Richard Guenther  

PR middle-end/42898
* gimplify.c (gimplify_init_constructor): For volatile LHS
initialize a temporary.

* gcc.dg/torture/pr42898.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr42898.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/gimplify.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/42850] [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-31 17:05 ---
(In reply to comment #3)
> The failure was introduced by my change to the libgcc_s so version.

I always wondered why we have to do this all the time for hppa...  every
other target seems to get along fine without doing this.  Considering that
hppa is dead it's even more disturbing that we have this instability.


-- 


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

[Bug middle-end/42898] [4.3/4.4/4.5 Regression] volatile structures and compound literal initializers

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-31 17:07 
---
Subject: Bug 42898

Author: rguenth
Date: Sun Jan 31 17:07:16 2010
New Revision: 156407

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156407
Log:
2010-01-31  Richard Guenther  

PR middle-end/42898
* gimplify.c (gimplify_init_constructor): For volatile LHS
initialize a temporary.

* gcc.dg/torture/pr42898.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr42898.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/gimplify.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/42898] [4.5 Regression] volatile structures and compound literal initializers

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-01-31 17:08 
---
Fixed on the branches.  Trunk is still broken because of SRA, reassigning to
Martin for that.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |jamborm at gcc dot gnu dot
   |org |org
  Known to work||4.3.5 4.4.4
Summary|[4.3/4.4/4.5 Regression]|[4.5 Regression] volatile
   |volatile structures and |structures and compound
   |compound literal|literal initializers
   |initializers|
   Target Milestone|4.3.6   |4.3.5


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

[Bug target/42850] [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2010-01-31 
17:23 ---
Subject: Re:  [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test

> (In reply to comment #3)
> > The failure was introduced by my change to the libgcc_s so version.
> 
> I always wondered why we have to do this all the time for hppa...  every
> other target seems to get along fine without doing this.  Considering that
> hppa is dead it's even more disturbing that we have this instability.

The change in signal frame handling for Ada broke some Java applications.
The Java exception support compensated for the signal frame bug.

I wasn't aware of the implicit dependence of glibc on libgcc_s.  ldd
doesn't show the dependency.

I think the mininimal change is to back out the version bump, and to
backport the signal frame changes to active GCC versions so that it's
possible to have a consistent set of libraries.

Dave


-- 


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

[Bug target/42850] [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2010-01-31 
17:26 ---
Subject: Re:  [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test

> That is correct, all glibc targets must provide the current version if
> libgcc_s.so. The NPTL implementation of pthread_cancel_init will dlopen that
> current version of libgcc_s.so and use the unwinder implementation from that
> library.

Why is this hard coded?

Dave


-- 


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

[Bug middle-end/42914] New: [4.5 Regression][graphite] ICE with -g -ffast-math -fgraphite-identity -O2: verify_ssa failed

[spop at gcc dot gnu dot org]

int find_sad_16x16(int *intra_mode)
{
  int current_intra_sad_2,best_intra_sad2;
  int M1[16][16],M0[4][4][4][4],M3[4],M4[4][4];
  int i,j,k;
  int ii,jj;

  for (jj=0;jj<4;jj++)
for (ii=0;ii<4;ii++)
  for (j=0;j<4;j++)
for (j=0;j<4;j++)
  current_intra_sad_2 += abs(M0[i][ii][j][jj]);

  if(current_intra_sad_2 < best_intra_sad2)
{
  best_intra_sad2=current_intra_sad_2;
  *intra_mode = k;
}
}

This reduced testcase comes from h264 in the SPEC2006.
It crashes GCC only when compiling with -g -ffast-math -fgraphite-identity
and with -Os, -O2, or -O3.  The ICE disappears when removing -g.


-- 
   Summary: [4.5 Regression][graphite] ICE with -g -ffast-math -
fgraphite-identity -O2: verify_ssa failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spop at gcc dot gnu dot org


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

[Bug middle-end/42914] [4.5 Regression][graphite] ICE with -g -ffast-math -fgraphite-identity -O2: verify_ssa failed

[spop at gcc dot gnu dot org]

-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug tree-optimization/42729] "-fcompare-debug failure" with "-O1 -fgraphite-identity"

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-01-31 18:08 ---
Created an attachment (id=19764)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19764&action=view)
different testcase

Fails at least with r155363, r155966, r156367

Command line:
gcc -O1 -fgraphite-identity -fcompare-debug -c pr42729-2.c


-- 


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

[Bug middle-end/42914] [4.5 Regression][graphite] ICE with -g -ffast-math -fgraphite-identity -O2: verify_ssa failed

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P3
   Target Milestone|--- |4.5.0


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

[Bug c++/42915] New: ICE: same canonical type node for different types in recent builds

[zsojka at seznam dot cz]

Command line:
gcc -c testcase.cpp

Tested revisions:
r156392 - crash
r156367 - crash
r156293 - OK
r156260 - OK
r154975 - OK (4.4)

Output:
$ /mnt/svn/gcc-trunk/binary-156367-lto/bin/gcc testcase.cpp -c
testcase.cpp:9:28: internal compiler error: same canonical type node for
different types A::B and A::B
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE: same canonical type node for different types in
recent builds
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86(_64)-pc-linux-gnu
GCC target triplet: x86(_64)-pc-linux-gnu


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

[Bug c++/42915] ICE: same canonical type node for different types in recent builds

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-01-31 19:16 ---
Created an attachment (id=19765)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19765&action=view)
reduced testcase

Command line:
g++ -c pr42915.cpp


-- 


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

[Bug target/42850] [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test

[danglin at gcc dot gnu dot org]

--- Comment #8 from danglin at gcc dot gnu dot org  2010-01-31 19:38 ---
Subject: Bug 42850

Author: danglin
Date: Sun Jan 31 19:37:52 2010
New Revision: 156410

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156410
Log:
PR target/42850
Revert:
2010-01-02  John David Anglin  

* config/pa/t-slibgcc-dwarf-ver (SHLIB_SOVERSION): Bump by two.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/t-slibgcc-dwarf-ver


-- 


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

[Bug target/42850] [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test

[danglin at gcc dot gnu dot org]

--- Comment #9 from danglin at gcc dot gnu dot org  2010-01-31 19:40 ---
Fixed.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/42915] [4.5 Regression] ICE: same canonical type node for different types in recent builds

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE: same canonical type|[4.5 Regression] ICE: same
   |node for different types in |canonical type node for
   |recent builds   |different types in recent
   ||builds
   Target Milestone|--- |4.5.0


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

[Bug middle-end/42898] [4.5 Regression] volatile structures and compound literal initializers

[ebotcazou at gcc dot gnu dot org]

--- Comment #12 from ebotcazou at gcc dot gnu dot org  2010-01-31 20:01 
---
Subject: Bug 42898

Author: ebotcazou
Date: Sun Jan 31 20:00:54 2010
New Revision: 156414

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156414
Log:
PR middle-end/42898
* gcc.dg/torture/pr42898-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr42898-2.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/42916] New: "-fcompare-debug failure" with "-O1 -funroll-loops -ftree-vectorize"

[zsojka at seznam dot cz]

Command line:
gcc -O1 -funroll-loops -ftree-vectorize -fcompare-debug -m32 -c testcase.c
(-m32 is needed for x86_64)

Tested revisions:
r156367 - crash
r155363 - crash
r153685 - crash

Output:
$ /mnt/svn/gcc-trunk/binary-156367-lto/bin/gcc -O1 -funroll-loops
-ftree-vectorize -fcompare-debug -m32 -c testcase.c
gcc: testcase.c: -fcompare-debug failure (length)


-- 
   Summary: "-fcompare-debug failure" with "-O1 -funroll-loops -
ftree-vectorize"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86(_64)-pc-linux-gnu
GCC target triplet: x86(_64)-pc-linux-gnu


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

[Bug tree-optimization/42916] "-fcompare-debug failure" with "-O1 -funroll-loops -ftree-vectorize"

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-01-31 20:32 ---
Created an attachment (id=19766)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19766&action=view)
reduced testcase

Command line:
gcc -O1 -funroll-loops -ftree-vectorize -fcompare-debug -m32 -c pr42916.c


-- 


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

[Bug c/42907] -fstrict-aliasing breaks valid code

[matz at gcc dot gnu dot org]

--- Comment #28 from matz at gcc dot gnu dot org  2010-01-31 20:34 ---
fejj: To see how your initial code is broken, I've transformed it a bit to
show you how it already is "miscompiled" with earlier compilers.  I've manually
unrolled the loop, and hoisted the two malloc calls to the front.
You hopefully agree that the function then is completely equivalent
to your initial testcase (assuming validity to start with).  Like so:

% cat broken.c
#include 
#include 

typedef struct _node {
struct _node *next;
int value;
} Node;

int main (int argc, char **argv)
{
Node *list, *node, *tail;
Node *n1, *n2;
int i;

n1 = malloc (sizeof (Node));
n2 = malloc (sizeof (Node));

list = NULL;
tail = (Node *) &list;

node = n1;
node->next = NULL;
node->value = 0;
tail->next = node;
tail = node;

node = n2;
node->next = NULL;
node->value = 2;
tail->next = node;
tail = node;

if (list == NULL)
printf ("oops, list is null???\n");
return 0;
}

Compile this with e.g. gcc-4.3 -O2 and see it broken too.  From your blog
entry I gather that you think this has something to do with the recent gcc@
discussion about interpreting the C standard regarding accesses through unions
or similar.  This is not the case.  The code as written simply is completely
unspecified in _any_ interpretation of the standard.  To see this, add this
statement into the list:

tail->value = tail->value;

This statement must be harmless iff tail indeed points to enough memory to
have a value member.  But in the first iteration tail points to list, a Node*,
hence it holds only enough memory for one pointer.  I.e. would you change
the order of the struct members ('value' first, 'next' second) already the
access to ->next in your original testcase would overwrite non-existing
memory (and depending on circumstance for instance valgrind would complain). 
The list variables simply is only one pointer long, not two.

I hope you see now that we don't even need to invoke aliasing arguments to
show that the testcase was invalid: In the first iteration tail points to
something that doesn't even have enough space to contain a whole Node.  We
don't even need to argue about the type of it.


-- 


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

[Bug c++/42915] [4.5 Regression] ICE: same canonical type node for different types in recent builds

[dodji at gcc dot gnu dot org]

--- Comment #2 from dodji at gcc dot gnu dot org  2010-01-31 20:35 ---
Confirmed on trunk.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-31 20:35:31
   date||


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

[Bug fortran/42309] Problem with a pointer array passed to a subroutine

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2010-01-31 20:40 ---
I think that I know how to fix this one, so am assigning myself.  I would
regard this as a "serious" bug.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-06 15:00:54 |2010-01-31 20:40:04
   date||


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

[Bug tree-optimization/42916] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops -ftree-vectorize"

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|"-fcompare-debug failure"   |[4.5 Regression] "-fcompare-
   |with "-O1 -funroll-loops -  |debug failure" with "-O1 -
   |ftree-vectorize"|funroll-loops -ftree-
   ||vectorize"
   Target Milestone|--- |4.5.0


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

[Bug middle-end/42898] [4.5 Regression] volatile structures and compound literal initializers

[ebotcazou at gcc dot gnu dot org]

--- Comment #13 from ebotcazou at gcc dot gnu dot org  2010-01-31 21:06 
---
Subject: Bug 42898

Author: ebotcazou
Date: Sun Jan 31 21:06:20 2010
New Revision: 156415

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156415
Log:
PR middle-end/42898
Backport from mainline:
2009-04-23  Eric Botcazou  

* gimplify.c (gimplify_modify_expr_rhs) : Do not do a direct
assignment from the constructor either if the target is volatile.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr42898-2.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/gimplify.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/42898] [4.5 Regression] volatile structures and compound literal initializers

[ebotcazou at gcc dot gnu dot org]

--- Comment #14 from ebotcazou at gcc dot gnu dot org  2010-01-31 21:08 
---
Subject: Bug 42898

Author: ebotcazou
Date: Sun Jan 31 21:08:15 2010
New Revision: 156416

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156416
Log:
2010-01-31  Eric Botcazou  

PR middle-end/42898
Backport from mainline:
2009-04-23  Eric Botcazou  

* gimplify.c (gimplify_modify_expr_rhs) : Do not do a direct
assignment from the constructor either if the target is volatile.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr42898-2.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/gimplify.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/42917] New: [4.5 Regression] "-fcompare-debug failure" with -ftree-loop-linear

[zsojka at seznam dot cz]

Command line:
gcc -O1 -ftree-loop-linear -fcompare-debug -c testcase.c
(fails at all -O1, -O2 and -O3 levels)

Tested revisions:
r156367 - crash
r155833 - crash
r154830 - crash
r153685 - crash

Output:
$ /mnt/svn/gcc-trunk/binary-156367-lto/bin/gcc -O1 -ftree-loop-linear
testcase.c -fcompare-debug
gcc: testcase.c: -fcompare-debug failure (length)

There is actually different code generated with -g, the outer loop isn't
removed. 4.4.2 generates the same code for both cases.


-- 
   Summary: [4.5 Regression] "-fcompare-debug failure" with -ftree-
loop-linear
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86(_64)-pc-linux-gnu
GCC target triplet: x86(_64)-pc-linux-gnu


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

[Bug tree-optimization/42917] [4.5 Regression] "-fcompare-debug failure" with -ftree-loop-linear

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-01-31 21:41 ---
Created an attachment (id=19767)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19767&action=view)
reduced testcase

Command line:
gcc -O1 -ftree-loop-linear -fcompare-debug -c pr42917.c


-- 


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

[Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670

[janus at gcc dot gnu dot org]

--- Comment #21 from janus at gcc dot gnu dot org  2010-01-31 21:56 ---
Subject: Bug 42888

Author: janus
Date: Sun Jan 31 21:56:02 2010
New Revision: 156418

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156418
Log:
gcc/fortran/
2010-01-31  Janus Weil  

PR fortran/42888
* resolve.c (resolve_allocate_expr): Move default initialization code
here from gfc_trans_allocate.
* trans.c (gfc_trans_code): Call gfc_trans_class_assign also for
EXEC_INIT_ASSIGN.
* trans-expr.c (gfc_trans_class_assign): Handle default initialization
of CLASS variables via memcpy.
* trans-stmt.c (gfc_trans_allocate): Move default initialization code
to resolve_allocate_expr.

gcc/testsuite/
2010-01-31  Janus Weil  

PR fortran/42888
* gfortran.dg/allocate_derived_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_derived_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/42917] [4.5 Regression] "-fcompare-debug failure" with -ftree-loop-linear

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670

[janus at gcc dot gnu dot org]

--- Comment #22 from janus at gcc dot gnu dot org  2010-01-31 22:01 ---
Fixed with r156418. Thanks for the report!


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/42918] New: "-fcompare-debug failure" with "-O2 -ftracer" (2)

[zsojka at seznam dot cz]

Command line:
gcc -O2 -ftracer -fcompare-debug -c testcase.c

Tested revisions:
r156367 - crash
r155609 - crash
r154830 - crash
r153685 - crash

Output:
$ /mnt/svn/gcc-trunk/binary-156367-lto/bin/gcc -O2 -ftracer -fcompare-debug -c
testcase.c
gcc: testcase.c: -fcompare-debug failure (length)


-- 
   Summary: "-fcompare-debug failure" with "-O2 -ftracer" (2)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86(_64)-pc-linux-gnu
GCC target triplet: x86(_64)-pc-linux-gnu


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

[Bug debug/42918] "-fcompare-debug failure" with "-O2 -ftracer" (2)

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-01-31 22:53 ---
Created an attachment (id=19768)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19768&action=view)
reduced testcase

Command line:
gcc -O2 -ftracer -fcompare-debug -c pr42918.c


-- 


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

[Bug middle-end/42919] New: [4.3/4.4/4.5 Regression] Argument unnecessarily spilled

[rguenth at gcc dot gnu dot org]

void foo(unsigned long long *x);
void testfunc2(unsigned long long a) { foo (&a); }

generates

testfunc2:
pushl   %ebp
movl%esp, %ebp
subl$40, %esp
movl8(%ebp), %eax
movl%eax, -16(%ebp)
movl12(%ebp), %eax
movl%eax, -12(%ebp)
leal-16(%ebp), %eax
movl%eax, (%esp)
callfoo
leave
ret

which is a lot worse to what compared to what 3.4 produced:

testfunc2:
pushl   %ebp
movl%esp, %ebp
leal8(%ebp), %eax
subl$8, %esp
movl%eax, (%esp)
callfoo
leave
ret


-- 
   Summary: [4.3/4.4/4.5 Regression] Argument unnecessarily spilled
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: i?86-*-*


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

[Bug middle-end/42919] [4.3/4.4/4.5 Regression] Argument unnecessarily spilled

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-31 22:56 ---
It also causes us to use more stack.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||3.3.6 4.3.4 4.4.3 4.5.0
  Known to work||2.95.2 3.4.6
   Last reconfirmed|-00-00 00:00:00 |2010-01-31 22:56:04
   date||
   Target Milestone|--- |4.3.5


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

[Bug middle-end/42919] [4.3/4.4/4.5 Regression] Argument unnecessarily spilled

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-01-31 22:57 ---
Weird that 3.3 fails but 3.4 works ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|3.3.6 4.3.4 4.4.3 4.5.0 |3.3.6 4.3.4 4.4.3 4.5.0
   ||4.0.1


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

[Bug ada/42554] Can't build gnatlink, gnatmake

[simon at pushface dot org]

--- Comment #4 from simon at pushface dot org  2010-01-31 22:58 ---
(In reply to comment #3)

> I'm not sure that deleting ../$(RTSDIR)/*.o before building common-tools will
> be OK in all circumstances, but it certainly works for a native Darwin build.
> The point is that by this stage all the libraries (???) will have been built;
> and we don't want gnatbind to pick up duplicate .o's from the rts directory
> (which it scans because of -I../rts).

After some discussion about this, in which the idea of deleting the RTSDIR
object files was frowned on (not to mention that there is at least one .o file
which needs to be retained in the RTSDIR), posted a patch at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01596.html Note that this patch's
Subject: refers to PR ada/42254 whereas it should of course be 42554.


-- 


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

[Bug c++/42920] New: gcc does not produce necessary vec_lvrx instructions

[ryan dot sammartino at gmail dot com]

In the following short program (preprocessed files will be attached), the
output is incorrect when compiled with

ppu-g++ -o bug -O3 bug.cpp -maltivec

I get the output:

0.00 1.00 2.00 3.00
0.00 0.00 0.00 7.00
0.00 0.00 0.00 30.00
0.00 0.00 0.00 15.00

I was expecting:

0.00 1.00 2.00 3.00
4.00 5.00 6.00 7.00
8.00 9.00 10.00 11.00
12.00 13.00 14.00 15.00


--- cut here ---
#include 
#include 

struct mat
{
vector float v0;
vector float v1;
vector float v2;
vector float v3;
};

vector float load_vec_unaligned(const float* a)
{
return vec_or(vec_lvlx(0, a), vec_lvrx(16, a));
}

mat load_unaligned(const float* a)
{
mat m;
m.v0 = load_vec_unaligned(a);
m.v1 = load_vec_unaligned(a+4);
m.v2 = load_vec_unaligned(a+8);
m.v3 = load_vec_unaligned(a+12);
return m;
}

int main()
{
__attribute__((aligned(16)))
float f[18] = {-12.0f,
   0.0f, 1.0f, 2.0f, 3.0f,
   4.0f, 5.0f, 6.0f, 7.0f,
   8.0f, 9.0f, 10.0f, 11.0f,
   12.0f, 13.0f, 14.0f, 15.0f,
   -12.0f};

const mat m = load_unaligned(&f[1]);

union { vector float v; float f[4]; } u;

u.v = m.v0;
printf("%f %f %f %f\n", u.f[0], u.f[1], u.f[2], u.f[3]);
u.v = m.v1;
printf("%f %f %f %f\n", u.f[0], u.f[1], u.f[2], u.f[3]);
u.v = m.v2;
printf("%f %f %f %f\n", u.f[0], u.f[1], u.f[2], u.f[3]);
u.v = m.v3;
printf("%f %f %f %f\n", u.f[0], u.f[1], u.f[2], u.f[3]);
}
--- cut here ---

For some reason, the load_unaligned function compiles correctly but something
goes wrong during inlining, as the vor instructions are not correct.

If I mark load_unaligned with __attribute__((noinline)), or compile with -O2, I
get the expected output.


-- 
   Summary: gcc does not produce necessary vec_lvrx instructions
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ryan dot sammartino at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: ppu


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

[Bug c++/42920] gcc does not produce necessary vec_lvrx instructions

[ryan dot sammartino at gmail dot com]

--- Comment #1 from ryan dot sammartino at gmail dot com  2010-01-31 23:00 
---
Created an attachment (id=19769)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19769&action=view)
Preprocessor output


-- 


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

[Bug c++/42920] gcc does not produce necessary vec_lvrx instructions

[ryan dot sammartino at gmail dot com]

--- Comment #2 from ryan dot sammartino at gmail dot com  2010-01-31 23:01 
---
Created an attachment (id=19770)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19770&action=view)
Assembler output


-- 


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

[Bug c++/42920] gcc does not produce necessary vec_lvrx instructions

[ryan dot sammartino at gmail dot com]

--- Comment #3 from ryan dot sammartino at gmail dot com  2010-01-31 23:02 
---
Gah... sorry for the incorrect summary, I got distracted while typing it. :(

It should say "... correct vec_or instructions".


-- 


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

[Bug target/42920] gcc does not produce necessary vec_lvrx instructions

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-01-31 23:18 ---
Actually can you paste the output of ppu-g++?  I think this has been fixed on
the trunk already.  Also can you try 4.4 which has Cell support in it, though I
cannot remember when I submitted the Cell Altivec support.  It might be only
included on the trunk.

I fixed at least a bug like this in the PS3 GCC based toolchain and made sure
that the fix made it into the FSF when I submitted the Cell Altivec support. 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING
  Component|c++ |target
  GCC build triplet|x86_64-linux-gnu|
   GCC host triplet|x86_64-linux-gnu|
 GCC target triplet|ppu |powerpc*-*-*
   Keywords||wrong-code


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

[Bug target/42920] gcc does not produce necessary vec_lvrx instructions

[ryan dot sammartino at gmail dot com]

--- Comment #5 from ryan dot sammartino at gmail dot com  2010-02-01 00:12 
---
(In reply to comment #4)
> Actually can you paste the output of ppu-g++?  

You mean -v, I hope:

$ ppu-g++ --v
Using built-in specs.
Target: ppu
Configured with: ../toolchain/gcc/configure --prefix=/usr/lib/cell/toolchain
--libexecdir=/usr/lib/cell/toolchain/lib --mandir=/usr/lib/cell/toolchain/man
--infodir=/usr/lib/cell/toolchain/info --with-sysroot=/usr/lib/cell/sysroot
--with-as=/usr/bin/ppu-as --with-ld=/usr/bin/ppu-ld --enable-threads
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-languages=c,c++,fortran --disable-nls
--enable-version-specific-runtime-libs --with-long-double-128
--disable-bootstrap --program-prefix=ppu- --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=ppu
Thread model: posix
gcc version 4.1.1

This is the latest available in Ubuntu repos (4.1.1r840-0ubuntu7).

> I think this has been fixed on
> the trunk already.  Also can you try 4.4 which has Cell support in it, though 
> I
> cannot remember when I submitted the Cell Altivec support.  It might be only
> included on the trunk.
> 

I'll try, but I'm getting to be a very lazy Linux user... if it ain't in Ubuntu
repos anymore, I can't remember how to build these things. :)

> I fixed at least a bug like this in the PS3 GCC based toolchain and made sure
> that the fix made it into the FSF when I submitted the Cell Altivec support. 

No, this is different.  I think I know the bug you're talking about and in that
case it was a problem with using something like &array[1] producing extra
splats.  In that case the fix was to use array+1 ... it doesn't fix it in this
case.


-- 


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

[Bug target/42920] gcc does not produce necessary vec_lvrx instructions

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-02-01 00:15 ---
No I have fixed a couple of these bugs before, trust me.  I will double check
the PS3 toolchain sources and see what happens in the PS3 toolchain.  Note I am
leaving sony friday so I will make sure that I finish it by Friday :).


-- 


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

[Bug middle-end/42919] [4.3/4.4/4.5 Regression] Argument unnecessarily spilled

[matz at gcc dot gnu dot org]

--- Comment #3 from matz at gcc dot gnu dot org  2010-02-01 00:21 ---
3.4 had this as initial RTL:

(insn 3 2 4 (set (reg:DI 60)
(mem/f:DI (reg/f:SI 53 virtual-incoming-args) [2 a+0 S8 A32])) -1 (nil)
(expr_list:REG_EQUIV (mem/f:DI (reg/f:SI 53 virtual-incoming-args)
 [2 a+0 S8 A32])
(nil)))

(insn 4 3 5 (set (mem/f:DI (addressof:SI (reg/v:DI 59) 58 0xf7c9a4a4)
 [2 a+0 S8 A64])
(reg:DI 60)) -1 (nil)
(nil))

(insn 15 7 16 0 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))

(insn 16 15 17 0 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A32])
(addressof:SI (reg/v:DI 59) 58 0xf7c9a4a4)) -1 (nil)
(nil))

(call_insn 17 16 19 0 (call (mem:QI (symbol_ref:SI ("foo") [flags 0x41]
 ) [0 S1 A8])
(const_int 16 [0x10])) -1 (nil)
(nil) (nil))

addressof RTL and handling was removed in 2004, but was our way of making this
optimization on RTL.  So this would now need to be implemented in expand
or something :-/  Well, or by implementing some more memory optimizations
on RTL (recognizing that mem1 has same content as mem2, and using &mem1 where
&mem2 was used and the former somehow is "better").  Not committing to MEM
to start with would be better, obviously.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||matz at gcc dot gnu dot org


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

[Bug tree-optimization/42916] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops -ftree-vectorize"

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-02-01 00:46 ---
Created an attachment (id=19771)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19771&action=view)
reduced testcase, better yet longer

This one doesn't need -m32, and fails with both -O1 and -O2

Command line:
gcc -O1 -funroll-loops -ftree-vectorize -fcompare-debug -c pr42916-2.c
or
gcc -O2 -funroll-loops -ftree-vectorize -fcompare-debug -c pr42916-2.c


-- 


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

[Bug middle-end/39193] Internal compiler error during FreeBSD 7.1 kernel compilation

[cyberleo at cyberleo dot net]

--- Comment #13 from cyberleo at cyberleo dot net  2010-02-01 01:39 ---
Alas, it would seem that, due to licensing issues, newer GCC versions are
unsupported for building the FreeBSD base system.

For note, I managed to get this section to compile with my chosen optimization
flags (-Os -march=c3-2) by removing -Werror (the default) and -Wno-error (to
get past errors from unused results and failed inlining earlier in the kernel
build).


-- 


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

[Bug middle-end/42898] [4.5 Regression] volatile structures and compound literal initializers

[howarth at nitro dot med dot uc dot edu]

--- Comment #15 from howarth at nitro dot med dot uc dot edu  2010-02-01 
01:47 ---
The new gcc.dg/torture/pr42898.c fails on x86_64-apple-darwin10...

FAIL: gcc.dg/torture/pr42898.c  -O1  scan-tree-dump-times optimized "\*ptr" 1
FAIL: gcc.dg/torture/pr42898.c  -O2  scan-tree-dump-times optimized "\*ptr" 1
FAIL: gcc.dg/torture/pr42898.c  -O3 -fomit-frame-pointer  scan-tree-dump-times
optimized "\*ptr" 1
FAIL: gcc.dg/torture/pr42898.c  -O3 -g  scan-tree-dump-times optimized "\*ptr"
1
FAIL: gcc.dg/torture/pr42898.c  -Os  scan-tree-dump-times optimized "\*ptr" 1


-- 


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

[Bug middle-end/42898] [4.5 Regression] volatile structures and compound literal initializers

[howarth at nitro dot med dot uc dot edu]

--- Comment #16 from howarth at nitro dot med dot uc dot edu  2010-02-01 
01:50 ---
Created an attachment (id=19772)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19772&action=view)
assembly for gcc.dg/torture/pr42898.c  -O1 on x86_64-apple-darwin10

/sw/src/fink.build/gcc45-4.4.999-20100131/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20100131/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20100131/gcc-4.5-20100131/gcc/testsuite/gcc.dg/torture/pr42898.c
-O1 -fdump-tree-optimized -S -o pr42898.s


-- 


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

[Bug middle-end/42898] [4.5 Regression] volatile structures and compound literal initializers

[howarth at nitro dot med dot uc dot edu]

--- Comment #17 from howarth at nitro dot med dot uc dot edu  2010-02-01 
01:54 ---
Created an attachment (id=19773)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19773&action=view)
.optimized for gcc.dg/torture/pr42898.c  -O1 on x86_64-apple-darwin10


-- 


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

[Bug middle-end/42919] [4.3/4.4/4.5 Regression] Argument unnecessarily spilled

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2010-02-01 02:41 ---
Well, actually it depends.  The code generated by 3.4 might theoretically
be slower, because it potentially uses a misaligned stack slot (incoming
stack with -m32 only 4 byte aligned).  With -mpreferred-stack-boundary=2 also
newer compilers use the incoming stack slot instead of copying it around.

When we determined we need a stack slot, the flow is like so: when the slot
alignment (32bits) is not known to be enough for it's declared type (64 bits
here), _and_ the preferred stack alignment (128 per default in new compilers)
is larger than the known slot alignment, then allocate a new stack slot.

"allocate a new stack slot" is what differs between old and new compilers.
New compilers will simply, well, allocate a new slot :)  Old compilers will
only use ADDRESSOF (if the type itself can otherwise be placed into
registers), a kind of deferred stack slot allocation to wait if the 
address really needs to be taken (in new compilers this is always the case,
because we can rely on TREE_ADDRESSABLE).  If it turns out to be necessary,
then it will reuse the stack slot, possibly misaligned (and the latter could
be regarded as bug).

If the 3.4 compiler also would check for alignment in the new way (it only
did so for STRICT_ALIGNMENT targets), it too wouldn't have used the incoming
stack slot.

This additional checking (not only for STRICT_ALIGNMENT targets) came in
as fix for PR18916 (that was after ADDRESSOF was removed already, otherwise
that fix would have affected that code too).

So, I think, everything works as intended, as long as the alignment facts are
as they are:
* long long is 64 aligned
* incoming stack is 32 aligned
* preferred alignment is 128 (and that this matters seems fishy too)

One might argue that this should only matter for STRICT_ALIGNMENT targets,
and therefore that ppc (ref PR18916) is such target.  But that was altivec
code.  And with such code (SSE) x86 also is sort of a STRICT_ALIGNMENT target.


-- 


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

[Bug middle-end/42919] [4.3/4.4/4.5 Regression] Argument unnecessarily spilled

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2010-02-01 02:53 ---
He, Alan already conjectured this problem:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01182.html


-- 


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

[Bug middle-end/42898] [4.5 Regression] volatile structures and compound literal initializers

[matz at gcc dot gnu dot org]

--- Comment #18 from matz at gcc dot gnu dot org  2010-02-01 03:13 ---
See comment #11


-- 


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

[Bug middle-end/39193] Internal compiler error during FreeBSD 7.1 kernel compilation

[kargl at gcc dot gnu dot org]

--- Comment #14 from kargl at gcc dot gnu dot org  2010-02-01 03:31 ---
(In reply to comment #13)
> Alas, it would seem that, due to licensing issues, newer GCC versions are
> unsupported for building the FreeBSD base system.

The above isn't exactly true.  No one has stepped forward to integrate
newer versions of gcc into the base system.  If you decided to do the 
work, I suspect the FreeBSD committers would be interested in your
work.  You simply need to introduce "make -DWITHOUT_GPLV3" into
Makefile.inc1 and isolated the problematic licensed code.

> For note, I managed to get this section to compile with my chosen optimization
> flags (-Os -march=c3-2) by removing -Werror (the default) and -Wno-error (to
> get past errors from unused results and failed inlining earlier in the kernel
> build).

I've already stated that the FreeBSD documentation clearly states
that only -O and -O2 are supported optimizations.  Any other 
choice is unsupported (see make.conf(5)).  

Groucho: "Doctor, it hurts when I do this."
Doctor:  "Well, don't do that."


-- 


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

[Bug preprocessor/42921] New: No error with missing header and -MM

[rhansen at bbn dot com]

The -MM option does not raise an error if the source includes a non-existent
header using angle brackets:

$ echo "#include " > foo.c
$ gcc -MM -MF foo.d foo.c && echo succeeded || echo failed
succeeded
$ cat foo.d
foo.o: foo.c

Including a file using double quotes does produce an error as expected:

$ echo '#include "does_not_exist.h"' > foo.c
$ gcc -MM -MF foo.d foo.c && echo succeeded || echo failed
foo.c:1:28: fatal error: does_not_exist.h: No such file or directory
compilation terminated.
failed

Seen in current trunk:
$ gcc -v
Using built-in specs.
COLLECT_GCC=./install/bin/gcc
COLLECT_LTO_WRAPPER=/home/rhansen/gcc_build/install/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/rhansen/gcc_build/install
--with-local-prefix=/home/rhansen/gcc_build/install --enable-languages=c
Thread model: posix
gcc version 4.5.0 20100131 (experimental) [trunk revision 156418] (GCC)

And in 4.4.1 from Ubuntu Karmic:
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)


-- 
   Summary: No error with missing header and -MM
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rhansen at bbn dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

gcc source code

[Dileepkumarvarma]

Hi i want to analyze gcc source code for my project. any body can give em the
source code. If possible documentation for the code. Please give me the code
and doc pleasee


Regards 
Dileep 
-- 
View this message in context: 
http://old.nabble.com/gcc-source-code-tp27399511p27399511.html
Sent from the gcc - bugs mailing list archive at Nabble.com.