--- Comment #9 from bonzini at gnu dot org 2007-05-31 06:40 ---
Subject: Bug 32098
Author: bonzini
Date: Thu May 31 06:40:42 2007
New Revision: 125215
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125215
Log:
2003-05-31 Paolo Bonzini <[EMAIL PROTECTED]>
PR libjava/32
--- Comment #2 from pault at gcc dot gnu dot org 2007-05-31 06:26 ---
(In reply to comment #1)
> Yes, it is indeed a regression, which was introduced between
> 2007-05-25-r125057 and 2007-05-29-r125159.
...and is almost certainly my doing - damn!
I am on to it
Paul
--
http://gcc.g
--- Comment #2 from bonzini at gnu dot org 2007-05-31 06:06 ---
I'm not sure we actually want to build libgcc stage1 optimized. But yes,
fixing 32009 will provide a way to fix this.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-31 02:19 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-31 02:19 ---
Subject: Bug 32145
Author: pinskia
Date: Thu May 31 02:19:03 2007
New Revision: 125213
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125213
Log:
2007-05-30 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-31 02:19 ---
Subject: Bug 32144
Author: pinskia
Date: Thu May 31 02:19:03 2007
New Revision: 125213
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125213
Log:
2007-05-30 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-31 02:19 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #19 from davek at gcc dot gnu dot org 2007-05-31 02:07 ---
Subject: Bug 14331
Author: davek
Date: Thu May 31 02:06:48 2007
New Revision: 125212
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125212
Log:
2007-05-31 Dave Korn <[EMAIL PROTECTED]>
PR preproces
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-31 01:52 ---
Can someone send me the backtrace for 3.4.x? (I think I am fixing the same bug
for the spu-elf target also).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25742
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-31 01:50 ---
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> warning: ./cc1obj-checksum.o differs
> warning: ./cc1plus-checksum.o differs
This has been happening for me before the branch of 4.2.
--
http://g
The stage1 libgcc.a and crt files are being built with -O0. This means that
the stage2 cc1 is using unoptimized libgcc.a, but the stage3 cc1 is using
optimized libgcc.a, which is causing them to be different, which is one of a
number of causes for
Comparing stages 2 and 3
warning: ./cc1-checksum.
--- Comment #8 from fang at csl dot cornell dot edu 2007-05-31 01:33
---
... and there was much rejoicing.
(Thanks, Doug, et al.!)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7412
--- Comment #8 from dgregor at gcc dot gnu dot org 2007-05-31 01:28 ---
Rvalue references are now supported on mainline (for 4.3.0) in the experimental
C++0x mode.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from dgregor at gcc dot gnu dot org 2007-05-31 01:27 ---
Fixed on mainline for GCC 4.3.0. DR 106 is implemented for C++0x mode and for
non-strict C++98 mode.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dgregor at gcc dot gnu dot org 2007-05-31 01:18 ---
Subject: Bug 7412
Author: dgregor
Date: Thu May 31 01:18:22 2007
New Revision: 125211
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125211
Log:
2007-05-30 Russell Yanofsky <[EMAIL PROTECTED]>
D
--- Comment #7 from dgregor at gcc dot gnu dot org 2007-05-31 01:18 ---
Subject: Bug 29939
Author: dgregor
Date: Thu May 31 01:18:22 2007
New Revision: 125211
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125211
Log:
2007-05-30 Russell Yanofsky <[EMAIL PROTECTED]>
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-31 00:05
---
Works OK for me on x86-64-gnu-linux. My system is a 5/27/2007 bootstrap of 4.3
trunk.
This could be platform specific. Can another Darwin user confirm this. Looks
like the problem may be platform specific. Y
--- Comment #8 from pcarlini at suse dot de 2007-05-30 23:21 ---
You are right, I was exactly noticing that at the same time as you. I'm fixing
that issue separately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
--- Comment #1 from eweddington at cso dot atmel dot com 2007-05-30 23:20
---
Also fails -O0 in latest 4.3 HEAD:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01434.html
but -O0 still passes in 4.2.1 20070525:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01304.html
--
http:
--- Comment #164 from ian at airs dot com 2007-05-30 23:18 ---
Created an attachment (id=13637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13637&action=view)
Patch
This is a modification of the previous patch which correctly handles the test
case in comment #85.
--
ian at a
--- Comment #6 from ian at airs dot com 2007-05-30 23:06 ---
Patch committed to mainline as revision 12503. The test case works for me.
--
ian at airs dot com changed:
What|Removed |Added
---
--- Comment #6 from mark at codesourcery dot com 2007-05-30 23:02 ---
Subject: Re: [4.1/4.2/4.3 Regression] sometimes TREE_READONLY
is still set for non read only variables causing wrong code
mueller at gcc dot gnu dot org wrote:
> --- Comment #5 from mueller at gcc dot gnu dot or
--- Comment #7 from mec at google dot com 2007-05-30 23:01 ---
I think the problem is independent of __is_pod. The new
std::uninitialized_fill has an "if" statement, not a template specialization.
Compilation always attempts to instantiate std::fill(__first_, __last_, __x),
whether tha
--- Comment #5 from mueller at gcc dot gnu dot org 2007-05-30 22:46 ---
is it okay that was_readonly will eventually turn on TREE_READONLY()
afterwards?
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from patchapp at dberlin dot org 2007-05-30 22:40 ---
Subject: Bug number PR29651
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/2007-05/msg02108.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #9 from eweddington at cso dot atmel dot com 2007-05-30 22:40
---
Testing for bug:
- r19 is modified, but not saved
avr-gcc -c -O1 bug.i -funroll-loops:
- fails with 4.2.0
- succeeds with 4.3-20070525
avr-gcc -c -O1 bug.i:
- succeeds with 4.2.0
--
eweddington at cso do
--- Comment #4 from eweddington at cso dot atmel dot com 2007-05-30 22:18
---
f32.c succeeds for
4.1.2, -O[0123s]
4.2.0, -O[0123s]
4.3-20070525, -O[0123s]
Lowering priority.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
---
--- Comment #6 from pcarlini at suse dot de 2007-05-30 21:46 ---
Many thanks to Andrew and Mark. I'm on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
--- Comment #5 from mark at codesourcery dot com 2007-05-30 21:38 ---
Subject: Re: uninitialized_fill compile failure if no default
assignment operator
pcarlini at suse dot de wrote:
> --- Comment #3 from pcarlini at suse dot de 2007-05-30 21:25 ---
> Thanks Mark. In fact, we
--- Comment #7 from dominiq at lps dot ens dot fr 2007-05-30 21:35 ---
> a and c are actually a little more accurate at the end.
> Its also interesting that this deviation between the methods
> appears to happen only near the end of the sequence.
> I have visually scanned in quite a
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-30 21:31 ---
(In reply to comment #3)
> has __is_pod(A) true. Actually, the problem affects also other front-end
> traits, probably most of them :( :( They are not working correctly with
> templates. First blush, any hint where I
--- Comment #12 from rask at sygehus dot dk 2007-05-30 21:29 ---
The AVR is unusual in having
#define STACK_PUSH_CODE POST_DEC
#define STACK_GROWS_DOWNWARD
where most targets would have PRE_DEC when the stack grows downward. The
middle-end tries to synthesize the missing pushdi pattern
--- Comment #3 from pcarlini at suse dot de 2007-05-30 21:25 ---
Thanks Mark. In fact, we have already a test for that, in ext/is_pod.cc. But we
have a problem with templates. This:
template
struct A
{
A() { }
};
has __is_pod(A) true. Actually, the problem affects a
--- Comment #4 from jakub at gcc dot gnu dot org 2007-05-30 21:24 ---
Subject: Bug 31809
Author: jakub
Date: Wed May 30 21:24:24 2007
New Revision: 125201
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125201
Log:
PR c++/31809
* decl.c (cp_finish_decl): Clear TRE
--- Comment #2 from mark at codesourcery dot com 2007-05-30 21:08 ---
Subject: Re: uninitialized_fill compile failure if no default
assignment operator
pcarlini at suse dot de wrote:
> --- Comment #1 from pcarlini at suse dot de 2007-05-30 21:00 ---
> Curious, this is actuall
--- Comment #6 from martin dot audet at imi dot cnrc-nrc dot gc dot ca
2007-05-30 21:02 ---
I'm the original submiter of this bug and I'am not sure now if it's a bug in
g++ template instantiation mechanism (e.g. problem with the two phase name
lookup) or if the code example itself is st
--- Comment #1 from pcarlini at suse dot de 2007-05-30 21:00 ---
Curious, this is actually a C++ front-end issue, a bug in my implementation of
__is_pod: currently it just forwards to pod_type_p, in cp/tree.c, and
apparently I was wrong to assume it exactly implements the Standard concep
--- Comment #38 from eweddington at cso dot atmel dot com 2007-05-30 20:59
---
termios.c successful for 4.2.0, 4.3-20070525, for all -Ox.
arpcache.i successful for 4.2.0, 4.3-20070525, for all -Ox.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
--- Comment #37 from eweddington at cso dot atmel dot com 2007-05-30 20:54
---
test.c fails in 4.2.0 for -Os only, -O[0123] works.
test.c succeeds for 4.3-20070525 for all -O[0123s].
--
eweddington at cso dot atmel dot com changed:
What|Removed |A
--- Comment #12 from andreast at gcc dot gnu dot org 2007-05-30 20:44
---
No negative feedback, so closing. Please reopen if not fixed.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from eweddington at cso dot atmel dot com 2007-05-30 20:40
---
Fails for 4.3-20070525
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #11 from eweddington at cso dot atmel dot com 2007-05-30 20:29
---
*** Bug 21834 has been marked as a duplicate of this bug. ***
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
-
--- Comment #4 from eweddington at cso dot atmel dot com 2007-05-30 20:29
---
Marking this bug as duplicate of bug #27386 because that bug has reduced test
case and more analysis.
*** This bug has been marked as a duplicate of 27386 ***
--
eweddington at cso dot atmel dot com chang
--- Comment #10 from eweddington at cso dot atmel dot com 2007-05-30 20:09
---
Test case fails for 4.3-20070525.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
-
--- Comment #5 from dgregor at gcc dot gnu dot org 2007-05-30 19:59 ---
The rvalue references patch (PR 29939) also implements reference collapsing as
described in core issue 106.
Unfortunately, however, Wolfgang's test case does not work even with reference
collapsing due to an interac
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-05-30 19:59 ---
*** Bug 32153 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-30 19:59 ---
...to mark as dup of PR19020.
*** This bug has been marked as a duplicate of 19020 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-30 19:59 ---
Reopen...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLV
--- Comment #5 from ian at airs dot com 2007-05-30 19:41 ---
I think this is fixed by this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01079.html
I am currently testing that patch.
--
ian at airs dot com changed:
What|Removed |Added
-
--- Comment #3 from eweddington at cso dot atmel dot com 2007-05-30 19:34
---
Testcase fails for 4.2.0 and 4.3-20070525.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
-
--- Comment #5 from eweddington at cso dot atmel dot com 2007-05-30 19:23
---
Bug still present in 4.2.0, and 4.3-20070525.
To test bug (fixed from last comment):
avr-gcc -Os shifty3.i -o shifty3.o
avr-objdump -d shifty3.o > shifty3.dis
Compare output.
--
eweddington at cso dot atm
--- Comment #19 from eweddington at cso dot atmel dot com 2007-05-30 18:59
---
Testcase succeeds with 4.3-20070525, with all -O settings. Changing target
milestone to 4.3.0, lowering priority.
--
eweddington at cso dot atmel dot com changed:
What|Removed
--- Comment #2 from eweddington at cso dot atmel dot com 2007-05-30 18:09
---
Fails with 4.3-20070525, and with 4.2.0, with same error, but line 54 in
rtlhooks.c.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
---
--- Comment #1 from patchapp at dberlin dot org 2007-05-30 18:05 ---
Subject: Bug number PR target/32130
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/2007-05/msg02078.html
--
http://gcc.gnu.org/bug
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-05-30 18:02
---
> -ftrapv only traps floating-point overflow - no integer overflows.
It's the other way around, -ftrapv is meant to trap on integer operations only.
But it's well-known for being broken...
--
ebotcazou at gc
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-30 18:02 ---
Fails with: 2007-05-25-r125057
Works with: 2007-05-24-r125013
Zdenek, I think it is one of your patches which either caused this regression
or which revealed it. Could you have a look or suggest someone to do so?
--- Comment #5 from fang at csl dot cornell dot edu 2007-05-30 18:00
---
test case fails with 4.2.0 (release)
test case works with 3.3.3 (x86 SuSE linux)
test case fails with 3.3 (powerpc Apple's blds. 1760/1819)
Yet 3.3.3 is currently listed under "known to fail".
The mixed results on
--- Comment #8 from hjl at lucon dot org 2007-05-30 17:58 ---
Libjava should build again.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|NEW
--
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 #7 from hjl at gcc dot gnu dot org 2007-05-30 17:54 ---
Subject: Bug 32098
Author: hjl
Date: Wed May 30 17:54:48 2007
New Revision: 125195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125195
Log:
2007-05-30 H.J. Lu <[EMAIL PROTECTED]>
PR libjava/32098
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-30 17:54 ---
-ftrapv only traps floating-point overflow - no integer overflows.
(This is not completely correct, as some systems seem to offer to send FPE also
for integer overflows, see e.g.
https://www.cisl.ucar.edu/docs/ibm/re
--- Comment #6 from hjl at gcc dot gnu dot org 2007-05-30 17:52 ---
Subject: Bug 32098
Author: hjl
Date: Wed May 30 17:52:05 2007
New Revision: 125194
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125194
Log:
2007-05-30 H.J. Lu <[EMAIL PROTECTED]>
PR libjava/32098
--- Comment #5 from hjl at gcc dot gnu dot org 2007-05-30 17:48 ---
Subject: Bug 32098
Author: hjl
Date: Wed May 30 17:48:10 2007
New Revision: 125193
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125193
Log:
2007-05-30 H.J. Lu <[EMAIL PROTECTED]>
PR libjava/32098
--- Comment #27 from manu at gcc dot gnu dot org 2007-05-30 17:23 ---
Reminder: this will need an entry in http://gcc.gnu.org/gcc-4.3/changes.html
before closing as FIXED.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
--- Comment #1 from dcb314 at hotmail dot com 2007-05-30 17:03 ---
Created an attachment (id=13636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13636&action=view)
fortran source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32160
I just tried to compile Fortran package LAPACK with the
GNU Fortran compiler version 4.3 snapshot 20070525
The compiler said
/home/dcb/gcc/20070525/results/bin/gfortran -g -O3 -Wall -c clanht.f -o
clanht.o
clanht.f: In function 'clanht':
clanht.f:1: error: found a virtual definition for a GIMPLE
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to f
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-30 16:58 ---
> When I compile the program listed below I get the message "Error: Global name
> 'len' at (1) is already being used as a FUNCTION at (2)"
(add NAG f95 to the list of compilers)
This is a bug in gfortran; an extended
For following program a warning should be printed. NAG f95 prints:
Warning: yy.f90, line 9: Type declaration for generic intrinsic LEN ignored
If one changes "real :: len" into "integer :: len", NAG f95 shows:
Warning: yy.f90, line 9: Intrinsic function LEN explicitly typed
I think it makes sense
--- Comment #8 from wdobler at ucalgary dot ca 2007-05-30 16:37 ---
> > PS: The same probem occurred with g95, but is fixed now.
>
> I can reproduce this with gfortran, however, also g95 fails whereas NAG f95
> has as only change the filename.
The current version (as of 30 May 2007) of
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-30 16:36 ---
Yes, it is indeed a regression, which was introduced between
2007-05-25-r125057 and 2007-05-29-r125159.
==26453==at 0x474E05: gfc_add_loop_ss_code (trans-array.c:1638)
==26453==by 0x475495: gfc_conv_loop_setu
--- Comment #5 from bonzini at gnu dot org 2007-05-30 15:57 ---
A bug with the same symptom resurfaced. David, did I understand right that
this time the problem is the huge environment passed from the toplevel
makefile?
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-30 15:56 ---
Here is the comment from rtl.h about MEM_READONLY_P:
/* 1 if RTX is a mem that is statically allocated in read-only memory. */
And not:
/* 1 in a REG, MEM, or CONCAT if the value is set at most once, anywhere. */
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-30 15:46 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
Here is a test program:
// Call uninitialized_fill on a type with a default copy constructor
// but no default assignment operator.
#include
#include
typedef std::pair MyPair;
void Alpha(MyPair* start, MyPair* end) {
MyPair my_pair(1, 2);
std::uninitialized_fill(start, end, my_pair);
};
==
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 15:27
---
(In reply to comment #3)
> I don't think MEM_READONLY_P should be set. I think this is related to PR
> 31809.
>
Memory location in question is a constant static variable in a function. When
the function is run
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 15:22
---
Created an attachment (id=13635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13635&action=view)
Patch
Updated patch.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-30 15:12 ---
I don't think MEM_READONLY_P should be set. I think this is related to PR
31809.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from ubizjak at gmail dot com 2007-05-30 15:08 ---
gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 rnflow.f90
time ./a.out
user0m37.982s
profiled run:
user0m43.147s
each sample counts as 0.01 seconds.
% cumulative self self tot
When I compile the program listed below I get the message "Error: Global name
'len' at (1) is already being used as a FUNCTION at (2)"
For what it's worth, Compaq, Lahey, and g95 do not consider it an error.
PROGRAM VAL
i = len(" ")
END
SUBROUTINE len(i)
END
--
Summary: Can a subrou
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 15:06
---
Created an attachment (id=13634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13634&action=view)
Patch
This patch fixes the issue but wasn't yet bootstrapped or tested in any other
way.
--
http://gcc.
--- Comment #7 from kazu at gcc dot gnu dot org 2007-05-30 15:02 ---
Doh, I'll post a patch to move the testcase to an appropriate directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27387
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 14:30
---
This is an aliasing issue.
true_dependence () returns '0' on mems from insns 15 and 58. This is due to
MEM_READONLY_P () flag set on them.
(insn:HI 15 13 16 3 (set (mem/u/f/c/i:DI (symbol_ref:DI ("_ZZ10testMeth
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-30 14:11 ---
Subject: Bug 32152
Author: rguenth
Date: Wed May 30 14:11:06 2007
New Revision: 125187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125187
Log:
2007-05-30 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #4 from jv244 at cam dot ac dot uk 2007-05-30 14:04 ---
the original testcase fails (again/still?)
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2007-05-30 14:03 ---
Worked around in 4.2.1+ and on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
generates an ICE, I think it is a regression
write (*,'(2A3)') 'X'//(/"1","2"/)//'Y'
END
--
Summary: ICE with characters
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
--- Comment #2 from jv244 at cam dot ac dot uk 2007-05-30 14:01 ---
this still fails with current gfortran, so isn't a duplicate
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2007-05-30 14:00 ---
Fixed on the trunk, gcc-4_2-branch and redhat/gcc-4_1-branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jv244 at cam dot ac dot uk 2007-05-30 13:54 ---
this one seems to work now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31221
--- Comment #4 from jakub at gcc dot gnu dot org 2007-05-30 13:49 ---
Subject: Bug 31769
Author: jakub
Date: Wed May 30 13:49:06 2007
New Revision: 125185
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125185
Log:
PR tree-optimization/31769
* except.c (duplicate_
--- Comment #9 from jakub at gcc dot gnu dot org 2007-05-30 13:48 ---
Subject: Bug 29382
Author: jakub
Date: Wed May 30 13:48:07 2007
New Revision: 125184
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125184
Log:
PR bootstrap/29382
* configure.in: Don't use -fke
--- Comment #3 from jakub at gcc dot gnu dot org 2007-05-30 13:46 ---
Subject: Bug 31769
Author: jakub
Date: Wed May 30 13:46:25 2007
New Revision: 125183
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125183
Log:
PR tree-optimization/31769
* except.c (duplicate_
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2007-05-30 13:42
---
Created an attachment (id=13633)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13633&action=view)
Failing program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32155
In the following code, __gfortran_os_error is thrown as unresolved at link
time. The trouble goes away if
//'=0'
is removed.
$ cat silly.f
character(16) :: str,namx
len=4
namx='abcdefg'
str=' '
str(7:)=namx(1:len)//'=0'
write (6,*) str
end
$ gfortran silly
--- Comment #8 from aph at gcc dot gnu dot org 2007-05-30 13:36 ---
*** Bug 24454 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10632
--- Comment #10 from aph at gcc dot gnu dot org 2007-05-30 13:36 ---
*** This bug has been marked as a duplicate of 10632 ***
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from jakub at gcc dot gnu dot org 2007-05-30 13:32 ---
Subject: Bug 29382
Author: jakub
Date: Wed May 30 13:32:34 2007
New Revision: 125182
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125182
Log:
PR bootstrap/29382
* configure.in: Don't use -fke
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-30 13:23 ---
This seems to have fixed itself - all three testcases run fine on 4.3.0
20070525. I'll check it out tonight on x86_ia64 and, if all is well, I'll
clear the PR.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
I configured GCC like this:
/n/08/rask/src/gcc/configure --target=powerpc-unknown-eabisim --disable-nls
--with-newlib --enable-sim --disable-shared --enable-languages=c,c++,objc
When make runs configure in the target subdirectories, sim-crt0.o from libgloss
isn't found:
configure:2362: checking
1 - 100 of 113 matches
Mail list logo
