[Bug target/19340] Compilation SEGFAULTs with -O1 -fschedule-insns2 -fsched2-use-traces on an x86 architecture.
--- Comment #6 from uros at gcc dot gnu dot org 2005-11-08 07:59 --- Subject: Bug 19340 Author: uros Date: Tue Nov 8 07:58:51 2005 New Revision: 106633 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106633 Log: PR target/19340 * reg-stack.c (reg_to_stack): Update register liveness also for flag_sched2_use_traces. PR target/24315 * config/i386/i386.md (*pushdi2_rex64 splitter) (*movdi_1_rex64 splitter, *ashldi3_1 splitter) (*ashrdi3_1 splitter, *lshrdi3_1 splitter): Delay splitting after flow2 pass only when (optimize > 0 && flag_peephole2). testsuite/ PR target/19340 * gcc.dg/pr19340.c: New test. PR target/24315 * gcc.target/i386/pr24315.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr19340.c branches/gcc-4_0-branch/gcc/testsuite/gcc.target/i386/pr24315.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/i386/i386.md branches/gcc-4_0-branch/gcc/reg-stack.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19340
[Bug target/24315] [3.4/4.0 Regression] amd64 fails -fpeephole2
--- Comment #14 from uros at gcc dot gnu dot org 2005-11-08 07:59 --- Subject: Bug 24315 Author: uros Date: Tue Nov 8 07:58:51 2005 New Revision: 106633 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106633 Log: PR target/19340 * reg-stack.c (reg_to_stack): Update register liveness also for flag_sched2_use_traces. PR target/24315 * config/i386/i386.md (*pushdi2_rex64 splitter) (*movdi_1_rex64 splitter, *ashldi3_1 splitter) (*ashrdi3_1 splitter, *lshrdi3_1 splitter): Delay splitting after flow2 pass only when (optimize > 0 && flag_peephole2). testsuite/ PR target/19340 * gcc.dg/pr19340.c: New test. PR target/24315 * gcc.target/i386/pr24315.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr19340.c branches/gcc-4_0-branch/gcc/testsuite/gcc.target/i386/pr24315.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/i386/i386.md branches/gcc-4_0-branch/gcc/reg-stack.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24315
[Bug tree-optimization/24653] [4.1 regression] EON regressed seriously on x86-64
--- Comment #5 from bonzini at gcc dot gnu dot org 2005-11-08 07:53 --- The approved patch is the one at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00212.html -- bonzini at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2005- |patches/2005- |11/msg00195.html|11/msg00212.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24653
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #18 from r dot emrich at de dot tecosim dot com 2005-11-08 07:47 --- Bootstrap of gcc-4.1-20051105 succeeded for c,c++,objc,obj-c++. Testsuite still in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug rtl-optimization/24408] [4.1 Regression] Invariant code no longer removed from loop when doing FDO.
--- Comment #5 from steven at gcc dot gnu dot org 2005-11-08 07:44 --- Created an attachment (id=10170) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10170&action=view) merge patch from the killloop-branch With this patch applied and -fmove-loop-invariants enabled by default at -O2, I am getting regressions in libjava on ia64. But it does bootstrap there and also passes bootstrap&testing on i686, x86_64, ppc, and ppc64 without problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24408
[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line
--- Comment #5 from sven dot buijssen at math dot uni-dortmund dot de 2005-11-08 07:04 --- > Sven, > Thanks for reporting this and narrowing it down. You're welcome, Jerry. I reckoned this to be the most promising way to get rid of this regression as soon as possible. :-) > This is a warning and you can get rid of warnings with the -w flag when > invoking gfc. Sure, I know, perfectly works. It's just that I consider this a spurious warning as no file (apart from /dev/zero) is of infinite length and by this, the end-of-file condition will end this "infinite loop" branching execution to label 99. By the way, I'm deeply impressed by the speed you handle this regression! Thanks a lot. Regards, Sven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24719
[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP
--- Comment #28 from phython at gcc dot gnu dot org 2005-11-08 06:48 --- Steven: How long does 4.0 take to compile this function on your box? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug c++/22172] [3.4 Regression] Internal compiler error, seg fault.
-- phython at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|phython at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line
--- Comment #4 from jvdelisle at verizon dot net 2005-11-08 06:37 --- Subject: Re: [4.1 Regression] Nonadvancing read does not read more than 1 line > For sake of compliance with the bug report policy: > * gfortran from cvs via > TZ=GMT cvs -q update -D'2005.10.24.03.00.00' > works, > * gfortran from cvs via > TZ=GMT cvs -q update -D'2005.10.24.04.00.00' > does not. > Sven, Thanks for reporting this and narrowing it down. > By the way, there is another small issue with the above testcase. I'm not sure > if I should file a separate bug report for it: > Changing line 6 of regression.f90 to > > 10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 10) saux > > gives the incorrect warning: > > In file regression.f90:6 > > 10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 10) saux > 1 > Warning: Branch at (1) causes an infinite loop > > while ifort and g95 do not complain. > > This is a warning and you can get rid of warnings with the -w flag when invoking gfc. It warns of a potential problem. Let me know if -w does not get rid of it for you. Regards, Jerry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24719
[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-11-08 06:22 --- I believe I have a fix for this one that works with the previous patch to pr24489. I am testing along with work on pr24699 to make sure we have no conflicts or regressions. pr24719, pr24699, pr24700, and pr24489 all relate to io/transfer.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24719
[Bug target/19340] Compilation SEGFAULTs with -O1 -fschedule-insns2 -fsched2-use-traces on an x86 architecture.
--- Comment #5 from uros at gcc dot gnu dot org 2005-11-08 06:21 --- Subject: Bug 19340 Author: uros Date: Tue Nov 8 06:21:51 2005 New Revision: 106632 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106632 Log: PR target/19340 * reg-stack.c (reg_to_stack): Update register liveness also for flag_sched2_use_traces. testsuite/ PR target/19340 * gcc.dg/pr19340.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr19340.c Modified: trunk/gcc/ChangeLog trunk/gcc/reg-stack.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19340
[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Comment #13 from amodra at bigpond dot net dot au 2005-11-08 05:24 --- Looking at fixing REG_FRAME_RELATED_EXPR in regrename. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug c++/13967] A warning could be emitted if a template parameter of a member template is begin shadowed by another member of the class
--- Comment #25 from bangerth at dealii dot org 2005-11-08 05:23 --- *** Bug 24657 has been marked as a duplicate of this bug. *** -- bangerth at dealii dot org changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13967
[Bug c++/24657] [3.4/4.0/4.1 Regression] bizarre diagnostic when a member variable and a template parameter have the same name
--- Comment #6 from bangerth at dealii dot org 2005-11-08 05:23 --- This is PR 13967. See in particular comment #11 in the audit trail there. Not that that PR would be particularly enlightening, but the situation is at least discussed at length there. W. *** This bug has been marked as a duplicate of 13967 *** -- bangerth at dealii dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24657
[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2005-08-15 17:49:53 |2005-11-08 05:23:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug c++/24657] [3.4/4.0/4.1 Regression] bizarre diagnostic on valid (?) constructor
--- Comment #5 from bangerth at dealii dot org 2005-11-08 05:14 --- This can of course be made even simpler: struct A { template A(int (*)[i]) : j(i) {} int * i; int j; }; int i[3]; A a(&i); g/x> /home/bangerth/bin/gcc-3.4.5-pre/bin/c++ -c x.cc x.cc: In constructor `A::A(int (*)[i]) [with int i = 3]': x.cc:8: instantiated from here x.cc:2: error: invalid conversion from `int*' to `int' I'm pretty sure I've seen this somewhere before -- the question was indeed which name should be looked up, the template name or the name of a member variable. In any case, the error message is not particularly helpful, and I know of at least one other compiler that accepts this. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-08 05:14:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24657
[Bug c/24727] type "const void *" produces a warning when promoting to "void *"
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 04:34 --- No, in C, these are two different function types. -- 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=24727
[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-08 04:28 --- I'm not convinced it's the same issue. With regard to 17402, comment #6 by Joseph there refers specifically to static inlines in that builtins shouldn't generate calls to "file-scope statics". However in my case glibc is instantiating *extern inlines* and it seems legitimate that gcc could (should) generate calls which take advantage of them. (Plus they're much much faster!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug c/24727] type "const void *" produces a warning when promoting to "void *"
--- Comment #2 from joshudson at gmail dot com 2005-11-08 04:25 --- Aren't function arguments contravariant rather than covariant? -- joshudson at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24727
[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 03:52 --- I want to say this is dup of bug 17402 which was marked as will not fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug middle-end/24729] New: function calls created by builtins do not make use of inline definitions
When doing transformations on builtins, if the builtin results in a function call that has an inline expansion, GCC emits a library call not the inline function body. E.g. glibc defines an inline for fputc_unlocked. Given this code: #define _GNU_SOURCE #include #define MAX 1 int main () { int i; for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug target/23704] gcc.dg/rs6000-fpint.c fails
--- Comment #6 from amodra at bigpond dot net dot au 2005-11-08 03:17 --- I meant, fixed on 3.4 and 4.0 by patch for pr20277 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23704
[Bug target/23704] gcc.dg/rs6000-fpint.c fails
--- Comment #5 from amodra at bigpond dot net dot au 2005-11-08 03:15 --- Fixed mainline. Bug fixed on 3.4 and 4.0 branch by patch for pr20227 -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23704
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2005-11-08 03:15 --- (In reply to comment #1) > See the thread on the gcc list discussing this bug. > http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html > > I suspect this is a bug in patches applied to the gcc-3.4.x sources as I do > not > see this problem in the FSF sources. Note the HP gcc-3.4.4 binary had the same problem. I just built gcc-3.4.4 with just one patch to fix the sco_math issue in PR24688: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html The new binary exhibits the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/23704] gcc.dg/rs6000-fpint.c fails
--- Comment #4 from amodra at gcc dot gnu dot org 2005-11-08 03:09 --- Subject: Bug 23704 Author: amodra Date: Tue Nov 8 03:08:43 2005 New Revision: 106631 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106631 Log: PR target/23704 * config/rs6000/rs6000.c (rs6000_handle_option ): Don't override prior explicit -mno-powerpc-gfxopt. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23704
[Bug c/8268] no compile time array index checking
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-08 02:41 --- *** Bug 24728 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Larry dot Finger at lwfinger ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/24728] Constant array index past end does not generate compile-time error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 02:41 --- First this is only undefined code which means that we have to accept the code. Second this is a dup of bug 8268. *** This bug has been marked as a duplicate of 8268 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24728
[Bug c/24728] New: Constant array index past end does not generate compile-time error
A constant reference to an array element past the end of the array does not generate an error. Included are the output from gcc -v and a test program that mimics the real-world case where the coding error corrupted the stack: Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java,ada --disable-checking --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind --host=i586-suse-linux Thread model: posix gcc version 4.0.2 20050901 (prerelease) (SUSE Linux) Test Program: = int sub1(int); int main(int argc, char **argv) { int i,j = 0; i = sub1(j); return i; } int sub1(int j ) { int b[13]; b[13] = j; return 0; } -- Summary: Constant array index past end does not generate compile- time error Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Larry dot Finger at lwfinger dot net GCC host triplet: i586-suse-linux GCC target triplet: i586-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24728
[Bug tree-optimization/23115] [4.1 Regression] -ftree-vectorize generates wrong code
--- Comment #8 from dpatel at apple dot com 2005-11-08 02:22 --- tree if-conversion was expecting perfect dimond, but it is not always true after tree-cleanup-branch work. I've started overnight patch test run. Hopefully, I'll send patch tomorrow for review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23115
[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-11-08 02:18 --- I have confirmed that when I revert the patch to pr24489 that this bug goes away. Isn't life wonderful! -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-08 02:18:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24719
[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-08 01:46 --- This is precisly when I committed the patch to pr24489. I am also seeing some possible connections with pr24699. I will investigate further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24719
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #1 from wilson at gcc dot gnu dot org 2005-11-08 01:41 --- See the thread on the gcc list discussing this bug. http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html I suspect this is a bug in patches applied to the gcc-3.4.x sources as I do not see this problem in the FSF sources. I do not have an ia64-hpux machine, so I can not easily investigate this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug tree-optimization/18595] [4.0/4.1 Regression] IV-OPTS is O(N^3)
--- Comment #60 from pinskia at gcc dot gnu dot org 2005-11-08 01:40 --- Fixed on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18595
[Bug c++/24687] [4.1 Regression] ICE after error
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-08 01:34 --- Actually I don't think my patch is the right one. Here is the patch: svn diff Index: tree.c === --- tree.c (revision 106572) +++ tree.c (working copy) @@ -2168,7 +2168,12 @@ decl_linkage (tree decl) /* Linkage of a CONST_DECL depends on the linkage of the enumeration type. */ if (TREE_CODE (decl) == CONST_DECL) -return decl_linkage (TYPE_NAME (TREE_TYPE (decl))); +{ + /* If we are inside a template, the type will be null. */ + if (!TREE_TYPE (decl)) + return lk_external; + return decl_linkage (TYPE_NAME (TREE_TYPE (decl))); +} /* Some things that are not TREE_PUBLIC have external linkage, too. For example, on targets that don't have weak symbols, we make all -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #12 from arun dot sharma at google dot com 2005-11-08 01:30 --- (In reply to comment #10) > (In reply to comment #9) > > Yes and the ones against gcc are only about eplogue or prologue so it should > > not matter for what you are doing. > > PR 18748 and PR 18749 both are about prologue and eplogue code which should > not > matter with the backtrace at all. > ok, will try to root cause our problems with libunwind (they show up as bad pointer dereferences in libunwind) and get back to you. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-08 01:23 --- (In reply to comment #7) > The particular malloc in question is coming from start_fde_sort() in > unwind-dw2-fde.c. Perhaps the sorting can be done earlier i.e. before > _Unwind_Backtrace() is called? If you do that, the start up time is high and every time you load a shared library it stalls and you keep around stuff which you don't need at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-08 01:12 --- (In reply to comment #9) > Yes and the ones against gcc are only about eplogue or prologue so it should > not matter for what you are doing. PR 18748 and PR 18749 both are about prologue and eplogue code which should not matter with the backtrace at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-08 01:10 --- (In reply to comment #8) > libunwind doesn't pass unit tests on amd64. davidm thinks that the problems > are > outside of libunwind. I think he has a couple of bugs open against gcc/glibc. Yes and the ones against gcc are only about eplogue or prologue so it should not matter for what you are doing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #8 from arun dot sharma at google dot com 2005-11-08 01:09 --- (In reply to comment #6) > Hmm, You could try libunwind instead, it should work on x86_64: > http://www.hpl.hp.com/research/linux/libunwind/ > > They show you how to use libunwind to generate a normal backtrace: > http://www.hpl.hp.com/research/linux/libunwind/man/libunwind(3).php > > Though I doubt that none of these will remove the use of malloc though. > libunwind doesn't pass unit tests on amd64. davidm thinks that the problems are outside of libunwind. I think he has a couple of bugs open against gcc/glibc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #7 from arun dot sharma at google dot com 2005-11-08 01:07 --- (In reply to comment #4) > I really doubt we can remove it because this is also used in the undwinding > for > exceptions. > It must be possible to do stack unwinding without any mallocs. If the exception throwing code path requires mallocs, that's fine by us. The particular malloc in question is coming from start_fde_sort() in unwind-dw2-fde.c. Perhaps the sorting can be done earlier i.e. before _Unwind_Backtrace() is called? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-08 01:02 --- Hmm, You could try libunwind instead, it should work on x86_64: http://www.hpl.hp.com/research/linux/libunwind/ They show you how to use libunwind to generate a normal backtrace: http://www.hpl.hp.com/research/linux/libunwind/man/libunwind(3).php Though I doubt that none of these will remove the use of malloc though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #5 from arun dot sharma at google dot com 2005-11-08 00:55 --- (In reply to comment #3) > You know that glibc has an backtrace function which might be more friendly for > your purpose? > glibc backtrace dlopens libgcc and uses _Unwind_Backtrace() on amd64. glibc backtrace has it's own problems (i.e. mallocs) which is why we're not using it. See: http://sources.redhat.com/bugzilla/show_bug.cgi?id=1579 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-08 00:53 --- I really doubt we can remove it because this is also used in the undwinding for exceptions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 00:51 --- You know that glibc has an backtrace function which might be more friendly for your purpose? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #2 from arun dot sharma at google dot com 2005-11-08 00:48 --- It deadlocks because malloc is holding a lock and then calls the unwinder. No, we're not throwing exceptions. One reason why malloc might want to use the unwinder is to do heap profiling. http://goog-perftools.sourceforge.net/doc/heap_profiler.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug tree-optimization/20656] No strength reduction for a simple testcase
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-08 00:30 --- Seen at test-case reduction also for code of the form: int i; for (i = 1; i <= shift_size; i++) { } not producing the same ICE as for: int i; i = 1 <= shift_size ? shift_size : 1; (I'll put a pointer here to the complete test-case in due time.) -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20656
[Bug other/24724] _Unwind_Backtrace() calls malloc
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 00:23 --- What is your malloc doing special and why would it dead lock? (if you are throwing from inside malloc I think that is an invalid thing to do). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP
--- Comment #27 from steven at gcc dot gnu dot org 2005-11-08 00:18 --- On AMD64, revision 106596M (the M is for a local loop-invariant.c patch, nothing special), compiler built with --enable-checking=release: at -O1: tree operand scan : 1.50 (10%) usr 0.09 (17%) sys 1.62 (10%) wall dominance frontiers : 9.09 (60%) usr 0.00 ( 0%) sys 9.20 (58%) wall TOTAL : 15.05 0.5315.80 at -O2: tree VRP : 12.20 (23%) usr 0.03 ( 3%) sys 12.44 (23%) wall dominance frontiers : 9.17 (18%) usr 0.01 ( 1%) sys 9.30 (17%) wall CPROP 1 : 8.17 (16%) usr 0.16 (16%) sys 8.44 (16%) wall CPROP 2 : 5.54 (11%) usr 0.11 (11%) sys 5.72 (11%) wall bypass jumps : 5.57 (11%) usr 0.11 (11%) sys 5.75 (11%) wall TOTAL : 52.31 1.0053.98 For GCC 3.3.5 at -O1 the total time is 26s, and at -O2 it is 31s. For AMD64 -m32 -march=i686: at -O1: tree operand scan : 1.48 (10%) usr 0.09 (18%) sys 1.59 (10%) wall dominance frontiers : 9.03 (61%) usr 0.00 ( 0%) sys 9.14 (59%) wall TOTAL : 14.70 0.4915.39 at -O2: tree VRP : 11.84 (24%) usr 0.04 ( 4%) sys 12.02 (24%) wall dominance frontiers : 9.11 (19%) usr 0.02 ( 2%) sys 9.25 (18%) wall CPROP 1 : 7.54 (15%) usr 0.10 (11%) sys 7.74 (15%) wall CPROP 2 : 4.99 (10%) usr 0.10 (11%) sys 5.15 (10%) wall bypass jumps : 4.96 (10%) usr 0.10 (11%) sys 5.12 (10%) wall TOTAL : 48.97 0.9350.54 For GCC 3.3.5 at -O1 the total time is 25s, and at -O2 it is 28s. Compared to my measurements from comment #17, this is good progress. James, do you think we can close this bug now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug ada/24726] Gigi abort, Code=508
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 00:09 --- *** Bug 24725 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24726
[Bug ada/24725] Gigi abort, Code=508
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 00:09 --- *** This bug has been marked as a duplicate of 24726 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24725
[Bug c/24727] type "const void *" produces a warning when promoting to "void *"
--- Comment #1 from schwab at suse dot de 2005-11-08 00:07 --- The warning is correct. The type of x_write is incompatible with x_io, because "const void *" is incompatible with "void *". Argument promotion does not come into play here. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24727
[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-07 23:56 --- I'm adding FX to the CC list, because this looks like it's related to his patch for FPU exceptions. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24342
[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-11-07 23:43 --- Subject: Re: Unclassifiable statement on implicitly typed character substring steven at gcc dot gnu dot org wrote: > --- Comment #8 from steven at gcc dot gnu dot org 2005-11-07 23:29 > --- > We get to "check_substring:" in match_varspec: > > PROGRAM P > IMPLICIT CHARACTER*8 (Y) > YLOCAL='A' > YBTABLE=YLOCAL(1:2) > END > > check_substring: > if (primary->ts.type == BT_CHARACTER) > { > switch (match_substring (primary->ts.cl, equiv_flag, &substring)) > { > case MATCH_YES: > if (tail == NULL) > primary->ref = substring; > > But at this point, while we have matched YLOCAL in the second assignment, we > still haven't picked up a type for it. So primary->ts.type == BT_UNKNOWN and > we never even try to match the substring. > > I'm not sure if YLOCAL should have just picked up a type earlier. Thoughts, > Tobi? It should have picked up a type in the first assignment. Why it doesn't, I don't know. Apparently, the failure is conditional on the facts that A) there already exists a symbol and B) this symbol doesn't have a type at that point. I'll look into this in more depth tomorrow. I remember that last time I looked into these issues (back before Jakub fixed PR18833), I noticed that the matching of primaries had been completely reworked in g95, and I can't think of any other bug relating to that than this one, so this bug might well turn out to be a snake pit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug c/24727] New: type "const void *" produces a warning when promoting to "void *"
Tried this on two machines: SunOS hornet 5.10 Generic sun4u sparc SUNW,Ultra-4 with GCC 4.0.1 Linux numenor 2.6.13 #9 Mon Sep 19 19:03:35 PDT 2005 i686 unknown unknown GNU/Linux with GCC 3.3.6 The following code produces spurios warning: /* Cut here */ int x_read(int h, void *buf, unsigned len); int x_write(int h, const void *buf, unsigned len); typedef int (*x_io)(int h, void *buf, unsigned len); int blockio(int h, long long offset, void *buf, x_io action); int bug(int h, unsigned where, void *buf) { return blockio(h, (long long)where << 10, buf, x_write); } /* Cut here */ sample.c: In function `bug': sample.c:9: warning: passing arg 4 of `blockio' from incompatible pointer type -- Summary: type "const void *" produces a warning when promoting to "void *" Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joshudson at gmail dot com GCC host triplet: Multiple http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24727
[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
--- Comment #8 from steven at gcc dot gnu dot org 2005-11-07 23:29 --- We get to "check_substring:" in match_varspec: PROGRAM P IMPLICIT CHARACTER*8 (Y) YLOCAL='A' YBTABLE=YLOCAL(1:2) END check_substring: if (primary->ts.type == BT_CHARACTER) { switch (match_substring (primary->ts.cl, equiv_flag, &substring)) { case MATCH_YES: if (tail == NULL) primary->ref = substring; But at this point, while we have matched YLOCAL in the second assignment, we still haven't picked up a type for it. So primary->ts.type == BT_UNKNOWN and we never even try to match the substring. I'm not sure if YLOCAL should have just picked up a type earlier. Thoughts, Tobi? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug ada/24726] New: Gigi abort, Code=508
Ture-Andersens-dator:~/Documents/Privat/programutveckling/ada/sudoku ture$ gnatmake sudoku gcc -c elements-sets.adb +===GNAT BUG DETECTED==+ | 3.3 20040913 (GNAT for Mac OS X build 1650) (powerpc-unknown-darwin) | | Gigi abort, Code=508 | | Error detected at elements-sets.adb:95:21| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | concatenated together with no headers between files. | +==+ Please include these source files with error report elements-sets.adb elements-sets.ads elements.ads compilation abandoned gnatmake: "elements-sets.adb" compilation error -- * Body name elements.sets.adb -- * Project name sudoku -- * -- * Version 1.0 -- * Last update 2005-11-06 -- * -- * Created by Ture Andersen on 2005-11-06. -- * Copyright (c) 2005 __MyCompanyName__. -- * GNAT modified GNU General Public License -- * with ada.text_io; use ada.text_io; with ada.unchecked_conversion; package body elements.sets is function member (e : element; s : set) return boolean is begin return (set_of (e) and s) > null_set; end; function member (e : element; s : set) return Natural is c : constant array (boolean) of natural := (false => 0, true => 1); begin return c (member (e, s)); end; function cardinality (s : set) return natural is C : natural := 0; begin for e in element loop c := c + member (e, s); end loop; return c; end cardinality; function empty_set (s : set) return boolean is begin return s = null_set; end empty_set; function set_of (m : element) return set is function uc is new ada.unchecked_conversion (Source => element, Target => set); begin return uc (m); end set_of; function union (l, r : element) return set is begin return set_of (l) or set_of (r); end union; function union (L : element; R : set) return set is begin return set_of (L) or R; end union; function union (L : set; R : element) return set is begin return L or set_of (R); end; function union (L, R : set) return set is begin return L or R; end; function disjoint (l, r : set) return boolean is begin return (l and r) = null_set; end disjoint; function proper_subset (subset, the_set : set) return boolean is begin return ((subset and the_set) = subset) and then (subset < the_set); end proper_subset; function improper_subset (subset, the_set : set) return boolean is begin return (subset and the_set) = subset; end improper_subset; function intersection (l, r : set) return set is begin return l and r; end; function complement (s : set) return set is begin return (not s) and universal_set; end complement; function difference (l, r : set) return set is begin return l - (l and r); end difference; function image (s : set) return string is i : string (int (one) .. int (nine)) := (others => ' '); begin for m in element loop if (set_of (m) and s) > 0 then i (int (m)) := image (m); end if; end loop; return i; end image; end elements.sets; -- * Spec. name elements.sets.ads -- * Project name sudoku -- * -- * Version 1.0 -- * Last update 2005-11-06 -- * -- * Created by Ture Andersen on 2005-11-06. -- * Copyright (c) 2005 __MyCompanyName__. -- * All rights reserved. -- *or (keep only one line or write your own) -- * GNAT modified GNU General Public License -- * package elements.sets is type set is private; null_set : constant set; universal_set : constant set; function set_of (m : element) return set; function image (s : set) return string; function union (l, r : element) return set; function "+" (l, r : element) return set renames union; function union (L : element; R : set) return set; function "+" (L : element; R : set) return set renames union; function union (L : set; R : element) r
[Bug ada/24725] New: Gigi abort, Code=508
-- Summary: Gigi abort, Code=508 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ture dot andersen at zenon dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24725
[Bug c/24724] New: _Unwind_Backtrace() calls malloc
As this stacktrace shows: #3 0x004044e2 in malloc (size=36024) at tcmalloc.cc:1314 #4 0x0047a938 in search_object () #5 0x0047b189 in _Unwind_Find_FDE () #6 0x00478049 in uw_frame_state_for () #7 0x00478eca in uw_init_context_1 () #8 0x004790b0 in _Unwind_Backtrace () there are code paths from _Unwind_Backtrace to malloc. This makes the unwinder deadlock prone when called from applications that have their own customized malloc. -- Summary: _Unwind_Backtrace() calls malloc Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arun dot sharma at google dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-07 23:24 --- In reply to comment #1, yes. The message in the log for -O3 and -Os is now: Executing on host: /home/hp/combined/crislinux-sim/gcc/testsuite/../gfortran -B/home/hp/combined/crislinux-sim/gcc/testsuite/../ \ /home/hp/combined/combined/gcc/testsuite/gfortran.fortran-torture/execute/in-pack.f90 -w -O3 -fomit-frame-pointer -L/home/h\ p/combined/crislinux-sim/ld -static -L/home/hp/combined/crislinux-sim/cris-axis-linux-gnu/./libgfortran/.libs -L/home/hp/combine\ d/crislinux-sim/cris-axis-linux-gnu/./libiberty -lm -o /home/hp/combined/crislinux-sim/gcc/testsuite/in-pack.x(timeout = 3\ 00) /home/hp/combined/crislinux-sim/cris-axis-linux-gnu/./libgfortran/.libs/libgfortran.a(fpu.o): In function `*_gfortrani_set_fpu':.\ /fpu-target.h:42: warning: warning: fedisableexcept is not implemented and will always fail^M output is: /home/hp/combined/crislinux-sim/cris-axis-linux-gnu/./libgfortran/.libs/libgfortran.a(fpu.o): In function `*_gfortrani_set_fpu':.\ /fpu-target.h:42: warning: warning: fedisableexcept is not implemented and will always fail^M PASS: gfortran.fortran-torture/execute/in-pack.f90 compilation, -O3 -fomit-frame-pointer program stopped with signal 6.^M So I guess you'd see it for targets where floating point rounding cannot be changed (usually, no hardware support and implemented through fp-bit.c). -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-07 23:24:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24342
[Bug c++/21308] [3.4/4.0 Regression] Very high compile time
--- Comment #15 from mmitchel at gcc dot gnu dot org 2005-11-07 23:10 --- *** Bug 23457 has been marked as a duplicate of this bug. *** -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||laurent dot deniau at cern ||dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21308
[Bug c++/23457] [3.4/4.0/4.1 Regression] compiler crash on huge object size with virtual base
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-11-07 23:10 --- *** This bug has been marked as a duplicate of 21308 *** -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23457
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Severity|normal |enhancement Status|REOPENED|ASSIGNED Last reconfirmed|2005-11-07 15:15:56 |2005-11-07 23:06:57 date|| Summary|[3.4/4.0/4.1 Regression]|__gnu_cxx::__exchange_and_ad |__gnu_cxx::__exchange_and_ad|d is called even for single |d is out of line and called |threaded applications |even for single threaded| |applications using | |std::string | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24720] poorly named include guard in stl_tree.h
--- Comment #2 from pcarlini at suse dot de 2005-11-07 21:54 --- (In reply to comment #1) > Note _TREE_H is reserved by the standard for implementations so this is a > correct use really. Anyone using _TREE_H in their headers are asking for > troubles as they are using a reserved identifier. Indeed. Please read closely 17.4.3.1.2. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24720
[Bug libstdc++/24720] poorly named include guard in stl_tree.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 21:51 --- Note _TREE_H is reserved by the standard for implementations so this is a correct use really. Anyone using _TREE_H in their headers are asking for troubles as they are using a reserved identifier. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24720
[Bug c++/24720] New: poorly named include guard in stl_tree.h
Due to the global nature of macros, the include guard at the top of stl_tree.h: #ifndef _TREE_H ... should be renamed to something more specific such as _STL_TREE_H. _TREE_H shouldn't really be defined by anyone, especially the STL library. I noticed this header from someone else who wrote code with a C include guard of the same name which caused a compiler error when using #include . This convention of being as specific as possible for any include guard macro should be pervasive through the entire C++ header collection. -- Summary: poorly named include guard in stl_tree.h Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carmelo dot piccione at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24720
[Bug fortran/24719] New: Summary: [4.1 Regression] Nonadvancing read does not read more than 1 line
Revision 1.64 of libgfortran/io/transfer.c causes a regression for the following testcase: % cat < regression.f90 program demonstration implicit none character(len=1) :: saux open(unit = 1, FILE = "foo.conf", STATUS = 'OLD', ACTION = 'READ') do 10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 11) saux print *, "'", saux, "'" cycle 11print *, "Newline" end do 99 close(1) end program EOF % cat < foo.conf foo1: bar 1.2 EOF ifort and g95 compiled binaries give: 'f' 'o' 'o' '1' ':' ' ' 'b' 'a' 'r' Newline '1' '.' '2' Newline while gfortran 4.1.0 20051024 gives only the characters from the first line of 'foo.conf', all characters after the first 'end of record' are whitespace: 'f' 'o' 'o' '1' ':' ' ' 'b' 'a' 'r' Newline ' ' ' ' ' ' Newline For sake of compliance with the bug report policy: * gfortran from cvs via TZ=GMT cvs -q update -D'2005.10.24.03.00.00' works, * gfortran from cvs via TZ=GMT cvs -q update -D'2005.10.24.04.00.00' does not. By the way, there is another small issue with the above testcase. I'm not sure if I should file a separate bug report for it: Changing line 6 of regression.f90 to 10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 10) saux gives the incorrect warning: In file regression.f90:6 10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 10) saux 1 Warning: Branch at (1) causes an infinite loop while ifort and g95 do not complain. -- Summary: Summary: [4.1 Regression] Nonadvancing read does not read more than 1 line Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sven dot buijssen at math dot uni-dortmund dot de 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=24719
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-07 21:16 --- (In reply to comment #8) > If - > > cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc > > is now wrong, what is the correct CVS command to use ? GCC does not use cvs any more. Read http://gcc.gnu.org/svn.html What happens if you do "make bootstrap" instead of make? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #8 from dir at lanl dot gov 2005-11-07 21:14 --- If - cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc is now wrong, what is the correct CVS command to use ? Changing the directory make no difference, I have done exactly the same thing for the last year or so and I had trouble building gfortran on the macintosh only one other time - configure --prefix=/Users/dir/bin --enable-languages=c,f95 make -j 4 ... ... for mlib in '' $MLIBS ; do \ strip -o libgcc_s.10.4.dylib_T${mlib} \ -s ../.././gcc/config/rs6000/darwin-libgcc.10.4.ver -c -u \ libgcc_s${mlib}.1.dylib || exit 1 ; \ done MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc -B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/ -B/Users/dir/bin/powerpc-apple-darwin8.3.0/bin/ -B/Users/dir/bin/powerpc-apple-darwin8.3.0/lib/ -isystem /Users/dir/bin/powerpc-apple-darwin8.3.0/include -isystem /Users/dir/bin/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \ | sed -e 's/;.*$//' -e '/^\.$/d' -e 's/^/_/'` ; \ for mlib in '' $MLIBS ; do \ strip -o libgcc_s.10.5.dylib_T${mlib} \ -s ../.././gcc/config/rs6000/darwin-libgcc.10.5.ver -c -u \ libgcc_s${mlib}.1.dylib || exit 1 ; \ done Could Not Open (-o) To Read make[2]: *** [libgcc_s.10.4.dylib] Error 1 make[2]: *** Waiting for unfinished jobs Could Not Open (-o) To Read make[2]: *** [libgcc_s.10.5.dylib] Error 1 rm cpp.pod gfortran.pod fsf-funding.pod gpl.pod gcc.pod gcov.pod gfdl.pod make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug c++/24717] spurious error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 21:00 --- Fixed in 4.0.0 and above. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||2.95.3 3.2.3 3.4.0 3.4.5 Known to work||4.0.0 4.1.0 4.0.3 Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24717
[Bug rtl-optimization/23490] [3.4/4.0 Regression] Long compile time for array initializer with inlined constructor
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-07 20:56 --- Fixed at least on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1 Regression]|[3.4/4.0 Regression] Long |Long compile time for array |compile time for array |initializer with inlined|initializer with inlined |constructor |constructor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-07 20:43 --- -O1 -fno-tree-ccp -fno-tree-store-ccp -fno-tree-dominator-opts works (maybe this will give a hint on how to reduce the issue). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-07 20:39 --- A little more info, umf_analyze.i is being miscompiled. I don't know which one yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug fortran/24409] ICE on module name vs dummy argument name
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-07 20:14 --- > Did this patch ever get posted? Tobi, that's a coincidence; I just found it whilst working on dot_product! I'll submit in the next 24 hours. I've found another patch that I just forgot about too -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24409
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #13 from thebohemian at gmx dot net 2005-11-07 20:03 --- anthony you're right. It should work without ffi_call invocation. Thanks for the review. I try to find out whether this fixes my segfault too, tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-07 20:03 --- Can you try first by not building in the source directory? Second that CVS repro is no longer being updated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug libstdc++/21072] base allocator change shared object issues
--- Comment #7 from matz at suse dot de 2005-11-07 19:59 --- Of course not. But unaware people trying trunk currently on distros which provided 3.4 or 4.0 will get non-obvious problems, and I'm not sure if that's a good idea (ignoring this problem 4.0 and trunk are nearly compatible, and 4.0 compiled programs work with the trunk libstc++, which has the same SOname like the 4.0 one). I think the only way to switch to the 'mt' allocator by default for the future without API issues would be to rename it to 'new', and not via some configure arguments. Another reason is that this switching back of the default allocator is not forgotten when 4.1 branches, which I think is necessary anyway, so that 4.1 libs are compatible with 4.0 programs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
[Bug preprocessor/15220] [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory
--- Comment #19 from wilson at gcc dot gnu dot org 2005-11-07 19:52 --- Fixed on gcc-3.4.x branch, gcc-4.0.x branch, and mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.3 4.1.0 |4.0.3 4.1.0 3.4.5 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug preprocessor/15220] [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory
--- Comment #18 from wilson at gcc dot gnu dot org 2005-11-07 19:51 --- Mine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2004-04-30 12:53:54 |2005-11-07 19:51:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug preprocessor/15220] [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory
--- Comment #17 from wilson at gcc dot gnu dot org 2005-11-07 19:49 --- Subject: Bug 15220 Author: wilson Date: Mon Nov 7 19:49:04 2005 New Revision: 106608 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106608 Log: Fix problem with -MM -MG and missing system header files. PR preprocessor/15220 * cppfiles.c (_cpp_find_file): New parameter angle_brackets. Fix all callers. Pass to open_file_failed. (open_file_failed): New parameter angle_brackets. Fix all callers. use in print_dep assignment. * cpphash.h (_cpp_find_file): Add new parm to declaration. * cppinit.c (cpp_read_main_file): Pass another arg to _cpp_find_file. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/cppfiles.c branches/gcc-3_4-branch/gcc/cpphash.h branches/gcc-3_4-branch/gcc/cppinit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug c++/21123] [4.0/4.1 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #24 from jason at gcc dot gnu dot org 2005-11-07 19:35 --- This is a bug in the generic thunk support; it doesn't show up on x86 because it uses asm thunks. Continuing to investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug driver/24718] New: Shared libgcc not used for linking by default
I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit the same problem. While trying to build Perl 5.8.6: $ gmake ... gcc -v -o libperl.so -shared -fPIC perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl -lnm -ldl -ldld -lm -lsec -lpthread -lc ... /opt/TWWfsw/gcc343/libexec/gcc/ia64-hp-hpux11.23/3.4.3/collect2 +Accept TypeMismatch -b -o libperl.so -L/opt/TWWfsw/gcc343r/lib -L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/../../.. perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl -lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc -lgcc ^^^ Notice the "-lgcc -lgcc" at the end of the collect2 command-line, not "-lgcc_s -lgcc_s". On HP-UX 11.23/PA-RISC, I get: /opt/TWWfsw/gcc343/libexec/gcc/hppa2.0-hp-hpux11.23/3.4.3/collect2 -z -b -o libperl.sl -L/opt/TWWfsw/gcc343r/lib -L/opt/TWWfsw/gcc343r/lib -L/opt/TWWfsw/gcc343/lib/gcc/hppa2.0-hp-hpux11.23/3.4.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/langtools/lib -L/opt/TWWfsw/gcc343/lib perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl -lnm -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lgcc_s -lgcc_s Using the HP pre-compiled binary of gcc-4.0.2, I get: /opt/hp-gcc/4.0.2/bin/../libexec/gcc/ia64-hp-hpux11.23/4.0.2/collect2 -z +Accept TypeMismatch -b -o libperl.so -L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2 -L/opt/hp-gcc/4.0.2/bin/../lib/gcc -L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2/../../.. -L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2/../../.. perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl -lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc_s -lunwind -lgcc_s -lunwind The "*libgcc" line from the 3.4.3/3.4.4 specs file: *libgcc: %{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64} %{static|static-libgcc:-lgcc -lgcc_eh -lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh -lunwind}%{shared-libgcc:-lgcc_s%M -lunwind -lgcc}}%{shared:-lgcc_s%M -lunwind%{!shared-libgcc:-lgcc} The "*libgcc" line from the 4.0.2 specs file (via -dumpspecs): *libgcc: %{static|static-libgcc:-lgcc -lgcc_eh -lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh -lunwind}%{shared-libgcc:-lgcc_s -lunwind -lgcc}}%{shared:-lgcc_s -lunwind}}} Is the problem in the "*libgcc" entry? It seems !shared-libgcc is true, though I don't know why. $ /opt/TWWfsw/gcc343/bin/gcc -v Reading specs from /opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/specs Configured with: /opt/build/gcc-3.4.3/configure --with-gnu-as --with-as=/opt/TWWfsw/gcc343/ia64-hp-hpux11.23/bin/as --with-included-gettext --enable-shared --datadir=/opt/TWWfsw/gcc343/share --enable-languages=c,c++,f77 --with-local-prefix=/opt/TWWfsw/gcc343 --prefix=/opt/TWWfsw/gcc343 Thread model: single gcc version 3.4.3 (TWW) -- Summary: Shared libgcc not used for linking by default Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugzilla-gcc at thewrittenword dot com GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #6 from dir at lanl dot gov 2005-11-07 19:19 --- I have a dual 2.5 GHZ PowerPC G5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #5 from dir at lanl dot gov 2005-11-07 19:17 --- I do the get with - [dranta:~/utlib] dir% cat gfortranGet cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc I do the configure with - [dranta:~/utlib] dir% cat gfortranConfig configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug driver/24684] No flag documentation for gomp (openmp)
--- Comment #2 from dnovillo at gcc dot gnu dot org 2005-11-07 19:06 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00458.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24684
[Bug c++/24717] New: spurious error
enum A{a,b,c}; template void f(const U&, int) {} template void f(const U&, int) {} template void f(const U&, int) {} template void f(const U&, int, int) {} template void f(const U&, int, int) {} template void f(const U&, int, int) {} int main() { bool b; f(b, 5); f(b, 5); f<>(b, 5); f(b, 5, 10); f(b, 5, 10); f<>(b, 5, 10); } gets you: ~/ootbc/members/src$ g++ foo.cc foo.cc: In function `int main()': foo.cc:11: error: invalid conversion from `int' to `A' foo.cc:12: error: invalid conversion from `int' to `A' Ivan -- Summary: spurious error Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24717
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #24 from ian at airs dot com 2005-11-07 18:58 --- Fixed on 4.0 branch and on mainline. The 3.4 branch breaks in a slightly different way. I'm not going to worry about it since you can only create this problem by building implausible addresses that include offsets of more than 2GB. -- ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #23 from ian at gcc dot gnu dot org 2005-11-07 18:55 --- Subject: Bug 24683 Author: ian Date: Mon Nov 7 18:55:03 2005 New Revision: 106602 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106602 Log: ./: PR rtl-optimization/24683 * config/i386/i386.c (legitimize_pic_address): If constant operand to PLUS is too large, put it in a register. testsuite/: PR rtl-optimization/24683 * gcc.dg/pr24683.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr24683.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/i386/i386.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #22 from ian at gcc dot gnu dot org 2005-11-07 18:52 --- Subject: Bug 24683 Author: ian Date: Mon Nov 7 18:52:24 2005 New Revision: 106601 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106601 Log: ./: PR rtl-optimization/24683 * config/i386/i386.c (legitimize_pic_address): If constant operand to PLUS is too large, put it in a register. testsuite/: PR rtl-optimization/24683 * gcc.dg/pr24683.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr24683.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-07 18:49 --- (In reply to comment #0) > The error seems to be specific to powerpc; it does not happen on i386. It does fail for me on i686 with 4.1.0 20051026. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #21 from mueller at kde dot org 2005-11-07 18:45 --- its an error in the testcase, the original code initializes i: if((j + len) > 63) { 562 memcpy(&context->buffer[j], data, (i = 64-j)); 563 transform(context->state, context->buffer); 564 for ( ; i + 63 < len; i += 64) { 565 transform(context->state, &data[i]); 566 } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-07 18:42 --- Created an attachment (id=10165) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10165&action=view) Tarball with source code demonstrating the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|Wrong code generated when |[4.1 Regression] Wrong code |optimising |generated when optimising Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #20 from ian at airs dot com 2005-11-07 18:41 --- By the way, Richard, I just want to note that while this is obviously a compiler bug, it is only being triggered for the original test case because of the uninitialized variable i in sha1_update: void sha1_update(SHA1_CONTEXT* context, unsigned char* data, Q_UINT32 len) { Q_UINT32 i, j; if((j + len) > 63) { for ( ; i + 63 < len; i += 64) { transform(context->state, &data[i]); } } } I don't know if that was a consequence of your test case reduction or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug bootstrap/24688] [3.4 Regression] sco_math fixincl breaks math.h
--- Comment #4 from sje at cup dot hp dot com 2005-11-07 18:40 --- Original patch submittal is at http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html I will apply this to the 3.4 branch and test it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
[Bug c/24716] New: Wrong code generated when optimising
In a large application, a certain routine from the UMFPACK library is miscompiled when -O is specified. Without optimisation, the routine works fine. This triggers an assertion failure in the code. I use gcc (GCC) 4.1.0 20051030 (experimental). The problem can be reproduced with the attached source files. To see the error, compile them with /gcc/bin/gcc -g -O -o umfpack-bug umfpack-call.c umf_analyze.i umf_apply_order.i umf_order_front_tree.i umf_dump.i When run, the executable aborts with an assertion failure: /Users/eschnett/Calpha/arrangements/AEIThorns/AHFinderDirect/src/sparse-matrix/umfpack/umf_analyze.c:500: failed assertion `parent == j+1' Abort trap (core dumped) To make the error go away, omit the "-O" option. In this case, the executable runs without producing any output. The error seems to be the following. The routine UMF_analyze contains a large loop in which the local variable pdest is changed. In the next iteration, pdest is reset to the value it had before the loop. This happens only for local variables, not for static or global variables. The error seems to be specific to powerpc; it does not happen on i386. gcc 3.3 does not have this problem. -- Summary: Wrong code generated when optimising Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: powerpc-apple-darwin8.2.0 GCC host triplet: powerpc-apple-darwin8.2.0 GCC target triplet: powerpc-apple-darwin8.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug bootstrap/24688] [3.4 Regression] sco_math fixincl breaks math.h
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|sco_math fixincl breaks |[3.4 Regression] sco_math |math.h |fixincl breaks math.h Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
[Bug bootstrap/24688] sco_math fixincl breaks math.h
--- Comment #3 from sje at cup dot hp dot com 2005-11-07 18:26 --- It looks like this is fixed on the mainline and on the 4.0 branch by the addition of bypass = "__GNUG__"; This patch was done in revision 90550 by jsm28. We should do this for the 3.4 branch as well. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-07 18:26:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #21 from bonzini at gcc dot gnu dot org 2005-11-07 18:22 --- Is this a 4.0 regression too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug bootstrap/17269] make install doesn't work after --enable-bootstrap enabled bootstrap
--- Comment #3 from bonzini at gcc dot gnu dot org 2005-11-07 18:19 --- it works now -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17269
[Bug c/24599] [4.0 regression] Overflow for true value
--- Comment #9 from bonzini at gcc dot gnu dot org 2005-11-07 18:18 --- fixed on 4.0 branch too -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.3 |4.0.2 Known to work|3.4.0 4.1.0 |3.4.0 4.0.3 4.1.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599