--- Comment #5 from nico at josuttis dot de 2010-04-25 07:03 ---
I gues with move.exe you mean my generated exe file.
I have three versions here:
cygcheck for the full buggy program (including vector declaration):
---
--- Comment #6 from nico at josuttis dot de 2010-04-25 07:06 ---
Created an attachment (id=20480)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20480action=view)
hello.exe for the buggy 4.5.0 version (with declared vector)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
I ran this simple example with the argument 45 through various versions of gcc
(option -O3):
#include stdlib.h
#include stdio.h
int fib(int AnArg) {
if (AnArg = 2) return (1);
return (fib(AnArg-1)+fib(AnArg-2));
}
int main(int argc, char* argv[]) {
int n = atoi(argv[1]);
--- Comment #7 from nico at josuttis dot de 2010-04-25 07:25 ---
compiling with -static also fixes the problem, which also supports
the theory of using wrong DLL's.
The only question is, why are the wrong libs used without -static.
Any idea?
--
--- Comment #2 from ubizjak at gmail dot com 2010-04-25 07:37 ---
The attached source does not fail for x86_64-linux target. Can you try to run
the compilation through the debugger to provide a backtrace? Follow this
procedure:
gdb --args /path/to/gcc/cc1 [...flags...] -quiet source.i
--- Comment #3 from gcc-tgc at jupiterrise dot com 2010-04-25 09:34 ---
$ gdb --args /export/home/tgc/build/gcc450_all_native/./gcc/cc1 -fpreprocessed
divtf3.i -quiet -dumpbase divtf3.c -mtune=generic -march=pentium4
-auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings
raised STORAGE_ERROR : stack overflow (or erroneous memory access)
make[3]: *** [ada/treeprs.ads] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
make[3]: Leaving directory `/home/ig25/Gcc/trunk-bin/gcc'
make[2]: *** [all-stage1-gcc] Fehler 2
make[2]: Leaving directory
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-04-25 11:16 ---
Created an attachment (id=20481)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20481action=view)
Build log (with script)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43885
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-25 11:42 ---
You can compare the code if you compile with -S (output .s assembler file). Or
you can compile with -S and attach the output of both compilers here, so
someone else can have a look.
--
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-25 12:13 ---
Confirmed on x86_64-linux by comparing gcc 4.3.3 vs. gcc 4.6.0 (r158482). The
average of 10 runs on each is 5.1s with gcc 4.3.3 vs. 5.7s for gcc 4.4.2, gcc
4.5.0 and gcc 4.6.0.
One interesting difference is that GCC
--- Comment #8 from davek at gcc dot gnu dot org 2010-04-25 12:14 ---
P:\gcc4\bin\cyggcc_s-sjlj-1.dll
This is the source of all your problems. Sorry, I should have been able to
work this out just from seeing your configure line earlier.
The SJLJ and DW2 EH models are incompatible.
The following code (reduced for context) is taken from n3092
[expr.prim.lambda], 5.1.2/13, where it states:
A lambda expression appearing in a default argument shall not implicitly or
explicitly capture and entity.
/cygdrive/d/CPPProjects/nano/gcc_bugs $cat _5_1_2_13.cpp
// file:
--- Comment #2 from tkoenig at gcc dot gnu dot org 2010-04-25 12:51 ---
Bootstrap succeeds when the first-stage compiler is
4.4.0.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-04-25 14:07
---
Please try with a more recent version (or avoid bootstrapping with mainline at
all, it's in constant flux).
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from nico at josuttis dot de 2010-04-25 14:15 ---
Subject: Re: container declaration disables standard
output
Thanks a lot, Paolo and Dave.
The explanation makes total sense to me and putting gcc 4.5.0
in front of the path fixes the problem.
I would have searched very
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-25 14:31 ---
can you provide a backtrace of this crash ?
Putting a breakpoint at fancy_abort is not enough to get a backtrace:
[karma] gcc/darwin_buildw% gdb /opt/gcc/darwin_buildw/./gcc/xgcc
GNU gdb 6.3.50-20050815 (Apple
--- Comment #17 from janus at gcc dot gnu dot org 2010-04-25 14:32 ---
Created an attachment (id=20482)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20482action=view)
patch v2
The attached patch extends the one in comment #7, fixing all regressions
related to non-generic TBPs
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-04-25 14:39
---
Putting a breakpoint at fancy_abort is not enough to get a backtrace:
Because you aren't debugging the right executable (xgcc instead of cc1). Pass
-v to the driver to get the command line involving cc1 and
--- Comment #4 from m dot b dot lankhorst at gmail dot com 2010-04-25
14:41 ---
Created an attachment (id=20483)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20483action=view)
Patch that fixes the testcase
It appears that SSE_REGPARM_MAX will change based on ix86_cfun_abi(), so
--- Comment #18 from janus at gcc dot gnu dot org 2010-04-25 14:42 ---
Here is a maximally reduced version of comment #8 example 2, which still fails
with the patch in comment #17:
module m
type :: t1
contains
procedure :: make_integer
generic :: extract = make_integer
--- Comment #19 from janus at gcc dot gnu dot org 2010-04-25 14:56 ---
Created an attachment (id=20484)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20484action=view)
patch v3
Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remaining
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-25 15:39 ---
Because you aren't debugging the right executable (xgcc instead of cc1). Pass
-v to the driver to get the command line involving cc1 and feed it to cc1
directly.
Thanks for the tip. The backtrace is
Program
The anchors created by makeinfo --html are not stable. This means that links to
anchors become outdated quickly. For example, the links to options in
http://gcc.gnu.org/gcc-4.5/changes.html
are already broken.
--
Summary: stable anchors needed
Product: gcc
--- Comment #20 from pault at gcc dot gnu dot org 2010-04-25 16:27 ---
(In reply to comment #19)
Janus,
When I got up this morning, I made a start on documenting the fortran-dev
version of gfc_find_derived_vtab with a view to understand the code flow and to
understand why the original
--- Comment #21 from dominiq at lps dot ens dot fr 2010-04-25 16:38 ---
Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remaining regressions are:
* dynamic_dispatch_{1-3}.f03
I also have
[macbook] f90/bug% gfc
--- Comment #22 from janus at gcc dot gnu dot org 2010-04-25 16:43 ---
(In reply to comment #21)
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03:84:0:
internal
compiler error: Segmentation fault
Yes, I can confirm that: typebound_operator_{3,4}.f03 both fail with
--- Comment #23 from janus at gcc dot gnu dot org 2010-04-25 17:09 ---
Created an attachment (id=20485)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20485action=view)
patch v4
The attached update of the patch removes the ICEs in
typebound_operator_{3,4}.f03.
--
--- Comment #24 from janus at gcc dot gnu dot org 2010-04-25 17:16 ---
(In reply to comment #20)
My suspicion, which is strengthened by the remaining regressions for version 3
of your fix, is that the generic components of the vtab should not be marked
as
ppc. I have been tempted
--- Comment #25 from janus at gcc dot gnu dot org 2010-04-25 18:23 ---
I just did a full testsuite run, verifying that dynamic_dispatch_{1-3}.f03
are indeed the only failures with the patch in comment #23.
This means that, if we can fix the failure in comment #24, the branch will most
--- Comment #26 from paul dot richard dot thomas at gmail dot com
2010-04-25 18:28 ---
Subject: Re: [fortran-dev Regression] ICE: segmentation
fault
Dear Janus,
I thought that I would lend a helping hand, so I applied your latest
patch to my fortran-dev. Since I had left
Here's what the alias-7.c test looks like, after preprocessing:
int foo __asm__ (_ foo) __attribute__((nocommon));
extern __typeof (foo) bar __attribute__ ((weak, alias (foo)));
int
main (void)
{
if (foo != bar || foo || bar)
abort ();
return bar;
}
But here's how it
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #1 from davek at gcc dot gnu dot org 2010-04-25 18:36 ---
Created an attachment (id=20487)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20487action=view)
Simple fix.
Maybe a bit verbose; I only made it a separate if clause so it could have its
own comment, but should
--- Comment #28 from paul dot richard dot thomas at gmail dot com
2010-04-25 18:59 ---
Subject: Re: [fortran-dev Regression] ICE: segmentation
fault
Janus,
Forget all of our last exchanges - I screwed up somehow with the
patch. This has nothing to do with your problem
--- Comment #13 from jb at gcc dot gnu dot org 2010-04-25 19:01 ---
Subject: Bug 40539
Author: jb
Date: Sun Apr 25 19:01:06 2010
New Revision: 158707
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158707
Log:
PR fortran/40539 Document LOGICAL representation
Modified:
--- Comment #14 from jb at gcc dot gnu dot org 2010-04-25 19:04 ---
The GFortran behavior is now documented on 4.4, 4.5, and trunk. Closing as
fixed.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from sfilippone at uniroma2 dot it 2010-04-25 19:16 ---
(In reply to comment #27)
Created an attachment (id=20486)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486action=view) [edit]
Tried this patch: compilation goes past the previous point, so we made
--- Comment #30 from janus at gcc dot gnu dot org 2010-04-25 19:50 ---
(In reply to comment #29)
(In reply to comment #27)
Created an attachment (id=20486)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486action=view) [edit]
Tried this patch: compilation goes past the
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-25 20:03 ---
Well, the innermost loop with current trunk is
.L3:
leal-1(%ebx), %eax
subl$2, %ebx
movl%eax, (%esp)
callfib
addl%eax, %esi
cmpl$2, %ebx
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-25 20:06 ---
Btw, with the optimal options -O2 -fwhole-program -fomit-frame-pointer
-mpreferred-stack-boundary=2 GCC 4.3 and 4.4 are slower than 4.1 and 4.5
(14.3s vs. 13.8s). The extra stack alignment drops us to 16.4s(!).
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-25 20:09 ---
There isn't any pattern for the TImode variant.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-25 20:13 ---
(In reply to comment #4)
(In reply to comment #2)
It is called directly because safe_close's value is replaced in the
indirect call. Since safe_close is static and not changed in the code
at all, it is
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-25 20:13 ---
Well. Mine then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from janus at gcc dot gnu dot org 2010-04-25 20:17 ---
Ok, back to fixing the remaining regression, namely comment #24. Compiling this
with and without the patch in comment #23 shows the following difference:
--- c24.dump.unpatched 2010-04-25 22:03:44.418204091 +0200
--- Comment #32 from sfilippone at uniroma2 dot it 2010-04-25 20:20 ---
(In reply to comment #30)
Salvatore: As you heard, Paul's patch is screwed up. Maybe you could rather
try
the patch in comment #23, which is clean (except for a small regression) and
fixes your original
--- Comment #7 from redi at gcc dot gnu dot org 2010-04-25 20:31 ---
(In reply to comment #5)
It really was picking up the default libstdc++.so from the OS installation. I
used -R/path/to/4.5.0/libstdc++.so to fix this library path. But it turns out
that
--- Comment #33 from janus at gcc dot gnu dot org 2010-04-25 21:44 ---
Created an attachment (id=20488)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20488action=view)
patch v5
The attached version of the patch clears the failures of
dynamic_dispatch_{1-3}.f03. It is free of
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-25 22:01 ---
(In reply to comment #4)
Btw, with the optimal options -O2 -fwhole-program -fomit-frame-pointer
-mpreferred-stack-boundary=2 GCC 4.3 and 4.4 are slower than 4.1 and 4.5
(14.3s vs. 13.8s). The extra stack
I've triaged the following regressions to be introduced at revision r154688:
FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O3
-fomit-frame-pointer -funroll-loops
FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions
FAIL:
--- Comment #34 from janus at gcc dot gnu dot org 2010-04-25 22:26 ---
(In reply to comment #33)
Will do a full testsuite run now.
The testsuite completed cleanly, without any failures. Paul, if you agree that
this patch is ok, I can commit it tomorrow.
--
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org
--- Comment #6 from hubicka at ucw dot cz 2010-04-25 23:42 ---
Subject: Re: [4.4/4.5/4.6 Regression] Performance
degradation for simple fibonacci numbers calculation due to extra
stack alignment
where the only difference is different loop alignment and keeping the
--- Comment #7 from hubicka at ucw dot cz 2010-04-25 23:43 ---
Subject: Re: [4.4/4.5/4.6 Regression] Performance
degradation for simple fibonacci numbers calculation due to extra
stack alignment
The slowdown also happens on x86-64. Stack alignment checks
leaf
--- Comment #4 from hubicka at ucw dot cz 2010-04-25 23:44 ---
Subject: Re: ICE with -flto -O3 (BB N can not
throw but has an EH edge)
Seems to work for me, even with the 4.5.0 release.
Note that on mainline the code removing wpa fixup should help here too. There
clearly was
/jarryd/gcc-latest-install --enable-languages=c,c++ --no-create
--no-recursion
Thread model: posix
gcc version 4.6.0 20100425 (experimental) (GCC)
--
Summary: invalid uninitialized reference in class
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
--- Comment #1 from hp at gcc dot gnu dot org 2010-04-26 02:36 ---
The regrename change renamed registers so the destination overlapped a clobber
in the div (or mod) insns. That in turn can be blamed on missing earlyclobbers
for those alternatives in the patterns, thus changing
--- Comment #20 from justinmattock at gmail dot com 2010-04-26 02:41
---
Created an attachment (id=20489)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20489action=view)
dmesg with 4.6.0 and latest kernel(good boot).
I compiled the kernel with the -01 option and ended up hitting
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-04-26 04:45
---
Created an attachment (id=20490)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20490action=view)
First attempt a a patch to allow reading inf and NaN with parens
This patch implements a filter to extract
58 matches
Mail list logo
