--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-01-14 08:22
---
Attached a patch that fixes the problem on x86 and a cross-compiler to
sparc64. I intend to contemplate it a bit further before I post it to the
list for review.
It doesn't seem to work for me (on the 4.1
--- Comment #41 from yanov at il dot ibm dot com 2006-01-14 09:29 ---
This fixes the problem on PowerPC.
(In reply to comment #39)
We should do the following:
Index: cfgloopmanip.c
===
--- cfgloopmanip.c
--- Comment #3 from pault at gcc dot gnu dot org 2006-01-14 09:44 ---
To quote Lahey on this one:
Compiling program unit TT at line 1:
1267-S: SOURCE.F90, line 6: If ASSIGNMENT is specified in the INTERFACE
statement, 'set' must have exactly 2 dummy arguments.
Strangely, ifort does
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-01-14 10:55 ---
(ignoring Pinskias valid but not helpful comments)
Sorry Mark, it was not meant as a personal offense, but as you asked for a
testcase in the first place and did not respond to me after providing one
and after
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-01-14 11:04
---
Subject: Bug 24257
Author: rguenth
Date: Sat Jan 14 11:04:16 2006
New Revision: 109701
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109701
Log:
2006-01-14 Steven Bosscher [EMAIL PROTECTED]
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-14 12:16 ---
4.1 branch has
;; Function foo (foo)
Analyzing Edge Insertions.
foo (r)
{
struct s temp_struct3;
struct s temp_struct2;
struct s temp_struct1;
bb 0:
temp_struct1 = r;
temp_struct2 = temp_struct1;
--- Comment #8 from steven at gcc dot gnu dot org 2006-01-14 12:22 ---
Mark,
Re. your comment #5, I think everyone respects your request that only the RM
sets priorities. But right now the RM fails to do so.
I have also set priorities on a number of bugs that obviously have the wrong
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-01-14 12:40
---
I decided to give this another look. My hack is surely a progression on this
issue and maybe even appropriate for the branches. Now trying to figure out
what goes wrong with it.
--
--- Comment #16 from steven at gcc dot gnu dot org 2006-01-14 13:56 ---
With this patch we force the alignment, but I have to admit I have no idea if
this approach is correct. The only other place in stor-layout.c where we look
at EMPTY_FIELD_BOUNDARY is in layout_decl, but that code
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-14 13:57 ---
If the approach is good, we should at least be checking (DECL_BIT_FIELD
(field)) also before forcing things...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-01-14 14:30 ---
Subject: Bug 22555
Author: rguenth
Date: Sat Jan 14 14:30:33 2006
New Revision: 109703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109703
Log:
2006-01-14 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-01-14 14:30 ---
Subject: Bug 22501
Author: rguenth
Date: Sat Jan 14 14:30:33 2006
New Revision: 109703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109703
Log:
2006-01-14 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-01-14 14:30 ---
Subject: Bug 22548
Author: rguenth
Date: Sat Jan 14 14:30:33 2006
New Revision: 109703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109703
Log:
2006-01-14 Richard Guenther [EMAIL PROTECTED]
PR
It appears that make clean (on a native bootstrap) always fails for me. After
make clean on a tree containing a build interrupted in stage 2, it fails trying
to make clean in stage 3 gcc. After make clean on a successfully-completed
bootstrap tree, it fails trying to make clean in stage 4 gcc.
--- Comment #18 from steven at gcc dot gnu dot org 2006-01-14 14:48 ---
This code in layout_decl looks suspicous:
/* Should this be controlled by DECL_USER_ALIGN, too? */
if (maximum_field_alignment != 0)
DECL_ALIGN (decl) = MIN (DECL_ALIGN (decl),
--- Comment #19 from steven at gcc dot gnu dot org 2006-01-14 15:17 ---
On AMD64, EMPTY_FIELD_BOUNDARY is 64 bits, so if we honnor that for the
zero-length bitfield, we get a size of 12 for the struct in the test case in
comment #9 (where we apparently expect 8, which is what you get
--- Comment #20 from steven at gcc dot gnu dot org 2006-01-14 15:35 ---
Indeed, in GCC 3.2 (GNU C version 3.2.3 (x86_64-unknown-linux-gnu)) initially
we have a DECL_ALIGN of 64 bits for the zero-length bitfield when we enter
field_decl:
Breakpoint 2, place_field (rli=0xa15b30,
--- Comment #10 from eedelman at gcc dot gnu dot org 2006-01-14 15:38
---
(In reply to comment #9)
Attached a patch that fixes the problem on x86 and a cross-compiler to
sparc64. I intend to contemplate it a bit further before I post it to the
list for review.
It doesn't
--- Comment #11 from eedelman at gcc dot gnu dot org 2006-01-14 15:40
---
Created an attachment (id=10640)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10640action=view)
Improved patch
--
eedelman at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-01-14 15:40 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from kazu at gcc dot gnu dot org 2006-01-14 15:42 ---
Subject: Bug 25485
Author: kazu
Date: Sat Jan 14 15:42:11 2006
New Revision: 109704
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109704
Log:
gcc/
PR tree-optimization/25485
* tree-vrp.c
--- Comment #5 from kazu at gcc dot gnu dot org 2006-01-14 15:48 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from steven at gcc dot gnu dot org 2006-01-14 15:55 ---
Created an attachment (id=10641)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10641action=view)
Fix x86_field_alignment for AMD64 zero-length bitfields; try to revert to
pre-jason ABI
So I'll just admit I
--- Comment #16 from steven at gcc dot gnu dot org 2006-01-14 16:59 ---
This is still not fixed on mainline, even with the new df implementation. The
code to record them is not executed (at least, not on AMD64). The function
responsible for recording them is df_bb_refs_record,
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-01-14 17:12
---
I have a fix which improves the situation by modifying the gimplifier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-14 17:24 ---
Created an attachment (id=10642)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10642action=view)
Fix df-scan.c
There doesn't seem to be a good reason to make adding the artificial defs for
the
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-01-14 17:25
---
Created an attachment (id=10640)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10640action=view) [edit]
Improved patch
The testsuite is now clean again, both on 32-bit and 64-bit SPARC. Thanks!
--
--- Comment #42 from danglin at gcc dot gnu dot org 2006-01-14 17:58
---
The patch in #41 doesn't seem to be a complete fix. I see the following
assembler code for testcase #2 on hppa-unknown-linux-gnu:
.LEVEL 1.1
.text
.align 4
.globl F1
.type F1,
--- Comment #43 from danglin at gcc dot gnu dot org 2006-01-14 18:16
---
Doh, forget my last comment. The lack of initialization just reflects
the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--- Comment #44 from steven at gcc dot gnu dot org 2006-01-14 18:18 ---
Dave, this is another comment that isn't helpful. What is wrong in the
assembler output for comment #42, what do you expect the assembler output to
look like, how is the problem related to this bug (if it is), and
--- Comment #9 from mark at codesourcery dot com 2006-01-14 18:44 ---
Subject: Re: [4.0/4.1/4.2 Regression] Trouble parsing nested
templated constructor calls
rguenth at gcc dot gnu dot org wrote:
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-01-14 10:55
---
--- Comment #10 from mark at codesourcery dot com 2006-01-14 18:48 ---
Subject: Re: [4.0/4.1/4.2 Regression] Trouble parsing nested
templated constructor calls
steven at gcc dot gnu dot org wrote:
--- Comment #8 from steven at gcc dot gnu dot org 2006-01-14 12:22
---
--- Comment #45 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-14
18:59 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed
Dave, this is another comment that isn't helpful. What is wrong in the
assembler output for comment #42, what do you
--
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
--
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 #15 from pinskia at gcc dot gnu dot org 2006-01-14 19:27
---
Fixed on the mainline at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #46 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-14
19:28 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed
The lack of initialization leads to some strangeness later in the
assembly code:
copy %r28,%r3
I would
--- Comment #47 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-14
19:48 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed
I see in postreload:
(jump_insn 21 19 24 2 (parallel [
(set (pc)
(if_then_else (ne
--- Comment #6 from gccbugzilla at multiwebinc dot com 2006-01-14 20:57
---
I have upgraded to ubuntu/kubuntu 5.10 and I am STILL getting this error
whenever I try to run `make` on ANYTHING. Does anyone have any suggestions? I
would really like to get this figured out. Maybe reinstall
--- Comment #48 from steven at gcc dot gnu dot org 2006-01-14 21:10 ---
I certainly don't see any way how this new issue has anything to do with the
ICE due to Mustafa's patch.
There's an easy check: is the code semantically equivalent to some other
compiler you trust (e.g. older gcc,
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-01-14 21:19 ---
Fixed
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-14 21:32 ---
Can you attach the preprocessed source as requested by
http://gcc.gnu.org/bugs.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25683
--- Comment #8 from gccbugzilla at multiwebinc dot com 2006-01-14 23:05
---
Created an attachment (id=10644)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10644action=view)
preprocessed source
I am assuming this is the preprocessed source. It was found in the src
subfolder of the
--- Comment #49 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-14
23:12 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed
--- Comment #48 from steven at gcc dot gnu dot org 2006-01-14 21:10
---
I certainly don't see any way how
--- Comment #13 from eedelman at gcc dot gnu dot org 2006-01-14 23:22
---
Created an attachment (id=10645)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10645action=view)
Improved patch
After some more testing, I found out that the previous patch still failed in
some cases.
--
--- Comment #50 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-15
00:37 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed
There's an easy check: is the code semantically equivalent to some other
compiler you trust (e.g. older gcc, hp system
--- Comment #51 from steven at gcc dot gnu dot org 2006-01-15 00:47 ---
*sigh*
Almost no-one knows HPPA assembly these days. It completely puzzles me why you
call the assembler output wrong if you're not specifically stating what
you're expecting instead. But then, I don't think it is
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-01-15 00:56
---
Subject: Bug 25663
Author: mmitchel
Date: Sun Jan 15 00:56:50 2006
New Revision: 109713
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109713
Log:
PR c++/25663
* parser.c
--- Comment #12 from mmitchel at gcc dot gnu dot org 2006-01-15 00:57
---
Subject: Bug 25663
Author: mmitchel
Date: Sun Jan 15 00:57:22 2006
New Revision: 109714
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109714
Log:
PR c++/25663
* parser.c
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-01-15 00:57
---
Subject: Bug 25663
Author: mmitchel
Date: Sun Jan 15 00:57:47 2006
New Revision: 109715
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109715
Log:
PR c++/25663
* parser.c
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-01-15 00:59
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-15 01:03 ---
Ping!
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #4 from davek at csh dot rit dot edu 2006-01-15 01:56 ---
as a work-around, I was able to fix this problem by copying the config.cache
from my root build directory into whatever directory was failing.
On my GNU/debian system, I had to copy it to
--- Comment #52 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-15
02:37 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed
Almost no-one knows HPPA assembly these days. It completely puzzles me why you
call the assembler output wrong if
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-15 03:14 ---
This might be fixed by (I am checking right now):
2006-01-14 Ian Lance Taylor ian@airs.com
* ifcvt.c (noce_init_if_info): New static function, broken out of
noce_process_if_block.
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-15 03:15 ---
This might have been fixed by (I am going to check soon) :
2006-01-14 Ian Lance Taylor ian@airs.com
* ifcvt.c (noce_init_if_info): New static function, broken out of
noce_process_if_block.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-15 03:53 ---
func3 is fixed on x86 but not func2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10050
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-15 04:05
---
This was not fixed.
If I rewrite the function like:
ulong f1(ulong a, ulong b)
{
ulong tmp = ab?b:a;
ulong tmp1 = ab?a:b;
a = tmp;
b = tmp1;
return use (a, b)+use(a,b);
}
It works.
--
--- Comment #53 from steven at gcc dot gnu dot org 2006-01-15 04:05 ---
FWIW, the part of the C99 standard that talk about uninitialized automatic
variables are 3.17.2, 6.2.4, 6.7.8 (especially point 10), and 6.8.
Also see Appendix J2 Undefined behavior.
To me, undefined behavior
--- Comment #8 from ian at airs dot com 2006-01-15 05:28 ---
My patch doesn't help for func2, at least on x86, because at the RTL level we
see stores to memory, and my patch doesn't attempt to handle that because of
all the aliasing issues between the then-block and the else-block.
It
--- Comment #9 from ian at airs dot com 2006-01-15 06:27 ---
Upon further reflection, I don't think this is amenable to a good fix using
conditional moves. func2 doesn't read from a. Using conditional moves will
require adding reads from a. It's not obvious that that is a good
--- Comment #54 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-15
06:46 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed
FWIW, the part of the C99 standard that talk about uninitialized automatic
variables are 3.17.2, 6.2.4, 6.7.8
~ which gcc
/usr/pubsw/bin/gcc
elaine:~ gcc -v
Reading specs from
/afs/ir.stanford.edu/systems/@sys/pubsw/package/Languages/gcc-3.4.4/sun4x_58/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.4/specs
Configured with: ../../gcc-3.4.4/configure --datadir=/lib --libexecdir=/lib
--sharedstatedir=/lib
attempting to cross-compile less-394 when i hit this:
lesskey.ii: In function `void tstr(char**)':
lesskey.ii:26: error: insn does not satisfy its constraints:
(insn 30 143 31 11 lesskey.ii:11 (set (reg/v:QI 0 %d0 [orig:32 ch ] [32])
(plus:QI (mem:QI (reg:SI 8 %a0) [0 S1 A8])
--- Comment #1 from vapier at gentoo dot org 2006-01-15 07:24 ---
Created an attachment (id=10646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10646action=view)
lesskey.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25792
65 matches
Mail list logo
