--- Comment #1 from rearnsha at gcc dot gnu dot org 2005-11-01 09:37
---
Subject: Re: New: The comment start symbol of arm target
On Tue, 2005-11-01 at 07:31, hanzac at gmail dot com wrote:
> It's true that the arm comment start symbol is '@', but GCC will generate some
> assembler c
--- Comment #3 from r dot emrich at de dot tecosim dot com 2005-11-01
09:46 ---
Created an attachment (id=10097)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10097&action=view)
assembler output
I compiled c-parser.c with the exact same commandline as in the bootstrap,
except the
--- Comment #7 from martin at mpa-garching dot mpg dot de 2005-11-01 10:22
---
The regression is unfortunately still there :(
Reducing the testcase is really hard, and I have some indications
that the problem vanishes if there is less work to do in the critical loop.
If you have any sug
--- Comment #4 from alexander_herrmann at yahoo dot com dot au 2005-11-01
10:46 ---
Subject: Re: [4.0/4.1 Regression] __builtin_expect getting in the way of
uninitialized warnings
Never is a long time. It may become release relevant
as soon as somebody extends the
-Wunused-value the
As a enhancement to the -Wunused-value which may allready detected by the
data-flow analysis.
int problem_funktion(int a)
{
int b = 0; // This should cause a warning as the value 0 is never used
if (__builtin_expect(((a > 0) && ((b = 5) != 0)), 1))
{
return(a*b);
}
return(a);
}
--- Comment #4 from r dot emrich at de dot tecosim dot com 2005-11-01
11:02 ---
Also fails on at least tree-data-ref.c and tree-cfg.c with xgcc: Internal
error: Trace/BPT/RangeErr/DivZero/Ovflow trap (program cc1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
Compiling the following code with "-fopenmp -O -Wall" yields a bogus warning
(happens with C and C++):
==
void foo()
{
int i;
#pragma omp threadprivate(i)
#pragma omp parallel sections
{
#pragma omp section
{
i = 0;
++i;
--- Comment #2 from pcarlini at suse dot de 2005-11-01 11:14 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pault at gcc dot gnu dot org 2005-11-01 12:15 ---
Subject: Bug 21565
Author: pault
Date: Tue Nov 1 12:15:07 2005
New Revision: 106326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106326
Log:
2005-11-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2005-11-01 12:15 ---
Subject: Bug 14994
Author: pault
Date: Tue Nov 1 12:15:07 2005
New Revision: 106326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106326
Log:
2005-11-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-01 12:15 ---
Subject: Bug 18737
Author: pault
Date: Tue Nov 1 12:15:07 2005
New Revision: 106326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106326
Log:
2005-11-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from tobi at gcc dot gnu dot org 2005-11-01 12:58 ---
Fixed by Paul's patch.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-01 13:01 ---
Created an attachment (id=10098)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10098&action=view)
reduced testcase
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-01 13:01 ---
Critical, as this happens in a lot of packages.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-01 13:03 ---
Fixed on mainline and 4.0
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #4 from pault at gcc dot gnu dot org 2005-11-01 13:04 ---
Fixed on mainline and 4.0
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
S
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #15 from rakdver at gcc dot gnu dot org 2005-11-01 14:08
---
C testcase (needs to be compiled with -O1 -funroll-loops and complete unrolling
on trees must be disabled)
int e_fn (int *p, int *q)
{
return *p - *q;
}
int main (void)
{
int a[8];
int b[8];
int A[8];
u
--- Comment #16 from rakdver at gcc dot gnu dot org 2005-11-01 14:15
---
Smaller testcase:
int e_fn (int *p, int *q)
{
return *p - *q;
}
int main (void)
{
int a[8] = {2,2,2,2,2,2,2,2};
int b[8] = {0,1,0,1,0,1,0,1};
int A[8];
unsigned i, j;
int tmp;
int *p = A;
for (i
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-01 14:22 ---
*** This bug has been marked as a duplicate of 18624 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-01 14:22 ---
*** Bug 24611 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P5 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
When the C++ parser encounters a "#pragma omp section" without enclosing
"#pragma omp sections" it crashes, like on the following one-liner:
==
#pragma omp section
==
bug1.cc:1: internal compiler error: in cp_parser_pragma, at cp/parser.c:18791
Please submi
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-01 14:54 ---
Actually it is "int*" and "int" and that mainly comes down to how we repesent
(int*)[d];
If we change the code (we should be able to do this in the IR also, Daniel
Berlin had a patch which did it):
extern int abs (in
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-01 14:55 ---
So this is invalid after all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-01 14:57 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00011.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #7 from dann at godzilla dot ics dot uci dot edu 2005-11-01
15:15 ---
(In reply to comment #5)
> Hmm,
> I am still not sure if it matters too much, but since there are actually
> dupes of this problem, I think we can simply add peep2 fixing this
> particular common case.
>
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-01 15:17 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
FAIL: gcc.dg/nested-func-4.c (test for excess errors)
(a new test) appeared on mainline on hppa2.0w-hp-hpux11.11 between 20051026 and
20051027.
Excess errors:
Warning: consider linking with `-static' as system libraries with
profiling support are only provided in archive format
Some other profi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.1.0 |4.1.0 4.0.3
Summary|[4.1 Regression] internal |[4.0/4.1
We ICE during building nss of the mozilla suite.
--
Summary: internal compiler error: in print_shift_count_operand,
at config/s390/s390.c:4025
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 15:47 ---
Created an attachment (id=10099)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10099&action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24615
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-01 15:56 ---
Regression from 4.0, btw.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ian at airs dot com 2005-11-01 16:09 ---
You've managed to change the code so that we still have two registers, but now
they have different values. I agree that there are probably going to be times
when it is good to have two different registers. But when they alway
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-01 16:17 ---
If we change (*p1)[d-1] to (*p1)[d], we get:
.L2:
movl 8(%edi), %eax
movswl (%eax),%edx
movl 4(%edi), %eax
movswl (%eax),%eax
subl %edx, %eax
movl %eax, %ecx
sarl $31, %ecx
xorl %ecx
In various situations where the BC-compiled classes are linked and a
NoClassDefFoundError is thrown, this error condition should be deferred to the
time when the actual erroneous code location is executed.
The situation always involves that a class cannot be resolved (because the
bytecode is not a
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
|
This is to track this nice suggestion from Howard:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg1.html
--
Summary: vector vs __erase_at_end
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
--- Comment #11 from janis at gcc dot gnu dot org 2005-11-01 16:42 ---
A regression hunt identified the following patch:
r65207 | jason | 2003-04-03 18:23:04 + (Thu, 03 Apr 2003) | 17 lines
* stor-layout.c (do_type_align): New fn, split out from...
(layout_decl): ..
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-01 16:44 ---
The mail to gcc-patches for the patch identified in comment #11 is
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00209.html.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-01 16:57
---
Related to PR 10145
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #5 from echristo at apple dot com 2005-11-01 17:27 ---
The patch to 23585 is likely the cause.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-01 17:33 ---
Maybe a testcase in:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00028.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, ice-on-valid-code
Priority|P2
--- Comment #7 from echristo at apple dot com 2005-11-01 17:43 ---
Changing to P1 since it's a regression that likely affects all mips (including
primary platform mips-elf).
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-01 17:44 ---
(In reply to comment #7)
> Changing to P1 since it's a regression that likely affects all mips (including
> primary platform mips-elf).
I don't know if it is allowed for someone to change the priority (except to P3
[forwarded from http://bugs.debian.org/336511]
bug submitter writes:
If mudflap is used to instrument a program using dlopen, and the program
(assuming it is compiled with -rdynamic) loads itself by passing NULL for the
path to dlopen, the program will crash unconditionally; that is, regardless o
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-01 17:48 ---
I think this is a GNU extension or one which came in from elf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24619
/usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1plus -fpreprocessed alpha_mask3.ii
-quiet -dumpbase alpha_mask3.cpp -m64 -mzarch -march=z900 -auxbase-strip
alpha_mask3.o -O2 -Wall -version -fmessage-length=0 -o alpha_mask3.s
alpha_mask3.cpp: In member function 'unsigned int the_application::render()':
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 18:00 ---
Created an attachment (id=10100)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10100&action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24620
--- Comment #9 from echristo at apple dot com 2005-11-01 18:06 ---
Bringing down to P3 and letting Mark set the priority.
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #5 from ian at airs dot com 2005-11-01 18:06 ---
That means that you did get only one register, and that therefore the block was
simple enough for RTL if-conversion to operate.
So I'd still like to understand why we get two identical registers in the
original test case, whic
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-11-01 18:13
---
I'm going to make this a P2. IRIX isn't a primary platform anymore. Thanks,
Eric.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-01 18:18
---
Oh, this effects mips-elf also which is a primary target.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-01 18:27
---
It is failing in:
285 return offset % GET_MODE_SIZE (mode) != 0;
mode is BLKmode which has a mode size of 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #9 from dnovillo at gcc dot gnu dot org 2005-11-01 18:29
---
Jeff has a much better approach to solving this.
http://gcc.gnu.org/ml/gcc/2005-11/msg00032.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-01 18:30
---
The RTL which is failing:
(set (reg:DI 2 $2 [197])
(unspec:DI [
(mem/s/c:BLK (plus:DI (reg/f:DI 29 $sp)
(const_int 8 [0x8])) [0+4 S8 A32])
(mem/s/c:QI (plus:DI (reg/f
--- Comment #6 from ian at airs dot com 2005-11-01 18:46 ---
Created an attachment (id=10101)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10101&action=view)
.s file from gcc 3.4 -S -O2
I've attached the assembler code generated by gcc 3.4 with -S -O2. This code
is much better t
--- Comment #7 from ian at airs dot com 2005-11-01 18:47 ---
Because the 4.1 code is worse than the 3.4 code, I believe that this is a 4.1
regression, and I am marking it as such. Please correct me if I made a
mistake.
--
ian at airs dot com changed:
What|Removed
We ICE compiling unrar
/usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1plus -fpreprocessed recvol.ii -quiet
-dumpbase recvol.cpp -m64 -mzarch -march=z900 -auxbase recvol -O2 -Wall -Wall
-version -fmessage-length=0 -fmessage-length=0 -o recvol.s
recvol.cpp: In member function 'bool RecVolumes::Restore(RA
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 18:49 ---
Created an attachment (id=10102)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10102&action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24621
--- Comment #10 from law at redhat dot com 2005-11-01 18:50 ---
Subject: Re: [4.1 Regression] Missing 'used
unintialized' warning
On Tue, 2005-11-01 at 18:29 +, dnovillo at gcc dot gnu dot org
wrote:
>
> --- Comment #9 from dnovillo at gcc dot gnu dot org 2005-11-01 1
--- Comment #11 from dnovillo at redhat dot com 2005-11-01 18:56 ---
Subject: Re: [4.1 Regression] Missing 'used unintialized' warning
On Tuesday 01 November 2005 13:50, law at redhat dot com wrote:
> I'd rather you not assign it to me just yet -- while I think my approach
> is better
--- Comment #5 from tobi at gcc dot gnu dot org 2005-11-01 19:22 ---
CCing pault, as he introduced that error. Looks like you've been to strict,
Paul
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
-
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
CC||tobi at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #1 from thebohemian at gmx dot net 2005-11-01 19:32 ---
Created an attachment (id=10103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10103&action=view)
A test for the linking mechanism
This is a slightly bigger test for the linking mechanism. Unpack the tar.bz2,
put
--- Comment #2 from thebohemian at gmx dot net 2005-11-01 19:38 ---
More hints for the test:
running the start script as:
??-run.sh nothing
should succeed on every vm in every variant since the critical code locations
are not touched in any way. However this only succeed for gij in int
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
CC||tobi at gcc dot gnu dot org
Severity|normal
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-01 19:51 ---
Maybe I am missing something, somewhere, what does the missing DECL_PACKED do?
Do you have a simple compile time testcase which fails with 4.1.0 but passes
with 4.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-01 19:53 ---
The ordering of errors is hard to tackle, the bad error description is easily
fixed on the other hand.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jsm28 at gcc dot gnu dot org 2005-11-01 20:03 ---
Working on a fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-01 20:05 ---
Subject: Bug 24404
Author: tobi
Date: Tue Nov 1 20:05:54 2005
New Revision: 106346
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106346
Log:
PR fortran/24404
* resolve.c (resolve_symbol): Outp
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-01 20:14 ---
It remains the ordering of the error messages which in this case is hard to
tackle, I'm tempted to say WONTFIX.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
---
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Target Milestone|--- |4.1.0
http
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24404
--- Comment #6 from tobi at gcc dot gnu dot org 2005-11-01 20:20 ---
(In reply to comment #3)
> The code is illegal, and therefore gfortran can do anything
> it wants (including start WW III).
>
> (1) rteps is never defined, so it can't be reference in the IF
> statement.
>
> (2)
--- Comment #6 from dank at kegel dot com 2005-11-01 20:22 ---
Is this a duplicate of bug 19564 ?
--
dank at kegel dot com changed:
What|Removed |Added
CC
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-01 20:25 ---
I'd say, if someone wants to implement the necessary specs, he's free to do so,
but for the time being, we can remove the support from invoke.texi, and gcc.c.
--
tobi at gcc dot gnu dot org changed:
What
--- Comment #2 from aph at gcc dot gnu dot org 2005-11-01 20:41 ---
THis looks like a hang in the unwinder the very first time any exception is
thrown
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20495
We ICE in compiling libxquery:
/usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1plus -fpreprocessed XQFLWOR.ii -quiet
-dumpbase XQFLWOR.cpp -m64 -mzarch -march=z900 -auxbase-strip
/usr/src/packages/BUILD/xquery-1.1.0/build_unix/.libs/XQFLWOR.o -O2 -Wall
-version -fmessage-length=0 -fPIC -o XQFLWOR.s
XQFL
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 20:57 ---
Created an attachment (id=10104)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10104&action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24623
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #24 from bonzini at gcc dot gnu dot org 2005-11-01 21:05
---
Aldy, I have a patch for this that only needs more testing. If you want, and
if you do not have any better idea than what I said in comment #17, I can take
this.
--
bonzini at gcc dot gnu dot org changed:
--- Comment #25 from aldyh at gcc dot gnu dot org 2005-11-01 21:16 ---
Bonzini:
Perhaps both approaches would be even better. We definitely should handle the
transformed vector, because theoretically it's still easy to generate. And
adding the extra check you mention would be icing on
--- Comment #9 from tobi at gcc dot gnu dot org 2005-11-01 21:18 ---
Ugh, I completely forgot about this one. I'll try to look into this later this
week.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from tobi at gcc dot gnu dot org 2005-11-01 21:21 ---
Fixed if I read Janne's measurements correctly, please reopen if I'm wrong.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from tobi at gcc dot gnu dot org 2005-11-01 21:22 ---
(In reply to comment #13)
> The patch from #12 has been committed to mainline.
So should this bug be closed?
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from bonzini at gcc dot gnu dot org 2005-11-01 21:23
---
Okay, taking this. If you ever want to make SPE constants more optimized, be
careful about this bug though! ;-)
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-01 21:24 ---
This is really the same as PR 20811: we don't take the (original) location of
the source file into account.
*** This bug has been marked as a duplicate of 20811 ***
--
tobi at gcc dot gnu dot org changed:
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-01 21:24 ---
*** Bug 23460 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-01 21:30 ---
I'd say we don't care. Results with other compilers:
pgf90:
0 F F F
1 T F F
2 F F F
3 T F F
4 F F F
ifort:
0 F F F
1 T T
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-01 21:36 ---
Actually, the .NEQV. case would be easily fixed, as there's a TRUTH_XOR_EXPR in
the middleend. On the other hand .EQV. would require adding some special case
logic to gfc_conv_expr_op (admittedly, not difficult logic).
--- Comment #5 from eedelman at gcc dot gnu dot org 2005-11-01 21:40
---
Subject: Bug 24245
Author: eedelman
Date: Tue Nov 1 21:40:06 2005
New Revision: 106353
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106353
Log:
fortran/
2005-11-01 Erik Edelmann <[EMAIL PROTECTED]>
We ICE compiling the linux kernel.
/usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1 -fpreprocessed inetpeer.i -quiet
-dumpbase inetpeer.c -m64 -mbackchain -msoft-float -march=z900 -mpacked-stack
-mstack-size=8192 -mstack-guard=256 -mwarn-dynamicstack -mwarn-framesize=256
-mzarch -auxbase-strip net/ipv4/.
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 21:48 ---
Created an attachment (id=10105)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10105&action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-11-01 21:50
---
Subject: Bug 24245
Author: eedelman
Date: Tue Nov 1 21:50:26 2005
New Revision: 106355
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106355
Log:
fortran/
2005-11-01 Erik Edelmann <[EMAIL PROTECTED]>
--- Comment #7 from eedelman at gcc dot gnu dot org 2005-11-01 21:51
---
With this bug fixed on both mainline and 4.0, I declare this PR fixed
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-01 21:53
---
This is a bug in the old loop optimizer introduced by:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00690.html
The problem with this patch is that it assumes
gen_move_insn where the source is a PLUS representing
a
1 - 100 of 185 matches
Mail list logo
