[Bug ada/19219] ICE on legal (?) code: deriving from tagged type with unknown discriminants
--- Comment #2 from baldrick at gcc dot gnu dot org 2006-12-01 08:08 --- Fixed in current version. FI: this was ACT bug E103-008. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19219
[Bug middle-end/19410] Overlapping memcpy with big struct copies
--- Comment #10 from baldrick at gcc dot gnu dot org 2006-12-01 08:31 --- None of the examples provided in this bug report generate an overlapping memcpy with current gcc. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410
[Bug ada/19413] ACATS c761010 - valgrind detects wrong code (Conditional jump or move depends on uninitialised value)
--- Comment #2 from baldrick at gcc dot gnu dot org 2006-12-01 08:38 --- Does not occur with current gcc. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19413
[Bug ada/19415] ACATS c953001 - valgrind detects wrong code (invalid read)
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 08:43 --- Does not happen with current gcc. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19415
[Bug ada/30036] ICE using interfaces: Assert_Failure sem_util.adb:1033
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 09:07 --- While this doesn't happen with GNAT-GPL 2006 or GNAT Pro 5.05w (20060118), that's not surprising because they are compiled with --disable-checking. Here are the details of the compiler for which I get this ICE: $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr/gnat-fsf --enable-languages=all,ada --enable-threads=posix Thread model: posix gcc version 4.3.0 20061128 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30036
[Bug ada/30037] New: Value assigned to array element in record always '0'
Please find below ada code that compiles and executes on 2 machines with
different gcc versions
Machine1 has gcc 3.3.3 and compiles and executes correctly
Machine2 has gcc 4.1.1 and compiles without warnings. It executes but produces
the wrong result. As you can see the code zeroes SL(1) and SL(2).
In both cases the command line is "gnatmake -Wall test" where the code extract
below is in test.adb
#This works
Linux machine1.domain 2.6.10-1.771_FC2smp #1 SMP Mon Mar 28 01:10:51 EST 2005
i686 athlon i386 GNU/Linux
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
#Program output
How to set Valid to TRUE, Method 1
Config_Message_Buffer = SL1= 100 SL2= 100 Valid=FALSE
Config_Message_Buffer = SL1= 100 SL2= 100 Valid=TRUE
How to set Valid to TRUE, Method 2
Config_Message_Buffer = SL1= 100 SL2= 100 Valid=FALSE
Config_Message_Buffer = SL1= 100 SL2= 100 Valid=TRUE
#This doesn't!
Linux machine2.domain 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006
i686 i686 i386 GNU/Linux
gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
#Program output
How to set Valid to TRUE, Method 1
Config_Message_Buffer = SL1= 100 SL2= 100 Valid=FALSE
Config_Message_Buffer = SL1= 0 SL2= 0 Valid=TRUE
How to set Valid to TRUE, Method 2
Config_Message_Buffer = SL1= 100 SL2= 100 Valid=FALSE
Config_Message_Buffer = SL1= 100 SL2= 100 Valid=TRUE
--
#Code
with text_io;
procedure test is
type Data_Type_A_Range is range 100 .. 200;
type Data_Type_A is array (1..2) of Data_Type_A_Range;
-- this record would have several declarations inside.
-- for this example I have cut it down to a single one called SL
type Config_Message_Type is
record
SL : Data_Type_A;
end record;
-- Defines the configuration message buffer type
type Config_Message_Buffer_Type is
record
Data : Config_Message_Type;
Valid : Boolean;
end record;
-- Defines the default configuration message buffer
Default_Config_Message_Buffer : constant Config_Message_Buffer_Type :=
Config_Message_Buffer_Type'
(Data => Config_Message_Type'(SL => Data_Type_A'(others =>
Data_Type_A_Range'first)),
Valid => False);
-- define 2 variables and set them both to the same default value
Config_Message_Buffer1 : Config_Message_Buffer_Type :=
Default_Config_Message_Buffer;
Config_Message_Buffer2 : Config_Message_Buffer_Type :=
Default_Config_Message_Buffer;
procedure dump_message_buffer (CMB : Config_Message_Buffer_Type) is
begin
text_io.put("Config_Message_Buffer = ");
text_io.put("SL1=" & Data_Type_A_Range'image(CMB.Data.SL(1)) & " ");
text_io.put("SL2=" & Data_Type_A_Range'image(CMB.Data.SL(2)) & " ");
text_io.put("Valid=" & boolean'image(CMB.Valid) & " ");
text_io.new_line;
end;
begin
text_io.put_line ("How to set Valid to TRUE, Method 1");
dump_message_buffer(Config_Message_Buffer1);
-- when Config_Message_Type has several declarations some are altered some
aren't
-- this is an example of a one that isnt changed and should set itself to
itself
Config_Message_Buffer1 := Config_Message_Buffer_Type'
(Data => Config_Message_Type'(SL => Config_Message_Buffer1.Data.SL),
Valid => True);
dump_message_buffer(Config_Message_Buffer1);
text_io.put_line ("How to set Valid to TRUE, Method 2");
dump_message_buffer(Config_Message_Buffer2);
Config_Message_Buffer2.Valid := True;
dump_message_buffer(Config_Message_Buffer2);
end test;
#End Code
-
--
Summary: Value assigned to array element in record always '0'
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: junk2 at fieldhome dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30037
[Bug tree-optimization/30038] New: Call to sin(x), cos(x) should be transformed to sincos(x)
See also: http://gcc.gnu.org/ml/fortran/2006-12/msg0.html Tim Prince's analysis why ifort needs 8.77s and gfortran 12.16s for one program: "My copy of gfortran makes separate scalar calls to sin and cos, where ifort makes a vector sincos call. 2 seconds to be gained there" In the Fortran program below, a there is a call to the same argument with sin and with cos. The resulting gfortran -msse3 -march=opteron -ffast-math -O3 -c -fdump-tree-optimized shows pretmp.56 = __builtin_sinf (pretmp.80); pretmp.86 = __builtin_cosf (pretmp.80); Using sincos should be faster. Fortran program: subroutine test(number_of_sample_points,radius,coefficient,radius_of_curvature,spin_frequency,time,tmp) implicit none integer :: number_of_sample_points real, parameter :: twopi = 6.28319 integer :: n real :: radius(number_of_sample_points), coefficient, radius_of_curvature, & spin_frequency,time,tmp(2,number_of_sample_points) do n = 1, number_of_sample_points coefficient = (radius(n) / radius_of_curvature) * sin(twopi *& spin_frequency * time) tmp(1,n) = coefficient coefficient = twopi * spin_frequency * (radius(n) / & radius_of_curvature) * cos(twopi * & spin_frequency * time) tmp(2,n) = coefficient end do end subroutine -- Summary: Call to sin(x), cos(x) should be transformed to sincos(x) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization 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=30038
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- Comment #1 from ubizjak at gmail dot com 2006-12-01 10:14 --- Depends on PR tree_optimization/17687. I guess it is a time to finally resolve that one... -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com BugsThisDependsOn||17687 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-01 10:14:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- Comment #2 from bonzini at gnu dot org 2006-12-01 10:57 --- Not only that; the glibc sincos, for example, would not gain anything. ifort gains because it basically computes the sine and cosine using two halves of an XMM register. Richard had a really gross ;-) patch to do this. -- bonzini at gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- Comment #3 from bonzini at gnu dot org 2006-12-01 11:04 --- We need multiple steps here to solve this bug and 17687: 1) change sincos (x, &s, &c) to sincos (x, &t1, &t2); s = t1; c = t2; Don't know the best place to do this. 2) alternatively, change sincos (x, &s, &c) to v2df = vec_sincos (x) *s = v2df[0] *c = v2df[1] This needs to be done at tree->rtl expansion time, because we don't have access to v2df[N] at tree level. 3) perform strength reduction of sin+cos to sincos. I believe it has to be done in a special pass (like CSE reciprocals), and that's actually why the file was named tree-ssa-_math-opts_.c rather than tree-ssa-recip.c. This could be the place to do (1) too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug c++/30033] ICE on valid with --std=c++0x (static_assert)
--- Comment #5 from pedro dot lamarao at mndfck dot org 2006-12-01 11:37 --- Ah, just as I thought, but I was too sleepy to find about that function on my own. Must someone present this to gcc-patches or will you do it yourself? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30033
[Bug bootstrap/30008] bootstrapping failure: multiple function definitions
--- Comment #3 from dfranke at gcc dot gnu dot org 2006-12-01 11:41 --- *** This bug has been marked as a duplicate of 29867 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30008
[Bug target/29867] [4.3 Regression] building libgfortran fails because of multiple definitions gcc-4.3-20061111
--- Comment #7 from dfranke at gcc dot gnu dot org 2006-12-01 11:41 --- *** Bug 30008 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||franke dot daniel at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
[Bug middle-end/29947] OpenMP parallel for fails for reversed loop range
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-11-22 22:11:45 |2006-12-01 12:14:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29947
[Bug tree-optimization/30032] sqrt(CGAMMA*PRES[j]/DENS[j]) much slower than competing compiler
--- Comment #7 from burnus at gcc dot gnu dot org 2006-12-01 12:17 --- I wonder whether this is bug is not identically to PR 21466 "sqrt() function not vectorized" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30032
[Bug target/29512] compile time hog / deadloop.
--- Comment #14 from pluto at agmk dot net 2006-12-01 12:24 --- no backport to 4.1/4.2 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug tree-optimization/30032] sqrt(CGAMMA*PRES[j]/DENS[j]) much slower than competing compiler
--- Comment #8 from burnus at gcc dot gnu dot org 2006-12-01 12:25 --- > I wonder whether this is bug is not identically to > PR 21466 "sqrt()function not vectorized" I mean for the Fortran test case: gastest.f90:8: note: LOOP VECTORIZED. gastest.f90:9: note: LOOP VECTORIZED. gastest.f90:23: note: Alignment of access forced using peeling. gastest.f90:23: note: Vectorizing an unaligned access. gastest.f90:23: note: Vectorizing an unaligned access. gastest.f90:23: note: not vectorized: relevant stmt not supported: D.1502_76 = __builtin_sqrtf (D.1501_75) The VLA -> normal array for C should be a different issue, where gcc could improve. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30032
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #10 from pault at gcc dot gnu dot org 2006-12-01 13:16 --- Created an attachment (id=12722) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12722&action=view) This patch fixes the testcase of #6 and regtests on Cygwin_NT/PIV Joost, I am not sure that I see how the test case in #6 can ever have worked; if it is indeed representative of the code in CP2K, I do not see how that can have worked either. I have been back through the diffs for expr (find_array_section) since I wrote it to fix PR16206 - it has had this error in it from the start. The bright side is that it is a one liner:-) Are you in a position to try the patch on CP2K? Regards Paul PS I should thank you; your PRs have given me something absorbing to do during what turned out to be a personally difficult year or so! -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/30039] New: HPPA: Incorrect code generated on 64bit host
Use of long long constants produces incorrect code when cross compiling for the hppa target on a 64 bit host $ hppa--linux-gcc -v Using built-in specs. Target: hppa--linux Configured with: /home/nick/gnu/gcc/configure --target=hppa--linux --prefix=/home/nick/gnu/path --enable-languages=c : (reconfigured) /home/nick/gnu/gcc/configure --target=hppa--linux --prefix=/home/nick/gnu/path --enable-languages=c Thread model: posix gcc version 4.1.2 20061021 (prerelease) (NetBSD nb1 20061021) $ hppa--linux-gcc -mpa-risc-1-1 -msoft-float -mdisable-fpregs -S test3.i -o test3.s $ cat test3.s .LEVEL 1.1 .text .align 4 .globl foo .type foo, @function foo: .PROC .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3 .ENTRY copy %r3,%r1 copy %r30,%r3 stwm %r1,64(%r30) ldil L'1221929280,%r29 ldi 0,%r28 ldo R'1221929280(%r29),%r29 stw %r28,8(%r3) stw %r29,12(%r3) ldw 8(%r3),%r19 ldw 12(%r3),%r20 extru %r19,31,28,%r28 extru %r20,31,32,%r29 ldo 64(%r3),%r30 ldwm -64(%r30),%r3 bv,n %r0(%r2) .EXIT .PROCEND .size foo, .-foo .ident "GCC: (GNU) 4.1.2 20061021 (prerelease) (NetBSD nb1 20061021)" $ -- Summary: HPPA: Incorrect code generated on 64bit host Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skrll at netbsd dot org GCC build triplet: sparc64--netbsd GCC host triplet: sparc64--netbsd GCC target triplet: hppa--linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30039
[Bug target/30039] HPPA: Incorrect code generated on 64bit host
--- Comment #1 from skrll at netbsd dot org 2006-12-01 13:40 --- Created an attachment (id=12723) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12723&action=view) reduced test case from netbsd src/sys/kern/kern_uuid.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30039
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #13 from hjl at gcc dot gnu dot org 2006-12-01 14:49 --- Subject: Bug 29921 Author: hjl Date: Fri Dec 1 14:49:15 2006 New Revision: 119401 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119401 Log: 2006-12-01 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/29921 * tree-ssa-ccp.c (canonicalize_float_value): New function. (set_lattice_value): Use canonicalize_float_value. 2006-12-01 H.J. Lu <[EMAIL PROTECTED]> Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/29921 * gcc.dg/pr29921-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr29921-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #14 from hjl at lucon dot org 2006-12-01 14:51 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug target/30040] New: [4.2/4.3]: -mtune=native is wrong on Core 2 Duo and Core Duo
On Core 2 Duo, I got [EMAIL PROTECTED] tmp]$ /usr/gcc-4.2/bin/gcc -mtune=native -S x.i -v ... /usr/gcc-4.2/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1 -fpreprocessed x.i -mtune=nocona -quiet -dumpbase x.i -auxbase x -version -o x.s ... On Core Duo, I got [EMAIL PROTECTED] tmp]$ /usr/gcc-4.2/bin/gcc -mtune=native -S x.i -v ... /usr/gcc-4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -fpreprocessed x.i -mtune=prescott -quiet -dumpbase x.i -auxbase x -version -o x.s -- Summary: [4.2/4.3]: -mtune=native is wrong on Core 2 Duo and Core Duo Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: hjl at lucon dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30040
[Bug ada/19416] ACATS cxa9001, cxa9002 - valgrind detects wrong code (unitialized data passed to syscall)
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 15:24 --- The uninitialized bytes are normal: the Unit_Type structure is 16 bytes long: type Unit_Type is record Position : Natural := 19; String_Value : String (1..9) := (others => 'X'); end record; but only 13 of the bytes are used. The 3 trailing bytes are not initialized. This seems to be GNAT policy. The uninitialized bytes are written to the file when Unit_Type is. Valgrind complains about this, and indeed it is a security leak. However I don't think it can be described as a compiler bug. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19416
[Bug testsuite/30041] New: FAIL: gcc.target/i386/sse3-movddup.c (internal compiler error)
When bootstrapping GCC trunk on Solaris 10 x86, sse3-movddup.c gives an ICE.
However, this test shouldn't even be running since I don't think my CPU has
sse3.
dev-zero:{bretta}$ isainfo -v
64-bit amd64 applications
sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc
fpu
32-bit i386 applications
sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc
fpu
Here's the output when compiling sse3-movddup.c
dev-zero:{bretta}$ /u01/var/tmp/gcc_trunk_svn/gcc_20061201/gcc/xgcc
-B/u01/var/tmp/gcc_trunk_svn/gcc_20061201/gcc/
/u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.target/i386/sse3-movddup.c
-O2 -msse3 -fno-show-column -lm -o ./sse3-movddup.exe
/u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.target/i386/sse3-movddup.c: In
function 'main':
/u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.target/i386/sse3-movddup.c:21:
internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: FAIL: gcc.target/i386/sse3-movddup.c (internal compiler
error)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brett dot albertson at stratech dot com
GCC build triplet: i386-pc-solaris2.10
GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30041
[Bug c++/29066] ptrmemfunc_vbit_in_delta is broken
--- Comment #5 from paolo at gcc dot gnu dot org 2006-12-01 15:55 --- Subject: Bug 29066 Author: paolo Date: Fri Dec 1 15:55:11 2006 New Revision: 119403 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119403 Log: 2006-12-01 Ryan Mansfield <[EMAIL PROTECTED]> PR c++/29066 * typeck.c (build_binary_op): Fix pointer to member function comparison for ptrmemfunc_vbit_in_delta targets. 2006-12-01 Ryan Mansfield <[EMAIL PROTECTED]> PR c++/29066 * g++.dg/expr/pr29066.c: New. Added: trunk/gcc/testsuite/g++.dg/expr/pr29066.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29066
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-01 16:00 --- My gross patch will still work ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-12-01 16:03 --- Btw, the "gross" patch is attached to PR17687. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug target/29512] compile time hog / deadloop.
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-12-01 16:04 --- Not a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-12-01 16:37 --- Subject: Bug 29433 Author: rguenth Date: Fri Dec 1 16:37:38 2006 New Revision: 119404 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119404 Log: 2006-12-01 Richard Guenther <[EMAIL PROTECTED]> PR c++/29433 * dwarf2out.c (struct pubname_struct): Make name const. (add_pubtype): Do not xstrdup identifiers. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-12-01 16:38 --- Improved for the case of building with -g, which should now be as bad as with plain -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #11 from burnus at gcc dot gnu dot org 2006-12-01 17:20 --- Created an attachment (id=12724) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12724&action=view) test case for interface "bl_copy" (In reply to comment #10) > This patch fixes the testcase of #6 and regtests on Cygwin_NT/PIV Tested on x86_64-unknown-linux-gnu and I get no ICE for both the test case in comment 6 as for all_cp2k_gfortran.f90.gz of comment 0. For all_cp2k_gfortran.f90, however, I get an error (after 2min compiling): all_cp2k_gfortran.f90:418697.22: USE f77_blas_generic 1 Error: Name 'bl_copy' at (1) is an ambiguous reference to 'bl_copy' from current program unit This is an error (see attachment) since the 'bl_copy' is only enhanced by the second "interface bl_copy" (happily accepted by ifort, g95 and NAG f95). I think even if one copies the sdcopy definition from f77_blas_extra to f77_blas_generic this shouldn't be an error as long as one does not access 'bl_copy' (f95 and ifort accept this; g95 rejects it). I tried compiling all_cp2k_gfortran.f90.gz with ifort, but I get after 4 minutes using "ifort -O0": Fatal compilation error: Out of memory asking for 33558536. And g95 (after using VIRT=3GB of memory for 7m [on a 2GB system]): virtual memory exhausted: Cannot allocate memory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c++/30042] New: ICE on invalid code
g++ --save-temps -W -Wall bug.cc bug.cc: In function `void p(T&)': bug.cc:10: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/ccGdoZOR.out file, please attach this to your bugreport. -- Summary: ICE on invalid code Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30042
[Bug c++/30042] ICE on invalid code
--- Comment #1 from bagnara at cs dot unipr dot it 2006-12-01 17:25 --- Created an attachment (id=12725) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12725&action=view) The file g++ asked me to attach. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30042
[Bug c++/29066] ptrmemfunc_vbit_in_delta is broken
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-01 18:04 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29066
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-01 18:05 --- (In reply to comment #5) > Btw, the "gross" patch is attached to PR17687. If you mean attachment (id=12055; patch using cexp) then note that it no longer applies cleanly: 2 out of 5 hunks FAILED -- saving rejects to file builtins.c.rej 1 out of 2 hunks FAILED -- saving rejects to file expr.c.rej -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug c++/30033] ICE on valid with --std=c++0x (static_assert)
--- Comment #6 from pinskia at gmail dot com 2006-12-01 18:19 --- Subject: Re: ICE on valid with --std=c++0x (static_assert) On Fri, 2006-12-01 at 11:37 +, pedro dot lamarao at mndfck dot org wrote: > Must someone present this to gcc-patches or will you do it yourself? I am going to do it but during this weekend. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30033
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #15 from elizabeth dot l dot yip at boeing dot com 2006-12-01 20:24 --- One of my colleaques said my test code in Bug 30025 works on his MAC OS X system at home. He has an older version of gfortran. Here is what he wrote: It worked using gfortran on my OS X system. ~/src/C_C++ $ gfortran -v Using built-in specs. Target: powerpc-apple-darwin7.9.0 Configured with: ../gcc/configure --prefix=/usr/local/gfortran --enable- languages=c,fortran --with-gmp=/tmp/gfortran-20060129/gfortran_libs -- with-mpfr=/tmp/gfortran-20060129/gfortran_libs --disable-libssp -- disable-libmudflap --disable-nlsThread model: posix gcc version 4.2.0 20060129 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug tree-optimization/30032] sqrt(CGAMMA*PRES[j]/DENS[j]) much slower than competing compiler
--- Comment #9 from ubizjak at gmail dot com 2006-12-01 20:54 --- (In reply to comment #8) > > I wonder whether this is bug is not identically to > > PR 21466 "sqrt()function not vectorized" Have you tried patch at http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01819.html? > The VLA -> normal array for C should be a different issue, where gcc could > improve. Could you open a new bug for this problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30032
[Bug java/29495] [ecj] some field & method flags not passed through
-- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-18 22:23:13 |2006-12-01 20:54:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29495
[Bug rtl-optimization/29840] [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump)
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-01 21:01 --- Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 MRO > No problem. If the compiler is not being miscompiled, I will be able to > look at it with a cross. Good luck! The ICE is here: (gdb) bt #0 forward_propagate_into (use=0x4011b258) at ../../gcc/gcc/fwprop.c:888 #1 0x0038796c in fwprop_addr () at ../../gcc/gcc/fwprop.c:1016 #2 0x0026a704 in execute_one_pass (pass=0x40012bcc) at ../../gcc/gcc/passes.c:871 #3 0x0026a8ac in execute_pass_list (pass=0x40012bcc) at ../../gcc/gcc/passes.c:918 #4 0x0026a8c0 in execute_pass_list (pass=0x40011420) at ../../gcc/gcc/passes.c:919 #5 0x000c73fc in tree_rest_of_compilation (fndecl=0x7ad35070) at ../../gcc/gcc/tree-optimize.c:463 #6 0x00039508 in c_expand_body (fndecl=0x7ad35070) at ../../gcc/gcc/c-decl.c:6855 #7 0x0029622c in cgraph_expand_function (node=0x7ad351c0) at ../../gcc/gcc/cgraphunit.c:1241 #8 0x00299798 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1306 #9 0x00041b50 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7968 #10 0x00236610 in toplev_main (argc=1073924712, argv=0x1) at ../../gcc/gcc/toplev.c:1046 #11 0x000aacfc in main (argc=2059796228, argv=0x7ade4334) at ../../gcc/gcc/main.c:35 DF_REF_INSN (def) is 0. It looks like the ICE can be avoided by a check on def_insn. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #32 from tkoenig at gcc dot gnu dot org 2006-12-01 21:04 --- Subject: Bug 29568 Author: tkoenig Date: Fri Dec 1 21:04:38 2006 New Revision: 119412 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119412 Log: 2006-12-01 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/29568 * gfortran.dg/convert_implied_open.f90: Change to new default record length. * gfortran.dg/unf_short_record_1.f90: Adapt to new error message. * gfortran.dg/unformatted_subrecords_1.f90: New test. 2006-12-01 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/29568 * gfortran.h (gfc_option_t): Add max_subrecord_length. (top level): Define MAX_SUBRECORD_LENGTH. * lang.opt: Add option -fmax-subrecord-length=. * trans-decl.c: Add new function set_max_subrecord_length. (gfc_generate_function_code): If we are within the main program and max_subrecord_length has been set, call set_max_subrecord_length. * options.c (gfc_init_options): Add defaults for max_subrecord_lenght, convert and record_marker. (gfc_handle_option): Add handling for -fmax_subrecord_length. * invoke.texi: Document the new default for -frecord-marker=. 2006-12-01 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/29568 * libgfortran/libgfortran.h (compile_options_t): Add record_marker. (top level): Define GFC_MAX_SUBRECORD_LENGTH. * runtime/compile_options.c (set_record_marker): Change default to four-byte record marker. (set_max_subrecord_length): New function. * runtime/error.c (translate_error): Change error message for short record on unformatted read. * io/io.h (gfc_unit): Add recl_subrecord, bytes_left_subrecord and continued. * io/file_pos.c (unformatted_backspace): Change default of record marker size to four bytes. Loop over subrecords. * io/open.c: Default recl is max_offset. If compile_options.max_subrecord_length has been set, set set u->recl_subrecord to its value, to the maximum value otherwise. * io/transfer.c (top level): Add prototypes for us_read, us_write, next_record_r_unf and next_record_w_unf. (read_block_direct): Separate codepaths for unformatted direct and unformatted sequential. If a recl has been set by the user, use the number of bytes left for the record if it is smaller than the read request. Loop over subrecords. Set an error if the user has set a recl and the read was short. (write_buf): Separate codepaths for unformatted direct and unformatted sequential. If a recl has been set by the user, use the number of bytes left for the record if it is smaller than the read request. Loop over subrecords. Set an error if the user has set a recl and the read was short. (us_read): Add parameter continued (to indicate that bytes_left should not be intialized). Change default of record marker size to four bytes. Use subrecord. If the subrecord length is smaller than zero, this indicates a continuation. (us_write): Add parameter continued (to indicate that the continued flag should be set). Use subrecord. (pre_position): Use 0 for continued on us_write and us_read calls. (skip_record): New function. (next_record_r_unf): New function. (next_record_r): Use next_record_r_unf. (write_us_marker): Default size for record markers is four bytes. (next_record_w_unf): New function. (next_record_w): Use next_record_w_unf. Added: trunk/gcc/testsuite/gfortran.dg/unformatted_subrecord_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/convert_implied_open.f90 trunk/gcc/testsuite/gfortran.dg/unf_short_record_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/compile_options.c trunk/libgfortran/runtime/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #33 from tkoenig at gcc dot gnu dot org 2006-12-01 21:18 --- Fixed on trunk. I'll be waiting for some time for any regressions before backporting to 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug c/30043] New: __attribute__((nonull(...))) and silent optimizations
when a coder writes (erroneously) such a code:
char *m_strrtrim(char *s) __attribute__((nonull(1));
char *m_strrtrim(char *s)
{
int len = s ? strlen(s) : 0;
while (len > 1 && isspace((unsigned char)s[len - 1]))
len--;
return s + len;
}
Then gcc uses the __attribute__((nonnull(1)) — which again is a
programming mistake — to optimize the check of s beeing NULL or not. That
is very correct from a compiling point of view, but it generated segfaults in
my code, that I had a very hard time to find, because of it beeing in the
header file rather than in the implementation where I looked for it (as the
backtrace pointed me in that function).
I suppose that gcc do the optimization because it knows that 's' is non NULL,
though it should make a distinction between s beeing non NULL because it knows
so (e.g. because s is a local buffer) or because it comes from a programmer
assertion.
When it's the latter, it should warn about any trivial test, like it does when
you test if an unsigned int is greater or equal to 0 for example. What I mean
is that:
__attribute__((nonull(1))) void foo(char *s) {
if (!s) {
if (!s) {
// do sth;
}
}
}
here, the first test on s SHOULD NOT be optimized silently, because at this
point s is marked as beeing NONNNUL thanks to a /programmer/ assertion, not
constant folding. I don't know for the second though, maybe it's worth to warn,
maybe not.
--
Summary: __attribute__((nonull(...))) and silent optimizations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: madcoder at debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c++/30021] [4.3 regression] ICE on invalid parameter for main
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-12-01 21:28 --- Subject: Bug 30021 Author: reichelt Date: Fri Dec 1 21:28:35 2006 New Revision: 119415 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119415 Log: PR c++/30021 * c-common.c (check_main_parameter_types): Check for error_mark_node. * g++.dg/other/main1.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/main1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30021
[Bug c++/30021] [4.3 regression] ICE on invalid parameter for main
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-12-01 21:29 --- Fixed on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30021
[Bug c++/30022] [4.0/4.1/4.2/4.3 regression] ICE on vector operand in division
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-12-01 21:35 --- Subject: Bug 30022 Author: reichelt Date: Fri Dec 1 21:35:25 2006 New Revision: 119416 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119416 Log: PR c++/30022 * typeck.c (type_after_usual_arithmetic_conversions): Fix assertion for vector types. (build_binary_op): Use temporary for inner type of vector types. * g++.dg/ext/vector5.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/vector5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30022
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-01 22:01 --- nonnull attribute to the function says the function's argument is non null at the time we enter the function so assuming that is correct. Also this is documented this way: nonnull (arg-index, ...) The nonnull attribute specifies that some function parameters should be non-null pointers. For instance, the declaration: extern void * my_memcpy (void *dest, const void *src, size_t len) __attribute__((nonnull (1, 2))); causes the compiler to check that, in calls to my_memcpy, arguments dest and src are non-null. If the compiler determines that a null pointer is passed in an argument slot marked as non-null, and the -Wnonnull option is enabled, a warning is issued. The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null. Witeness the last sentence. -- 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=30043
[Bug java/28453] [ecj] compiler support for reflection data
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-01 22:06 --- Fixed on the branch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28453
[Bug rtl-optimization/29840] [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump)
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-01 22:22 --- Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 MRO > DF_REF_INSN (def) is 0. It looks like the ICE can be avoided by > a check on def_insn. The attached patch seems to get by the ICE. Dave --- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-01 22:22 --- Created an attachment (id=12726) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12726&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
[Bug c++/30022] [4.0/4.1/4.2/4.3 regression] ICE on vector operand in division
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-12-01 22:27 --- Subject: Bug 30022 Author: reichelt Date: Fri Dec 1 22:27:03 2006 New Revision: 119418 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119418 Log: PR c++/30022 * typeck.c (type_after_usual_arithmetic_conversions): Fix assertion for vector types. (build_binary_op): Use temporary for inner type of vector types. * g++.dg/ext/vector5.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/vector5.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/typeck.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30022
[Bug c++/30022] [4.0/4.1/4.2/4.3 regression] ICE on vector operand in division
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-12-01 22:29 --- Subject: Bug 30022 Author: reichelt Date: Fri Dec 1 22:29:13 2006 New Revision: 119419 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119419 Log: PR c++/30022 * typeck.c (type_after_usual_arithmetic_conversions): Fix assertion for vector types. (build_binary_op): Use temporary for inner type of vector types. * g++.dg/ext/vector5.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/vector5.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/typeck.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30022
[Bug c++/30022] [4.0/4.1/4.2/4.3 regression] ICE on vector operand in division
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-12-01 22:32 --- Subject: Bug 30022 Author: reichelt Date: Fri Dec 1 22:32:00 2006 New Revision: 119420 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119420 Log: PR c++/30022 * typeck.c (type_after_usual_arithmetic_conversions): Fix assertion for vector types. (build_binary_op): Use temporary for inner type of vector types. * g++.dg/ext/vector5.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/ext/vector5.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/typeck.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30022
[Bug c++/30022] [4.0/4.1/4.2/4.3 regression] ICE on vector operand in division
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-12-01 22:33 --- Fixed on mainline, 4.2 branch, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30022
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #2 from madcoder at debian dot org 2006-12-01 22:45 ---
Please, I'm not telling the behaviour is crazy, it's indeed correct.
I'm just asking for a smallish warning that I may be shooting myself in the
foot when I do sth like my 'foo' function from the bug report.
When you do :
size_t i;
// ...
if (i >= 0) { ...
if (i < 0) { ...
gcc issues a warning to tell me that I'm doing a test that will always be true
(or always be false). I'd just like to have the same when I've specified that a
parameter is nonnull and that I nontheless tries to see if it's NULL or not.
You're not answering to what I ask, I've read the documentation, and I've
already acknowledged that gcc optimizations in presence of the nonnull
attribute are legitimate.
--
madcoder at debian dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-01 22:49 ---
(In reply to comment #2)
> Please, I'm not telling the behaviour is crazy, it's indeed correct.
>
> I'm just asking for a smallish warning that I may be shooting myself in the
> foot when I do sth like my 'foo' function from the bug report.
>
> When you do :
>
> size_t i;
>
> // ...
>
> if (i >= 0) { ...
> if (i < 0) { ...
And this optimization happens way after we are done parsing so ...
I don't think a warning is the right thing in this case because the developer
should have read the documention and it is harder to give a warning in this
case really as this optimization is done currently only in the VRP so we don't
know if it is from
*a = 1;
if (!a)
...
of just
from nonnull.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c++/28986] Failure to diagnose overflow in constant expression
--- Comment #4 from manu at gcc dot gnu dot org 2006-12-01 23:36 --- I am working in a patch but don't expect it too soon. Yet, I am quite advanced, that is why I am accepting it. If this is not the proper way to do it, please let me know. -- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-09 04:14:01 |2006-12-01 23:36:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28986
gcj: ICE on gcj -c seda.jar
$ gcj -c /usr/share/java/seda.jar
seda/sandStorm/internal/AggTPSThreadManager.java: In class
'seda.sandStorm.internal.AggTPSThreadManager$governorThread':
seda/sandStorm/internal/AggTPSThreadManager.java: In method
'seda.sandStorm.internal.AggTPSThreadManager$governorThread.run()':
seda/sandStorm/internal/AggTPSThreadManager.java:328: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
The line the compiler mentions is...
$ cat -n ./seda/src/seda/sandStorm/internal/ATTIC/AggTPSThreadManager.java
...
25 package seda.sandStorm.internal;
...
44 class AggTPSThreadManager implements ThreadManagerIF, sandStormConst {
45
46 private static final boolean DEBUG = true;
47 private static final boolean DEBUG_VERBOSE = false;
...
327 public void run() {
328 if (DEBUG) System.err.println("AggTPSTM Governor: starting");
329
...
$ gcj --version |head -1
gcj (GCC) 4.1.2 20061020 (prerelease) (Debian 4.1.1-17)
The binary and source files in question may be downloaded from a Debian archive:
http://packages.debian.org/testing/libs/libseda-java
Cheers,
Shaun
[Bug fortran/21061] gfortran ignores -Werror
--- Comment #6 from dfranke at gcc dot gnu dot org 2006-12-02 00:12 --- Fixed on trunk, closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21061
[Bug c++/28284] [4.1 regression] ICE with invalid static const variable
--- Comment #7 from patchapp at dberlin dot org 2006-12-02 02:15 --- Subject: Bug number PR c++/28284 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00064.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28284
[Bug c++/30044] New: ICE in tsubst, at cp/pt.c:7359
I get this when compiling the attached minimal test case. The condition for getting an ICE seems to be that: 1. A template template parameter's type is defined with 2 or more parameters 2. The type (ignoring the first parameter) is defined in terms of previous template parameters, and none of the type's parameters are typename 3. A default parameter instantiates the template parameter This seems to go back to at least gcc 3.3. To reproduce: g++ icetest.C $ g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --with-gmp=/tmp/gcc-inst --prefix=/tmp/gcc-inst --with-mpfr=/tmp/gcc-inst --enable-languages=c,c++ Thread model: posix gcc version 4.3.0 20061201 (experimental) -- Summary: ICE in tsubst, at cp/pt.c:7359 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcc03 at doc dot ic dot ac dot uk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30044
[Bug c++/30044] ICE in tsubst, at cp/pt.c:7359
--- Comment #1 from pcc03 at doc dot ic dot ac dot uk 2006-12-02 02:47 --- Created an attachment (id=12727) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12727&action=view) minimal test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30044
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #4 from zackw at panix dot com 2006-12-02 05:19 --- Andrew, please don't close enhancement requests WONTFIX because you think they're too hard to implement. There is no harm in leaving them open in case someone decides that it's not too hard and they're going to code it. Also, please don't insult our users by implying they didn't read the documentation, especially when the immediately previous message demonstrates beyond question that they did. Actually, just quit insulting the users. OK? -- zackw at panix dot com changed: What|Removed |Added CC||zackw at panix dot com Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-02 05:52 ---
The main issue I have emitting a warning here is that it will produce a bunch
of false positives for an example:
static int f(int *a)
{
if (a)
return *a;
return -1;
}
int g(int *a, int c) __attribute__((nonnull(1) ));
int g(int *a, int c)
{
if (c)
return f(a);
return -1;
}
int h(int *a, int c)
{
if (c)
return f(a);
return -1;
}
Or even f is a define:
#define f(a) ({int *b_ = a; int t = -1; if(b_) t = *b_; t;})
Also we don't want to warn for:
int g(int *a, int c) __attribute__((nonnull(1) ));
int *x;
int g(int *a, int c)
{
if (!c) a = x
if (a) return *a;
return c;
}
This shows how very fragile this warning will have to be to be able to not to
warn in those cases. The unsigned warning is very fragile when it comes to
macros (and templates) also but it is not as fragile as this warning as it is
not flow sensative.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug tree-optimization/30045] New: [4.1/4.2/4.3 Regression] ICE in nonnull_arg_p with the CHAIN decl
While thinking about PR 30043 a little, I also looked into the code for VRP and
noticed if we had the CHAIN decl while checking for nonnull we could crash so I
wrote a testcase that crashes with -O2 -fno-inline:
int f(int *a)
{
int __attribute__((nonnull(1))) g(int *b)
{
int **c = &a;
if (b)
return *a + **c;
return *b;
}
if (a)
return g(a);
return 1;
}
--
Summary: [4.1/4.2/4.3 Regression] ICE in nonnull_arg_p with the
CHAIN decl
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30045
[Bug tree-optimization/30045] [4.1/4.2/4.3 Regression] ICE in nonnull_arg_p with the CHAIN decl
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 4.2.0 4.3.0 Known to work||4.0.4 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30045
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #6 from zackw at panix dot com 2006-12-02 06:00 --- Subject: Re: __attribute__((nonull(...))) and silent optimizations Well, it's just like 'may be used uninitialized' false positives, isn't it? The warning shouldn't issue from the VRP pass, we should have some kind of data-flow-dependent warning pass that operates really, really early (though still on language-independent IL) so that we can have nice predictable rules about what it will and will not catch... Anyway that's how I'd do it. Which I am not volunteering to do, mind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #7 from zackw at panix dot com 2006-12-02 06:04 --- Subject: Re: __attribute__((nonull(...))) and silent optimizations Also: my main concern here is not the technical details of the feature but my dislike for your tendency to blow off bug reports that you think are bogus and insult the users who reported them. That's not the public face the project should present. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c++/30046] New: ICE on invalid code in digest_init at cp/typeck2.c:709
The following crashes g++-4.1.1:
template < typename T >
void boom ( T & a ) {
T tmp = a;
}
template < typename T >
void null_op ( void ) {}
typedef void(&F)( void );
int main ( void ) {
F f = &null_op;
boom( f );
}
gcc> /added/pkg/gcc-4.1.1/usr/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --prefix=/added/pkg/gcc-4.1.1/usr
--with-ld=/usr/i686-pc-linux-gnu/binutils-bin/2.16.1/ld --enable-debug
--enable-libstdcxx-debug --enable-concept-checks
--with-as=/usr/i686-pc-linux-gnu/binutils-bin/2.16.1/as
--host=i686-pc-linux-gnu : (reconfigured) ../gcc-4.1.1/configure
--prefix=/added/pkg/gcc-4.1.1/usr
--with-ld=/usr/i686-pc-linux-gnu/binutils-bin/2.16.1/ld --enable-debug
--enable-libstdcxx-debug --enable-concept-checks
--with-as=/usr/i686-pc-linux-gnu/binutils-bin/2.16.1/as
--host=i686-pc-linux-gnu
Thread model: posix
gcc version 4.1.1
My g++-3.4.6 (gentoo) does not crash on the code.
Best
Kai-Uwe Bux
--
Summary: ICE on invalid code in digest_init at cp/typeck2.c:709
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkherciueh at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30046
[Bug target/30041] FAIL: gcc.target/i386/sse3-movddup.c (internal compiler error)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-02 07:27 --- This testcase should be testing on your machine. GCC should not ICE on this testcase anyways. Also when it runs the if statement: /* Run SSE3 test only if host has SSE3 support. */ if ((cpu_facilities & bit_SSE3)) Should be false. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|testsuite |target Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30041
[Bug libstdc++/30047] New: Corrupt return value in specific context
The following code prints an incorrect return value from F.
#include
#include
int F()
{
std::vector buffer; // this can be any container
std::cout << std::endl;
return 12345;
std::cout << std::endl;
}
int main()
{
std::cout << F() << std::endl; // prints something other than 12345
}
If any of the lines in F are rearranged, the bug goes away. I did a fresh
rebuild of GCC 4.1.1 under MinGW and bug remained. Before the rebuild, the
return value was somewhat random, as if it were accessing invalid memory.
Since the rebuild, the return value has been a steady 0.
Compiled with:
$ g++ -oprog prog.cpp && prog
--
Summary: Corrupt return value in specific context
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spam at david dot osborn dot name
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30047
[Bug c++/30042] ICE on invalid code
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-02 07:35 --- See http://bugzilla.redhat.com/bugzilla> for instructions. And this works for me with "4.1.0 20051026" and 4.1.2 20061125 Oh this is a dup of 29435. *** This bug has been marked as a duplicate of 29435 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30042
[Bug c++/29435] [4.1 Regression] seg fault with sizeof and templates
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-12-02 07:35 --- *** Bug 30042 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bagnara at cs dot unipr dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
[Bug c++/30044] ICE in tsubst, at cp/pt.c:7359
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-02 07:39 --- Confirmed, not a regression, goes back to at least 2.95.3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||2.95 3.2.3 3.4.0 4.0.0 4.2.0 ||4.0.4 4.1.2 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-12-02 07:39:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30044
[Bug c++/30046] [4.1/4.2/4.3 Regression] ICE on invalid code in digest_init at cp/typeck2.c:709
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-02 07:42 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.1.2 4.2.0 4.3.0 Known to work||4.0.4 Last reconfirmed|-00-00 00:00:00 |2006-12-02 07:42:15 date|| Summary|ICE on invalid code in |[4.1/4.2/4.3 Regression] ICE |digest_init at |on invalid code in |cp/typeck2.c:709|digest_init at ||cp/typeck2.c:709 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30046
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-02 07:56 --- I don't run into this failure when building libgfortran for spu-elf. Can you provide the preprocessed temp? Also by the way newlib for most targets don't have enough of POSIX to be able to run the libgfortran testsuite, it is missing dup and access at least. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
