--- Comment #5 from mtrudel at gmx dot ch 2007-04-25 07:17 ---
You write it needs a host version of gcj,
your host is i686-pc-linux-gnu and
configure looks for i686-pc-linux-gnu-gcj?
Seems correct to me? What gcj should be searched for? The only problem I'm
currently aware of is that
--- Comment #2 from aesok at gcc dot gnu dot org 2007-04-25 07:18 ---
Subject: Bug 18989
Author: aesok
Date: Wed Apr 25 07:18:33 2007
New Revision: 124141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124141
Log:
PR target/18989
* config/avr/avr.h
In the attached testcase, gcc assigns the same register to several inline asm
named operands resulting in incorrect code generated. Seems like names of
operands do matter ('c' and 'count' are assigned the same register but renaming
'c' operand to 'xxc' for example makes this bug disappear).
--
--- Comment #1 from siarhei dot siamashka at gmail dot com 2007-04-25
07:26 ---
Created an attachment (id=13436)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13436action=view)
testcase for this bug
Testcase attached
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693
--- Comment #2 from siarhei dot siamashka at gmail dot com 2007-04-25
07:28 ---
This may be related to #31386
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-25 07:38 ---
foo1 (__result, n)
{
bar1 ((int4 *) n, foo1);
goto __return_foo1;
__return_foo1:;
looks strange. Shouldn't this be:
bar1 ((int4 *) n, __result)
In addition, the warning
g.f90:8: warning: Function does not
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-04-25 08:07 ---
Unfortunately, such a failure might happen also with a bad
kernel, an ill-configured glibc or a linker problem. This
report shows nothing about any compiler problem and other
folks successfully used shared
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2007-04-25 08:36
---
Subject: Bug 31299
Author: fxcoudert
Date: Wed Apr 25 08:36:20 2007
New Revision: 124143
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124143
Log:
PR libfortran/31299
*
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-04-25 08:37
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-04-25 08:39
---
Subject: Bug 31299
Author: fxcoudert
Date: Wed Apr 25 08:38:59 2007
New Revision: 124144
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124144
Log:
PR libfortran/31299
* intrinsic.texi
--- Comment #2 from patchapp at dberlin dot org 2007-04-25 08:40 ---
Subject: Bug number PR 31668
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-04/msg01609.html
--
When preprocessing Fortran code (ie when cc1 is called with -lang-fortran) we
should define a __GFORTRAN__ macro. Here's a patch that does just that:
Index: c-common.h
===
--- c-common.h (revision 124116)
+++ c-common.h (working
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2007-04-25 08:42:29
int func1( unsigned long long val )
{
return __builtin_ctzll( val );
}
int func2( unsigned long long val )
{
unsigned lo = (unsigned)val;
return lo ? __builtin_ctz(lo) : __builtin_ctz(unsigned(val32)) + 32;
}
func1 is more than 2 times slower than func2.
But it should be at least as fast
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-25 09:32 ---
Subject: Bug 31668
Author: burnus
Date: Wed Apr 25 09:32:21 2007
New Revision: 124147
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124147
Log:
fortran/
2007-04-25 Tobias Burnus [EMAIL PROTECTED]
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-25 09:33
---
Fixed on mainline, closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-25 09:35 ---
Fixed. For completeness, I only support PROC_MODULE (for interfaces to external
routines) and not PROC_INTERNAL as there is no way (except VALUE) to make use
of a call-by-value variable.
--
--- Comment #4 from kristoffer_e1 at hotmail dot com 2007-04-25 09:36
---
When this bug was reported I had these issues, it later turned out to be due to
glibc. All versions after 2.3.3 (in other words 2.3.4 -) works perfectly fine.
Sorry for not closing this.
--
--- Comment #7 from jb at gcc dot gnu dot org 2007-04-25 09:41 ---
BTW, here's some slides describing NAG:s experience, they use lazy symbol
lookup combined with caching, and claim it is up to 1000 times faster than
non-lazy (which gfortran uses AFAICS).
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-25 09:53 ---
Works for me. Can you attach the FILE.c.t93.optimized file you get if you
build with gcc -O3 -fno-inline -fdump-tree-optimized?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-04-25
09:57 ---
Testing a patch.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
The following code goes wrong with gfortran -malign-double (but is OK without
malign-double)
PROGRAM test
CHARACTER(80) :: buffer
READ (*,1) buffer
1 FORMAT(a)
END PROGRAM test
$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.9.1
Configured with: ../gcc-4.3-20070316/configure
This is with the Polyhedron aermod.f90 test case
(http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html).
The program crashes (in 1 sec) with
gfortran -funroll-loops -march=opteron -O2 -g aermod.f90
It does not crash:
- without: -march=opteron
- without: -funroll-loops
- with:
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-04-25 11:14
---
Confirmed with -O2 -fno-inline too, thanks for the reduced testcase.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-04-25 11:14
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-04-25
11:17 ---
Fixed.
Author: dannysmith
Date: Wed Apr 25 11:06:28 2007
New Revision: 124149
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124149
Log:
* config/i386/winnt.c (i386_pe_file_end): Strip
beachboys++ /tmp g++ -O2 mytestcase.i
mytestcase.i: In member function void D::Do(B*, C*):
mytestcase.i:36: internal compiler error: in compare_name_with_value, at
tree-vrp.c:3272
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for
--- Comment #1 from thimo dot neubauer at cst dot com 2007-04-25 12:53
---
Created an attachment (id=13437)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13437action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31698
--- Comment #7 from eduardo dot iniesta at aquiline dot es 2007-04-25
13:26 ---
Thank you very much, Tom.
I have updated GCC 4.3.0. Everything is well.
(In reply to comment #6)
Ok. You are running a version of gcj 4.3 from *before* the gcj-eclipse
merge. So, this is correctly
This is with the Polyhedron rnflow.f90 test case
(http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html)
It was working on 2007-04-23 (should be r124055) and started to fail since
2007-04-24 (should be r124093). (Same with PR 31697)
Crash after 1.5 seconds with
gfortran -m32
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-25 13:28 ---
Might be related to the similar PR 31699.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31697
JNI_CreateJavaVM fails to recognise -X options such as -Xmx and friends. It
says:
libgcj: unknown option: -Xmx128M
I tracked it to this code in libjava/prims.cc:
else if (vm_args-ignoreUnrecognized)
{
if (option_string[0] == '_')
parse_x_arg (option_string +
Hello all,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problem while executing the following program.
--
#include stdio.h
extern
--- Comment #26 from rguenth at gcc dot gnu dot org 2007-04-25 14:22
---
We fail to add the SFTs to the may_alias set of SMT.11, so add_virtual_operand
sees NULL may_aliases and doesn't add SFTs as clobbered.
I believe compute_flow_insensitive_aliasing is the culprit here as one can
--- Comment #4 from stephaniechc-gccbug at yahoo dot com 2007-04-25 14:26
---
Created an attachment (id=13438)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13438action=view)
output of -fdump-tree-optimized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31691
--- Comment #27 from rguenth at gcc dot gnu dot org 2007-04-25 14:42
---
The workaround doesn't work. I'll test the patch in comment #26, otherwise
I'm out of ideas and clue on how it should work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-04-25 15:04
---
Created an attachment (id=13439)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13439action=view)
prototype patch
I'm testing this one. It'll make aliasing slower and more conservative, so I
bet it's not the
Compilation *crashes* when -O argument is greater than 0 (i.e. -O1, -O2, or
-O3).
If -O0 is used (or -O is omitted) compilation *passes*.
Note that a below needs to be external to the function. If the line char*
a; is placed inside the test() function, compilation *passes*.
REDUCED TEST CASE:
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-25 15:21 ---
This is related to PR29446, backporting the fix for it should fix this one
also.
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |tree-optimization
Summary|ICE in
bash-3.1$ ./xgcc -m32 -B./ -O2 -S /tmp/reload1.i
reload1.c: In function reload_reg_free_p:
reload1.c:4420: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4677
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for
--- Comment #1 from hjl at lucon dot org 2007-04-25 15:25 ---
Created an attachment (id=13440)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13440action=view)
A testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31703
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[Regression 4.3] Crash of |[4.3 Regression] Crash of
|gen. prog. when using -
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-25 15:38 ---
Because it calls into libgcc and that without tail-calling:
_Z5func1y:
.LFB2:
pushl %ebp
.LCFI2:
movl%esp, %ebp
.LCFI3:
subl$24, %esp
.LCFI4:
movl8(%ebp), %eax
--- Comment #40 from schwab at suse dot de 2007-04-25 15:46 ---
Closing for now.
--
schwab at suse dot de changed:
What|Removed |Added
Status|REOPENED
When I compile this test case with -O2 for x86_64:
extern void g (void);
float
f (float sum, float mult, int *pi)
{
int i, j;
for (i = 0; i 10; ++i)
{
g ();
for (j = 0; j 1000; ++j)
sum += *pi++ * mult;
}
return sum;
}
I get this result:
f:
.LFB2:
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-04-25 16:32
---
Oh, btw. why the may_aliases bitmap for SMT.11 is empty on entry to the loops
computing the transitive closure (it tries to, right?) is that SFT.0 is not
considered stored to in the first nested loop over pointers
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-25 16:34 ---
what do you expect from an abi changing option?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from eweddington at cso dot atmel dot com 2007-04-25 16:34
---
This is very probably an mcore target issue. The test case passes for the AVR
target for 4.1.1 and 4.1.2 with all -O settings (0,1,2,3,s).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31702
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-04-25 16:42
---
Created an attachment (id=13441)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13441action=view)
a patch I like more
this one attached, bootstrap/testing in progress.
--
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #2 from KnowlesPJ at Cardiff dot ac dot uk 2007-04-25 16:47
---
I don't understand your response, or the assumptions that might be behind it.
The program is standard fortran that compiles without warning, and I cannot see
why I would not want doubles aligned at 64 bits on
--- Comment #4 from vbraun at physics dot upenn dot edu 2007-04-25 16:51
---
Super-condensed testcase (gcc 4.1.2):
-- snip on -
templatetypename T void f() {}
class A
{
void f() {};
friend void fint(); // line 5
};
-- snip off
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||rsandifo at sources dot
|
--- Comment #31 from dberlin at gcc dot gnu dot org 2007-04-25 17:01
---
Subject: Re: [4.2 Regression] -O3 optimizer bug
On 25 Apr 2007 15:32:41 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-04-25 16:32
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-25 17:10
---
Subject: Bug 29446
Author: rguenth
Date: Wed Apr 25 17:10:31 2007
New Revision: 124158
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124158
Log:
2007-04-25 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-25 17:10 ---
Subject: Bug 31698
Author: rguenth
Date: Wed Apr 25 17:10:31 2007
New Revision: 124158
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124158
Log:
2007-04-25 Richard Guenther [EMAIL PROTECTED]
PR
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Target Milestone|--- |4.3.0
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-04-25 17:13
---
No idea. The only place I found was setup_pointers_and_addressables, but that
hits the path only if
/* Add pointer variables that have been dereferenced to the POINTERS
array and create a symbol
--- Comment #2 from hjl at lucon dot org 2007-04-25 17:24 ---
I have verified that this patch
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01399.html
causes this regression. On Linux/i686, it fails to compile gcc 3.2. On
Linux/x86-64, it miscompiles gcc 3.2.
--
hjl at lucon dot
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #3 from eweddington at cso dot atmel dot com 2007-04-25 18:04
---
Note that the -MM-DD date format is ISO standard 8601, which also includes
formats for time as well.
http://en.wikipedia.org/wiki/ISO_8601
Any new formats for __DATE__ and __TIME__ should probably
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-04-25 18:07 ---
Patch installed
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ghazi at gcc dot gnu dot org 2007-04-25 18:08 ---
Updated testsuite results:
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01287.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-25 18:12 ---
Does not matter, this option changes the ABI, it is like any other ABI changing
option, you should not use it unless you understand what you are doing which is
clearly not the case.
--
pinskia at gcc dot gnu dot
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-04-25 18:14 ---
(In reply to comment #5)
ah, ok. so, in that case we probably want to just change the '3' to '2' in the
above test:
Index: testsuite/gfortran.dg/vect/vect-5.f90
--- Comment #3 from hjl at lucon dot org 2007-04-25 18:15 ---
rewrite_bittest has
lhs = GENERIC_TREE_OPERAND (stmt, 0);
...
/* A (1 B) */
t = fold_build2 (BIT_AND_EXPR, TREE_TYPE (a), a, name);
stmt2 = build_gimple_modify_stmt (lhs, t);
When A (1 B) is long
--- Comment #48 from zhong dot xie at yahoo dot ca 2007-04-25 18:16 ---
Solaris 10 x86 i386
gcc 3.3.6,
binutils 2.17.50.20070307
has the same issue.
binutils 2.17.50.20070307 not even compile under this platform. We have to
modify some scripts to make it work.
--
zhong dot xie at
--- Comment #1 from tromey at gcc dot gnu dot org 2007-04-25 18:38 ---
Yeah, this logic looks bogus.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janis at gcc dot gnu dot org 2007-04-25 18:55 ---
A regression hunt on powerpc-linux using the reduced testcase from comment #3
with -g2 -feliminate-dwarf2-dups -finline-functions identified the following
patch:
http://gcc.gnu.org/viewcvs?view=revrev=100802
The source file:
double helperDoubleTan(double * a, double * b)
{
double tmpA, tmpB;
tmpA = *a;
{
double y[3] = { 0.0, 0.0, 0.0 };
double r;
int lq;
lq = __ieee754_rem_pio2(tmpA, y);
r =
PROGRAM ReclBug
OPEN (UNIT= 11, FILE= 'bla', ACCESS= 'SEQUENTIAL',
FORM= 'UNFORMATTED', RECL= 100,
STATUS= 'UNKNOWN', ACTION= 'WRITE', IOSTAT= iostat )
IF (iostat /= 0) STOP
WRITE (11) 1,2,3
CLOSE (11, STATUS= 'KEEP')
END PROGRAM ReclBug
!! gfortran
--- Comment #3 from aesok at gcc dot gnu dot org 2007-04-25 19:38 ---
Subject: Bug 18989
Author: aesok
Date: Wed Apr 25 19:38:32 2007
New Revision: 124159
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124159
Log:
PR target/18989
* config/avr/avr.h
--- Comment #33 from dberlin at gcc dot gnu dot org 2007-04-25 19:45
---
I think richi said on IRC that the following backport from 4.3 will fix it (if
so, it's the correct fix here)
Index: tree-ssa-structalias.c
===
---
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-25 19:49 ---
Has anyone any objection if I change the purpose of this PR to:
-
gfortran should detect that the local variable ncoset is never allocated -
as NAG f95 does:
Error: foo.f90, line 45: ALLOCATABLE array NCOSET
--- Comment #3 from geoffk at gcc dot gnu dot org 2007-04-25 19:49 ---
I'm fairly sure this is in fact a bug in GCC. The problem is that in a routine
which uses setjmp, alloca() must ensure that the previous stack backchain is
preserved, which means it needs to allocate enough space
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from aesok at gcc dot gnu dot org 2007-04-25 19:52 ---
Subject: Bug 18989
Author: aesok
Date: Wed Apr 25 19:52:21 2007
New Revision: 124162
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124162
Log:
PR target/18989
* config/avr/avr.h
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-25 19:54 ---
What is your gfortran version (gfortran -v)?
I cannot repoduce it with neither -static nor without using
gfortran 4.1.3 20070413 (prerelease)
and 4.3.0 20070425 (experimental)
under x86_64-unknown-linux-gnu
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-25 19:58 ---
From the man page:
-malign-double
-mno-align-double
Control whether GCC aligns double, long double, and long long variables
on a two word boundary or a one word boundary. Aligning double variables on
a two word
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #7 from dorit at il dot ibm dot com 2007-04-25 21:30 ---
Are you going to submit/install your patch?
yes, I'll go ahead and submit the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
--- Comment #2 from janis at gcc dot gnu dot org 2007-04-25 21:31 ---
A regression hunt on powerpc-linux looking for DWARF2 line number information
for lines with gotos identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=83385
r83385 | hubicka | 2004-06-19 15:33:06
--- Comment #2 from janis at gcc dot gnu dot org 2007-04-25 21:50 ---
A regression hunt on powerpc-linux for the changeover from error message to ICE
identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=116311
r116311 | jason | 2006-08-21 20:54:57 + (Mon,
--- Comment #15 from pluto at agmk dot net 2007-04-25 21:56 ---
(In reply to comment #14)
4.1.2 uses 56MB.
I'll backport the changes (this is more or less copying tree-ssa-structalias.c
from 4.3 to 4.2 and modifying the few things that changed in 4.3 :P)
Daniel, are you working on
1 - 100 of 125 matches
Mail list logo
