--- Comment #3 from pbrook at gcc dot gnu dot org 2006-07-06 15:26 ---
It looks like this is a latent bug.
My patch allows negxf to operate on integer registers (previously it was only
implemented on FP regs).
This causes the register allocator to make different register choices, and
--- Comment #4 from pbrook at gcc dot gnu dot org 2006-07-07 23:39 ---
Subject: Bug 27991
Author: pbrook
Date: Fri Jul 7 23:38:56 2006
New Revision: 115272
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115272
Log:
2006-07-08 Paul Brook <[EMAIL PROTECTED]>
--- Comment #5 from pbrook at gcc dot gnu dot org 2006-07-07 23:39 ---
Fixed.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pbrook at gcc dot gnu dot org 2009-01-02 17:01 ---
That's what dg-require-profiling does.
IMHO this is a deficiency in your glibc. It's very hard to distinguish between
"something is subtly busted" and "my glibc sucks", so I'm not
--- Comment #4 from pbrook at gcc dot gnu dot org 2005-11-06 12:23 ---
Both still fail for me
Target: m68k-elf
Configured with: ../gcc/configure --prefix=/home/paul/arm --target=m68k-elf
--with-newlib --disable-shared --disable-threads --enable-languages=c,c++
Thread model: single
gcc
--- Comment #3 from pbrook at gcc dot gnu dot org 2005-11-10 14:16 ---
Yes. You should use binutils HEAD for csl-arm-branch. Ther
binutils-csl-arm-branch is obsolete.
We'll probably add a configure check before merging this code to mainline, but
that's not a priority for csl-
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: hp at gcc dot gnu dot org
ReportedBy: pbrook at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68
--- Comment #1 from pbrook at gcc dot gnu dot org 2005-12-19 18:53 ---
This also occurs in a couple of places in the gcc testsuite, eg.
gcc.c-torture/compile/20050303-1.c
Reduced C testcase below.
int crc(int nleft)
{
int toread;
unsigned char buf[(128 * 1024)];
toread
--- Comment #2 from pbrook at gcc dot gnu dot org 2005-12-20 17:48 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01534.html
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pbrook at gcc dot gnu dot org 2005-12-20 18:15 ---
Looks like a dup of PR23482
*** This bug has been marked as a duplicate of 23482 ***
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pbrook at gcc dot gnu dot org 2005-12-20 18:15 ---
*** Bug 25136 has been marked as a duplicate of this bug. ***
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pbrook at gcc dot gnu dot org 2005-12-30 01:09 ---
Subject: Bug 23482
Author: pbrook
Date: Fri Dec 30 01:09:11 2005
New Revision: 109164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109164
Log:
2005-12-30 Paul Brook <[EMAIL PROTECTED]>
--- Comment #11 from pbrook at gcc dot gnu dot org 2006-07-18 21:42 ---
I'm working on this. Looks like a CSE bug.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |
--- Comment #12 from pbrook at gcc dot gnu dot org 2006-07-20 13:57 ---
Subject: Bug 27363
Author: pbrook
Date: Thu Jul 20 13:57:31 2006
New Revision: 115614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115614
Log:
2006-07-20 Paul Brook <[EMAIL PROTECTED]>
--- Comment #13 from pbrook at gcc dot gnu dot org 2006-07-20 13:59 ---
Subject: Bug 27363
Author: pbrook
Date: Thu Jul 20 13:59:22 2006
New Revision: 115616
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115616
Log:
Backport from mainline.
PR 27363
--- Comment #14 from pbrook at gcc dot gnu dot org 2006-07-20 15:07 ---
Subject: Bug 27363
Author: pbrook
Date: Thu Jul 20 15:07:25 2006
New Revision: 115620
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115620
Log:
2006-07-20 Paul Brook <[EMAIL PROTECTED]>
--- Comment #15 from pbrook at gcc dot gnu dot org 2006-07-20 15:08 ---
FIxed.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from pbrook at gcc dot gnu dot org 2006-07-27 23:37 ---
Huh. I thought glibc had removed all their nested functions.
The unwind table generation code can't cope with the prologue generated for
nested functions.
The reduced testcase passes the -O because gcc un-nest
--- Comment #6 from pbrook at gcc dot gnu dot org 2006-07-28 13:19 ---
If your test fails with -fno-exceptions then you're hitting a different bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-07-28 15:06 ---
I don't believe that it's possible to trigger this ICE unless you specify
-fexceptions or -funwind-tables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
duct: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pbrook at gcc dot gnu dot org
GCC target tri
--- Comment #1 from pbrook at gcc dot gnu dot org 2006-07-30 22:53 ---
Created an attachment (id=11976)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11976&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547
--- Comment #1 from pbrook at gcc dot gnu dot org 2006-08-08 23:05 ---
*** Bug 25428 has been marked as a duplicate of this bug. ***
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pbrook at gcc dot gnu dot org 2006-08-08 23:05 ---
Assembly in initial comment is bogus. Should be ldmfd {..., pc}^. ldmrd {...
lr}^ does somethething completely different.
*** This bug has been marked as a duplicate of 16634 ***
--
pbrook at gcc dot gnu dot
--- Comment #2 from pbrook at gcc dot gnu dot org 2006-08-08 23:47 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00230.html
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot
|dot org
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-08-25 20:40 ---
Subject: Bug 28621
Author: pbrook
Date: Fri Aug 25 20:39:48 2006
New Revision: 116431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116431
Log:
2006-08-25 Jan Hubicka <[EMAIL PROTECTED]&g
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|pbrook at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #5 from pbrook at gcc dot gnu dot org 2006-09-13 19:00 ---
This is looking like a latent reload bug.
I don't see anything in r105121 that could cause this bug. I can reproduce it
on non-linux and non-eabi arm targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot
|dot org
--- Comment #15 from pbrook at gcc dot gnu dot org 2006-09-19 13:18 ---
Subject: Bug 28516
Author: pbrook
Date: Tue Sep 19 13:18:27 2006
New Revision: 117055
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117055
Log:
2006-09-19 Paul Brook <[EMAIL PROTECTED]&g
--- Comment #16 from pbrook at gcc dot gnu dot org 2006-09-19 13:19 ---
Subject: Bug 28516
Author: pbrook
Date: Tue Sep 19 13:19:24 2006
New Revision: 117056
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117056
Log:
2006-09-19 Paul Brook <[EMAIL PROTECTED]&g
--- Comment #17 from pbrook at gcc dot gnu dot org 2006-09-19 13:26 ---
Fixed.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-09-20 22:55 ---
IIRC my change can cause entries to be present into the hash table that
wouldn't have been there before. However this should be harmless. I don't have
any helpful suggestons why this is broken.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot
|dot org
--- Comment #11 from pbrook at gcc dot gnu dot org 2006-09-27 14:12 ---
I ICE in comment #10 looks like it may be a different problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
--- Comment #7 from pbrook at gcc dot gnu dot org 2006-09-27 17:10 ---
Subject: Bug 29230
Author: pbrook
Date: Wed Sep 27 17:09:40 2006
New Revision: 117253
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117253
Log:
2006-09-27 Paul Brook <[EMAIL PROTECTED]>
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-09-27 17:10 ---
Subject: Bug 29230
Author: pbrook
Date: Wed Sep 27 17:10:22 2006
New Revision: 117254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117254
Log:
2006-09-27 Paul Brook <[EMAIL PROTECTED]>
--- Comment #9 from pbrook at gcc dot gnu dot org 2006-09-27 17:11 ---
Fixed.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from pbrook at gcc dot gnu dot org 2007-01-30 18:06 ---
Before reload the problematic instruction is:
(set (mem:HI (something))
(subreg:HI (reg:SI 177)))
Reload decides to reload the second operand into a register.
In find_reloads_subreg_address
--- Comment #8 from pbrook at gcc dot gnu dot org 2007-03-02 22:51 ---
Fixed.
trunk r122437 http://gcc.gnu.org/ml/gcc-cvs/2007-03/msg00020.html
4.2 r122489 http://gcc.gnu.org/ml/gcc-cvs/2007-03/msg00072.html
--
pbrook at gcc dot gnu dot org changed:
What|Removed
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dave dot korn at artimi dot
|dot org
--- Comment #4 from pbrook at gcc dot gnu dot org 2007-07-16 01:04 ---
Builds fine for me.
The bogus constraint is in a pattern that is never used - the predicate is
"TARGET_ARM && TARGET_HARD_FLOAT && TARGET_MAVERICK && 0 [...]"
gen* are clever enoug
--- Comment #5 from pbrook at gcc dot gnu dot org 2007-07-16 01:28 ---
In further investigation building with a prehistoric (<3.0.1) host compiler may
also cause the same failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32753
--- Comment #8 from pbrook at gcc dot gnu dot org 2007-07-16 13:01 ---
Subject: Bug 32753
Author: pbrook
Date: Mon Jul 16 13:01:18 2007
New Revision: 126679
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126679
Log:
2007-07-16 Paul Brook <[EMAIL PROTECTED]>
--- Comment #9 from pbrook at gcc dot gnu dot org 2007-07-16 13:03 ---
Subject: Bug 32753
Author: pbrook
Date: Mon Jul 16 13:03:07 2007
New Revision: 126680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126680
Log:
2007-07-16 Paul Brook <[EMAIL PROTECTED]>
--- Comment #10 from pbrook at gcc dot gnu dot org 2007-07-16 13:18 ---
Subject: Bug 32753
Author: pbrook
Date: Mon Jul 16 13:18:45 2007
New Revision: 126681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126681
Log:
2007-07-16 Paul Brook <[EMAIL PROTECTED]&g
--- Comment #8 from pbrook at gcc dot gnu dot org 2007-07-24 19:11 ---
You can use -mpreferred-stack-boundary=2 to disable this feature if you know
you're never going to need the additional stack alignment.
The compiler has know way of knowing whet the rest of your application doe
--- Comment #11 from pbrook at gcc dot gnu dot org 2007-07-25 15:47 ---
Should be fixed now.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-03-19
01:58 ---
Due to general gfortran lameness only contained functions are ever inlined.
Top-level functions are never inlined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20538
--- Comment #6 from pbrook at gcc dot gnu dot org 2008-02-13 14:17 ---
I agree with Nick. Unless there's some evidence that this bug still exists in
versions of gcc that we still support, I'm going to put this down to general
3.4 brokeness and assume it has already been f
--- Comment #9 from pbrook at gcc dot gnu dot org 2008-02-19 01:30 ---
Fixed
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from pbrook at gcc dot gnu dot org 2008-02-19 01:29 ---
Subject: Bug 35071
Author: pbrook
Date: Tue Feb 19 01:29:09 2008
New Revision: 132404
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132404
Log:
2008-02-19 Paul Brook <[EMAIL PROTECTED]>
--- Comment #11 from pbrook at gcc dot gnu dot org 2008-02-19 04:33 ---
Subject: Bug 35071
Author: pbrook
Date: Tue Feb 19 04:32:15 2008
New Revision: 132408
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132408
Log:
2008-02-19 Paul Brook <[EMAIL PROTECTED]&g
--- Comment #1 from pbrook at gcc dot gnu dot org 2009-03-12 13:45 ---
I'm not so sure documenting these is a good idea. Aren't these really internal
implementation details that are accidentally exposed via asm()?
IMHO putting them in the user documentation is risky becaus
--- Comment #2 from pbrook at gcc dot gnu dot org 2007-05-16 20:05 ---
Fixed.
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01010.html
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pbrook at gcc dot gnu dot org 2007-05-20 12:18 ---
Subject: Bug 32007
Author: pbrook
Date: Sun May 20 11:18:27 2007
New Revision: 124871
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124871
Log:
2007-04-20 Martin Michlmayr <[EMAIL PROTECTED]&g
--- Comment #7 from pbrook at gcc dot gnu dot org 2007-05-21 23:55 ---
On arm-elf structures are padded/aligned to a 4-byte boundary. This is a
"feature" of the ABI. The microsoft compiler obviously conforms to a different
ABI, which is why you get different results. Both ar
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-09-16
03:26 ---
This looks like a bug. However I don't agree with this analysis.
We should be applying the same transformation to both l and r.
Also, multiplying then dividing by the same value makes no
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-09-16
03:27 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-09-30
16:06 ---
Identifiers containing dollar signs are reserved by ARM ELF, so allowing them by
default is probably a bad idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24111
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pbrook at gcc dot gnu dot org
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
--- Comment #1 from pbrook at gcc dot gnu dot org 2005-10-24 01:33 ---
Original testcase above is reduced from
gcc.c-torture/execute/920501-6.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
--- Comment #5 from pbrook at gcc dot gnu dot org 2005-10-24 13:02 ---
Fixed
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #29 from pbrook at gcc dot gnu dot org 2010-03-30 14:04 ---
Wouldn't it be better to just remove _Unwind_GetRegionStart?
This function is not part of the ARM EABI, and removing it would expose any
(already broken) users at compile time.
--
http://gcc.gnu.org/bug
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-06-22
16:00 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-06-22
18:51 ---
Reopening until 4.0 is unforzen and the patch applied there
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot
|dot org |org
Status|REOPENED
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-07-05
12:10 ---
unwind.h is a target header. It should not be included by host code (ie. the
compiler).
--
What|Removed |Added
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-07-05
14:19 ---
In that case this may be a darwin bug.
IIUC gnat1 uses exceptions, and needs the host unwind.h to do so. These
exceptions may be different to the exceptions on the target system. If darwin
doesn't have
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-07-14
22:19 ---
There are many wrong-code and rejects-valid bugs effecting gfortran. This one is
no worse than the others. The only way to make sure a bug is fixed is to fix it
yourself or pay someone else to fix it for
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-07-15
15:22 ---
Fix applied to 4.0-branch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-07-21
21:06 ---
gcc4 behaviour seems fine to me.
A slightly simpler example
int foo(int a)
{
int b;
asm ("" : "+r" (b) : "r" (a));
return b;
}
Can be (and is) le
--- Comment #13 from pbrook at gcc dot gnu dot org 2007-11-28 19:05 ---
The short answer is don't do that.
-mabi=iwmmxt selects a bare-metal (short-enum) AAPCS variant with iWMMXt
calling conventions. As such it is incompatible with the Linux EABI supplement
--- Comment #6 from pbrook at gcc dot gnu dot org 2007-12-13 01:04 ---
Subject: Bug 30192
Author: pbrook
Date: Thu Dec 13 01:03:53 2007
New Revision: 130800
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130800
Log:
2007-12-13 Richard Earnshaw <[EMAIL PROTECTED]&g
--- Comment #1 from pbrook at gcc dot gnu dot org 2008-05-29 00:13 ---
I think this is a gfortran bug. It implements its own short-enums flag instead
of using flag_short_enums.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pbrook at gcc dot gnu dot org 2006-01-22 13:41 ---
Smaller testcase:
void
read_encoded_value_with_base (const unsigned char *p, unsigned * val)
{
union unaligned
{
unsigned short u2;
}
__attribute__ ((__packed__));
const union unaligned *u = (const
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-03-28 18:03 ---
Subject: Bug 23623
Author: pbrook
Date: Tue Mar 28 18:03:06 2006
New Revision: 112460
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112460
Log:
2006-03-28 Paul Brook <[EMAIL PROTECTED]>
--- Comment #9 from pbrook at gcc dot gnu dot org 2006-03-29 15:21 ---
Subject: Bug 23623
Author: pbrook
Date: Wed Mar 29 15:21:13 2006
New Revision: 112493
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112493
Log:
2006-03-29 Paul Brook <[EMAIL PROTECTED]>
--- Comment #10 from pbrook at gcc dot gnu dot org 2006-03-29 17:44 ---
Should be fixed now.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pbrook at gcc dot gnu dot org 2006-04-02 13:19 ---
Subject: Bug 18527
Author: pbrook
Date: Sun Apr 2 13:19:15 2006
New Revision: 112622
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112622
Log:
2006-04-02 Paul Brook <[EMAIL PROTECTED]>
--- Comment #12 from pbrook at gcc dot gnu dot org 2006-04-04 17:40 ---
Subject: Bug 18527
Author: pbrook
Date: Tue Apr 4 17:40:00 2006
New Revision: 112675
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112675
Log:
2006-04-04 Paul Brook <[EMAIL PROTECTED]>
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-04-24
14:23 ---
The original testcase can (and should) be checked at compile time. The argument
is a simple variable of known length.
The error should be unconditional (ie. not just when -pedantic is specified)
--
http
l-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pbrook at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21469
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-05-09
20:04 ---
Annother testcase. This one fails at -O2 with gcc 4.1.0 20050507 and 4.0.1
20050430.
This is a regression from 3.4.
typedef unsigned long long uint64_t;
register int *env asm ("ebp");
register l
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-05-15
21:42 ---
I already did.
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01246.html
--
What|Removed |Added
--- Additional Comments From pbrook at gcc dot gnu dot org 2004-12-27
17:41 ---
The test causes memory corruption, so the actual symptoms are fairly
arbitrary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-04
22:48 ---
I don't think that patch is sufficient. I'm about halfway to a fix.
I don't think the behaviour should be conditional on STRICT_ALIGNMENT.
Either enforce alignment, or annotate things prope
--
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |200
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-06
23:39 ---
This is a mis-ferature inherited from g77. It's definitely premitted by the
standard, but probably wants "fixing" anyway.
Full discussion here:
http://gcc.gnu.org/ml/fortran/2004-1
--
Bug 19292 depends on bug 17675, which changed state.
Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in
EQUIVALENCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675
What|Old Value |New Value
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-09
22:59 ---
Should be fixed now.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 18977 depends on bug 17675, which changed state.
Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in
EQUIVALENCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675
What|Old Value |New Value
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-10
01:28 ---
This is a f2003 feature, and not legal f95.
http://gcc.gnu.org/ml/fortran/2005-01/msg00091.html
--
What|Removed |Added
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-15
11:09 ---
Technically illagal, so removing rejects-valid keyword.
IFC is not a particularly good judge of whether code is legal ;-)
--
What|Removed |Added
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-16
13:04 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--
Bug 19292 depends on bug 17675, which changed state.
Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in
EQUIVALENCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675
What|Old Value |New Value
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-16
23:21 ---
Fixed.
--
What|Removed |Added
Status|REOPENED|RESOLVED
--
Bug 18977 depends on bug 17675, which changed state.
Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in
EQUIVALENCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675
What|Old Value |New Value
1 - 100 of 133 matches
Mail list logo
