--- Comment #3 from paul dot thomas at jet dot uk 2006-05-05 06:26 ---
The patch below fixes the problem by enclosing the expression for the array
reference outputs%signal_number in parentheses(You can verify that this does
the right thing by doing it explicitly in the fortran.). This
--- Comment #21 from eggert at gnu dot org 2006-05-05 06:54 ---
Created an attachment (id=11381)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11381action=view)
port GCC to 'sort' and 'tail' that use POSIX syntax
This patch (originally reported in Bug 27434) ports the
GCC build
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-05-05 07:04
---
(In reply to comment #15)
I probably do something wrong, but with
GNU Fortran 95 (GCC) 4.2.0 20060504 (experimental)
from http://quatramaran.ens.fr/~coudert/gfortran/gfortran-x86_64-linux.tar.gz
I still
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-05 07:06 ---
Small testcase with the GNU runtime:
@interface NXConstantString
{
void *isa;
const char * const nxcsptr;
const unsigned int nxcslen;
}
@end
NXConstantString *a = @NSInconsistentArchiveException;
--
--- Comment #12 from anlauf at gmx dot de 2006-05-05 07:09 ---
(In reply to comment #11)
I've looked at the problem. The -Wall option will set the -Wnonstd-intrinsic
option. This flag appears to trigger a warning when used with -pedantic.
It does not trigger a warning if you use
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-05 07:10
---
(In reply to comment #0)
Currently, gfortran only detects that the IO format descriptor contains
insufficient data at run time. It would be great (though of low priority) if
it would find them at compile time.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 07:11 ---
Confirmed, related to PR 8923.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-05 07:20
---
I should note that this testcase fails on darwin because strlen is mentioned
twice in the testcase as there is a stub for strlen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-05 07:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 07:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-05 07:31 ---
(In reply to comment #4)
Small testcase with the GNU runtime:
Note only -Wall -funit-at-a-time is enough to reproduce the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27438
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 08:01 ---
Confirmed, reduced testcase:
#include objc/Object.h
@interface NSObject
-lock;
@end
static NSObject *local_lock = (id)0;
void GSSetupEncodingTable(id t)
{
[(local_lock != (id)0 ? local_lock : t) lock];
}
For
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-05 08:11
---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 08:19 ---
In .orginal:
goto L;
if ( error )
{
L:;
}
In ,gimple:
foo ()
{
void L = error ;
goto L;
}
We really should keep the if (error_mark_node)
Confirmed.
--
pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 08:32 ---
Comment out two lines in the gimplifier like:
Index: gimplify.c
===
--- gimplify.c (revision 113452)
+++ gimplify.c (working copy)
@@ -5655,8 +5655,8
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-05-05 09:00
---
Subject: Bug 25681
Author: fxcoudert
Date: Fri May 5 09:00:25 2006
New Revision: 113551
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113551
Log:
PR fortran/25681
* simplify.c
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-05-05 09:01
---
Fixed on mainline and 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 09:13 ---
Here is a quick prototype addition for VRP, it does not handle the generic case
only [0, 1] | 1:
Index: tree-vrp.c
===
--- tree-vrp.c (revision
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-05 09:17 ---
the issue for foo might be considered a different harder issue to resolve. I
think we need to decide what type is the argument for the ARRAY_REF, is it the
type which the ARRAY has for its bounds or some other
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-05 09:19 ---
(In reply to comment #6)
nobody cares about this bad flags pickup?
(In reply to comment #5)
hmm, CFLAGS_FOR_TARGET picks up CFLAGS.
Nobody else has ran into this and the patch was not posted to [EMAIL
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 09:22 ---
Maybe it is time to add POINTER_PLUS_EXPR which should solve the problem (well
95% of the way as what is the type of the 2nd operand, a signed or unsigned
type).
--
I'm not sure if this relates to Bug #8923, so I created a new bug report.
The following code causes gij to segfault:
class Bug
{
public void bug()
{
int x;
System.out.println((x 1).toString()); // segfault here
}
}
--
Summary: gcj segfaults on invalid
The fortran testcase fortran-torture/execute/entry_3.f90 cannot compile as of
20060505 (but it worked on 20060504); see full testresults here:
http://quatramaran.ens.fr/~coudert/gfortran/test-results/test-linux-20060505.log
The backtrace is:
Program received signal SIGSEGV, Segmentation fault
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:07
---
(In reply to comment #4)
would you care to replace rystride == ycount with rystride == xcount
as a fix for this, independent of the matmul BLAS issue?
I think this is definitely worth it, especially for 4.1.
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:08
---
Subject: Bug 26985
Author: fxcoudert
Date: Fri May 5 11:08:23 2006
New Revision: 113552
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113552
Log:
PR libfortran/26985
* m4/matmul.m4:
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:12
---
This is indeed fixed on 4.1 branch, that should be (soon?) released as 4.1.1.
This was previously reported as bug #26716.
*** This bug has been marked as a duplicate of 26716 ***
--
fxcoudert at gcc dot gnu
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-05 11:12
---
*** Bug 27401 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pluto at agmk dot net 2006-05-05 11:29 ---
crossbuild of 4.1.1-20060504 (rev. 113515) for
i686-ppc64 and x86-64-ppc64 works to me now.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #8 from pluto at agmk dot net 2006-05-05 11:52 ---
patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00204.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
--
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 #9 from jakub at gcc dot gnu dot org 2006-05-05 12:26 ---
For static variables in function contexts dwarf2out in several places wants
to look up the parent context DIE. Now when the variables are registered
with dwarf2out before the containing function, the parent context
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-05-05 12:39
---
*** This bug has been marked as a duplicate of 27437 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-05 12:39
---
*** Bug 27443 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-05 12:41
---
Here's a testcase that crashes on x86_64-unknown-linux-gnu with -O3
or -O2 -fsee:
unsigned char foo(unsigned char i)
{
while (1 i)
--i;
return i;
}
--- Comment #5 from hjl at lucon dot org 2006-05-05 13:01 ---
There are several problems with the current SEE implementation:
1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE
is safe. But with -g, NEXT_INSN/PREV_INSN may point to a NOTE:
(note:HI 17 14 18 2
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-05 13:10 ---
Yes it does. Not that the outcome is optimal here...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2006-05-05 14:25 ---
Subject: Re: gfortran: intrinsics and std=f95, inconsistency with other
compilers
On Fri, May 05, 2006 at 07:09:37AM -, anlauf at gmx dot de wrote:
--- Comment #12 from anlauf at
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-05 15:04 ---
(In reply to comment #5)
There are several problems with the current SEE implementation:
1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE
is safe. But with -g, NEXT_INSN/PREV_INSN may
--- Comment #2 from tromey at gcc dot gnu dot org 2006-05-05 15:05 ---
Subject: Bug 27294
Author: tromey
Date: Fri May 5 15:05:20 2006
New Revision: 113554
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113554
Log:
PR libgcj/27294:
* java/lang/natVMClassLoader.cc
--- Comment #3 from tromey at gcc dot gnu dot org 2006-05-05 15:06 ---
Now we print something nicer:
opsy. gij t
Exception in thread main java.lang.VirtualMachineError: found class file for
class t, but no interpreter configured in this libgcj
--
tromey at gcc dot gnu dot org
--- Comment #4 from pluto at agmk dot net 2006-05-05 15:10 ---
(In reply to comment #3)
You cannot. Though you can try extending c-common.c:strict_aliasing_warning
and
cp/typeck.c:build_reinterpret_cast_1 to warn in this case.
sorry, but i don't know compiler internals to do this.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 15:30 ---
This looks very much related to PR 27403 which also looks very valid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 15:44 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
hjl at lucon dot org changed:
What|Removed |Added
CC||denis dot nagorny at intel
||dot
--- Comment #7 from hjl at lucon dot org 2006-05-05 15:49 ---
(In reply to comment #6)
(In reply to comment #5)
There are several problems with the current SEE implementation:
1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE
is safe. But with -g,
--- Comment #6 from patchapp at dberlin dot org 2006-05-05 15:55 ---
Subject: Bug number PR23744
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00200.html
--
(see also: http://gcc.gnu.org/ml/gcc/2006-05/msg00158.html)
While following GCC's handling of 'volatile' and other type
qualifiers, I noticed that the gimplify pass created temporaries
with a type with 'volatile' asserted if the underlying type also
had 'volatile' asserted.
Temporaries are
--- Comment #2 from gary at intrepid dot com 2006-05-05 16:06 ---
Created an attachment (id=11382)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11382action=view)
create_tmp_var_raw patch: remove type qualifiers
This patch compiles, but hasn't been tested.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-05 16:04 ---
Do you have a testcase this will better understand the problem and to see if
your patch is correct?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
--- Comment #3 from gary at intrepid dot com 2006-05-05 16:12 ---
(In reply to comment #1)
Do you have a testcase this will better understand the problem and to see if
your patch is correct?
I'm not sure how to demonstrate that there is a problem. I think it
is clear that the author
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-05 16:16 ---
Then the real question is why do you think this is a bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
This bug is linked to PR27395 because the same 2 fortran test cases are the
ones triggering the problem. (The test cases can be found further bellow or as
their equivalents PR27395_1.f90 and PR27395_2.f90 in the libgomp dejagnu
testsuite)
Once PR27395 was corrected (Thanks Jakub) I played around
--- Comment #5 from gary at intrepid dot com 2006-05-05 16:37 ---
(In reply to comment #4)
Then the real question is why do you think this is a bug?
1. it is a bug to create temporaries and assert 'volatile' on them
2. there is code in create_tmp_var_raw() that creates a type with
--- Comment #5 from gary at intrepid dot com 2006-05-05 16:37 ---
(In reply to comment #4)
Then the real question is why do you think this is a bug?
1. it is a bug to create temporaries and assert 'volatile' on them
Why do you say that?
2. there is code in
--- Comment #6 from pinskia at physics dot uc dot edu 2006-05-05 16:39
---
Subject: Re: create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile'
on temps
--- Comment #5 from gary at intrepid dot com 2006-05-05 16:37 ---
(In reply to comment #4)
Then the
The following invalid testcase triggers an ICE since GCC 4.1.0:
void (A::* p)();
bug.cc:1: error: 'A' has not been declared
bug.cc:1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-05-05 16:44
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 16:45 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 16:49 ---
(In reply to comment #7)
You are right. Using next_nonnote_insn/prev_nonnote_insn won't solve -O3
(without -g). One real problem is SEE can't determine if SEE is safe by just
looking at
--- Comment #7 from gary at intrepid dot com 2006-05-05 16:58 ---
Consider the following:
volatile int j;
void p()
{
++j;
}
Gimplify in its present form might transform the statement above into
something like the following:
volatile int j;
void p()
{
volatile int T1;
T1 = j +
--- Comment #14 from sgk at troutmask dot apl dot washington dot edu
2006-05-05 17:09 ---
Subject: Re: gfortran: intrinsics and std=f95, inconsistency with other
compilers
On Fri, May 05, 2006 at 07:09:37AM -, anlauf at gmx dot de wrote:
Any chance that -std=f95 -Wall
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 17:10 ---
(In reply to comment #7)
Consider the following:
volatile int j;
void p()
{
++j;
}
Gimplify in its present form might transform the statement above into
something like the following:
It will never get
Compiling the attached simple openmp program with gcc -fopenmp ... gives
omp_hog.c: In function 'main':
omp_hog.c:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
--- Comment #1 from ak at muc dot de 2006-05-05 17:17 ---
Created an attachment (id=11383)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11383action=view)
preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-05 17:33 ---
Interesting it does not fail on x86-linux-gnu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-05 17:35 ---
Or this was just fixed yesterday. Can you give the output of gcc -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-05 17:38 ---
Also as of today this works on x86_64 also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27448
--- Comment #9 from gary at intrepid dot com 2006-05-05 17:55 ---
Your issue with ++j not using incr is not related to the gimplifier at all as
it also happens in every compiler version since at least 2.95.3.
I agree that is unrelated. I didn't file this bug thinking that it would
gfortran.dg/transfer_array_intrinsic_2.f90 fails on hppa64-hp-hpux11.11, I
created a cut down test case and the cutdown test fails on hppa64-hp-hpux11.11
and ia64-hp-hpux11.23. On IA64 it fails in 32 and 64 bit modes. I think the
problem is with alignment since the program is dying on an 8 byte
I haven't looked into the rev. history, to see why/when this fix was made,
but will ask the hypothetical: was this fix made to workaround the
misbehavior in create_tmp_var_raw()? Note that create_tmp_var_raw()
is exported from gimplify.c and appears to be called from quite a few
places.
--- Comment #10 from dberlin at gcc dot gnu dot org 2006-05-05 18:06
---
Subject: Re: create_tmp_var_raw (gimplify.c)
inadventently asserts 'volatile' on temps
I haven't looked into the rev. history, to see why/when this fix was made,
but will ask the hypothetical: was
--- Comment #5 from ak at muc dot de 2006-05-05 18:13 ---
I got a new gcc today before reporting
/pkg/gcc-4.2/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/pkg/gcc-4.2-060409
--disable-checking --enable-languages=c,c++
--- Comment #6 from ak at muc dot de 2006-05-05 18:14 ---
Oops as you can see I indeed used an old gcc by mistake - a symlink
was set wrong. With the current gcc it works.
--
ak at muc dot de changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2006-05-05 18:42 ---
Bud already voted to close this in comment #11 :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-05 19:48
---
Subject: Bug 27240
Author: reichelt
Date: Fri May 5 19:48:26 2006
New Revision: 113559
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113559
Log:
PR objc/27240
* objc-act.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-05 19:51
---
Subject: Bug 27240
Author: reichelt
Date: Fri May 5 19:51:37 2006
New Revision: 113560
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113560
Log:
PR objc/27240
* objc-act.c
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-05 19:54
---
Fixed on mainline and the 4.1 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-05 20:01
---
It's indeed the same issue as PR 24672.
I knew there was a similar problem, but I couldn't find it.
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from patchapp at dberlin dot org 2006-05-05 20:03 ---
Subject: Bug number PR c/27420
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00203.html
--
--- Comment #3 from patchapp at dberlin dot org 2006-05-05 20:04 ---
Subject: Bug number PR c++/27422
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00205.html
--
--- Comment #4 from patchapp at dberlin dot org 2006-05-05 20:04 ---
Subject: Bug number PR c++/27423
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00206.html
--
--- Comment #3 from patchapp at dberlin dot org 2006-05-05 20:05 ---
Subject: Bug number PR c++/27427
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00207.html
--
--- Comment #3 from patchapp at dberlin dot org 2006-05-05 20:06 ---
Subject: Bug number PR c++/27430
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00208.html
--
Got this :
cc -I../libvo -I../../libvo -fno-PIC -O4 -march=pentium-m -mtune=pentium-m
-pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DHAVE_AV_CONFIG_H -I..
-I/home/cartman/CVS/mplayer/libavutil -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE
--- Comment #1 from ismail at pardus dot org dot tr 2006-05-05 21:09
---
Created an attachment (id=11385)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11385action=view)
Preprocessed source code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27450
--- Comment #2 from ismail at pardus dot org dot tr 2006-05-05 21:11
---
Created an attachment (id=11386)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11386action=view)
dsputil.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27450
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-05 21:15 ---
*** This bug has been marked as a duplicate of 27437 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-05 21:15 ---
*** Bug 27450 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from sje at cup dot hp dot com 2006-05-05 21:19 ---
Is it time to close this defect out? I tried to reproduce this on HP-UX with
3.4.5, 4.0.1, and 4.1 but they all worked. The 3.2 (and I think 3.3) branches
are closed aren't they?
--
sje at cup dot hp dot com
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Known to fail||4.1.1
--- Comment #8 from sje at cup dot hp dot com 2006-05-05 21:36 ---
Since this looks like an installation problem and not a real bug I am closing
it out as invalid.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #4 from sje at cup dot hp dot com 2006-05-05 21:47 ---
PR 21613 (same bug on a different platform) was closed with the comment that
this got fixed when tree-ssa was merged in and that it would hard to fix in the
3.4 branch. I verified I can still see it on 3.4.5 and that it
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-05 21:47
---
I'll commit a testcase when I find some time this week-end...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from sje at cup dot hp dot com 2006-05-05 22:11 ---
I don't see this failure anymore so I think we can assume it was the same bug
as PR 25168. Resolving as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-05 22:18
---
Here is another testcase:
unsigned char clip_uint8(int a)
{
if (a(~255))
return (-a)31;
return a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
--- Comment #13 from sje at cup dot hp dot com 2006-05-05 22:21 ---
Dave, it looks like this defect has been fixed. Is there any reason not to
close the defect?
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-05 22:22
---
My last case looks like HJL's 4 case. I wish x86 was not like this instead did
something different bug oh well
(insn:HI 6 8 7 2 (set (reg/v:SI 60 [ a ])
(mem/c/i:SI (reg/f:SI 16 argp) [2 a+0 S4 A32])) 34
--- Comment #1 from sje at cup dot hp dot com 2006-05-05 22:32 ---
This is an HP linker bug and it is in PHSS_33033 and possibly in some earlier
linker patches too. There is a replacement for PHSS_33033 now. For HP-UX
11.00 the new patch is PHSS_33034 and for HP-UX 11.11 the new patch
--- Comment #15 from anlauf at gmx dot de 2006-05-05 22:44 ---
(In reply to comment #14)
How does this look to you?
Steve,
this is perfect!
Many thanks,
-ha
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20248
--- Comment #14 from danglin at gcc dot gnu dot org 2006-05-05 22:50
---
Fixed by patch 3.4 and leter.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 118 matches
Mail list logo
