--- Comment #16 from jakub at gcc dot gnu dot org 2008-08-29 07:22 ---
It is not incorrect, but is a code quality regression, which counts too.
So I'd prefer the testcase to stay as is and let the RA get fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25199
With the attached test case I get:
[EMAIL PROTECTED] type_ambiguity]$ gfortran -v -c type_ambiguity.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.1/configure --prefix=/usr/local/gcc43
--with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp
Thread model: posix
gcc v
--- Comment #1 from sfilippone at uniroma2 dot it 2008-08-29 07:42 ---
Created an attachment (id=16159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16159&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
gcc (GCC) 4.4.0 20080828 (experimental)
gcc -g -O2 -march=i686 -fstack-protector -c task.c -o task.o
--
Summary: ICE when compile libgomp/task.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from linuxl4 at sohu dot com 2008-08-29 07:52 ---
Created an attachment (id=16160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16160&action=view)
the preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37275
--- Comment #3 from svobodamo at gmail dot com 2008-08-29 07:53 ---
okay, i'll try to upgrade, thanks guys
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37268
--- Comment #2 from pault at gcc dot gnu dot org 2008-08-29 08:31 ---
Confirmed
Salvatore, what is the date on your 4.2.4? Is it the release version - ie.
19th May 2008?
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-29 08:37 ---
Subject: Bug 37207
Author: rguenth
Date: Fri Aug 29 08:36:10 2008
New Revision: 139754
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139754
Log:
2008-08-29 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from sfilippone at uniroma2 dot it 2008-08-29 08:39 ---
Yes, it's the release.
[EMAIL PROTECTED] type_ambiguity]$ gfortran -v -c type_ambiguity.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.4/configure
Thread model: posix
gcc version 4.
--- Comment #4 from sfilippone at uniroma2 dot it 2008-08-29 08:46 ---
Does it have anything to do with 36374?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
--- Comment #5 from pault at gcc dot gnu dot org 2008-08-29 08:54 ---
(In reply to comment #4)
> Does it have anything to do with 36374?
>
Salvatore,
I don't think so, since this PR is a regression. Anyway, I'll take a look at
them both together in a few days. I'm still not entir
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-08-29 09:30
---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassign
--- Comment #13 from uros at gcc dot gnu dot org 2008-08-29 09:43 ---
Subject: Bug 37101
Author: uros
Date: Fri Aug 29 09:41:57 2008
New Revision: 139758
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139758
Log:
Backport from mainline:
2008-08-14 Christophe Sao
--- Comment #14 from ubizjak at gmail dot com 2008-08-29 09:44 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from dodji at gcc dot gnu dot org 2008-08-29 09:58 ---
This is an update of what we get with gcc-4_3-branch.
For the program (line numbers added for better legibility):
1 #include
2 class A {
3 public:
4A (int a, int b);
5int a_;
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-08-29 11:42
---
Subject: Bug 37236
Author: rguenth
Date: Fri Aug 29 11:40:47 2008
New Revision: 139763
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139763
Log:
2008-08-29 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-08-29 11:49
---
Fixed for the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #2 from jakub at gcc dot gnu dot org 2008-08-29 11:55 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #3 from jakub at gcc dot gnu dot org 2008-08-29 12:23 ---
Caused by PR33691 fix btw.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37261
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37193
Hi, I'm getting this annoying run-time Seg-fault for the below. Apparently,
isn't a regression, but really, if we could fix it, the C++ library would
benefit a lot from the fix!
namespace my_std
{
inline double
atan(double __x)
{ return __builtin_atan(__x); }
inline doub
--- Comment #1 from paolo dot carlini at oracle dot com 2008-08-29 13:04
---
I think it can be safely confirmed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37276
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-29 13:08 ---
Funny. (just look at the asm...)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
/home/wakelyjo/src/gcc/gcc-4.3.2/configure
--prefix=/home/wakelyjo/src/gcc/sol10-64/INSTALL
--with-gmp=/home/wakelyjo/src/gcc/sol10-64/INSTALL
--with-mpfr=/home/wakelyjo/src/gcc/sol10-64/INSTALL --with-dwarf2
Bootstrap fails with:
build/gengtype /home/wakelyjo/src/gcc/gcc-4.3.2/gcc gtyp-input.li
--- Comment #1 from jwakely dot gcc at gmail dot com 2008-08-29 13:11
---
Created an attachment (id=16161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16161&action=view)
gcc/gtyp-input.list
Here is the generated file with the duplicate entry
--
http://gcc.gnu.org/bugzilla/
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-29 13:11 ---
Actually, it looks like we treat
namespace std
{
inline double
atanh(double __x)
{ return __builtin_atanh(__x); }
}
as a definition of ::atanh (with C linkage), and emit
atanh:
.LFB0:
pushq %rbp
.L
(GCC) 4.4.0 20080829 (experimental)
2.796sg++ (GCC) 4.4.0 20080829 (experimental) with --param
max-inline-insns-auto=126
So I believe lack of inlining is the biggest 4.4's problem. We do not inline
3x3 matrix multiplication in benchmark loop.
While looking at it I found that einline2 dum
On Linux/ia32, revision 139760 causes
FAIL: g++.dg/tree-ssa/pr29902.C (internal compiler error)
FAIL: g++.dg/tree-ssa/pr29902.C (test for excess errors)
FAIL: gcc.c-torture/execute/builtins/memset-chk.c compilation, -O3
-fomit-frame-pointer (internal compiler error)
UNRESOLVED: gcc.c-torture/exe
--- Comment #7 from manu at gcc dot gnu dot org 2008-08-29 13:28 ---
No warning in GCC 4.4 with any of those:
-O0 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O1 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O2 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O3 -Wall -Wextra -Wretu
--- Comment #2 from jwakely dot gcc at gmail dot com 2008-08-29 13:36
---
I think this is a regression against 4.2.2 as I have working compilers for
sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 which were both configured
with --with-dwarf2 (although I didn't build them myself so I'
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37099
Last successful sparc testresult (sun or linux) is from 06Aug2008:
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00636.html
"trunk revision 138734"
Whereas there were plenty of results before.
At trunk revision 139756 on sparc-unknown-linux-gnu I get during stage2:
build/genconfig ../../trun
--- Comment #4 from paolo dot carlini at oracle dot com 2008-08-29 14:18
---
>From the "outside", without looking deeper, I agree it seems a front-end issue.
The following seg-faults only when built with the C++ compiler:
inline double
atanh(double __x)
{ return __builtin_atanh(__x); }
--- Comment #1 from dominiq at lps dot ens dot fr 2008-08-29 14:40 ---
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c:
In function 'test6':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c:557:
internal compiler error: Bus error
--- Comment #13 from dodji at gcc dot gnu dot org 2008-08-29 14:41 ---
Created an attachment (id=16162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16162&action=view)
The debug info of the program
Okay, here is a more accurate analysis. I will refer to the debug info
attached.
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-08-29 14:58 ---
Subject: Bug 37278
Author: hubicka
Date: Fri Aug 29 14:57:20 2008
New Revision: 139768
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139768
Log:
PR middle-end/37278
* predict.c (optimize_lo
The linux kernel doesn't build anymore with gcc version 4.4.0 20080826
The problem seems to be that one extern variable (kallsyms_token_index)
declared with __attribute__((weak)) does not get a ".weak" in the assembler
output
anymore (compared the gcc 4.3)
I attached a preprocessed test case.
B
--- Comment #6 from pault at gcc dot gnu dot org 2008-08-29 15:29 ---
Created an attachment (id=16163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16163&action=view)
A reduced version of the testcase
I still do not feel much the wiser - making vector visible in class motion
make
--
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 #5 from pinskia at gcc dot gnu dot org 2008-08-29 15:52 ---
I think this testcase is invalid without -std=c++98.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37276
--- Comment #12 from vmakarov at redhat dot com 2008-08-29 15:55 ---
Here is the analysis of regressions on pr36222 and pr36246. PR36222 contains
the following code:
p64:V4SI=vec_concat (p66:V2SI, p65:V2SI) dead p66 and p65
xmm0:V2DI=subreg:V2DI (p64:V4SI)
IRA allocates p65, p66, and p
--- Comment #6 from paolo dot carlini at oracle dot com 2008-08-29 15:56
---
Why?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37276
--- Comment #7 from paolo dot carlini at oracle dot com 2008-08-29 16:01
---
The strict c++98 standard, without GNU extensions, doesn't know anything about
atanh - there isn't a single mention in the entire Standard - therefore I don't
see why any difference is wanted. Even less I see w
--- Comment #1 from hp at gcc dot gnu dot org 2008-08-29 16:02 ---
(In reply to comment #0)
> I attached a preprocessed test case.
Where?
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from hp at gcc dot gnu dot org 2008-08-29 16:02 ---
(In reply to comment #0)
> I attached a preprocessed test case.
Where?
--- Comment #2 from andi-gcc at firstfloor dot org 2008-08-29 16:02 ---
Created an attachment (id=16164)
--> (http://gcc.gnu.org/bugzilla
--- Comment #8 from paolo dot carlini at oracle dot com 2008-08-29 16:05
---
(In reply to comment #7)
> The strict c++98 standard, without GNU extensions, doesn't know anything about
> atanh - there isn't a single mention in the entire Standard - therefore I
> don't
> see why any diffe
--- Comment #14 from jason at gcc dot gnu dot org 2008-08-29 16:09 ---
Dodji is right: since the variable is shared between all concrete instances,
there is no need to repeat anything about it in the concrete instance. The
debugger should find the information it wants in the abstract in
--- Comment #13 from vmakarov at gcc dot gnu dot org 2008-08-29 16:18
---
Subject: Bug 37243
Author: vmakarov
Date: Fri Aug 29 16:16:45 2008
New Revision: 139769
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139769
Log:
2008-08-29 Vladimir Makarov <[EMAIL PROTECTED]>
--- Comment #7 from vmakarov at gcc dot gnu dot org 2008-08-29 16:19
---
Subject: Bug 37251
Author: vmakarov
Date: Fri Aug 29 16:18:11 2008
New Revision: 139770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139770
Log:
2008-08-29 Vladimir Makarov <[EMAIL PROTECTED]>
This is a copy of a Debian report that I made (I thought I might as well report
it directly here too): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496965
g++ generates bad code for this program on an amd64 machine. It works with
fine in 64-bit and with older versions of gcc.
#include
str
--- Comment #3 from hp at gcc dot gnu dot org 2008-08-29 16:30 ---
This is fixed by the patch in PR37170.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37280
This code is undefined as the value of 32 is outside the range of the
enum.
Sent from my iPhone
On Aug 29, 2008, at 9:29, "gmorin1 at bloomberg dot net" <[EMAIL PROTECTED]
> wrote:
This is a copy of a Debian report that I made (I thought I might as
well report
it directly here too): htt
--- Comment #1 from pinskia at gmail dot com 2008-08-29 16:39 ---
Subject: Re: New: bad code generation with enum and -m32
This code is undefined as the value of 32 is outside the range of the
enum.
Sent from my iPhone
On Aug 29, 2008, at 9:29, "gmorin1 at bloomberg dot net"
<[EM
--- Comment #2 from gmorin1 at bloomberg dot net 2008-08-29 16:57 ---
I thought it was correct because it seems that the standard allows to cast
explicity inside the range. The range is not the one of the integral type but
the one of smallest bit field that can stop all the values. So
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-29 17:00 ---
In GCC 4.4 we warn about this with -Wconversion.
warning: the result of the conversion is unspecified because 32 is outside
the range of type MyTypes::Type
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37281
--- Comment #4 from hp at gcc dot gnu dot org 2008-08-29 17:03 ---
A wee bit shorter:
extern int kallsyms_token_index[] __attribute__((weak));
extern int kallsyms_token_table[] __attribute__((weak));
void kallsyms_expand_symbol(int *result)
{
int len = *result;
int *tptr;
while(len
--- Comment #61 from andreast at gcc dot gnu dot org 2008-08-29 17:16
---
Created an attachment (id=16165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165&action=view)
preprocessed source from hppa2.0w-hp-hpux11.11
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #14 from hjl dot tools at gmail dot com 2008-08-29 18:24
---
I suspect this patch
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01903.html
is incorrect. Back it out from IRA branch fixed the testcase
in comment #11. I am running SPEC CPU 2000/2006 with IRA
branch using revi
--- Comment #7 from jakub at gcc dot gnu dot org 2008-08-29 18:42 ---
Subject: Bug 23057
Author: jakub
Date: Fri Aug 29 18:41:19 2008
New Revision: 139773
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139773
Log:
PR fortran/29635
PR fortran/23057
* debug
--- Comment #10 from jakub at gcc dot gnu dot org 2008-08-29 18:42 ---
Subject: Bug 29635
Author: jakub
Date: Fri Aug 29 18:41:19 2008
New Revision: 139773
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139773
Log:
PR fortran/29635
PR fortran/23057
* debu
--- Comment #9 from paolo dot carlini at oracle dot com 2008-08-29 18:46
---
FWIW, this kind of contortion appear to work, but really I'd rather prefer not
using it...
namespace my_std
{
inline double
atan(double __x)
{ return __builtin_atan(__x); }
inline double
atanh(doubl
--- Comment #8 from jakub at gcc dot gnu dot org 2008-08-29 18:46 ---
Subject: Bug 23057
Author: jakub
Date: Fri Aug 29 18:45:25 2008
New Revision: 139775
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139775
Log:
PR fortran/23057
* dwarf2out.c (gen_variable_die)
--- Comment #7 from jakub at gcc dot gnu dot org 2008-08-29 18:48 ---
Subject: Bug 24790
Author: jakub
Date: Fri Aug 29 18:47:19 2008
New Revision: 139777
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139777
Log:
PR fortran/24790
* trans-decl.c (create_function_
--- Comment #4 from jakub at gcc dot gnu dot org 2008-08-29 19:00 ---
Subject: Bug 37261
Author: jakub
Date: Fri Aug 29 18:59:13 2008
New Revision: 139784
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139784
Log:
PR c/37261
* fold-const.c (fold_binary): In (X |
--- Comment #5 from jakub at gcc dot gnu dot org 2008-08-29 19:09 ---
Subject: Bug 37261
Author: jakub
Date: Fri Aug 29 19:08:18 2008
New Revision: 139786
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139786
Log:
PR c/37261
* fold-const.c (fold_binary): In (X |
--- Comment #6 from jakub at gcc dot gnu dot org 2008-08-29 19:11 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from vmakarov at redhat dot com 2008-08-29 19:17 ---
I believe that patch
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02279.html
solves the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539
On IRA branch, revision 139582 caused
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
+FAIL: gcc.target/i386
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-29 19:40 ---
On Linux/ia64, it caused
+FAIL: g++.dg/opt/eh3.C execution test
+FAIL: gfortran.dg/list_read_8.f90 -O0 execution test
+FAIL: gfortran.dg/list_read_8.f90 -O1 execution test
+FAIL: gfortran.dg/list_read_8.f90 -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-29 19:45 ---
I think that patch is a mis labeled. Before that patch IRA was not enabled by
default so running the testsuite without -fira as the option passed to GCC to
one after that patch does not show the regressions.
--
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-08-29 19:46
---
(In reply to comment #14)
> I suspect this patch
>
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01903.html
>
That patch enabled IRA by default, before it was only enabled via the -fira
flag. So please test be
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-08-29 20:26
---
Remove --with-dwarf2, it is useless now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
GCC (SVN trunk 139772) generates code that GNU as (Binutils 2.18.50.20080827)
refuses to assemble:
T=`${PWDCMD-pwd}`/ \
&& cd ../.././gcc \
&& make GCC_FOR_TARGET="/home/arm/build/gcc/./gcc/xgcc
-B/home/arm/build/gcc/./gcc/ -B/home/arm/install/arm-elf/bin/
-B/home/arm/install/arm-e
--- Comment #1 from sam at gcc dot gnu dot org 2008-08-29 20:37 ---
Created an attachment (id=16166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16166&action=view)
crtstuff.s produced by GCC
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37283
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pbrook at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-29 20:48 ---
First the back-end does not disable section anchors for -fno-toplevel-reorder
so that is being produced.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37283
--- Comment #62 from hp at gcc dot gnu dot org 2008-08-29 20:51 ---
Looks like the HPPA port, like Darwin, transforms the original symbol_refs upon
seeing them, such that output_operand doesn't see all required,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #63 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-29
22:39 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
> Looks like the HPPA port, like Darwin, transforms the original symbol_refs
> upon
> seeing them, such that output_operand doesn't see all required,
--- Comment #3 from sam at gcc dot gnu dot org 2008-08-29 22:53 ---
Right. There are two problems indeed, fix is being tested.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from kargl at gcc dot gnu dot org 2008-08-29 23:20 ---
See
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02322.html
Your welcome.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36153
--- Comment #13 from jsm28 at gcc dot gnu dot org 2008-08-29 23:31 ---
Subject: Bug 37086
Author: jsm28
Date: Fri Aug 29 23:30:18 2008
New Revision: 139792
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139792
Log:
PR bootstrap/37086
* tree-vrp.c (find_switch_ass
--- Comment #7 from sam at gcc dot gnu dot org 2008-08-29 23:46 ---
I think the fix is wrong: when optimization_options() is called, user options
have not been processed yet. It is likely that section anchors are always
disabled by this change.
The patch for PR37283 at
http://gcc.gnu.or
Does not ICE without -fstrict-aliasing:
$ g++ -c -fstrict-aliasing PatternDriverTop.cc
In file included from
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/i686-pc-cygwin/bits/c++allocator.h:40,
from
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../includ
--- Comment #1 from mckelvey at maskull dot com 2008-08-29 23:51 ---
Created an attachment (id=16167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16167&action=view)
Compressed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37284
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-29 23:52 ---
change_dynamic_type should have been removed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from mckelvey at maskull dot com 2008-08-30 00:14 ---
Created an attachment (id=16168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16168&action=view)
Smaller test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37284
--- Comment #64 from hp at gcc dot gnu dot org 2008-08-30 00:39 ---
(In reply to comment #63)
> If the encoding for function names is getting stripped, then
> ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.
Not sure what you meant by that comment; that's not what happen
--- Comment #65 from hp at gcc dot gnu dot org 2008-08-30 01:05 ---
If the extern references had been "sort -u":ed, they'd had looked like this,
diff from unpatched to patched for the attachment in comment #61, compiled with
-O2:
--- ../../../comboo/hppa2/gcc/hppa2.s 2008-08-29 22:32:
--- Comment #66 from hp at gcc dot gnu dot org 2008-08-30 01:08 ---
(In reply to comment #61)
> Created an attachment (id=16165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165&action=view) [edit]
> preprocessed source from hppa2.0w-hp-hpux11.11
Could you please dig out the c
--- Comment #67 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-30
01:19 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
> If the extern references had been "sort -u":ed, they'd had looked like this,
> diff from unpatched to patched for the attachment in comment #61, compi
Hi, it looks like some of the VRP enhancements for switch statements is causing
an ICE on some code in binutils.
Testcase:
_bfd_xcoff_canonicalize_dynamic_reloc (unsigned long long l_symndx)
{
if (l_symndx < 3)
{
switch (l_symndx)
{
case 0:
case 1:
break;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Target Milestone|--- |4.4.0
http:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-30 01:41 ---
I have seen this in other cases even for the non doloop case, though I don't
know if it is because of -O1 or because it is not removing it.
Testcase:
int _bfd_xcoff_canonicalize_dynamic_reloc (unsigned long long l_sy
--- Comment #68 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-30
02:48 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
> > If the encoding for function names is getting stripped, then
> > ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.
>
> Not sure what
--- Comment #1 from kargl at gcc dot gnu dot org 2008-08-30 02:58 ---
I may have a patch for this problem. Note, there is an ambiguity
due to a set of intrinsics such as ETIME, which has both a function
form and a subroutine form.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3322
--- Comment #69 from hp at gcc dot gnu dot org 2008-08-30 03:20 ---
(In reply to comment #64)
> Not sure what you meant by that comment; that's not what happens here AFAICT.
> I stated that output_operand does not see the same symbol_ref as was passed to
> the rtl insn expander, so targe
--- Comment #70 from hp at gcc dot gnu dot org 2008-08-30 03:37 ---
(In reply to comment #67)
> > - .IMPORT _ZNSoD1Ev,CODE
>
> If any of these functions is present in the .s, then there's a problem.
> The default for a 32-bit HP-UX symbol that isn't imported is DATA.
The problem
--- Comment #5 from corsepiu at gcc dot gnu dot org 2008-08-30 05:13
---
With gcc-4.3.2, for me, the "j1.c" testcase doesn't segfault anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36583
--- Comment #71 from hp at gcc dot gnu dot org 2008-08-30 06:27 ---
Created an attachment (id=16169)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16169&action=view)
Patch, take 6.
Sigh. This just moves the TREE_STATIC check from the early-return to the
weak-test, since it's wron
100 matches
Mail list logo
