--- Comment #10 from pault at gcc dot gnu dot org 2007-10-27 07:07 ---
The logic is all wrong in parse.c(gfc_fixup_sibling_symbols). I can fix this
bug but I need to regtest and to check for other such cases in the standard.
Paul
--
pault at gcc dot gnu dot org changed:
--- Comment #16 from jakub at gcc dot gnu dot org 2007-10-27 09:42 ---
Created an attachment (id=14413)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14413&action=view)
perl-5.8.7-aliasing.patch
Sure, here is a minimal patch against perl 5.8.7 which cures this (and for
whatever re
--- Comment #17 from jakub at gcc dot gnu dot org 2007-10-27 09:43 ---
Closing as this isn't really a GCC bug, but perl and 400.perlbench bug.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-10-27 11:10
---
Subject: Bug 33870
Author: rguenth
Date: Sat Oct 27 11:10:09 2007
New Revision: 129675
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129675
Log:
2007-10-27 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-27 11:18
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from steven at gcc dot gnu dot org 2007-10-27 11:34 ---
After making hoist_code look down the dominator tree a bit further, and fixing
--param max-gcse-passes for code hoisting, the next problem surfaces.
When we hoist an expression, we replace the expression with the rea
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-27 11:58 ---
Subject: Bug 33842
Author: jakub
Date: Sat Oct 27 11:58:26 2007
New Revision: 129677
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129677
Log:
PR c++/33842
* cxx-pretty-print.h (pp_cxx_offseto
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-27 12:00 ---
Fixed so far on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #6 from rask at gcc dot gnu dot org 2007-10-27 12:46 ---
As far as I can tell (from running cc1 in a debugger), the problem is not so
much the size of the file, but that it contains two large functions and GCC
leaks memory. After compiling the first large function, the proces
--- Comment #6 from jakub at gcc dot gnu dot org 2007-10-27 13:29 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #11 from burnus at gcc dot gnu dot org 2007-10-27 13:31 ---
To recap (correct me, if I'm wrong):
The program in comment 0 (original bug description) is valid Fortran, but the
"setbd" is an external function which needs to be provided at link time. It is
not the module functi
--- Comment #4 from rask at gcc dot gnu dot org 2007-10-27 13:40 ---
*** Bug 33918 has been marked as a duplicate of this bug. ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rask at gcc dot gnu dot org 2007-10-27 13:40 ---
This is not a regression (as far as I know), so it won't be fixed in anything
earlier than 4.3.0.
GCC dies trying to figure out which of BYTE PTR, WORD PTR, etc. it should print
for a structure. You may be able to work
With current trunk:
(sid)[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O3 gclcvs-tinfo.c
gclcvs-tinfo.c: In function 'init_code':
gclcvs-tinfo.c:19: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summa
--- Comment #1 from tbm at cyrius dot com 2007-10-27 14:16 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
typedef union lispunion *object;
struct character
{
long e;
};
extern struct symbol Cnil_body;
extern struct symbol Ct_body;
struct vector
{
object *v_self;
};
union
--- Comment #2 from tbm at cyrius dot com 2007-10-27 14:16 ---
Program received signal SIGSEGV, Segmentation fault.
0x40705cb1 in combine_blocks (loop=0x204214a0)
at gcc/tree-if-conv.c:727
727 if (TREE_CODE (tmp_cond) == TRUTH_NOT_EXPR)
(gdb) where
#0 0x400
--- Comment #2 from burnus at gcc dot gnu dot org 2007-10-27 14:44 ---
Subject: Bug 33862
Author: burnus
Date: Sat Oct 27 14:43:53 2007
New Revision: 129680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129680
Log:
2007-10-27 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-27 14:46 ---
FIXED on the trunk (GCC 4.3.0).
As suggested, .FTN (and now .FOR) use the preprocessor.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
Executing on host: /home/dave/gcc-4.3/objdir/gcc/xgcc
-B/home/dave/gcc-4.3/objdi
r/gcc/ /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.dg/debug/debug-6.c -gdwarf-2
-d
A -fno-show-column -S -o debug-6.s(timeout = 300)
PASS: gcc.dg/debug/debug-6.c -gdwarf-2 (test for excess errors)
PASS: gcc.dg/debug
--- Comment #17 from jason at gcc dot gnu dot org 2007-10-27 15:19 ---
Subject: Bug 5247
Author: jason
Date: Sat Oct 27 15:19:45 2007
New Revision: 129681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129681
Log:
PR c++/5247
* call.c (convert_default_arg): Detec
--- Comment #1 from danglin at gcc dot gnu dot org 2007-10-27 15:22 ---
Oops, I somehow cut and pasted the wrong lines. Should be these:
Testing debug/debug-6.c, -gdwarf-2 -O
Executing on host: /home/dave/gcc-4.3/objdir/gcc/xgcc
-B/home/dave/gcc-4.3/objdi
r/gcc/ /home/dave/gcc-4.3/gcc/
--- Comment #6 from rask at gcc dot gnu dot org 2007-10-27 15:24 ---
Tested revision 129548 which works.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-27 15:30 ---
Mine - I have patch.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
The following program take about 30 seconds to compile on IA64 with -O3 and
trunk, but took less than a second with 4.2. On x86_x86 it take about 3
seconds.
(sid)[EMAIL PROTECTED]:~$ time /usr/lib/gcc-snapshot/bin/gcc -c -O3 slow.c
real0m32.572s
user0m18.838s
sys 0m0.049s
(sid)[EMAIL
With current trunk on ia64:
(sid)[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O3 brltty-braille.c
brltty-braille.c: In function 'brl_readCommand':
brltty-braille.c:72: error: insn does not satisfy its constraints:
(insn 8165 2623 3131 8 brltty-braille.c:49 (set (reg:SI 63 loc31)
--- Comment #1 from tbm at cyrius dot com 2007-10-27 15:43 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
static int pendingCommand;
static int currentModifiers;
typedef struct
{
int (*updateKeys) (int *keyPressed);
}
ProtocolOperations;
static const ProtocolOperations *pr
--- Comment #12 from paulthomas2 at wanadoo dot fr 2007-10-27 15:47 ---
Subject: Re: Incorrect host association in module
burnus at gcc dot gnu dot org wrote:
> --- Comment #11 from burnus at gcc dot gnu dot org 2007-10-27 13:31
> ---
> To recap (correct me, if I'm wrong):
>
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-27 15:48 ---
-ftime-report output please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33922
While compiling the projets [5] with ASIS options [2] a GNAT [1,2,3] Compiler
Bug is detected
[1] GCC Version
version gcc 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
[2] GCC Options
gcc-4.1 -c -gnatc -gnatt -I- -gnatA aws-net-sets.ads
[3] GCC Configuration
Configuré avec: ../src/configu
--- Comment #1 from dsauvage at altern dot org 2007-10-27 15:51 ---
Created an attachment (id=14414)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14414&action=view)
tarball to reproduce the gnat compiler bug
How to reproduce the bug
$ tar -xvzf GCC_Bug_AWS.tar.gz
$ cd GCC_Bug_AWS
--- Comment #2 from danglin at gcc dot gnu dot org 2007-10-27 15:51 ---
I think this regression was caused by this change:
2007-10-26 Daniel Jacobowitz <[EMAIL PROTECTED]>
* reorg.c (emit_delay_sequence): Move insn locator from the
first insn to the sequence.
It's th
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-27 15:55 ---
Subject: Bug 33844
Author: jakub
Date: Sat Oct 27 15:55:34 2007
New Revision: 129682
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129682
Log:
PR c++/33844
* cxx-pretty-print.c (pp_cxx_pm_expr
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-27 15:58 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #2 from tbm at cyrius dot com 2007-10-27 16:03 ---
compile times:
20070303 0m25.928s
20070422 0m8.723s
20070515 0m7.345s
20070613 0m8.996s
20070811 0m8.172s
20070916 0m24.503s
20071020 0m34.445s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33922
--- Comment #3 from tbm at cyrius dot com 2007-10-27 16:05 ---
20070916 is ok, 20071020 shows the segfault.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33920
--- Comment #2 from tbm at cyrius dot com 2007-10-27 16:05 ---
20070811 is ok, 20070902 shows the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33923
--- Comment #3 from tbm at cyrius dot com 2007-10-27 16:07 ---
(In reply to comment #1)
> -ftime-report output please?
(sid)[EMAIL PROTECTED]:~/x$ /usr/lib/gcc-snapshot/bin/gcc -c -O3 -ftime-report
slow.c
Execution times (seconds)
garbage collection: 0.05 ( 0%) usr 0.00 ( 0%)
--- Comment #4 from tbm at cyrius dot com 2007-10-27 16:13 ---
Maybe something for Maxim to look at?
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2007-10-27 16:15 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from drow at gcc dot gnu dot org 2007-10-27 16:39 ---
All that patch does is change the line number associated with an instruction,
i.e., .debug_line. xyzzy is supposed to appear in .debug_info, so I don't see
how it could make a difference.
That doesn't mean it doesn't,
--- Comment #5 from tromey at gcc dot gnu dot org 2007-10-27 16:42 ---
I looked at this a little.
This test is a little bit funny because the '+' has undefined
overflow but the '*' does not. Move the cast to make the '+'
have defined overflow, and it works.
What happens is that we cal
--- Comment #5 from tbm at cyrius dot com 2007-10-27 16:44 ---
Oops, I forgot to add the testcase:
typedef enum
{
ST_TiemanStyle,
}
BrailleDisplay;
static int pendingCommand;
static int currentModifiers;
typedef struct
{
int (*updateKeys) (BrailleDisplay * brl, int *keyPressed);
}
P
gcc -Waddress got a little bit worse between gcc 4.0.4 and gcc 4.1.2. It would
be useful to get this warning, especially for C++ inline methods.
[EMAIL PROTECTED]:~/exp-address$ cat z2.cc
extern bool Alpha();
inline bool Beta(bool b) { return b; }
class MyClass { public: static bool MyMethod(bool
--- Comment #4 from ubizjak at gmail dot com 2007-10-27 17:20 ---
(In reply to comment #3)
> 20070916 is ok, 20071020 shows the segfault.
Patch in testing:
Index: tree-if-conv.c
===
--- tree-if-conv.c (revision 129683
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-10-27 17:29 ---
"This goes wrong in extract_muldiv..."
sorry for not pasting my complete analysis (actually the testcase is carefuly
crafted from looking at this code ;)). The recursion through conversions
case CONVERT_EXPR:
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-10-27 17:30 ---
I'll take this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #4 from drow at gcc dot gnu dot org 2007-10-27 17:42 ---
Confirmed. Here the &xyzzy and the call are in the same line. That means that
previously the sequence got the right locator by accident, and the jump kept
the right locator. Afterwards the sequence has the right loca
--- Comment #6 from tbm at cyrius dot com 2007-10-27 17:50 ---
As a comparison, here is what I get with 20070811:
(sid)[EMAIL PROTECTED]:~/x$ /usr/lib/gcc-snapshot/bin/gcc -c -O3 -ftime-report
slow.c
Execution times (seconds)
garbage collection: 0.06 ( 2%) usr 0.00 ( 0%) sys
--- Comment #7 from tbm at cyrius dot com 2007-10-27 17:52 ---
So scheduling 2 has gone from 2.5 to 19.36 seconds from 20070811 to
20071020 (both with checking enabled).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33922
--- Comment #1 from tbm at cyrius dot com 2007-10-27 17:56 ---
David, are you running Debian on your O2? Do you see this? I haven't really
seen this on Debian/mipsel.
--
tbm at cyrius dot com changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from jakub at gcc dot gnu dot org 2007-10-27 17:58 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-10-27 18:00
---
Subject: Bug 31306
Author: jvdelisle
Date: Sat Oct 27 17:59:59 2007
New Revision: 129685
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129685
Log:
2007-10-27 Jerry DeLisle <[EMAIL PROTECTED]>
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-10-27 18:00 ---
> Extra diagnostic checks enabled; compiler may run slowly.
> Configure with --enable-checking=release to disable checks.
We added this message for a reason, seems like you should try that for first.
The release br
--- Comment #6 from jakub at gcc dot gnu dot org 2007-10-27 18:00 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from daney at gcc dot gnu dot org 2007-10-27 18:04 ---
>From my O2:
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01186.html
Please update and try again. Use contrib/gcc_update so that the svn version
number is put into the version information.
--
http://gcc.gnu
--- Comment #8 from jakub at gcc dot gnu dot org 2007-10-27 18:05 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from tbm at cyrius dot com 2007-10-27 18:08 ---
(In reply to comment #8)
> > Extra diagnostic checks enabled; compiler may run slowly.
> > Configure with --enable-checking=release to disable checks.
>
> We added this message for a reason, seems like you should try that fo
On 27 Oct 2007 18:08:21 -, tbm at cyrius dot com
<[EMAIL PROTECTED]> wrote:
> Well, I showed that even with checking enabled the compiler was _much_ faster
> 2 months ago. But, ok, I'll try with checking disabled too.
Well someone (maybe DF) could have added a lot of checking.
-- Pinski
--- Comment #10 from pinskia at gmail dot com 2007-10-27 18:10 ---
Subject: Re: [4.3 Regression] slow compilation on ia64
On 27 Oct 2007 18:08:21 -, tbm at cyrius dot com
<[EMAIL PROTECTED]> wrote:
> Well, I showed that even with checking enabled the compiler was _much_ faster
> 2
I got
FAIL: gcc.dg/dfp/convert-dfp-round-thread.c execution test
on Linux/ia32 and Linux/x86-64 with revision 129372 and revision 129351
is OK.
--
Summary: FAIL: gcc.dg/dfp/convert-dfp-round-thread.c execution
test
Product: gcc
Version: 4.3.
--- Comment #11 from tbm at cyrius dot com 2007-10-27 18:13 ---
(In reply to comment #10)
> Well someone (maybe DF) could have added a lot of checking.
OK, good point.
I'll report my findings in a few hours.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33922
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-10-27 18:25
---
Subject: Bug 31306
Author: jvdelisle
Date: Sat Oct 27 18:25:43 2007
New Revision: 129686
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129686
Log:
2007-10-27 Jerry DeLisle <[EMAIL PROTECTED]>
PR
Like PR 33790, dse.c could handle the case mentioned in there. The current
issue is that it does:
if (GET_MODE_CLASS (read_mode) != GET_MODE_CLASS (store_mode))
return false;
And the clases are different, one is the vector float class (V4SF) and the
other is the vector integer class (V4SI)
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-10-27 18:29
---
Fixed and closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from sam at rfc1149 dot net 2007-10-27 18:32 ---
Here is a small test case for this program. Compile with -mregparm=3 (or any
value greater than 0 on x86).
#include
typedef void (*func) (int a, ...);
void f (int a, int b)
{
printf ("a = %d, b = %d\n", a, b);
}
int
--- Comment #12 from tbm at cyrius dot com 2007-10-27 18:53 ---
Same results without checking (actually, even slower - is that possible?):
(sid)[EMAIL PROTECTED]:~/tmp/gcc/gcc-4.3-20071027-r129674-no-checking/gcc$
./xgcc
-B. -ftime-report -O3 -c ~/slow.c
Execution times (seconds)
df
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-10-27 18:59
---
What happens if you compile with -O3 -fno-tree-vectorize ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sam at rfc1149 dot net 2007-10-27 19:10 ---
I can reproduce it with GNAT 4.1.3 20071019 (prerelease) (Debian 4.1.2-17)
(i486-pc-linux-gnu), but it compiles fine with the current trunk version
(129681).
--
sam at rfc1149 dot net changed:
What|Remove
--- Comment #14 from tbm at cyrius dot com 2007-10-27 19:27 ---
(In reply to comment #13)
> What happens if you compile with -O3 -fno-tree-vectorize ?
It's still slow:
(sid)[EMAIL PROTECTED]:~/tmp/gcc/gcc-4.3-20071027-r129674-no-checking/gcc$
./xgcc
-B. -ftime-report -O3 -
--- Comment #2 from sam at rfc1149 dot net 2007-10-27 19:29 ---
Created an attachment (id=14415)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14415&action=view)
Updated patch for the current enhancement report
I've produced a patch from the given sources, adapted to the current t
--- Comment #53 from burnus at gcc dot gnu dot org 2007-10-27 19:57 ---
> Note that I still see achar_4.f90 fail with type-checking and there are now
> some more testcases that also fail.
Reopened based on this comment to make sure we won't forget about this PR.
To recap:
a) We need t
--- Comment #54 from rguenther at suse dot de 2007-10-27 20:03 ---
Subject: Re: wrong types in character array/scalar binop
On Sat, 27 Oct 2007, burnus at gcc dot gnu dot org wrote:
> --- Comment #53 from burnus at gcc dot gnu dot org 2007-10-27 19:57
> ---
> > Note that I s
--- Comment #1 from siegerstein at pochta dot ru 2007-10-27 20:26 ---
Can any body comment this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33852
posix
gcc version 4.3.0 20071027 (experimental) (GCC)
% gcc -c z.adb
+===GNAT BUG DETECTED==+
| 4.3.0 20071027 (experimental) (i686-pc-linux-gnu) GCC error: |
| in gnat_to_gnu_entity, at ada/decl.c:300
--- Comment #2 from siegerstein at pochta dot ru 2007-10-27 20:27 ---
Created an attachment (id=14416)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14416&action=view)
bug.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33852
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org
|dot org
--- Comment #12 from burnus at gcc dot gnu dot org 2007-10-27 21:07 ---
(In reply to comment #8)
> Interesting is whether the following should be accepted or not.
[...]
> EXTERNAL foo ! implicit interface
> call sub(foo) ! sub's argument has an explicit interface
gfortran, NAG f95 and
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org
|dot org
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org
|dot org
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|aldyh at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--- Comment #5 from ubizjak at gmail dot com 2007-10-27 21:35 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01649.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-10-27 21:50 ---
Hm, it works OK for me on FC6 and:
Compiler version: 4.3.0 20071027 (experimental) [trunk revision 129683] (GCC)
Platform: x86_64-unknown-linux-gnu
configure flags: --enable-languages=c,c++,fortran
BOOT_CFLAGS=-g -O2
--- Comment #2 from hjl at lucon dot org 2007-10-27 23:16 ---
If you run autoconf in libgcc, you will see the failure. See
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01652.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33926
--- Comment #7 from rask at gcc dot gnu dot org 2007-10-27 23:16 ---
Created an attachment (id=14417)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14417&action=view)
possible patch
Please give this patch a try. I need it to build GCC with OpenWatcom, which
wants parameters on the
On 27 Oct 2007 23:16:57 -, rask at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Please give this patch a try. I need it to build GCC with OpenWatcom, which
> wants parameters on the stack by default.
I think this makes some worse code in some cases. Var-args is very
bad for code generatio
--- Comment #8 from pinskia at gmail dot com 2007-10-27 23:22 ---
Subject: Re: Gcc can't be compiled with -mregparm=3
On 27 Oct 2007 23:16:57 -, rask at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Please give this patch a try. I need it to build GCC with OpenWatcom, which
> wa
--- Comment #3 from hjl at gcc dot gnu dot org 2007-10-27 23:23 ---
Subject: Bug 33926
Author: hjl
Date: Sat Oct 27 23:22:57 2007
New Revision: 129687
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129687
Log:
2007-10-27 H.J. Lu <[EMAIL PROTECTED]>
PR regression/33926
--- Comment #9 from rask at gcc dot gnu dot org 2007-10-27 23:36 ---
It happens to work because all the compilers people use to build GCC pass
varargs the same way as non-varargs, at least for the number of arguments
received by the gen_* functions. IOW you shouldn't see any speed differ
--- Comment #4 from danglin at gcc dot gnu dot org 2007-10-27 23:45 ---
I believe the SUPPORTS_INIT_PRIORITY portion of my 2003 patch needs
to be reverted.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-10-28 00:30 ---
Hmm, I have a question about IPA CP, should it call cfgcleanup also? It does
not fix the problem here but it seems like a good idea. I can test a patch
which adds the cfgcleanup if it is a good idea.
--
http:/
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-10-28 00:40 ---
Here is a testcase without using IPA CP:
/* { dg-do run } */
/* { dg-options "-O3" } */
int k;
void f1 (int a, int b)
{
a = 1; b = 1;
if (a)
{
int c;
goto d;
do {
k = 1;
d:
c
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-28 00:44 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-28 00:49 ---
(void) (((struct Tuple *) this)->base = TARGET_EXPR ;, try
Note, this is not related to templates, you can reproduce the ICE with the
following source too (I think ErrorInfo just needs to be a non-POD):
class Err
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-28 00:53 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-10-28 01:11 ---
A quick patch to fix this:
Index: tree-outof-ssa.c
===
--- tree-outof-ssa.c(revision 129686)
+++ tree-outof-ssa.c(working copy)
@@ -758,7 +758,1
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-10-28 01:18 ---
This is the patch which I am going to test (it also deletes the eh edges early
on which should speed up things a little):
Index: tree-outof-ssa.c
===
--
1 - 100 of 104 matches
Mail list logo
