[Bug target/24055] [4.1 regression] "could not split insn" with -O1 -ffast-math
--- Additional Comments From uros at kss-loka dot si 2005-09-26 07:35 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01581.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg01581.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-09-25 14:23:12 |2005-09-26 07:35:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24055
[Bug target/24027] A gcc primitive, under special circumstances, can crash the AVR
--- Additional Comments From zoltan at bendor dot com dot au 2005-09-26 07:42 --- Subject: A gcc primitive, under special circumstances, can crash the AVR > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23 > 12:56 --- > Is there some source someone can look at? Yes, I attach an assembly source that details the bug and also serves a self-contained testcode that demonstrates the bug. It should be noted that the bug is in the AVR core (or its incomplete documentation) and *not* in gcc, but gcc can very easily work around the bug. Best Regards, Zoltan --- Additional Comments From zoltan at bendor dot com dot au 2005-09-26 07:42 --- Created an attachment (id=9806) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9806&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24027
[Bug libfortran/20406] SIZE() matters?
--- Additional Comments From dave dot offiler at metoffice dot gov dot uk 2005-09-26 08:04 --- Subject: Re: SIZE() matters? Accepted, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20406
[Bug c++/22172] [3.4/4.0/4.1 Regression] Internal compiler error, seg fault.
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-26
08:09 ---
I don't think that this is a proper fix, since the following IMHO valid
code snippet is rejected:
namespace N { template struct A { operator int() const; }; }
template void foo()
{
+typename N::A<0>();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug c++/24063] New: Invalid promotion with -fshort-enums
The following code doesn't compile with -fshort-enums option.
$ cat enum.cpp
enum E { E_value = 32768 };
template struct is_same;
template struct is_same {};
int main()
{
typedef typeof(+E_value) promoted;
is_same ok;
}
$ g++ enum.cpp
$
$ g++ -fshort-enums enum.cpp
enum.cpp: In function `int main()':
enum.cpp:10: error: aggregate `is_same ok' has incomplete
type and cannot be defined
$
$ g++ -v
Reading specs from /opt/arina/tools/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ../../gcc-3.4.4/configure --prefix=/opt/arina/tools
--disable-nls --with-system-zlib --enable-languages=c++ --enable-threads=posix
--enable-long-long --disable-checking --enable-__cxa_atexit
--enable-version-specific-runtime-libs
--with-gxx-include-dir=/opt/arina/tools/include/g++-3.4.4 --with-libiberty=no
--program-suffix=-3.4.4
Thread model: posix
According to the standard, E should be promoted to int because its the only
value can be represented by int.
Indeed, enum.cpp complies fine without -fshort-enums option.
However, if -fshort-enums option is passed to g++, E gets promoted to unsigned
int.
--
Summary: Invalid promotion with -fshort-enums
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Alexander dot Nasonov at db dot com
CC: gcc-bugs at gcc dot gnu dot org
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=24063
[Bug middle-end/15855] [3.4/4.0/4.1 Regression] g++ crash with -O2 and -O3 on input file
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 08:38 --- Subject: Bug 15855 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 08:38:32 Modified files: gcc: ChangeLog gcse.c Log message: 2005-09-26 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/15855 * gcse.c: Include hashtab.h, define ldst entry hashtable. (pre_ldst_expr_hash, pre_ldst_expr_eq): New functions. (ldst_entry): Use the hashtable instead of list-walking. (find_rtx_in_ldst): Likewise. (free_ldst_entry): Free the hashtable. (compute_ld_motion_mems): Create the hashtable. (trim_ld_motion_mems): Remove entry from hashtable if removing it from list. (compute_store_table): Likewise^2. (store_motion): Free hashtable in case we did not see any stores. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10020&r2=2.10021 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcse.c.diff?cvsroot=gcc&r1=1.348&r2=1.349 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug middle-end/15855] [3.4/4.0/4.1 Regression] g++ crash with -O2 and -O3 on input file
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 08:43 --- Subject: Bug 15855 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 08:43:00 Modified files: gcc/cp : ChangeLog decl2.c Log message: 2005-09-26 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/15855 * decl2.c (do_static_destruction): Remove. (finish_static_initialization_or_destruction): Likewise. (DECL_EFFECTIVE_INIT_PRIORITY): New macro. (NEEDS_GUARD_P): Likewise. (do_static_initialization): Rename to do_static_initialization_or_destruction. Process all initializers/destructors and handle common conditionalizing. (start_static_initialization_or_destruction): Rename to one_static_initialization_or_destruction. Handle only decl-specific conditionalizing. (cp_finish_file): Call do_static_initialization_or_destruction. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4901&r2=1.4902 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.802&r2=1.803 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug middle-end/23831] [4.1 Regression] ICE in immed_double_const with vectorized multipication
--- Additional Comments From uros at kss-loka dot si 2005-09-26 08:59 --- This is in fact middle-end problem. Patch at http://gcc.gnu.org/ml/gcc- patches/2005-09/msg01583.html. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg01583.html Status|NEW |ASSIGNED Component|target |middle-end Keywords||patch Last reconfirmed|2005-09-12 13:51:38 |2005-09-26 08:59:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23831
[Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
--- Additional Comments From pcarlini at suse dot de 2005-09-26 09:16 --- Then, issue 6.19 of N1837 (Library Extension Technical Report - Issues List) should be also updated... Certainly, this inconsistency between the (associative, see DR130) containers and the new unordered containers is annoying... -- What|Removed |Added CC||austern at gcc dot gnu dot ||org BugsThisDependsOn||24054 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
[Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
--- Additional Comments From pcarlini at suse dot de 2005-09-26 09:42 --- Actually, on second thought, I'm not sure we should give up consistency so easily only because the it = t.erase(it) idiom cannot be meaningfully used together with unordered containers: otherwise, why, f.i., vector::erase returns an iterator?!?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
[Bug libstdc++/24064] New: tr1::unordered_map seems to seg-fault when caching hash values
The following snippet of code seg-faults: typedef std::tr1::unordered_map< int, char, __gnu_cxx::hash< int>, std::equal_to< int>, std::allocator< std::pair< const int, char> >, true> // (*) map_t; map_t m; int i; for(i = 0; i < 1000; ++i) m[i] = 'a'; for(i = 0; i < 1000; ++i) ++m.find(i)->second; If, however, the value in the line marked with (*) is changed to false (i.e., the container does not cache hash values), it runs fine. g++ --version outputs: g++ (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) Thanks! -- Summary: tr1::unordered_map seems to seg-fault when caching hash values Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: atavory at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24064
[Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
--- Additional Comments From pcarlini at suse dot de 2005-09-26 10:03 --- To be clear: my impression is that the resolution of DR130 was dictated by and large by consistency and that the current wording for the iterator returned by erase would be Ok also for unordered containers (besides all the other containers). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
[Bug bootstrap/23776] configure: error: no acceptable cc found in $PATH
--- Additional Comments From filip693 at wp dot pl 2005-09-26 10:13 --- Subject: Odp: configure: error: no acceptable cc found in $PATH Where can I download a compiler from and how to install it? Thanks for help. Dnia 8-09-2005 o godz. 13:06 pinskia at gcc dot gnu dot org napisa³(a): > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-08 11:06 --- > Do you have a compiler installed? > You need a compiler installed to build/install GCC. > > -- >What|Removed |Added > -- -- > Status|UNCONFIRMED |WAITING > Component|debug |bootstrap > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23776 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > SIN CITY - Miasto Grzechu. Najnowszy film Rodrigueza i Tarantino w wypo¿yczalniach DVD i wideo! http://klik.wp.pl/?adr=www.film.wp.pl%2Ffilm.html%3Fid%3D24839%26h%3D1&sid=516 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23776
[Bug libstdc++/24064] tr1::unordered_map seems to seg-fault when caching hash values
--- Additional Comments From pcarlini at suse dot de 2005-09-26 10:17 --- Just a side note for now: the entire cached/non-cached thing should be carefully reviewed as soon as possible, because it's certainly not standard conforming adding additional template parameters (see DR94, in particular the Rationale). This implies that, *short-term* indeed, we could simply remove the argument and disable the possibility of caching (while keeping & reviewing the infrastructure) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24064
[Bug tree-optimization/24059] [4.1 Regression] ICE with -ftree-vectorize -O2
--- Additional Comments From uros at kss-loka dot si 2005-09-26 10:21 --- Confirmed, ICEs also on i686 with -O2 -msse2 -ftree-vectorize: gcc -O2 -msse2 -ftree-vectorize pr24059.c pr24059.c: In function 'compute_predicate_codes': pr24059.c:10: internal compiler error: in expand_expr_real_1, at expr.c:6935 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|x86_64-unknown-linux-gnu|i686-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2005-09-26 10:21:18 date|| Summary|[4.1 Regression] ICE with - |[4.1 Regression] ICE with - |ftree-vectorize -O2 |ftree-vectorize -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24059
[Bug c/24065] New: "Designated (dot) Initializers" with "Unnamed struct/union fields within structs/unions"
"Designated (dot) Initializers" and "Unnamed struct/union fields" are regular
constructs in gcc, though, they connot be parsed together.
(tested up to gcc 3.3.3)
typedef struct {
union {
long MV;
int mv[2];
struct {
int x;
int y;
};
};
int z;
}foo_t;
foo_t foo[2] = {
{
.z=2,
.mv={0,1},
},
{
.z=5,
.y=4,
.x=3,
},
};
foo_t foo2[2]= {
{.z=2,.MV=0x0001},
{.z=5,.MV=0x00030002},
};
--
Summary: "Designated (dot) Initializers" with "Unnamed
struct/union fields within structs/unions"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benoit dot guerin at thomson dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24065
[Bug c/24065] "Designated (dot) Initializers" with "Unnamed struct/union fields within structs/unions"
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-09-26 12:15 --- *** This bug has been marked as a duplicate of 10676 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24065
[Bug c/10676] Using unnamed fields in initializers
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-09-26 12:15 --- *** Bug 24065 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||benoit dot guerin at thomson ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[Bug treelang/24066] New: almost all treelang testsuite fails with -maltivec as an option
The warning which is produced: /Users/pinskia/src/ns/gcc/gcc/testsuite/treelang/compile/extrafunc.tree:0: warning: 'const' attribute directive ignored -- Summary: almost all treelang testsuite fails with -maltivec as an option Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P2 Component: treelang AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24066
[Bug treelang/24066] almost all treelang testsuite fails with -maltivec as an option
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 12:23 --- http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01199.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24066
[Bug c++/24063] [3.4 Regression] Invalid promotion with -fshort-enums
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 12:28 --- Confirmed only a 3.4 regression. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid, wrong-code Known to fail||3.4.0 Known to work||4.0.0 4.1.0 3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-09-26 12:28:28 date|| Summary|Invalid promotion with -|[3.4 Regression] Invalid |fshort-enums|promotion with -fshort-enums Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24063
[Bug ada/23995] GNAT BUG DETECTED
--- Additional Comments From michael dot foerster at eads dot com 2005-09-26 13:14 --- (In reply to comment #1) > no ICE on x86 and x86_64, must be sparc specific. I agree, I generated the ADA compiler on a x86 and it works. Additional: compileing the test file succeeds with the following versions on Solaris9/sparc: 3.3 (date unknown) 3.5.0 20040412 (experimental) 4.1.0 20050917 (experimental) With regards Michael Foerster -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23995
[Bug tree-optimization/23049] [4.1 Regression] ICE with -O3 -ftree-vectorize on 4.1.x
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 13:20 --- This is also testsuite/gcc.c-torture/execute/builtin-bitops-1.c failure with "-ftree-vectorize -maltivec" on powerpc-darwin, see http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01199.html http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01201.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049
[Bug target/23602] [4.1 regression] 1081 test failures in libjava, when configured for i486-linux
--- Additional Comments From debian-gcc at lists dot debian dot org 2005-09-26 13:22 --- after an update to 2005-09-25, the bug seems to be hidden again, a diff on the test summary i686/i486 Matthias --- ../test-summary-i6862005-09-26 01:56:04.465389392 + +++ test-summary2005-09-26 13:11:28.149852952 + @@ -25,13 +25,15 @@ FAIL: gcc.dg/cleanup-11.c execution test FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test +XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times link_error 0 FAIL: gcc.dg/vect/pr20122.c scan-tree-dump-times vectorized 1 loops 2 === gcc Summary === # of expected passes 37375 # of unexpected failures 5 -# of expected failures 96 +# of unexpected successes 1 +# of expected failures 95 # of untested testcases28 # of unsupported tests 344 /home/packages/gcc/snap/gcc-snapshot-20050925/build/gcc/xgcc version 4.1.0 20050925 (experimental) @@ -85,10 +87,13 @@ Running target unix +FAIL: objc/execute/exceptions/catchall-1.m execution, -O3 -fomit-frame-pointer -fgnu-runtime +FAIL: objc/execute/exceptions/local-variables-1.m execution, -O3 -fomit-frame-pointer -fgnu-runtime === objc Summary === -# of expected passes 1672 +# of expected passes 1670 +# of unexpected failures 2 # of unsupported tests 22 /home/packages/gcc/snap/gcc-snapshot-20050925/build/gcc/xgcc version 4.1.0 20050925 (experimental) @@ -113,12 +118,32 @@ Running target unix +FAIL: ArrayStore -O3 execution - source compiled test +FAIL: ArrayStore -O3 execution - bytecode->native test +FAIL: Divide_1 -O3 execution - source compiled test +FAIL: Divide_1 -O3 execution - bytecode->native test +FAIL: Invoke_1 -O3 execution - source compiled test +FAIL: Serialization execution - source compiled test +FAIL: Serialization execution - gij test +FAIL: Serialization execution - bytecode->native test +FAIL: Serialization -O3 execution - source compiled test +FAIL: Serialization execution - gij test +FAIL: Serialization -O3 execution - bytecode->native test +FAIL: String_overflow -O3 execution - source compiled test +FAIL: Thread_Interrupt -O3 execution - source compiled test +FAIL: Throw_1 -O3 execution - source compiled test +FAIL: initexc -O3 execution - source compiled test +FAIL: instinit2 -O3 execution - source compiled test +FAIL: instinit2 -O3 execution - bytecode->native test +FAIL: newarray_overflow -O3 execution - source compiled test +FAIL: newarray_overflow -O3 execution - bytecode->native test === libjava Summary === -# of expected passes 3968 -# of expected failures 10 -# of untested testcases8 +# of expected passes 3931 +# of unexpected failures 19 +# of expected failures 9 +# of untested testcases27 === libmudflap tests === @@ -228,7 +253,7 @@ Compiler version: 4.1.0 20050925 (experimental) Platform: i486-pc-linux-gnu -configure flags: -v --prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/gcc-snapshot/jre --enable-mpfr --disable-werror --with-arch=i686 --with-tune=i686 i486-linux-gnu --enable-languages=c,c++,fortran,java,objc,obj-c++,treelang +configure flags: -v --prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/gcc-snapshot/jre --enable-mpfr --disable-werror --with-arch=i486 --with-tune=i686 i486-linux-gnu --enable-languages=c,c++,fortran,java,objc,obj-c++,treelang BOOT_CFLAGS=-O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23602
[Bug libstdc++/24064] tr1::unordered_map seems to seg-fault when caching hash values
--- Additional Comments From chris at bubblescope dot net 2005-09-26 13:42 --- I'm not convinced that this is valid code.. unless I'm missing something, you are altering values inside the hash table, which isn't allowed unless you change the values in such a way that their hashed value stays the same. This is similar to the situation with (multi)map/(multi)set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24064
[Bug libstdc++/24064] tr1::unordered_map seems to seg-fault when caching hash values
--- Additional Comments From chris at bubblescope dot net 2005-09-26 13:47 --- Sorry, you are of course changing the second value, which is fine. It's the first one you shouldn't change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24064
[Bug rtl-optimization/9240] weird scheduling on v850 unless -fno-sched-spec specified
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 15:21 --- I think the patch at http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00370.html will fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9240
[Bug rtl-optimization/9350] -fomit-frame-pointer does not work for main
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 15:24 --- The note in the documention should be expanded to say approximately "-fomit-frame-pointer does nothing for the function main as it is the entry point and the need for realigning the stack is needed". -- What|Removed |Added GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9350
[Bug rtl-optimization/13049] Does not warn on obvious aliasing problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 15:38 --- Even -Wstrict-aliasing=2 does not warn. -- What|Removed |Added Last reconfirmed|2005-05-27 00:40:18 |2005-09-26 15:38:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13049
[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
-- What|Removed |Added Keywords||alias Last reconfirmed|2005-05-26 12:37:22 |2005-09-26 15:42:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319
[Bug ada/23995] [4.0 regression] ICE on misaligned rep clause
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-26 16:01 --- > no ICE on x86 and x86_64, must be sparc specific. > I agree, I generated the ADA compiler on a x86 and it works. Confirmed. strict-alignment specific I presume. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to work||3.3 Last reconfirmed|-00-00 00:00:00 |2005-09-26 16:01:38 date|| Summary|GNAT BUG DETECTED |[4.0 regression] ICE on ||misaligned rep clause http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23995
[Bug target/23150] 20050713-1.c fails on arm-none-eabi with -O2 or -Os.
--- Additional Comments From kazu at gcc dot gnu dot org 2005-09-26 16:13
---
Slightly reduced to:
extern void abort (void) __attribute__((noreturn));
struct S
{
int a, b, c;
};
void
foo2 (struct S x, struct S y)
{
if (x.b != 4)
abort ();
}
void
bar2 (struct S x, struct S y)
{
foo2 (y, x);
}
int
main (void)
{
struct S a = { 3, 4, 5 }, b = { 6, 7, 8 };
bar2 (b, a);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23150
[Bug ada/24053] [4.1 Regression] Ada bootstrap ICE in build_int_cst_wide, at tree.c:795
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-26 16:56 --- This works at -O on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24053
[Bug target/24055] [4.1 regression] "could not split insn" with -O1 -ffast-math
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
17:21 ---
Subject: Bug 24055
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 17:21:02
Modified files:
gcc: ChangeLog
gcc/config/i386: i386.md
Log message:
PR target/24055
* config/i386/i386.md ("*fistdi2_1"): New pattern.
("*fist2_1"): Use only HImode and SImode register operands.
("fist2_with_temp"): Use only register operands.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10022&r2=2.10023
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.655&r2=1.656
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24055
[Bug target/24055] [4.1 regression] "could not split insn" with -O1 -ffast-math
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 17:26 --- Subject: Bug 24055 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 17:25:49 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: pr24055.c Log message: PR target/24055 * gcc.target/i386/pr24055.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6102&r2=1.6103 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr24055.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24055
[Bug c++/22172] [3.4/4.0/4.1 Regression] Internal compiler error, seg fault.
--- Additional Comments From phython at gcc dot gnu dot org 2005-09-26 17:31 --- So this is an ice-on-valid and an ice-on-invalid bug then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug middle-end/23831] [4.1 Regression] ICE in immed_double_const with vectorized multipication
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 18:16 --- Subject: Bug 23831 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 18:16:11 Modified files: gcc: ChangeLog simplify-rtx.c Log message: PR middle-end/23831 * simplify-rtx.c (simplify_immed_subreg) [MODE_INT]: Skip simplification if elem_bitsize > 2 * HOST_BITS_PER_WIDE_INT. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10024&r2=2.10025 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/simplify-rtx.c.diff?cvsroot=gcc&r1=1.247&r2=1.248 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23831
[Bug middle-end/23831] [4.1 Regression] ICE in immed_double_const with vectorized multipication
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 18:18 --- Subject: Bug 23831 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 18:17:54 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/vect: pr23831.c Log message: PR middle-end/23831 * gcc.dg/vect/pr23831.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6103&r2=1.6104 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/pr23831.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23831
[Bug tree-optimization/23942] [4.1 Regression] loop problem / testcase takes very long time to compile
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 18:43 --- Subject: Bug 23942 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 18:43:09 Modified files: gcc: ChangeLog tree-scalar-evolution.c Log message: PR tree-optimization/23942 * Makefile.in (SCEV_H): Depends on PARAMS_H. * tree-scalar-evolution.c: Include params.h. (t_bool): New enum. (follow_ssa_edge, follow_ssa_edge_in_rhs, follow_ssa_edge_in_condition_phi_branch, follow_ssa_edge_in_condition_phi, follow_ssa_edge_inner_loop_phi): Change return type to t_bool. Use a parameter to limit the size of trees that are walked before stopping (analyze_evolution_in_loop): Initialize the limit to 0. (follow_ssa_edge): Give up by returning t_dont_know if the limit exceeds PARAM_SCEV_MAX_EXPR_SIZE. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10025&r2=2.10026 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.c.diff?cvsroot=gcc&r1=2.38&r2=2.39 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23942
[Bug tree-optimization/23942] [4.1 Regression] loop problem / testcase takes very long time to compile
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 18:44 --- Subject: Bug 23942 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 18:44:23 Modified files: gcc: Makefile.in Log message: PR tree-optimization/23942 * Makefile.in (SCEV_H): Depends on PARAMS_H. * tree-scalar-evolution.c: Include params.h. (t_bool): New enum. (follow_ssa_edge, follow_ssa_edge_in_rhs, follow_ssa_edge_in_condition_phi_branch, follow_ssa_edge_in_condition_phi, follow_ssa_edge_inner_loop_phi): Change return type to t_bool. Use a parameter to limit the size of trees that are walked before stopping (analyze_evolution_in_loop): Initialize the limit to 0. (follow_ssa_edge): Give up by returning t_dont_know if the limit exceeds PARAM_SCEV_MAX_EXPR_SIZE. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1541&r2=1.1542 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23942
[Bug c++/22172] [3.4/4.0/4.1 Regression] Internal compiler error, seg fault.
--- Additional Comments From bangerth at dealii dot org 2005-09-26 19:00 --- The testcase in comment #3 shows an ice-on-invalid. The testcase in comment #7 is valid, and ices anyway. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug target/23847] Darwin -mpowerpc64 complex ABI breakage
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 19:13 --- Subject: Bug 23847 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 19:12:34 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.c Log message: PR target/23847. Oked by David Edelsohn. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10026&r2=2.10027 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.869&r2=1.870 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23847
[Bug target/22576] [4.0/4.1 regression] ICE with simple factorial program compiled with -ffast-math on gcc 4.0.2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 19:20 --- Subject: Bug 22576 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 19:19:43 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: pr22576.c pr22585.c pr23268.c builtin-apply-mmx.c Log message: 2005-08-26 Uros Bizjak <[EMAIL PROTECTED]> * gcc.target/i386/builtin-apply-mmx.c: New test. PR target/22576 * gcc.target/i386/pr22576.c: New test. PR target/22585 * gcc.target/i386/pr22585.c: New test. PR target/23268 * gcc.target/i386/pr23268.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6104&r2=1.6105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr22576.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr22585.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr23268.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/builtin-apply-mmx.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22576
[Bug target/22585] [4.0 regression] ICE with long doubles in expand_simple_unop
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 19:20 --- Subject: Bug 22585 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 19:19:43 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: pr22576.c pr22585.c pr23268.c builtin-apply-mmx.c Log message: 2005-08-26 Uros Bizjak <[EMAIL PROTECTED]> * gcc.target/i386/builtin-apply-mmx.c: New test. PR target/22576 * gcc.target/i386/pr22576.c: New test. PR target/22585 * gcc.target/i386/pr22585.c: New test. PR target/23268 * gcc.target/i386/pr23268.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6104&r2=1.6105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr22576.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr22585.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr23268.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/builtin-apply-mmx.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22585
[Bug target/23268] [4.1 Regression] ICE using math functions log & rint, -ffast-math, -O1 (,2,3,s)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 19:20 --- Subject: Bug 23268 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 19:19:43 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: pr22576.c pr22585.c pr23268.c builtin-apply-mmx.c Log message: 2005-08-26 Uros Bizjak <[EMAIL PROTECTED]> * gcc.target/i386/builtin-apply-mmx.c: New test. PR target/22576 * gcc.target/i386/pr22576.c: New test. PR target/22585 * gcc.target/i386/pr22585.c: New test. PR target/23268 * gcc.target/i386/pr23268.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6104&r2=1.6105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr22576.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr22585.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr23268.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/builtin-apply-mmx.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23268
[Bug c/24068] New: Unconditional warning when using -fwhole-program
When trying to compile the attached preprocessed files using gcc -c -fwhole-program --combine xterm.i xlwmenu.i These warnings are produced unconditionally: /home/dann/build/Emacs-CVS/emacs/lwlib/xlwmenu.c:57: warning: prototype for 'x_alloc_nearest_color_for_widget' follows non-prototype definition /home/dann/build/Emacs-CVS/emacs/lwlib/xlwmenu.c:58: warning: prototype for 'x_alloc_lighter_color_for_widget' follows non-prototype definition /home/dann/build/Emacs-CVS/emacs/lwlib/xlwmenu.c:64: warning: prototype for 'x_clear_errors' follows non-prototype definition /home/dann/build/Emacs-CVS/emacs/lwlib/xlwmenu.c:65: warning: prototype for 'x_copy_dpy_color' follows non-prototype definition AFAICT the warnings don't make much sense. The code is correct. The functions in questions are defined in one file and then prototyped and used in the other file. This kind of stuff appears in countless C programs. Can this warning be turned off by default? -- Summary: Unconditional warning when using -fwhole-program Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dann at godzilla dot ics dot uci dot edu CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug fortran/23446] Valid internal subprogram array argument declaration is not accepted.
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:24 --- Patch posted on fortran list: http://gcc.gnu.org/ml/fortran/2005-09/msg00400.html Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23446
[Bug c/24068] Unconditional warning when using -fwhole-program
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-26 19:25 --- Created an attachment (id=9807) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9807&action=view) xterm.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug c/24068] Unconditional warning when using -fwhole-program
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-26 19:25 --- Created an attachment (id=9808) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9808&action=view) xlwmenu.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug fortran/16404] should reject invalid code with -pedantic -std=f95 ? (x8)
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:28 --- > I have a patch for 3 and will try to sort out 6 (+pr21986) as soon as I have a > moment. Both sorted in http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html Paul T -- Bug 16404 depends on bug 18870, which changed state. Bug 18870 Summary: [g77 regression] Equivalencing two common blocks is not caught http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18870 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16404
[Bug c/24068] Unconditional warning when using -combine
-- What|Removed |Added Summary|Unconditional warning when |Unconditional warning when |using -fwhole-program |using -combine http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug fortran/20835] error needed with EQUIVALENCE and TARGET
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:29 --- Sorted in: http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20835
[Bug fortran/20890] initializing two equivalenced variabled
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:30 --- This will be resolved by http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20890
[Bug c/24068] Unconditional warning when using -combine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 19:31 --- Actually this is where C standard is werid really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug fortran/20899] pure function may not modify common variable through equivalence
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:31 --- This will be resolved by: http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20899
[Bug fortran/20900] use-associated variable may not be equivalenced
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:32 --- This is resolved by http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20900
[Bug fortran/20901] different intrinsic types in equivalence not detected
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:33 --- This is resolved by http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20901
[Bug fortran/20902] can't equivalence derived types with default initialization
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:34 --- This is resolved by http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20902
[Bug fortran/20903] types shouldn't propagate into interfaces
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:35 --- This is resolved by http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20903
[Bug fortran/20901] different intrinsic types in equivalence not detected
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:37
---
(In reply to comment #1)
> This is resolved by
>
> http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
>
> Paul T
PS The testcase checks the character sequence, rather than default character
type:
! { dg-do compile }
! { dg-options "-std=f95" }
! PR20901 - F95 constrains mixing of types in equivalence.
! Contributed by Joost VandeVondele <[EMAIL PROTECTED]>
TYPE data_type
SEQUENCE
character :: j
END TYPE data_type
INTEGER :: j
TYPE (data_type) :: d
EQUIVALENCE (d, J) ! { dg-error "in CHARACTER EQUIVALENCE statement" }
END
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20901
[Bug target/23847] Darwin -mpowerpc64 complex ABI breakage
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 19:41 --- Subject: Bug 23847 CVSROOT:/cvs/gcc Module name:gcc Branch: apple-local-200502-branch Changes by: [EMAIL PROTECTED] 2005-09-26 19:40:51 Modified files: gcc: ChangeLog.apple-ppc gcc/config/rs6000: rs6000.c Log message: Radar 4263935 (PR target/23847). Is in FSF mainline. OKed by Geoff. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.apple-ppc.diff?cvsroot=gcc&only_with_tag=apple-local-200502-branch&r1=1.1.4.162&r2=1.1.4.163 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&only_with_tag=apple-local-200502-branch&r1=1.786.2.38&r2=1.786.2.39 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23847
[Bug c/24068] Unconditional warning when using -combine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
19:41 ---
Because one file uses K&R style function defintions and the other uses a
prototype which is ANSI/ISO
style.
Simple example:
file1.c:
int f(int);
---
file2.c:
int f(a)
int a;
{
return a;
}
---
Compile it as:
gcc file2.c file1.c -combine
So this about the following:
int f(a)
int a;
{
return a;
}
int f(int);
Which is questionable.
So I don't think this is not an inappropriate warning.
As an aside, I wish people would stop using K&R style C already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug c/24068] Unconditional warning when using -combine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 19:46 --- I really want to say this is a bug in their code as x_alloc_nearest_color_for_widget's prototype is in the source file which is bad form really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug target/23847] Darwin -mpowerpc64 complex ABI breakage
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 19:48 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23847
[Bug gcov/profile/24069] New: ice during feedback stage of profiledbootstrap on powerpc
Ran into an ice today while attempting a profiled bootstrap of mainline: /> gcc -c -O2 -fprofile-use -freorder-blocks-and-partition dwarf2out.i dwarf2out.c: In function âoutput_call_frame_infoâ: dwarf2out.c:2410: internal compiler error: in make_edges, at cfgbuild.c:350 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I'll attach .i, .gcda, and .gcno files -- Summary: ice during feedback stage of profiledbootstrap on powerpc Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steinmtz at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug rtl-optimization/24069] ice during feedback stage of profiledbootstrap on powerpc
-- What|Removed |Added Component|gcov/profile|rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug c/24068] Unconditional warning when using -combine
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-26 19:54 --- (In reply to comment #4) > Because one file uses K&R style function defintions and the other uses a prototype which is ANSI/ISO > style. > Simple example: [snip] > So I don't think this is not an inappropriate warning. The question is: can this EVER result in incorrect behavior? Is it incorrect from the standard point of view? If the answer to the above is no, then there no reason to warn. > > As an aside, I wish people would stop using K&R style C already. Aggreed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug middle-end/23831] [4.1 Regression] ICE in immed_double_const with vectorized multipication
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 19:55 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23831
[Bug tree-optimization/23942] [4.1 Regression] loop problem / testcase takes very long time to compile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 19:55 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23942
[Bug rtl-optimization/24069] ice during feedback stage of profiledbootstrap on powerpc
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26 19:57 --- Created an attachment (id=9809) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9809&action=view) dwarf2out.gcda Attached dwarf2out.gcda -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-26 19:58 --- libffi bug that Gary found while doing builds on PPC64 http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01605.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug rtl-optimization/24069] ice during feedback stage of profiledbootstrap on powerpc
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26 19:58 --- Created an attachment (id=9810) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9810&action=view) dwarf2out.gcno Attached dwarf2out.gcno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug c/24068] Unconditional warning when using -combine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 19:59 --- This is not a regression. -- What|Removed |Added Keywords||diagnostic Known to fail||3.4.0 4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug rtl-optimization/24069] ice during feedback stage of profiledbootstrap on powerpc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 20:01 --- Is gcc really being used or is "stage1/xgcc -B stage1" being used? -- What|Removed |Added Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug target/24055] [4.1 regression] "could not split insn" with -O1 -ffast-math
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 20:02 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24055
[Bug fortran/23677] -fno-automatic does not accept legal save statements
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26 20:06 --- Subject: Bug 23677 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-26 20:06:37 Modified files: gcc/fortran: ChangeLog gcc/testsuite : ChangeLog gcc/fortran: options.c symbol.c resolve.c Added files: gcc/testsuite/gfortran.dg: save_1.f90 gcc/testsuite/gfortran.fortran-torture/execute: save_1.f90 Log message: PR fortran/23677 * symbol.c (gfc_is_var_automatic): Return true if character length is non-constant rather than constant. * resolve.c (gfc_resolve): Don't handle !gfc_option.flag_automatic here. * options.c (gfc_post_options): Set gfc_option.flag_max_stack_var_size to 0 for -fno-automatic. * gfortran.fortran-torture/execute/save_1.f90: New test. * gfortran.dg/save_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.568&r2=1.569 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6105&r2=1.6106 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/options.c.diff?cvsroot=gcc&r1=1.25&r2=1.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.34&r2=1.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.55&r2=1.56 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/save_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/save_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23677
[Bug rtl-optimization/24069] ice during feedback stage of profiledbootstrap on powerpc
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26 20:14 --- When I first saw it, it was with "stage1/xgcc -B stage1", however I've since done a non-profiled bootstrap of mainline, and the resulting gcc exhibits the same problem. Working on getting the .i attached. Unfortunately the file is a bit too large so I'm working to reduce it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug rtl-optimization/24069] ice during feedback stage of profiledbootstrap on powerpc
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26 20:28 --- Until I attach a .i file, this could be reproduced by anyone with a copy of the mainline source and the gcda/gcno attachments I've already provided. You'd need to to something like this: .../build-gcc-mline/gcc> set MYSRC="/home/steinmtz/src/mainline/gcc" .../build-gcc-mline/gcc> cd ~/build-gcc-mline/gcc .../build-gcc-mline/gcc> /home/steinmtz/install/mainline/bin/gcc -c -O2 - DIN_GCC -DHAVE_CONFIG_H -I. -I$MYSRC/gcc -I$MYSRC/gcc/../include - I$MYSRC/gcc/../libcpp/include -fprofile-use -freorder-blocks-and-partition $MYSRC/gcc/dwarf2out.c -o dwarf2out.o /home/steinmtz/work/src/mainline/gcc/gcc/dwarf2out.c: In function âoutput_call_frame_infoâ: /home/steinmtz/work/src/mainline/gcc/gcc/dwarf2out.c:2410: internal compiler error: in make_edges, at cfgbuild.c:350 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug c/24068] Unconditional warning when using -combine
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 20:46 ---
(In reply to comment #4)
> So this about the following:
> int f(a)
> int a;
> {
> return a;
> }
> int f(int);
>
> Which is questionable.
>
> So I don't think this is not an inappropriate warning.
It seems that the warning was designed for code like your example above.
But if you have 1 K&R file and one C90 file, then there should be no warning...
Another bad thing is that if you swap the files on the command line then you get
no warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
[Bug rtl-optimization/24069] ice during feedback stage of profiledbootstrap on powerpc
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26 21:49 --- Created an attachment (id=9811) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9811&action=view) dwarf2out.i Here's the .i. It results in a little "noise" in the form of some warnings during the compilation, but the resulting failure is the same. I'll update it if I get a chance to clean it up more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug rtl-optimization/9240] weird scheduling on v850 unless -fno-sched-spec specified
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26 22:07 --- Unless the common infrastructure bb frequency and edge probabilities have been updated to reflect builtin_expect, http://gcc.gnu.org/ml/gcc-patches/2005- 09/msg00370.html probably won't fix this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9240
[Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
--- Additional Comments From atavory at gmail dot com 2005-09-26 22:22 --- (In reply to comments #2 and #3: Actually, on second thought, I'm not sure we should give up consistency so easily only because the it = t.erase(it) idiom cannot be meaningfully used together with unordered containers: otherwise, why, f.i., vector::erase returns an iterator?!?!) For hash-based containers, i = t.erase(i) is effectively similar to: t.erase(i->first) // or t.erase(*i) i = t.begin(); std::advance(i, ::rand() % t.size()); (In fact, it's even somewhat worse than the above.) How could the return value be useful? Conversely, i = t.erase(i) makes sense for both tree-based containers or vectors, as it can be used in snippets such as the one in the original post. The problem is not, IMHO, whether the container is ordered or not (e.g., an unsorted std::vector). The problem is whether the container's sequence is well defined. Prior to hash-tables, the STL had only containers with well-defined sequences. (Put differently, one can think of a vector (or even a list) as an "associative container" mapping 1 .. t.size() - 1 to the values of t.) So, IMHO, this isn't giving up consistency; it's just reflecting inherent inconsistency through an inconsistent interface. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
[Bug libgcj/24051] [4.1 Regression]: libjava failed to configure
--- Additional Comments From mckinlay at redhat dot com 2005-09-26 22:36 --- AC_PROG_CXX is, presumably, needed by classpath in order to build the Qt peers. Although this is not the default configuration, it means we can't remove AC_PROG_CXX. The libjava configure gets around this issue using GCC_NO_EXECUTABLES, which disables linking of configure tests where possible. One solution is to add GCC_NO_EXECUTABLES to the classpath configure. Unfortunatly this introduces a divergance from the upstream configure.ac. We also need to butcher classpath's AC_CHECK_FUNCs because many of these do not work with GCC_NO_EXECUTABLES. However, they are probably not needed anyway because we do not build classpath's JNI code - only the AWT peers. Perhaps the AC_CHECK_FUNCs can be made conditional so as to reduce divergance from upstream? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24051
[Bug libgcj/24057] [4.1 regression] libgcj installs jawt.h and jni.h in version independent location
--- Additional Comments From mckinlay at redhat dot com 2005-09-26 22:41 --- Please ignore this patch, I attached it to the wrong bug. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24057
[Bug rtl-optimization/24069] ice during feedback stage of profiledbootstrap on powerpc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26 22:48 --- Just a note: I was able to profiledbootstrap on x86_64-pc-linux-gnu (but that was over a week ago). On powerpc-darwin, it failed, and I got PR 23396 out of it, from what I heard from someone else using a newer glibc on i686-pc-linux-gnu and it will fail the same way. I will try x86_64-pc-linux-gnu and see if I get something like this. Also: > When I first saw it, it was with "stage1/xgcc -B stage1", however I've since > done a non-profiled bootstrap of mainline, and the resulting gcc exhibits the > same problem. I just wantted to make sure that the build mechanism was not messed up, because that would actually be easier to fix :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug debug/24070] New: Dwarf macro info has bad file numbers
When passed the -g3 flag, GCC can generate Dwarf macro info that contains bad file numbers. The test input file bad-macro-file.i is included at the bottom. $ gcc --version gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -v Using built-in specs. Target: x86_64-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,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=x86_64-redhat-linux Thread model: posix gcc version 4.0.1 20050727 (Red Hat 4.0.1-5) $ gcc -g3 -S -dA bad-macro-file.i $ Look at the .debug_macro section in bad-macro-file.s. After the #inclusion of stdarg.h, the numbers used to refer to files in the dwarf info no longer match the numbers used in the .file directives. If we proceed with the link, readelf -wml shows that this has indeed produced bogus info. Note that the line info file table has only 18 entries, but the macro information refers to file number 19 (file numbers start with one, not zero). Things start to go bad after the data for : DW_MACINFO_start_file - lineno: 139 filenum: 18 DW_MACINFO_define - lineno : 24 macro : L_tmpnam 20 DW_MACINFO_define - lineno : 25 macro : TMP_MAX 238328 file number 18 is sys_errlist.h, but L_tmpnam is defined on line 24 of /usr/include/bits/stdio_lim.h. Dump of debug contents of section .debug_line: ... The File Name Table: Entry Dir TimeSizeName 1 0 0 0 bad-macro-file.c 2 1 0 0 stdio.h 3 1 0 0 features.h 4 2 0 0 cdefs.h 5 3 0 0 stubs.h 6 4 0 0 wordsize.h 7 3 0 0 stubs-64.h 8 5 0 0 stddef.h 9 4 0 0 types.h 104 0 0 typesizes.h 111 0 0 libio.h 121 0 0 _G_config.h 131 0 0 wchar.h 144 0 0 wchar.h 151 0 0 gconv.h 165 0 0 stdarg.h 174 0 0 stdio_lim.h 184 0 0 sys_errlist.h Line Number Statements: Extended opcode 2: set Address to 0x400468 Special opcode 8: advance Address by 0 to 0x400468 and Line by 3 to 4 Special opcode 61: advance Address by 4 to 0x40046c and Line by 0 to 4 Advance PC by 2 to 40046e Extended opcode 1: End of Sequence Contents of the .debug_macinfo section: DW_MACINFO_start_file - lineno: 0 filenum: 1 DW_MACINFO_define - lineno : 1 macro : __STDC_HOSTED__ 1 DW_MACINFO_define - lineno : 1 macro : __GNUC__ 4 DW_MACINFO_define - lineno : 1 macro : __GNUC_MINOR__ 0 DW_MACINFO_define - lineno : 1 macro : __GNUC_PATCHLEVEL__ 1 DW_MACINFO_define - lineno : 1 macro : __GNUC_RH_RELEASE__ 5 DW_MACINFO_define - lineno : 1 macro : __SIZE_TYPE__ long unsigned int DW_MACINFO_define - lineno : 1 macro : __PTRDIFF_TYPE__ long int DW_MACINFO_define - lineno : 1 macro : __WCHAR_TYPE__ int DW_MACINFO_define - lineno : 1 macro : __WINT_TYPE__ unsigned int DW_MACINFO_define - lineno : 1 macro : __INTMAX_TYPE__ long int DW_MACINFO_define - lineno : 1 macro : __UINTMAX_TYPE__ long unsigned int DW_MACINFO_define - lineno : 1 macro : __GXX_ABI_VERSION 1002 DW_MACINFO_define - lineno : 1 macro : __SCHAR_MAX__ 127 DW_MACINFO_define - lineno : 1 macro : __SHRT_MAX__ 32767 DW_MACINFO_define - lineno : 1 macro : __INT_MAX__ 2147483647 DW_MACINFO_define - lineno : 1 macro : __LONG_MAX__ 9223372036854775807L DW_MACINFO_define - lineno : 1 macro : __LONG_LONG_MAX__ 9223372036854775807LL DW_MACINFO_define - lineno : 1 macro : __WCHAR_MAX__ 2147483647 DW_MACINFO_define - lineno : 1 macro : __CHAR_BIT__ 8 DW_MACINFO_define - lineno : 1 macro : __INTMAX_MAX__ 9223372036854775807L DW_MACINFO_define - lineno : 1 macro : __FLT_EVAL_METHOD__ 0 DW_MACINFO_define - lineno : 1 macro : __FLT_RADIX__ 2 DW_MACINFO_define - lineno : 1 macro : __FLT_MANT_DIG__ 24 DW_MACINFO_define - lineno : 1 macro : __FLT_DIG__ 6 DW_MACINFO_define - lineno : 1 macro : __FLT_MIN_EXP__ (-125) DW_MACINFO_define - lineno : 1 macro : __FLT_MIN_10_EXP__ (-37) DW_MACINFO_define - lineno : 1 macro : __FLT_MAX_EXP__ 128 DW_MACINFO_define - lineno : 1 macro : __FLT_MAX_10_EXP__ 38 DW_MACINFO_define - lineno : 1 macro : __FLT_MAX__ 3.40282347e+38F DW_MACINFO_define - lineno : 1 macro : __FLT_MIN__ 1.17549435e-38F DW_MACINFO_define - lineno : 1 macro : __FLT_EPSILON__ 1.19209290e-7F DW_MACINFO_define - lineno : 1 macro : __FLT_DE
[Bug debug/24070] Dwarf macro info has bad file numbers
--- Additional Comments From jimb at redhat dot com 2005-09-26 22:57 --- Created an attachment (id=9814) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9814&action=view) Preprocessed input file for the bug report. This is the result of preprocessing bad-macro-file.c on my machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24070
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete its keys
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-26 23:03 --- André, Any chance you can detail how I can reproduce your failure? thanks, benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From kev dot gilbert at cdu dot edu dot au 2005-09-26 23:17 --- Whilst this bug has been marked as resolved, I am still experiencing the same problems (with arts-1.4.91 - the version shipped with KDE 35. Beta 1). My gcc version info : gcc (GCC) 4.1.0 20050924 (experimental) The following is the stack dump for the problem: --- Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1209124384 (LWP 31570)] [KCrash handler] #4 0x0034ffe3 in __gnu_cxx::__pool::_M_reclaim_block (this=0xa91b20, __p=0x84e6378 "\234�\b�\b�N\b", __bytes=4) at ../../.././libstdc++-v3/src/mt_allocator.cc:254 #5 0x00a71f37 in __gnu_cxx::__mt_alloc >::deallocate (this=0xbfc15838, __p=0x84e6378, __n=1) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/ext/mt_allocator.h:711 #6 0x00a71f71 in std::_Vector_base >::_M_deallocate (this=0xbfc15838, __p=0x84e6378, __n=1) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_vector.h:129 #7 0x00a71fae in ~_Vector_base (this=0xbfc15838) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_vector.h:115 #8 0x00a72017 in ~vector (this=0xbfc15838) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_vector.h:268 #9 0x00a7204a in ~ObjectReference (this=0xbfc1582c) at ../mcop/core.h:117 #10 0x00a5adc7 in Arts::SoundServerStartup_base::_fromString ( [EMAIL PROTECTED]) at soundserver.cc:2545 #11 0x08067572 in SoundServerStartup (this=0xbfc158b0, [EMAIL PROTECTED]) at soundserver.h:1376 #12 0x08066b83 in Arts::SoundServerStartup_impl::cleanReference ( this=0x853e6f8) at soundserverstartup_impl.cc:54 #13 0x08066cc1 in Arts::SoundServerStartup_impl::lock (this=0x853e6f8) at soundserverstartup_impl.cc:78 #14 0x08062bf9 in Arts::SoundServerStartup::lock (this=0xbfc15a58) at soundserver.h:2082 #15 0x080624ac in main (argc=14, argv=0xbfc15b74) at artsd.cc:293 --- My gcc was installed by: --- export CVS_RSH=ssh export CVSROOT=":ext:[EMAIL PROTECTED]:/cvsroot/gcc" cvs -z9 checkout -P gcc wwwdocs cd gcc ./configure make -j 2 make install --- I have peformed a random check of the patches in Remark #42 below and they seem to be in the source I've downloaded. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug libstdc++/24071] New: solaris vs. __gthread_active_p
The patch for 22309 kills Solaris 2.6, 2.7, 2.8, and 2.9. The failure mode is as
follows:
FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
FAIL: ext/mt_allocator/check_delete.cc execution test
FAIL: ext/mt_allocator/check_new.cc execution test
FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test
FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-1.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-3.cc execution test
FAIL: ext/mt_allocator/tune-1.cc execution test
FAIL: ext/mt_allocator/tune-2.cc execution test
FAIL: ext/mt_allocator/tune-3.cc execution test
FAIL: ext/mt_allocator/tune-4.cc execution test
And can be seen here:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01189.html
Eric Botcazou provided the following commentary in private email:
backtrace at -O0:
Program received signal SIGSEGV, Segmentation fault.
0x0001d354 in __gnu_cxx::__pool_base::_M_get_binmap (this=0x30eac, __bytes=40)
at ext/mt_allocator.h:146
146 { return _M_binmap[__bytes]; }
(gdb) bt
#0 0x0001d354 in __gnu_cxx::__pool_base::_M_get_binmap (this=0x30eac,
__bytes=40) at ext/mt_allocator.h:146
#1 0x0001d7fc in __gnu_cxx::__mt_alloc >::allocate
(this=0xffbefa3e, __n=10)
at ext/mt_allocator.h:674
#2 0x0001d940 in __gnu_test::check_new<__gnu_cxx::__mt_alloc >, true>
([EMAIL PROTECTED])
at testsuite_allocator.h:187
#3 0x0001d9cc in test01 ()
at
/home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/ext/mt_allocator/check_new.cc:49
#4 0x0001da7c in main ()
at
/home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/ext/mt_allocator/check_new.cc:54
(gdb) p _M_binmap
$1 = (short unsigned int *) 0x0
I put 3 breakpoints in mt_allocator.cc and _M_binmap is never initialized, as
__gnu_cxx::__common_pool_base<__gnu_cxx::__pool, true>::_S_initialize() is
never called.
The problem stems from:
static void
_S_initialize_once()
{
static bool __init;
if (__builtin_expect(__init == false, false))
{
if (__gthread_active_p())
{
// On some platforms, __gthread_once_t is an aggregate.
static __gthread_once_t __once = __GTHREAD_ONCE_INIT;
__gthread_once(&__once, _S_initialize);
}
else
_S_get_pool()._M_initialize_once();
__init = true;
}
}
__gthread_once never calls _S_initialize on Solaris 7, 8, 9, while it does on
Solaris 10. This boils down to the following lines in the manual:
" These switches are supported in addition to the above on Solaris:
`-threads'
Add support for multithreading using the Solaris threads library.
This option sets flags for both the preprocessor and linker. This
option does not affect the thread safety of object code produced
by the compiler or that of libraries supplied with it.
`-pthreads'
Add support for multithreading using the POSIX threads library.
This option sets flags for both the preprocessor and linker. This
option does not affect the thread safety of object code produced
by the compiler or that of libraries supplied with it."
You need to pass -pthreads to the compiler to make the thing work.
More:
No, pthread_cancel is defined because it is present in the libc:
gax% nm -pl /lib/libc.so.1 | grep pthread_cancel
634812 T* _pthread_cancel
634812 T* pthread_cancel
gax% nm -pl /lib/libpthread.so.1 | grep pthread_cancel
015516 T _pthread_cancel
015516 T* pthread_cancel
Same for pthread_once:
gax% nm -pl /lib/libc.so.1 | grep pthread_once
635324 T* _pthread_once
635324 T* pthread_once
gax% nm -pl /lib/libpthread.so.1 | grep pthread_once
015476 T _pthread_once
015476 T* pthread_once
But the latter is probably a dummy function because:
Reformatting page. Please Wait... done
Threads Library Functions pthread_once(3THR)
NAME
pthread_once - initialize dynamic package
[...]
NOTES
Solaris threads do not offer this functionality.
SunOS 5.8Last change: 2 Jun 19982
The situation is different on Solaris 10 because all the functions in the
pthreads library are only placeholders for the libc functions:
hikaru% nm -pl /lib/libpthread.so.1 | grep pthread_cancel
00 T _pthread_cancel
00 T pthread_cancel
hikaru% nm -pl /lib/libc.so.1 | grep pthread_cancel
703188 T _pthread_cancel
703188 T* pthread_cancel
... thus leading to the odd behavior where __gthread_active_p is true, but
__gthread_once doesn't run the "once" function, and yet returns zero.
It looks like this has been an issue in past versions of the mt_allocator.h
code, in that initialization was forced after the gthread_once call. This was
confusing, but apparently necessary due to the tricky gthread_once issue.
Possible solutions:
1) force double init
[Bug libstdc++/24071] solaris vs. __gthread_active_p
-- What|Removed |Added CC||ebotcazou at libertysurf dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071
[Bug libstdc++/24071] solaris vs. __gthread_active_p
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-26 23:24 --- Created an attachment (id=9815) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9815&action=view) double intialization patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071
[Bug libstdc++/24071] solaris vs. __gthread_active_p
-- What|Removed |Added Attachment #9815|double intialization patch |force intialization patch description|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From bangerth at dealii dot org 2005-09-27 00:44 --- Kevin, can you try out the various testcases from this report and see whether your compiler fails any of them? W. -- What|Removed |Added CC||kev dot gilbert at cdu dot ||edu dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug debug/24070] Dwarf macro info has bad file numbers
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27 01:08 --- Hmm, I think this should have been fixed by PR 20253. I don't have any FSF 4.0.x compiler after that. Double hmm, it works with 32 bits but not 64bits on the mainline. -- What|Removed |Added Keywords||wrong-debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24070
[Bug debug/24070] Dwarf macro info has bad file numbers
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27 01:12 --- The difference between 32 and 64bit: --- 64 2005-09-27 03:10:18.552798040 +0200 +++ 32 2005-09-27 03:10:26.250627792 +0200 @@ -1,7 +1,7 @@ Dump of debug contents of section .debug_line: - Length: 388 + Length: 385 DWARF Version: 2 Prologue Length: 364 Minimum Instruction Length: 1 @@ -9,7 +9,7 @@ Dump of debug contents of section .debug Line Base: -5 Line Range: 14 Opcode Base: 10 - (Pointer size: 8) + (Pointer size: 4) Opcodes: Opcode 1 has 0 args @@ -53,8 +53,9 @@ Dump of debug contents of section .debug Line Number Statements: Extended opcode 2: set Address to 0x0 Special opcode 8: advance Address by 0 to 0x0 and Line by 3 to 4 - Special opcode 61: advance Address by 4 to 0x4 and Line by 0 to 4 - Advance PC by 2 to 6 + Advance PC by constant 17 to 0x11 + Special opcode 159: advance Address by 11 to 0x1c and Line by 0 to 4 + Advance PC by 2 to 1e Extended opcode 1: End of Sequence @@ -565,7 +566,7 @@ Contents of the .debug_macinfo section: DW_MACINFO_define - lineno : 119 macro : SEEK_CUR 1 DW_MACINFO_define - lineno : 120 macro : SEEK_END 2 DW_MACINFO_define - lineno : 125 macro : P_tmpdir "/tmp" - DW_MACINFO_start_file - lineno: 139 filenum: 18 + DW_MACINFO_start_file - lineno: 139 filenum: 17 DW_MACINFO_define - lineno : 24 macro : L_tmpnam 20 DW_MACINFO_define - lineno : 25 macro : TMP_MAX 238328 DW_MACINFO_define - lineno : 26 macro : FILENAME_MAX 4096 @@ -579,7 +580,7 @@ Contents of the .debug_macinfo section: DW_MACINFO_define - lineno : 149 macro : stderr stderr DW_MACINFO_define - lineno : 449 macro : getc(_fp) _IO_getc (_fp) DW_MACINFO_define - lineno : 491 macro : putc(_ch,_fp) _IO_putc (_ch, _fp) - DW_MACINFO_start_file - lineno: 751 filenum: 19 + DW_MACINFO_start_file - lineno: 751 filenum: 18 DW_MACINFO_end_file DW_MACINFO_end_file DW_MACINFO_start_file - lineno: 3 filenum: 16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24070
[Bug debug/24070] Dwarf macro info has bad file numbers
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27 01:16 --- Likewise for .s files: @@ -1502,7 +1502,7 @@ .byte 0x3 # Start new file .uleb128 0x8b # Included from line number 139 .file 17 "/usr/include/bits/stdio_lim.h" - .uleb128 0x12 # Filename we just started + .uleb128 0x11 # Filename we just started .byte 0x1 # Define macro .uleb128 0x18 # At line number 24 .ascii "L_tmpnam 20\0" # The macro @@ -1543,7 +1543,7 @@ .byte 0x3 # Start new file .uleb128 0x2ef # Included from line number 751 .file 18 "/usr/include/bits/sys_errlist.h" - .uleb128 0x13 # Filename we just started + .uleb128 0x12 # Filename we just started .byte 0x4 # End file .byte 0x4 # End file .byte 0x3 # Start new file So this is definitely a bug in gcc and not in readelf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24070
[Bug debug/24070] [4.0/4.1 Regression] Dwarf macro info has bad file numbers
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27 01:24 --- I need to try FSF 4.0.2 because redhat's compiler is known not to be clean. But currently I can confirm this fails on the mainline and works with 4.0.0 20050301 and 3.3.6. -- What|Removed |Added Known to fail||4.1.0 Known to work||4.0.0 3.3.6 Summary|Dwarf macro info has bad|[4.0/4.1 Regression] Dwarf |file numbers|macro info has bad file ||numbers Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24070
[Bug c++/24072] New: diagnostics, oh my!
extern volatile signed int i; volatile unsigned int i = 0; gets you: ~/ootbc/members/src$ g++ foo.cc foo.cc:2: error: conflicting declaration 'volatile unsigned int i' foo.cc:1: error: 'i' has a previous declaration as `volatile int i' foo.cc:2: error: type mismatch with previous external decl of `volatile unsigned int i' foo.cc:1: error: previous external decl of `volatile int i' foo.cc:2: error: declaration of `volatile unsigned int i' foo.cc:1: error: conflicts with previous declaration `volatile int i' -- Summary: diagnostics, oh my! Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24072
[Bug c++/24072] [3.4 Regression] diagnostics, oh my!
-- What|Removed |Added Keywords||diagnostic Known to fail||3.4.0 Known to work||4.0.0 4.1.0 3.3.3 Summary|diagnostics, oh my! |[3.4 Regression] ||diagnostics, oh my! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24072
