[Bug c++/4205] function template can call other function with incorrect parameters
--- Comment #14 from jason at gcc dot gnu dot org 2009-11-19 06:18 --- This seems to have been fixed sometime in the 4.3 release cycle; it works properly with the current 4.3, 4.4 and 4.5 branches. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4205
[Bug c++/561] std:unclear about Overloaded Function Pointer resolution
-- jason at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Keywords||rejects-valid Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=561
[Bug fortran/42104] Segmentation fault with procedure pointer component
--- Comment #2 from m dot a dot hulsen at tue dot nl 2009-11-19 06:08 --- Created an attachment (id=19043) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19043&action=view) simplified (removed pp in main) Removed the pp in the main program, because ifort does not seem to like it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug fortran/42104] Segmentation fault with procedure pointer component
--- Comment #1 from m dot a dot hulsen at tue dot nl 2009-11-19 05:52 --- Created an attachment (id=19042) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19042&action=view) source exposing the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug fortran/42104] New: Segmentation fault with procedure pointer component
The attached file gives: 1.9045084 1.9045084 Segmentation fault Both ifort and g95 seems fine. -- Summary: Segmentation fault with procedure pointer component Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m dot a dot hulsen at tue dot nl GCC host triplet: Linux x86_64 GCC target triplet: Linux x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-11-19 05:27 --- Subject: Bug 42090 Author: jvdelisle Date: Thu Nov 19 05:27:15 2009 New Revision: 154317 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154317 Log: 2009-11-18 Jerry DeLisle PR libgfortran/42090 * gfortran.dg/direct_io_11.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/direct_io_11.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug middle-end/42103] [4.4 regression] packed 64-bit field reports as violation of strict aliasing rules
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-19 05:25 --- Without a full testcase it is hard to see what is going on here. Please attach the preprocessed source. Note using the may_alias attribute will fix the aliasing issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42103
[Bug c/42103] New: [4.4 regression] packed 64-bit field reports as violation of strict aliasing rules
The following two declarations work under gcc 4.2.4, but are inconsistent under
gcc 4.4.1:
static inline void put_unaligned_uint64(void *p, uint64_t datum)
{
struct { uint64_t d; } __attribute__((packed)) *pp = p;
pp->d = datum;
}
static inline void put_unaligned_uint32(void *p, unsigned int datum)
{
struct { unsigned int d; } __attribute__((packed)) *pp = p;
pp->d = datum;
}
Given that the only difference between these two functions is that one is
64-bit, while the other is 32-bit, they should either both fail under strict
aliasing rules or they should both succeed with no error. The error reported
under gcc 4.4.1 is as follows:
/home/tilghman/Asterisk/asterisk-trunk/include/asterisk/unaligned.h:55: error:
dereferencing pointer âppâ does break strict-aliasing rules
/home/tilghman/Asterisk/asterisk-trunk/include/asterisk/unaligned.h:53: note:
initialized from here
--
Summary: [4.4 regression] packed 64-bit field reports as
violation of strict aliasing rules
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tlesher at digium dot com
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42103
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-11-19 04:50 --- Subject: Bug 42090 Author: jvdelisle Date: Thu Nov 19 04:50:04 2009 New Revision: 154316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154316 Log: 2009-11-18 Jerry DeLisle PR libgfortran/42090 * io/transfer.c (skip_record): Set bytes_left_subrecord to zero after skipping the remaining bytes in the record. (next_record_r): Call skip_record with the number of bytes_left to be skipped. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug bootstrap/42093] bootstrap hangs in stage2 run of build/gengtype
--- Comment #1 from doko at ubuntu dot com 2009-11-19 04:11 --- only seen when configuring with --with-mode=thumb, disabling scheduling for thumb2 shows the same endless loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42093
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-11-19 03:49 --- Confirmed and have a patch. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-19 03:49:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug target/42102] ICE of optimize
--- Comment #1 from ysato at users dot sourceforge dot jp 2009-11-19 03:18 --- Created an attachment (id=19041) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19041&action=view) test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42102
[Bug target/42102] New: ICE of optimize
rx-elf-gcc -O2 -S failed.c
failed.c: In function ¡Æwrite_cache_pages¡Ç:
failed.c:76:1: error: insn does not satisfy its constraints:
(insn 123 230 39 12 failed.c:68 (set:QI (mem/s/j:QI (plus:SI (reg:SI 11 r11)
(const_int 20 [0x14])) [0 S1 A32])
(ior:QI (mem/s/j:QI (plus:SI (reg:SI 14 r14)
(const_int 20 [0x14])) [0 S1 A32])
(ashift:QI (const_int 1 [0x1])
(const_int 1 [0x1] 63 {bitset_in_memory} (nil))
failed.c:76:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
"rx-elf-gcc -O1 -S failed.c" is success.
--
Summary: ICE of optimize
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ysato at users dot sourceforge dot jp
GCC host triplet: x86_64-linux
GCC target triplet: rx-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42102
[Bug c++/42101] Linking failure with static constants and ternary inline function
--- Comment #7 from andhow at gmail dot com 2009-11-19 02:41 --- (In reply to comment #6) > This is pretty basic C++, by the way. Mmm hmm. SO basic that it warranted special clarification in 9.4.2-4: "The member shall still be defined in a namespace scope if it is used in the program and the namespace scope definition shall not contain an initializer." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42101
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2009-11-19 02:27 --- In case this helps, I have attached the assembly diffs from... gcc-4 -O1 -m32 -g --save-temps complex-sign-add_red_1.c for the 20090908 compiler (before the VTA merge) and for the 20091118 compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2009-11-19 02:25 --- Created an attachment (id=19040) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19040&action=view) assembly diffs from 20090908 vs 20091118 compiler for testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/42101] Linking failure with static constants and ternary inline function
--- Comment #6 from paolo dot carlini at oracle dot com 2009-11-19 02:16 --- It doesn't have any definition, it does have a *declaration*. This is pretty basic C++, by the way. Just add out of class: const size_t X::DEPENDENT_LENGTH_MASK; ... ... and everything will be fine. The compiler doesn't diagnose that, right, because the actual diagnosis, as for any undefined entity, eg, functions, happens only at link time, the linker tells you: as happens for functions, you could well have the definitions in another file. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42101
[Bug c++/42101] Linking failure with static constants and ternary inline function
--- Comment #5 from dvander at alliedmods dot net 2009-11-19 01:58 --- I'll also note that the compiler seems to accept it, as I get a .o file. The linking step botches. -- dvander at alliedmods dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42101
[Bug c++/42101] Linking failure with static constants and ternary inline function
--- Comment #4 from andhow at gmail dot com 2009-11-19 01:53 --- (In reply to comment #3) > (In reply to comment #2) > > You don't have a definition of the static const variable which you need for > > this to be valid C++. Heh, oops, hit 'Commit' accidentally. This example does have a definition for the static member variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42101
[Bug c++/42101] Linking failure with static constants and ternary inline function
--- Comment #3 from andhow at gmail dot com 2009-11-19 01:52 --- (In reply to comment #2) > You don't have a definition of the static const variable which you need for > this to be valid C++. -- andhow at gmail dot com changed: What|Removed |Added CC||andhow at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42101
[Bug c++/42101] Linking failure with static constants and ternary inline function
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-19 01:46 --- You don't have a definition of the static const variable which you need for this to be valid C++. -- 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=42101
[Bug c++/42101] Linking failure with static constants and ternary inline function
--- Comment #1 from dvander at alliedmods dot net 2009-11-19 01:44 --- Created an attachment (id=19039) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19039&action=view) reduced test case This program doesn't link, though it should. keima:src dvander$ g++ test.cpp -o test test.cpp: In function int main(): test.cpp:28: warning: format %d expects type int, but argument 2 has type size_t Undefined symbols: "X::LENGTH_MASK", referenced from: X::dependentLength() const in ccdhJ0JB.o "X::DEPENDENT_LENGTH_MASK", referenced from: X::dependentLength() const in ccdhJ0JB.o ld: symbol(s) not found collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42101
[Bug c++/42101] New: Linking failure with static constants and ternary inline function
When using private, static constants in a class declaration, and using these constants in an inline function that returns a ternary expression , gcc produces linker errors. This seems to be a problem going back to at least 4.0, and I can reproduce it against 4.4.1. I have not tried anything earlier than 4.0 or later than 4.4.1. -- Summary: Linking failure with static constants and ternary inline function Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dvander at alliedmods dot net GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42101
[Bug c++/42087] stl::map breaks strict-aliasing rules
--- Comment #4 from riddikulus at verizon dot net 2009-11-19 01:22 --- (In reply to comment #3) > > *** This bug has been marked as a duplicate of 39390 *** > Just FYI, the test code in bug #39390 does not generate any warnings with GCC 4.4.1, while the test code attached to this bug (#42087) does. This suggests these two bugs "might" not be precisely the same one. I'll defer to your experience though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42087
[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
--- Comment #16 from lwalkera at ieee dot org 2009-11-19 00:53 ---
The bug also occurs with 4.4.2 when building uClibc:
libm/nan.c:45: error: insn does not satisfy its constraints:
(insn 95 92 49 4 libm/nan.c:42 (set (reg/f:SI 13 sp)
(reg/f:SI 44 wcgr1 [141])) 441 {*iwmmxt_movsi_insn} (nil))
libm/nan.c:45: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug pending/41998] GCC 4.6 pending patches meta-bug
--- Comment #3 from law at redhat dot com 2009-11-19 00:05 --- Created an attachment (id=19038) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19038&action=view) patch to improve register allocation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41998
[Bug target/42100] soft float flags missings from libgcc.a (and others) if no --with-float given at configure time
--- Comment #1 from schodet at efrei dot fr 2009-11-18 23:43 --- Created an attachment (id=19037) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19037&action=view) Modified t-arm-elf Lines have been commented out to enable a more flexible multilib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42100
[Bug target/42100] New: soft float flags missings from libgcc.a (and others) if no --with-float given at configure time
This is similar to #14895. On arm-elf target, the compiler defaults to soft-float even when no option is passed. Binutils defaults to hard-float (it sets the SOFTFLOAT only if the soft-float option is given). When libgcc is built for soft-float, gas receives no option from gcc and therefore does not set the SOFTFLOAT flag. This is shown using arm-elf-objdump -p on the libgcc.a file ([software FP] missing). A workaround is to provide an explicit --with-float=soft at configure time. In this case, this is added to configure_default_options, and OPTION_DEFAULT_SPECS saves us. Configured with: /home/nico/arm/gcc-arm-elf-4.3.2/src/configure --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --datadir=/usr/share --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --build=i486-linux-gnu --host=i486-linux-gnu --target=arm-elf --enable-languages=c --enable-shared --with-system-zlib --enable-nls --without-included-gettext --disable-checking --disable-libssp --enable-interwork --enable-multilib I use a customised t-arm-elf to build multilib with hard and soft float. Thanks. -- Summary: soft float flags missings from libgcc.a (and others) if no --with-float given at configure time Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schodet at efrei dot fr GCC build triplet: all GCC host triplet: all GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42100
[Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only
--- Comment #6 from ludovic at ludovic-brenta dot org 2009-11-18 22:09
---
With a stock GCC 4.4.2 bootstrapped with the default options (-g -O2, I think)
on alpha the symptoms are the same. Here is a backtrace:
(gdb) run -vP2 -Pp
Starting program: /home/lbrenta/gcc-obj/gcc/gnatmake -vP2 -Pp
GPR_PROJECT_PATH=".:/home/lbrenta/gcc/lib/gcc/alphaev68-unknown-linux-gnu/4.4.2/../../../gnat"
Project_Path_Name_Of ("p", "/home/lbrenta/");
Trying /home/lbrenta//p.gpr
Project_Name_From ("/home/lbrenta/p.gpr")
^C
Program received signal SIGINT, Interrupt.
0x0001200f8ed8 in prj.part.parse_single_project (in_tree=0x1205fc3e0,
path_name=, extended=,
from_extended=, in_limited=false,
packages_to_check=..., depth=0, current_dir=...)
at /home/lbrenta/gcc-4.4.2/gcc/ada/prj-part.adb:1104
1104 Tree_Private_Part.Projects_Htable.Get_Next
(In_Tree.Projects_HT);
(gdb) bt
#0 0x0001200f8ed8 in prj.part.parse_single_project (in_tree=0x1205fc3e0,
path_name=, extended=,
from_extended=, in_limited=false,
packages_to_check=..., depth=0, current_dir=...)
at /home/lbrenta/gcc-4.4.2/gcc/ada/prj-part.adb:1104
#1 0x0001200fb020 in prj.part.parse (in_tree=0x1205fc3e0,
project_file_name=,
always_errout_finalize=, packages_to_check=, store_comments=false, current_directory=...)
at /home/lbrenta/gcc-4.4.2/gcc/ada/prj-part.adb:525
#2 0x0001200f4878 in prj.pars.parse (in_tree=,
project_file_name=..., packages_to_check=...,
when_no_sources=, reset_tree=true) at
/home/lbrenta/gcc-4.4.2/gcc/ada/prj-pars.adb:63
#3 0x0001200858f8 in make.initialize () at
/home/lbrenta/gcc-4.4.2/gcc/ada/make.adb:6993
#4 0x0001200866cc in make.gnatmake () at
/home/lbrenta/gcc-4.4.2/gcc/ada/make.adb:4708
#5 0x000120067708 in gnatmake () at
/home/lbrenta/gcc-4.4.2/gcc/ada/gnatmake.adb:38
(gdb) p In_Tree.Projects_HT
$4 = (access prj.tree.tree_private_part.projects_htable.tab.instance_data) 0x0
The infinite loop appears to be the loop starting at prj-pars.adb:1048 (frame
#0 in the above backtrace). I'll attach a disassembly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42073
[Bug c++/561] std:unclear about Overloaded Function Pointer resolution
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-18 22:00 --- Er, actually this is http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#247 which was resolved to say that the example is well-formed, so G++ should accept it. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|SUSPENDED |ASSIGNED Last reconfirmed|2005-12-11 21:49:36 |2009-11-18 22:00:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=561
[Bug c++/950] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base
-- jason at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
[Bug c++/950] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base
--- Comment #15 from jason at gcc dot gnu dot org 2009-11-18 21:55 --- Actually, this is issue 203, so I'll suspend it instead of closing. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#203 -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
[Bug bootstrap/42096] lto.c:289:7: error: implicit declaration of function 'strtoll'
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-11-18 21:51 --- Subject: Re: lto.c:289:7: error: implicit declaration of function 'strtoll' > Is strtoll defined in some other header in hppa64-hp-hpux11.11? If it isn't, I > will start porting it to libiberty. It's not defined. strtol is available, and long and long long are the same size on this target. However, this isn't going to work on 32-bit hpux targets. So, I think porting it mto libibery is a good idea. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42096
[Bug middle-end/42099] Error in 64-bit division for 32-bit target
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-18 21:22 --- This is a HWI issue as it works with --enable-target=all but fails without that (--enable-targets=all changes HWI to be 64bits). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||HWI == 32bits Known to fail||4.1.1 4.3.0 Last reconfirmed|-00-00 00:00:00 |2009-11-18 21:22:02 date|| Summary|[4.5 Regression] Error in |Error in 64-bit division for |64-bit division for 32-bit |32-bit target |target | Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug middle-end/42099] [4.5 Regression] Error in 64-bit division for 32-bit target
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|Error in 64-bit division for|[4.5 Regression] Error in |32-bit target |64-bit division for 32-bit ||target Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug middle-end/42099] Error in 64-bit division for 32-bit target
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-18 20:59 --- (In reply to comment #1) > Actually there is a defect report against the C standard for this issue. I take that back. Note it worked for some previous versions of GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #9 from rguenther at suse dot de 2009-11-18 20:52 --- Subject: Re: flag_gtoggle in free_lang_data hides -fcompare-debug errors On Wed, 18 Nov 2009, aoliva at gcc dot gnu dot org wrote: > --- Comment #8 from aoliva at gcc dot gnu dot org 2009-11-18 20:05 > --- > We used to do such things, using pointers rather than UIDs even, and I fixed a > number of such issues to avoid codegen differences. But hey, if you could > prove that a DECL uid would never affect decisions taken by the compiler, > including decisions that might depend on the order in which you perform > similar > tests over difference pieces of code, more power to you, don't let me stand on > your way. Bonus points if you can devise a way to avoid such dependences on > UIDs from being accidentally introduced at a later time. This is what we have bootstrap-debug for. Btw, I obviously cannot "prove" anything. But one could randomize the delta we add to next_decl_uid - we should get bootstrap comparison errors very reliably that way. (I remember doing that once, but I don't remember the outcome) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug middle-end/42099] Error in 64-bit division for 32-bit target
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-18 20:51 --- Actually there is a defect report against the C standard for this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug middle-end/42099] New: Error in 64-bit division for 32-bit target
I compiled this test case in a i686-pc-linux-gnu gcc configured with
--with-arch=pentium4:
long long foo(long long v) { return v / -0x08000LL; }
void main() { if (foo(0x08000LL) != -1) abort(); exit (0); }
The value of 0x8000LL / -0x8000LL is -1. However, gcc computes it as
0, and the test fails. It fails at -O0 but succeeds if the division is
inlined.
--
Summary: Error in 64-bit division for 32-bit target
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug c/42098] gcc does not honor alignment specification, gives different alignment than g++
--- Comment #1 from jepler at unpythonic dot net 2009-11-18 20:23 --- Created an attachment (id=19036) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19036&action=view) test program to demonstrate the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42098
[Bug c/42098] New: gcc does not honor alignment specification, gives different alignment than g++
Given the declaration: typedef volatile double D __attribute__((aligned(16))); gcc and g++ give different alignments (and thus differing offsets and sizes) for structures that contain D. Removal of the volatile qualifier changes the alignment behavior. $ g++ -m32 vs.c && ./a.out $ gcc -m32 -Dvolatile= vs.c && ./a.out $ gcc -m32 vs.c && ./a.out a.out: vs.c:8: main: Assertion `__alignof__(S) == 8' failed. Aborted $ gcc -v 2>&1 | tail -1 gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4) -- Summary: gcc does not honor alignment specification, gives different alignment than g++ Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jepler at unpythonic dot net 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=42098
[Bug bootstrap/42096] lto.c:289:7: error: implicit declaration of function 'strtoll'
--- Comment #1 from espindola at gcc dot gnu dot org 2009-11-18 20:21 --- Is strtoll defined in some other header in hppa64-hp-hpux11.11? If it isn't, I will start porting it to libiberty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42096
[Bug c/42097] Reference operator (&) error from included file.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-18 20:11 --- C90/C99 does not have a reference type. extern void Prop (double &, double &, double &, double &, double &, double &, int) ; is C++ code, compile it with the C++ front-end. -- 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=42097
[Bug c/42097] New: Reference operator (&) error from included file.
Using built-in specs. Target: i586-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --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.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i586 --build=i586-redhat-linux Thread model: posix gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) # 1 "air0.c" # 1 "" # 1 "" # 1 "air0.c" # 17 "air0.c" # 1 "cntls.h" 1 # 32 "cntls.h" # 1 "/usr/include/math.h" 1 3 4 # 28 "/usr/include/math.h" 3 4 # 1 "/usr/include/features.h" 1 3 4 # 352 "/usr/include/features.h" 3 4 # 1 "/usr/include/sys/cdefs.h" 1 3 4 # 365 "/usr/include/sys/cdefs.h" 3 4 # 1 "/usr/include/bits/wordsize.h" 1 3 4 # 366 "/usr/include/sys/cdefs.h" 2 3 4 # 353 "/usr/include/features.h" 2 3 4 # 376 "/usr/include/features.h" 3 4 # 1 "/usr/include/gnu/stubs.h" 1 3 4 # 1 "/usr/include/bits/wordsize.h" 1 3 4 # 5 "/usr/include/gnu/stubs.h" 2 3 4 # 1 "/usr/include/gnu/stubs-32.h" 1 3 4 # 8 "/usr/include/gnu/stubs.h" 2 3 4 # 377 "/usr/include/features.h" 2 3 4 # 29 "/usr/include/math.h" 2 3 4 # 1 "/usr/include/bits/huge_val.h" 1 3 4 # 35 "/usr/include/math.h" 2 3 4 # 1 "/usr/include/bits/huge_valf.h" 1 3 4 # 37 "/usr/include/math.h" 2 3 4 # 1 "/usr/include/bits/huge_vall.h" 1 3 4 # 38 "/usr/include/math.h" 2 3 4 # 1 "/usr/include/bits/inf.h" 1 3 4 # 41 "/usr/include/math.h" 2 3 4 # 1 "/usr/include/bits/nan.h" 1 3 4 # 44 "/usr/include/math.h" 2 3 4 # 1 "/usr/include/bits/mathdef.h" 1 3 4 # 36 "/usr/include/bits/mathdef.h" 3 4 typedef long double float_t; typedef long double double_t; # 48 "/usr/include/math.h" 2 3 4 # 71 "/usr/include/math.h" 3 4 # 1 "/usr/include/bits/mathcalls.h" 1 3 4 # 53 "/usr/include/bits/mathcalls.h" 3 4 extern double acos (double __x) __attribute__ ((__nothrow__)); extern double __acos (double __x) __attribute__ ((__nothrow__)); extern double asin (double __x) __attribute__ ((__nothrow__)); extern double __asin (double __x) __attribute__ ((__nothrow__)); extern double atan (double __x) __attribute__ ((__nothrow__)); extern double __atan (double __x) __attribute__ ((__nothrow__)); extern double atan2 (double __y, double __x) __attribute__ ((__nothrow__)); extern double __atan2 (double __y, double __x) __attribute__ ((__nothrow__)); extern double cos (double __x) __attribute__ ((__nothrow__)); extern double __cos (double __x) __attribute__ ((__nothrow__)); extern double sin (double __x) __attribute__ ((__nothrow__)); extern double __sin (double __x) __attribute__ ((__nothrow__)); extern double tan (double __x) __attribute__ ((__nothrow__)); extern double __tan (double __x) __attribute__ ((__nothrow__)); extern double cosh (double __x) __attribute__ ((__nothrow__)); extern double __cosh (double __x) __attribute__ ((__nothrow__)); extern double sinh (double __x) __attribute__ ((__nothrow__)); extern double __sinh (double __x) __attribute__ ((__nothrow__)); extern double tanh (double __x) __attribute__ ((__nothrow__)); extern double __tanh (double __x) __attribute__ ((__nothrow__)); # 87 "/usr/include/bits/mathcalls.h" 3 4 extern double acosh (double __x) __attribute__ ((__nothrow__)); extern double __acosh (double __x) __attribute__ ((__nothrow__)); extern double asinh (double __x) __attribute__ ((__nothrow__)); extern double __asinh (double __x) __attribute__ ((__nothrow__)); extern double atanh (double __x) __attribute__ ((__nothrow__)); extern double __atanh (double __x) __attribute__ ((__nothrow__)); extern double exp (double __x) __attribute__ ((__nothrow__)); extern double __exp (double __x) __attribute__ ((__nothrow__)); extern double frexp (double __x, int *__exponent) __attribute__ ((__nothrow__)); extern double __frexp (double __x, int *__exponent) __attribute__ ((__nothrow__)); extern double ldexp (double __x, int __exponent) __attribute__ ((__nothrow__)); extern double __ldexp (double __x, int __exponent) __attribute__ ((__nothrow__)); extern double log (double __x) __attribute__ ((__nothrow__)); extern double __log (double __x) __attribute__ ((__nothrow__)); extern double log10 (double __x) __attribute__ ((__nothrow__)); extern double __log10 (double __x) __attribute__ ((__nothrow__)); extern double modf (double __x, double *__iptr) __attribute__ ((__nothrow__)); extern double __modf (double __x, double *__iptr) __attribute__ ((__nothrow__)); # 127 "/usr/include/bits/mathcalls.h" 3 4 extern double expm1 (double __x) __attribute__ ((__nothrow__)); extern double __expm1 (double __x) __attribute__ ((__nothrow__)); ex
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #8 from aoliva at gcc dot gnu dot org 2009-11-18 20:05 --- We used to do such things, using pointers rather than UIDs even, and I fixed a number of such issues to avoid codegen differences. But hey, if you could prove that a DECL uid would never affect decisions taken by the compiler, including decisions that might depend on the order in which you perform similar tests over difference pieces of code, more power to you, don't let me stand on your way. Bonus points if you can devise a way to avoid such dependences on UIDs from being accidentally introduced at a later time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #7 from rguenther at suse dot de 2009-11-18 19:50 --- Subject: Re: flag_gtoggle in free_lang_data hides -fcompare-debug errors On Wed, 18 Nov 2009, aoliva at gcc dot gnu dot org wrote: > --- Comment #6 from aoliva at gcc dot gnu dot org 2009-11-18 17:58 > --- > decl UIDs are used in various expression hashes. Enforcing strict ordering > among them without relying on UIDs would be an interesting problem, but if you > have a solution for that, go for it. Disabling the printing of UIDs in > -fcompare-debug dumps will be the least of your problems. Expression hashes do not have to be ordered. Nobody walks them and generates code from them. Instead they hash expressions and for different UIDs the expressions better are different. And we'd better have only one same expression in a hash. So I fail to see how expression hashes matter here at all. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #7 from alanpae at ilkda dot com 2009-11-18 19:39 --- changing to --disable-threads also works. alan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug c++/42085] Typedef templates
--- Comment #4 from redi at gcc dot gnu dot org 2009-11-18 18:47 --- (In reply to comment #3) > you tell me when they plan to release a stable version of a C++1x compiler ? After the C++1x standard is finished, which might be next year, or might not. I don't know of any compiler that implements template aliases yet. This is the wrong place to ask, all you'll learn here is GCC doesn't support them -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42085
[Bug c++/42085] Typedef templates
--- Comment #3 from marc dot coiffier at free dot fr 2009-11-18 18:13 --- (In reply to comment #2) > (In reply to comment #1) > > I think C++0x (well renamed to C++1x) has something like this. > > Called template aliases: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf > > Note GCC does not implement them yet. > Thank you, I looked it up and it does seem to match what I want. Do you know of any compiler (or compiler branch or compiler extension or plugin), even experimental, that would let me experience this feature, though ? Also, could you tell me when they plan to release a stable version of a C++1x compiler ? -- marc dot coiffier at free dot fr changed: What|Removed |Added CC||marc dot coiffier at free ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42085
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-11-18 18:04 --- Yes, I will have a look tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #6 from aoliva at gcc dot gnu dot org 2009-11-18 17:58 --- decl UIDs are used in various expression hashes. Enforcing strict ordering among them without relying on UIDs would be an interesting problem, but if you have a solution for that, go for it. Disabling the printing of UIDs in -fcompare-debug dumps will be the least of your problems. The only bootstrap-debug failures I remember on x86_64-linux-gnu were in ada, because of the boolean type. Others required the stricter -fcompare-debug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug middle-end/42095] [4.5 Regression] g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link
--- Comment #2 from hjl dot tools at gmail dot com 2009-11-18 17:31 --- It is caused by revision 154284: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00505.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42095
[Bug bootstrap/42096] New: lto.c:289:7: error: implicit declaration of function 'strtoll'
/test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp -hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/lib/ -isystem /op t/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-4. 5.0/hppa64-hp-hpux11.11/sys-include-c -g -O2 -DIN_GCC -W -Wall -Wwrite-st rings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attr ibute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wer ror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Ilto - I../../gcc/gcc -I../../gcc/gcc/lto -I../../gcc/gcc/../include -I../../gcc/gcc/.. /libcpp/include -I/opt/gnu64/gcc/gcc-4.5.0/include -I../../gcc/gcc/../libdecnum ber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/gnu64/include -I/opt/gnu64/include/libelf ../../gcc/gcc/lto/lto-lang.c -o lto/lto-lang.o /test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp -hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/lib/ -isystem /op t/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-4. 5.0/hppa64-hp-hpux11.11/sys-include-c -g -O2 -DIN_GCC -W -Wall -Wwrite-st rings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attr ibute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wer ror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Ilto - I../../gcc/gcc -I../../gcc/gcc/lto -I../../gcc/gcc/../include -I../../gcc/gcc/.. /libcpp/include -I/opt/gnu64/gcc/gcc-4.5.0/include -I../../gcc/gcc/../libdecnum ber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/gnu64/include -I/opt/gnu64/include/libelf ../../gcc/gcc/lto/lto.c -o lto/lto.o cc1: warnings being treated as errors ../../gcc/gcc/lto/lto.c: In function 'lto_resolution_read': ../../gcc/gcc/lto/lto.c:289:7: error: implicit declaration of function 'strtoll' make[3]: *** [lto/lto.o] Error 1 make[3]: Leaving directory `/test/gnu/gcc/objdir/gcc' -- Summary: lto.c:289:7: error: implicit declaration of function 'strtoll' Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42096
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-18 16:53 --- Btw, when I remove the flag_gtoggle check from free-lang-data we should get bootstrap-debug comparison fails, no? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #4 from rguenther at suse dot de 2009-11-18 16:51 --- Subject: Re: flag_gtoggle in free_lang_data hides -fcompare-debug errors On Wed, 18 Nov 2009, aoliva at gcc dot gnu dot org wrote: > --- Comment #3 from aoliva at gcc dot gnu dot org 2009-11-18 16:30 > --- > Different UIDs affect hash table walks, which in turn may affect codegen. > We've had several -g/-g0 codegen differences ultimately caused by decl UID > differences, and they were detected and fixed long before -fcompare-debug was > even introduced, i.e., they were detected with the compare-debug script that > compares actual generated code. > > That's why -fcompare-debug must report such differences. Even if the code > ends > up the same in one particular testcase, supersets of that testcase would > likely > diverge. Disregarding the UIDs in -fcompare-debug would hide errors. Sorry, but hashtable walks are always broken if codegen depends on them and you do not ensure proper ordering. Enforcing same UIDs for -g/-g0 just forces us to use more memory than necessary. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug middle-end/42095] [4.5 Regression] g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link
--- Comment #1 from hjl dot tools at gmail dot com 2009-11-18 16:41 --- I got lto1: error: edge points to wrong declaration:^M >^M QI^M size ^M unit size ^M align 8 symtab 0 alias set -1 canonical type 0x7f77d2ab9210 method basetype ^M arg-types ^M chain >>^M pointer_to_this >^M nothrow public static QI file /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/lto/20081118-1_0.C line 17 col 1 align 16 initial abstract_origin ^M arguments ^M readonly unsigned SI^M size ^M unit size ^M align 32 symtab 0 alias set -1 canonical type 0x7f77d2ab96e0>^M readonly unsigned SI file /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/lto/20081118-1_0.C line 17 col 7 size unit size ^M align 32 context abstract_origin arg-type >^M result ^M ignored VOID file /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/lto/20081118-1_0.C line 19 col 1^M align 8 context >^M struct-function 0x7f77d2bae1b0>^M Instead of: >^M QI^M size ^M unit size ^M align 8 symtab 0 alias set -1 canonical type 0x7f77d2ab9210 method basetype ^M arg-types ^M chain >>^M pointer_to_this >^M addressable used public external virtual QI file /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/lto/20081118-1_1.C line 4 col 11 align 16 abstract_origin ^M arguments ^M readonly unsigned SI^M size ^M unit size ^M align 32 symtab 0 alias set -1 canonical type 0x7f77d2ab96e0>^M readonly unsigned SI file /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/lto/20081118-1_1.C line 4 col 14 size unit size ^M align 32 context arg-type >>^M -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42095
[Bug middle-end/42095] New: [4.5 Regression] g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link
On Linux/ia32, revision 154285 gave: FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link Revision 154283 is OK. -- Summary: [4.5 Regression] g++.dg/lto/20081118-1 cp_lto_20081118- 1_0.o-cp_lto_20081118-1_1.o link Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42095
[Bug testsuite/42086] FAIL: gcc.target/ia64/fptr-1.c execution test
--- Comment #1 from hjl dot tools at gmail dot com 2009-11-18 16:37 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00936.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||11/msg00936.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42086
[Bug debug/41886] [4.5 Regression] ICE from '-O -ftree-loop-distribution -ftree-vectorize -g'
--- Comment #3 from aoliva at gcc dot gnu dot org 2009-11-18 16:31 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41886
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #3 from aoliva at gcc dot gnu dot org 2009-11-18 16:30 --- Different UIDs affect hash table walks, which in turn may affect codegen. We've had several -g/-g0 codegen differences ultimately caused by decl UID differences, and they were detected and fixed long before -fcompare-debug was even introduced, i.e., they were detected with the compare-debug script that compares actual generated code. That's why -fcompare-debug must report such differences. Even if the code ends up the same in one particular testcase, supersets of that testcase would likely diverge. Disregarding the UIDs in -fcompare-debug would hide errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug lto/42020] field not merged causes cc1 to be miscompiled
--- Comment #5 from espindola at gcc dot gnu dot org 2009-11-18 16:18 --- (In reply to comment #4) > Hm, the assert doesn't trigger if I add a tem != field check. In fact I do > not > understand the assert you added at all ;) I completely misunderstood the assert you asked for. The testcase was over reduced because of it. I am trying a new bootstrap. Lets see what happens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42020
[Bug c/42094] Overwritten floor() function
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-18 16:06 --- floor is considered a builtin by default, use either -fno-builtins or -fno-builtin-floor to disable this behavior. -- 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=42094
[Bug c++/42092] wcslen returns bad length when use -fshort-wchar
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-18 16:05 --- (In reply to comment #2) > where can i get this libraries? (or how i can compile them with this option ? > ) > You recompile all of the distro yourself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42092
[Bug testsuite/41913] ERROR: tcl error sourcing gcc.dg/lto/lto.exp
--- Comment #7 from hjl dot tools at gmail dot com 2009-11-18 16:04 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41913
[Bug testsuite/41913] ERROR: tcl error sourcing gcc.dg/lto/lto.exp
--- Comment #6 from hjl at gcc dot gnu dot org 2009-11-18 16:02 --- Subject: Bug 41913 Author: hjl Date: Wed Nov 18 16:02:17 2009 New Revision: 154296 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154296 Log: 2009-11-18 H.J. Lu PR testsuite/41913 * lib/lto.exp (scan-symbol): Properly check if target exist. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/lto.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41913
[Bug c++/950] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base
--- Comment #14 from jason at gcc dot gnu dot org 2009-11-18 15:51 --- Created an attachment (id=19035) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19035&action=view) patch If this were a bug, this would be the fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
[Bug c/42094] New: Overwritten floor() function
Consider the following code:
#include
double floor(double d) {
return 5;
}
int main() {
printf("Floor: %f", floor(3.4) );
}
Note I'm not importing math.h so floor(3.4) should return 5, but the output
from this function is:
lyo...@soba-testing-) floor2
Floor: 3.00
So it replaces it before checking for any overwritten* functions which return
and take the same types and parameters. I assume this goes for ceil and trunc
as well, but haven't tested them. It's not even overwritten because I'm not
even importing math.h. The built in optimisation functions shouldn't have
replaced floor(3.4) because I'm not importing math.h, but they did.
This is compiled simply with 'gcc floor2.c floor2'
--
Summary: Overwritten floor() function
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mindez at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42094
[Bug c++/42092] wcslen returns bad length when use -fshort-wchar
--- Comment #2 from prodotahunter at gmail dot com 2009-11-18 15:30 --- where can i get this libraries? (or how i can compile them with this option ? ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42092
[Bug bootstrap/42093] New: bootstrap hangs in stage2 run of build/gengtype
trunk 20091117 configured with --with-arch=armv7-a --with-mode=thumb --with-float=softfp --with-fpu=vfp hangs in the stage2 run of build/gengtype with 100% cpu time attaching to the running process: (gdb) bt #0 0x00029fb4 in ?? () #1 0xa4a8 in walk_type () #2 0xa4a8 in walk_type () Backtrace stopped: previous frame identical to this frame (corrupt stack?) -- Summary: bootstrap hangs in stage2 run of build/gengtype Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42093
[Bug c++/42092] wcslen returns bad length when use -fshort-wchar
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-18 15:28 --- -fshort-wchar changes the ABI which means you need libraries that are compiled with that option too. -- 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=42092
[Bug c++/42092] New: wcslen returns bad length when use -fshort-wchar
i use -fshort-wchar option for ggc to make wchar_t 16bit but when i use wcslen - it returns incorrect values i think problem in libraries, because they are same(like for 32bit wchar_t with -fshort-wchar) -- Summary: wcslen returns bad length when use -fshort-wchar Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: prodotahunter at gmail dot com GCC build triplet: same GCC host triplet: same GCC target triplet: same http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42092
[Bug tree-optimization/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
--- Comment #7 from matz at gcc dot gnu dot org 2009-11-18 15:04 --- I'm not terribly thrilled by having to clutter the code with 20 lines of code which should have been maybe two :-/ Even less so as nothing can make use of the info. Let's drop it for now with a comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug tree-optimization/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
--- Comment #6 from jakub at gcc dot gnu dot org 2009-11-18 14:03 --- Created an attachment (id=19034) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19034&action=view) gcc45-pr42078.patch Untested patch. Though, maybe it is an overkill, because at least DWARF3 nor current DWARF4 draft isn't able to represent 1.0 / x division (and any other floating point operation, stack works solely on integers) and we should just drop the debug stmt instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-11-18 14:02 --- The dSYM issues looks like part of PR41473. I'll revert to debugging in gcc 4.4.2 for now which shouldn't have the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-18 13:25 --- Subject: Bug 42072 Author: janus Date: Wed Nov 18 13:24:54 2009 New Revision: 154292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154292 Log: 2009-11-18 Janus Weil PR fortran/42072 * trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer dummies which are passed to C_F_PROCPOINTER. 2009-11-18 Janus Weil PR fortran/42072 * gfortran.dg/proc_ptr_8.f90: Extended. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_8.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #9 from mexas at bristol dot ac dot uk 2009-11-18 12:50 --- and the same for gcc45: [skip] unwind-ia64_s.o(.text+0x30b2): In function `uw_frame_state_for': ../.././../gcc-4.5-20091112/libgcc/../gcc/config/ia64/unwind-ia64.c:1788: undefined reference to `_Unwind_FindTableEntry' unwind-ia64_s.o(.text+0x7632): In function `_Unwind_FindEnclosingFunction': ../.././../gcc-4.5-20091112/libgcc/../gcc/config/ia64/unwind-ia64.c:1745: undefined reference to `_Unwind_FindTableEntry' /usr/bin/ld: ./libgcc_s.so.1.tmp: hidden symbol `_Unwind_FindTableEntry' isn't defined collect2: ld returned 1 exit status gmake[3]: *** [libgcc_s.so] Error 1 gmake[3]: Leaving directory `/usr/ports/lang/gcc45/work/build/ia64-portbld-freebsd9.0/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/usr/ports/lang/gcc45/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc45/work/build' gmake: *** [bootstrap-lean] Error 2 *** Error code 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug c/42091] New: -imacros option does not work on gcc 4.2.1 scratchbox
I use Scratchbox on an Ubuntu 8.04 OS with ARM target. The gcc version used in the scratchbox is 4.2.1. I modified the gcc.specs file, I add -imacros option to cpp. Compilation don't even sart, I have a fatal error. If I add to cpp the compilation switches -DTOTO1 -DTOTO2 instead -imacros, the compilation is OK. But I have to use -imacros option, in the near future the project I work on will have thousands of switches. Does someone have a clue on this issue ? Thank you ! -- Summary: -imacros option does not work on gcc 4.2.1 scratchbox Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: frederic dot chifflet-nonst at stericsson dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42091
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #8 from mexas at bristol dot ac dot uk 2009-11-18 12:30 --- this seems to help to pass that error, now I'm stopped with this: [skip] # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. /bin/sh ../.././../gcc-4.4-20091110/libgcc/../mkinstalldirs . /usr/ports/lang/gcc44/work/build/./gcc/xgcc -B/usr/ports/lang/gcc44/work/build/./gcc/ -B/usr/local/ia64-portbld-freebsd9.0/bin/ -B/usr/local/ia64-portbld-freebsd9.0/lib/ -isystem /usr/local/ia64-portbld-freebsd9.0/include -isystem /usr/local/ia64-portbld-freebsd9.0/sys-include -O2 -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -B./ __divxf3_s.o __divdf3_s.o __divsf3_s.o __divdi3_s.o __moddi3_s.o __udivdi3_s.o __umoddi3_s.o __divsi3_s.o __modsi3_s.o __udivsi3_s.o __umodsi3_s.o __save_stack_nonlocal_s.o __nonlocal_goto_s.o __restore_stack_nonlocal_s.o __trampoline_s.o _fixtfdi_s.o _fixunstfdi_s.o _floatditf_s.o _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-ia64_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so unwind-ia64_s.o(.text+0x1b62): In function `_Unwind_FindEnclosingFunction': ../.././../gcc-4.4-20091110/libgcc/../gcc/config/ia64/unwind-ia64.c:1736: undefined reference to `_Unwind_FindTableEntry' unwind-ia64_s.o(.text+0x1e32): In function `uw_frame_state_for': ../.././../gcc-4.4-20091110/libgcc/../gcc/config/ia64/unwind-ia64.c:1779: undefined reference to `_Unwind_FindTableEntry' /usr/bin/ld: ./libgcc_s.so.1.tmp: hidden symbol `_Unwind_FindTableEntry' isn't defined collect2: ld returned 1 exit status gmake[3]: *** [libgcc_s.so] Error 1 gmake[3]: Leaving directory `/usr/ports/lang/gcc44/work/build/ia64-portbld-freebsd9.0/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/usr/ports/lang/gcc44/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc44/work/build' gmake: *** [bootstrap-lean] Error 2 *** Error code 1 Stop in /usr/ports/lang/gcc44. *** Error code 1 Stop in /usr/ports/lang/gcc44. TZAV# -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
-- enrico dot scholz at informatik dot tu-chemnitz dot de changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug c++/40892] maybe_warn_cpp0x i18n problems
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-18 11:37 --- Fixed for 4.5.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40892
[Bug c++/40892] maybe_warn_cpp0x i18n problems
--- Comment #2 from paolo at gcc dot gnu dot org 2009-11-18 11:36 --- Subject: Bug 40892 Author: paolo Date: Wed Nov 18 11:36:00 2009 New Revision: 154288 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154288 Log: /cp 2009-11-18 Shujing Zhao PR c++/40892 * error.c (maybe_warn_cpp0x): Accept enum cpp0x_warn_str as argument. (maybe_warn_variadic_templates): Update the maybe_warn_cpp0x calls to match the new declaration. * cp-tree.h (cpp0x_warn_str): New type. (maybe_warn_cpp0x): Adjust prototype with new argument. * call.c (reference_binding): Update the maybe_warn_cpp0x calls. * decl.c (reshape_init_r, check_initializer, grokdeclarator): Likewise. * parser.c (cp_parser_primary_expression) (cp_parser_parenthesized_expression_list, cp_parser_new_initializer) (cp_parser_assignment_expression, cp_parser_condition) (cp_parser_jump_statement, cp_parser_mem_initializer) (cp_parser_simple_type_specifier, cp_parser_elaborated_type_specifier) (cp_parser_enum_specifier, cp_parser_initializer) (cp_parser_pure_specifier, cp_parser_functional_cast): Likewise. /testsuite 2009-11-18 Shujing Zhao * g++.old-deja/g++.other/crash28.C: Make expected dg-error strings explicit. * g++.dg/inherit/error4.C: Likewise. * g++.dg/template/crash90.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/error.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/inherit/error4.C trunk/gcc/testsuite/g++.dg/template/crash90.C trunk/gcc/testsuite/g++.old-deja/g++.other/crash28.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40892
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-18 11:17 --- Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope > --- Comment #5 from YLitvinenko at astana dot oilfield dot slb dot com > 2009-11-18 07:03 --- > Is it better to let configure guess about thread model on OpenSolaris x86 > 32bit > build >= snv_126? Sure: the default should be fine unless you have specific reasons to prefer UI threads instead. This has nothing to do with OpenSolaris in any way, but is true for any recent Solaris 2 release. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug c/42076] regression on float representation
--- Comment #2 from vaillant dot etienne at gmail dot com 2009-11-18 11:17 --- (In reply to comment #1) > You are likely running into excess precision issues of i?86. Try using > -mpc64 or -mfpmath=sse. > I try : $ gcc-4.4 -msse2 y.c -o y-4.4 $ ./y-4.4 ration=0.21 ratio*1000=209 same problem :( I watch asm code and : c code : double ratio = 0.21; asm code on 4.3 : fldl 0x8048580 fstpl -0x10(%ebp) asm code en 4.4 : fldl 0x8048590 fstpl 0x38(%esp) I think the is on 0x8048580 and 0x8048590 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42076
[Bug middle-end/22201] Parameter description strings should all start with a capital letter
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-18 11:11 --- Fixed for 4.5.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22201
[Bug middle-end/22201] Parameter description strings should all start with a capital letter
--- Comment #2 from paolo at gcc dot gnu dot org 2009-11-18 11:10 --- Subject: Bug 22201 Author: paolo Date: Wed Nov 18 11:09:50 2009 New Revision: 154287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154287 Log: 2009-11-18 Shujing Zhao PR middle-end/22201 * params.def (PARAM_INLINE_UNIT_GROWTH) PARAM_IPCP_UNIT_GROWTH) (PARAM_EARLY_INLINING_INSNS, PARAM_IRA_MAX_LOOPS_NUM) (PARAM_IRA_MAX_CONFLICT_TABLE_SIZE) (PARAM_LOOP_INVARIANT_MAX_BBS_IN_LOOP) (PARAM_MIN_INSN_TO_PREFETCH_RATIO) (PARAM_PREFETCH_MIN_INSN_TO_MEM_RATIO) PARAM_IPA_SRA_PTR_GROWTH_FACTOR): Uppercase the first letter of the description string. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22201
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #2 from burnus at gcc dot gnu dot org 2009-11-18 11:03 --- It's a regression with regards to 4.1.2. Jerry can you have a look? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Keywords||wrong-code Known to fail||4.3.4 4.4.1 4.5.0 Known to work||4.1.2 Summary|Problems when reading |[4.3/4.4/4.5 Regression] |partial records in formatted|I/O: Problems when reading |direct access files |partial records in formatted ||direct access files Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug fortran/42089] Problems when readinf partial records on direct access files
--- Comment #1 from burnus at gcc dot gnu dot org 2009-11-18 10:57 --- *** This bug has been marked as a duplicate of 42090 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42089
[Bug fortran/42090] Problems when reading partial records in formatted direct access files
--- Comment #1 from burnus at gcc dot gnu dot org 2009-11-18 10:57 --- *** Bug 42089 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug lto/42020] field not merged causes cc1 to be miscompiled
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-18 10:55 --- Hm, the assert doesn't trigger if I add a tem != field check. In fact I do not understand the assert you added at all ;) We do find the correct field, if that ends up still being the wrong one then DECL_CONTEXT is already wrong which means we end up not unifying types as we should. In fact for the testcase both FIELD_DECLs of the two COMPONENT_REFs for new_bb->succs and bb->succs are the same. So - did you just not properly reduce the testcase? The assert to be put in I suggested would have been Index: gcc/lto-streamer-in.c === --- gcc/lto-streamer-in.c (revision 154283) +++ gcc/lto-streamer-in.c (working copy) @@ -1091,8 +1091,8 @@ input_gimple_stmt (struct lto_input_bloc /* In case of type mismatches across units we can fail to unify some types and thus not find a proper field-decl here. Just do nothing in this case. */ - if (tem != NULL_TREE) - TREE_OPERAND (op, 1) = tem; + gcc_assert (tem != NULL_TREE); + TREE_OPERAND (op, 1) = tem; } op = TREE_OPERAND (op, 0); which I probably should re-add under ENABLE_CHECKING at least (I think it failed somewhere in SPEC though). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42020
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-18 10:32 --- Oh, the UIDs appear in the dumps you compare. That's a bug in your comparer, we never said different UIDs are not ok, only codegen differences are not (and yes, UID _ordering_ differences have a great chance of causing them, but mere differences are not). Please fix your comparer. The tree.c issue didn't show up with a regular bootstrap-debug? Or is that because of the flag_gtoggle check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-18 10:28 ---
Hmpf, no testcases ...
./xgcc -B. -c tree.i -O -g -fcompare-debug=-g0
has a compare-debug failure (-O0 does not). Fixed by
Index: gcc/tree.c
===
--- gcc/tree.c (revision 154283)
+++ gcc/tree.c (working copy)
@@ -4313,7 +4313,8 @@ free_lang_data_in_block (tree fn, tree b
tp = &BLOCK_VARS (block);
while (*tp)
{
- if (!pointer_set_contains (locals, *tp))
+ if (TREE_CODE (*tp) == VAR_DECL
+ && !pointer_set_contains (locals, *tp))
*tp = TREE_CHAIN (*tp);
else
tp = &TREE_CHAIN (*tp);
Note that UID differences that do not change UID order are a red herring
IMHO and should be tracked down and fixed. Any idea where this particular
one comes from? Most of the time it's walking hashtables in hash order,
like FOR_EACH_REFERENCED_VAR does. Relevant such walkings might be
in insert_phi_nodes, analyze_all_variable_accesses (both easy to fix,
but fixing them doesn't fix the debug miscompare).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-18 10:28:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug tree-optimization/42084] [4.5 Regression] Wrong result with -Os -fno-delete-null-pointer-checks
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-18 09:57 --- Confirmed. Only fails with -m32 on x86_64. It is VRP that triggers the miscompile, thus -O1 -ftree-vrp -fno-delete-null-pointer-checks is enough. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.5.0 Known to work||4.4.2 Last reconfirmed|-00-00 00:00:00 |2009-11-18 09:57:53 date|| Summary|Wrong result with -Os -fno- |[4.5 Regression] Wrong |delete-null-pointer-checks |result with -Os -fno-delete- ||null-pointer-checks Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42084
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #35 from jakub at gcc dot gnu dot org 2009-11-18 09:54 --- Subject: Bug 3187 Author: jakub Date: Wed Nov 18 09:53:52 2009 New Revision: 154284 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154284 Log: PR c++/3187 * cgraph.h (struct cgraph_node): Add same_body and same_body_alias fields. (cgraph_same_body_alias, cgraph_remove_same_body_alias): New prototypes. * cgraphunit.c (cgraph_expand_function, cgraph_emit_thunks, cgraph_materialize_all_clones): Handle same_body aliases. * cgraph.c (cgraph_allocate_node): New function. (cgraph_create_node): Use it. (cgraph_node_for_decl, cgraph_node, cgraph_get_node, cgraph_node_for_asm, cgraph_remove_node): Handle same_body aliases. (cgraph_same_body_alias, cgraph_remove_same_body_alias): New functions. * lto-cgraph.c (lto_output_node): Stream out same_body aliases. (input_node): Stream in same_body aliases. * lto-symtab.c (lto_cgraph_replace_node): Clear node pointers for same_body aliases. (lto_symtab_merge_cgraph_nodes_1): Handle same_body aliases. * cp-tree.h (expand_or_defer_fn_1): New prototype. * decl2.c (cp_write_global_declarations): Mark as !DECL_EXTERNAL also all same_body aliases. * semantics.c (expand_or_defer_fn): Move most of the function except registering with cgraph to ... (expand_or_defer_fn_1): ... here. New function. * optimize.c: Include cgraph.h. (maybe_clone_body): If in charge parm is not used and both base and complete clones are created and are not comdat, tell cgraph they have the same body. * Make-lang.in (cp/optimize.o): Depend on $(CGRAPH_H). * g++.dg/abi/mangle26.C: Also match *C2* definition. * g++.dg/abi/mangle27.C: Likewise. * g++.dg/abi/mangle28.C: Likewise. * g++.dg/abi/mangle29.C: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/optimize.c trunk/gcc/cp/semantics.c trunk/gcc/lto-cgraph.c trunk/gcc/lto-symtab.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/mangle26.C trunk/gcc/testsuite/g++.dg/abi/mangle27.C trunk/gcc/testsuite/g++.dg/abi/mangle28.C trunk/gcc/testsuite/g++.dg/abi/mangle29.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug fortran/42090] New: Problems when reading partial records in formatted direct access files
Consider the following: Wot now ? cat da.f90 Program da Implicit None Real :: a, b a = 1.1 b = 2.2 Open( 10, File = 't.dat', Form = 'Formatted', Access = 'Direct', Recl = 12 ) Write( 10, rec = 1, fmt = '( f6.4, /, f6.4 )' ) a, b Close( 10 ) a = -1.0 b = -1.0 Open( 10, File = 't.dat', Form = 'Formatted', Access = 'Direct', Recl = 12 ) Read( 10, rec = 1, fmt = '( f6.4, /, f6.4 )' ) a, b Write( *, '( "Partial record 1", t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f6.4 )' ) a, b Write( *, '( "Partial record 2", t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f12.4, /, f12.4 )' ) a, b Write( *, '( "Full record 1", t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f12.4 )' ) a, b Write( *, '( "Full record 2", t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f6.4, 6x, /, f6.4, 6x )' ) a, b Write( *, '( "Full record with 6x", t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f6.4 )' ) a Read( 10, rec = 2, fmt = '( f6.4 )' ) b Write( *, '( "Record at a time", t25, 2( f6.4, 1x ) )' ) a, b End Program da Wot now ? ~/Download/usr/local/gfortran/bin/gfortran --version GNU Fortran (GCC) 4.5.0 20091116 (experimental) [trunk revision 154218] Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Wot now ? ~/Download/usr/local/gfortran/bin/gfortran -W -Wall -pedantic -fbounds-check -g -O2 da.f90 Wot now ? ./a.out Partial record 11. 0. Partial record 21. 0. Full record 1 1. 2. Full record 2 1. 2. Full record with 6x 1. 2. Record at a time1. 2. Wot now ? Note that when reading partial records gfortran gets the value of b wrong. Compare g95 and the sun fortran compiler: Wot now ? g95 --version G95 (GCC 4.0.3 (g95 0.92!) Mar 27 2009) Copyright (C) 2002-2008 Free Software Foundation, Inc. G95 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of G95 under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Wot now ? g95 -W -Wall -pedantic -fbounds-check -g -O2 da.f90 Wot now ? ./a.out Partial record 11. 2. Partial record 21. 2. Full record 1 1. 2. Full record 2 1. 2. Full record with 6x 1. 2. Record at a time1. 2. Wot now ? f90 -V f90: Sun Fortran 95 8.4 Linux_i386 2009/06/03 Usage: f90 [ options ] files. Use 'f90 -flags' for details Wot now ? f90 da.f90 Wot now ? ./a.out Partial record 11. 2. Partial record 21. 2. Full record 1 1. 2. Full record 2 1. 2. Full record with 6x 1. 2. Record at a time1. 2. I've also checked against the intel, portland group, pathscale and cray compilers and they all give what I think is the correct result, i.e. the same as g95 and the sun compiler Also sorry about screwing up the first attempt at submission ! -- Summary: Problems when reading partial records in formatted direct access files Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian dot bush at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug fortran/42089] New: Problems when readinf partial records on direct access files
-- Summary: Problems when readinf partial records on direct access files Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian dot bush at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42089
