--- Comment #13 from burnus at gcc dot gnu dot org 2010-04-26 06:11 ---
Kai, what about the GetTempPath? Cf. the rough draft in attachment 20460 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
--- 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=20490&action=view)
First attempt a a patch to allow reading inf and NaN with parens
This patch implements a filter to extract t
--- 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=20489&action=view)
dmesg with 4.6.0 and latest kernel(good boot).
I compiled the kernel with the -01 option and ended up hitting
--- 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 componen
ix=/home/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: UNC
--- 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
--- 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 functi
--- 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
> s
--
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 #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.
--
http://gcc.gnu.org/bugz
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 #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 ali
--- 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=20488&action=view)
patch v5
The attached version of the patch clears the failures of
dynamic_dispatch_{1-3}.f03. It is free of regr
--- 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 -L/path/to/4.5.0/libstdc
--- 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 p
--- 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 #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
AssignedT
--- 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
--- 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 #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 #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 #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=20486&action=view) [edit]
> >
> Tried this patch: compilation goes past t
--- 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=20486&action=view) [edit]
>
Tried this patch: compilation goes past the previous point, so we made
pro
--- 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 #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=gcc&view=rev&rev=158707
Log:
PR fortran/40539 Document LOGICAL representation
Modified:
branch
--- 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
Sorr
--- 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=20487&action=view)
Simple fix.
Maybe a bit verbose; I only made it a separate if clause so it could have its
own comment, but should
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
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
--- 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 so
--- 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 #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 tempt
--- 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=20485&action=view)
patch v4
The attached update of the patch removes the ICEs in
typebound_operator_{3,4}.f03.
--
http://gcc.g
--- 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 #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
/opt/gcc/work/gcc/t
--- 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 p
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
Ver
--- 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 r
--- 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=20484&action=view)
patch v3
Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remainin
--- 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
en
--- 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=20483&action=view)
Patch that fixes the testcase
It appears that SSE_REGPARM_MAX will change based on ix86_cfun_abi(), so
--- 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 fe
--- 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=20482&action=view)
patch v2
The attached patch extends the one in comment #7, fixing all regressions
related to non-generic TBPs (h
--- 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 ver
--- 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 l
--- 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 #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
--
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: _5_1_
--- 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.
--- 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 #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.
--
http://gcc.gnu.org/bugzilla
--- 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=20481&action=view)
Build log (with script)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43885
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 `/home/ig25/G
--- 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
-
--- 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 #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?
--
http://gcc.gnu.org/bugzilla/show_bug.c
I ran this simple example with the argument 45 through various versions of gcc
(option -O3):
#include
#include
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]);
printf("fib(%i)=%i\n", n, fib(n));
--- 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=20480&action=view)
hello.exe for the buggy 4.5.0 version (with declared vector)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
--- 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):
---
D:\bu
59 matches
Mail list logo
