--- Comment #8 from patchapp at dberlin dot org 2007-01-25 09:55 ---
Subject: Bug number PR 26494
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-01/msg02068.html
--
I tried to add a comment to my bug #28686. Being a common user, I could not
modify the asignee, that was static text only no entry field. When I comitted
my addition, I was asked for my password, and then told:
You tried to change the Assignee field from [EMAIL PROTECTED] to
__UNKNOWN__, but only
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-25 10:59 ---
Try deleting all cookies related to gcc bugzilla, there was a change in setup
recently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30584
--- Comment #2 from Martin dot vGagern at gmx dot net 2007-01-25 11:03
---
No luck there. But here it works! strange!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30584
--- Comment #2 from Martin dot vGagern at gmx dot net 2007-01-25 11:06
---
As this has been unconfirmed for so long and should be relatively easy to
confirm, here are the commands to reproduce the problems above:
gcc -fPIC -fomit-frame-pointer -O2 -S ebp.c grep DEBUG ebp.s
gcc
Christian BRUEL wrote:
After loged in with my Bugzilla account, I'm trying to add a new
Additional Comment to the bug #29845. I didn't modify any of the other
fields. I keep getting the following error message:
You're not the only one Christian. See bug #30584.
Andrew
--- Comment #3 from Martin dot vGagern at gmx dot net 2007-01-25 11:08
---
Clearing browser cache helped. Maybe bugzilla did not mark a page as changed
that had in fact changed for some reason. I'm ready to provide additional
information if I can. Just ask. Unfortunately it is too late
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2007-01-25 11:41
---
(In reply to comment #3)
scheduling:6473.35 (100%) usr 0.60 (88%) sys6473.98 (100%)
wall
499608 kB (90%) ggc
On which revision of gcc-4_2-branch or trunk have you seen it? It looks to me
--- Comment #1 from muntyan at tamu dot edu 2007-01-25 13:27 ---
The original code warns if you use -O3 (I guess because of inlining or
something), the code below is better:
-
#include stdio.h
int func (void);
int main (void)
{
int foo;
if (func ())
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-01-25 13:52
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-01-25 14:06 ---
And indeed we should support Annex F in this regard.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from gdr at gcc dot gnu dot org 2007-01-25 14:14 ---
Won't be fixed in GCC-4.0.4. So closing, sorry.
The code appears to work in recent versions of GCC.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
$ gcj -Werror /tmp/x.java
invalid warning: error
$ gcj -Wall /tmp/x.java
invalid warning: all
--
Summary: gcj doesn't accept -Wall and -Werror anymore
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #16 from tg at mirbsd dot org 2007-01-25 14:28 ---
Interestingly enough, nbd of OpenWrt has found that the bug
doesn't appear (i.e. the assert is triggered) if the function
is inlined (at -O3, with -finline-functions, or the attribute).
I've used a simpler test programme
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-01-25 14:49
---
Backporting the fix for PR28651 should fix it I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
$ cat abi.cc
#include iostream
struct abi;
void foo (abi );
$ gcc abi.cc
abi.cc:3: error: variable or field #8216;foo#8217; declared void
abi.cc:3: error: expected primary-expression before #8216;#8217; token
abi.cc:3: error: expected primary-expression before #8216;)#8217; token
The problem is
--- Comment #11 from bkoz at gcc dot gnu dot org 2007-01-25 15:30 ---
Subject: Bug 29722
Author: bkoz
Date: Thu Jan 25 15:30:32 2007
New Revision: 121175
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121175
Log:
2007-01-24 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #50 from gdr at gcc dot gnu dot org 2007-01-25 15:51 ---
This is not going to be fixed for GCC-4.0.4, so adjusting milestone.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from gdr at gcc dot gnu dot org 2007-01-25 15:54 ---
Fixed in GCC-4.1.2 and higher.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from gdr at gcc dot gnu dot org 2007-01-25 15:58 ---
This PR will not be fixed in GCC-4.0.4, so adjusting
the milestone.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from gdr at gcc dot gnu dot org 2007-01-25 16:04 ---
Adjusting milestone
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #18 from tg at mirbsd dot org 2007-01-25 16:09 ---
Subject: Integer Overflow detection code optimised away, -fwrapv
broken
Dixi:
Commit ID: 10045B8CAF141886704
CVSROOT: /cvs
Module name: gcc
Changes by:[EMAIL PROTECTED] 2007/01/25 15:21:11 UTC
I've posted this to the mailing list and figured i might as well post a bug
report to accompany it.
It's not as much of a bug as it a missing feature that gcc3 had.
Basically gcc v3 placed padding between the end of local variables and the
saved frame pointer or other control information and
-languages=c,c++,java
Thread model: posix
gcc version 4.3.0 20070125 (experimental)
$ time /usr/bin/gcj -I../../frysk/frysk-imports -I. -Igetopt.jar -Ijunit.jar
-Werror -Wall -fPIC -g -O -fjni -c antlr.jar
real0m36.455s
user0m35.666s
sys 0m0.644s
$ time /home/mark/src/gcc-install/bin
--- Comment #1 from aph at gcc dot gnu dot org 2007-01-25 16:59 ---
I'm guessing this is either because of more aggressive alalysis or perhaps
we're now compiling unit-at-a-time. In any case, I don't think Java is the
correct component.
--
A simple example of what breaks the libgfortran build:
$ cat a.c
#include math.h
extern float foo(float);
float bar(float x) { return sinhf(x); }
int main(void)
{
float x;
x = bar(x);
x = foo(x);
return 0;
}
$ cat b.c
#include math.h
int foo(float x) { return sinhf(x); }
$ gcc a.c
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-25 17:01
---
Sorry I have CCed the wrong person.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-25 17:02
---
Created an attachment (id=12954)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12954action=view)
Preprocessed source file for a.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-25 17:03
---
Created an attachment (id=12955)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12955action=view)
Preprocessed source file for b.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
--- Comment #1 from sje at gcc dot gnu dot org 2007-01-25 17:07 ---
Subject: Bug 30182
Author: sje
Date: Thu Jan 25 17:06:55 2007
New Revision: 121178
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121178
Log:
PR other/30182
* config/pa/pa.c (pa_init_builtins):
--- Comment #2 from sje at cup dot hp dot com 2007-01-25 17:09 ---
Resolved with patch to call _Isfinite* routines.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #4 from jconner at apple dot com 2007-01-25 17:11 ---
I'll investigate fixing this in the 4.1 and 4.2 branches, as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
--- Comment #3 from sqrammi at hotmail dot com 2007-01-25 17:11 ---
I've modified the source so that there are no warnings and (hopefully) no
aliasing violations. The problem still occurs. Here is my line that I use to
compile:
arm-926ejs-linux-gnu-gcc -Wall -O2 -fno-strict-aliasing
--- Comment #4 from sqrammi at hotmail dot com 2007-01-25 17:12 ---
Created an attachment (id=12956)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12956action=view)
Modified code - no warnings
--
sqrammi at hotmail dot com changed:
What|Removed
--- Comment #5 from rearnsha at gcc dot gnu dot org 2007-01-25 17:25
---
-- volatile char buf[512] /*__attribute__ ((aligned (4)))*/;
WHat makes you think this buffer will be word-aligned? One of your
sub-routines creates a variable with 33 bytes, and when inlining happens
there's
--- Comment #6 from sqrammi at hotmail dot com 2007-01-25 17:28 ---
The problem is that the compiler is not either 1) automatically aligning the
buffer so that the program actually works or 2) warning the user that their
code is retarded and needs to be modified so that all the stacks
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-25 17:22 ---
This was caused by the MEM-ssa merge, I thought I had a patch but it crashed
during build __gcc_bcmp.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-01-25 17:35
---
(In reply to comment #6)
The problem is that the compiler is not either
1) automatically aligning the
buffer so that the program actually works or
It doesn't have to, because the user hasn't asked it to
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-25 17:41 ---
This is not a bug really. There is no reason to think stack layout will not
change and will not be because of alignment or anything else.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from schwab at suse dot de 2007-01-25 17:47 ---
Use -Wcast-align.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
--- Comment #8 from sqrammi at hotmail dot com 2007-01-25 17:45 ---
It would be easy to add support to the compiler to at least warn about char
arrays of non-CPU-word-size length being placed on the stack, right? It
wouldn't even have to be a warning that shows up unless -Wall (or it's
--- Comment #10 from sqrammi at hotmail dot com 2007-01-25 17:55 ---
Great. That's perfect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
--- Comment #11 from sqrammi at hotmail dot com 2007-01-25 18:01 ---
Thinking about it some more, this actually may be a bug in my Linux kernel
configuration that fixes up unaligned accesses. It's probably trying to fix up
for a big-endian system on my little-endian system.
--
--- Comment #1 from dalej at gcc dot gnu dot org 2007-01-25 18:29 ---
Early drafts of the ABI spec said that, but the final version calls for passing
this struct as integers. I believe the following is publicly accessible:
--- Comment #2 from dalej at gcc dot gnu dot org 2007-01-25 18:30 ---
as above
--
dalej at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|blocker
Target Milestone|--- |4.3.0
--- Comment #3 from sje at cup dot hp dot com 2007-01-25 18:58 ---
I reproduced this bug with 3.4.5, but all the 4.* compilers I tried worked fine
(4.0.2, 4.0.3, 4.1.0, 4.1.1) so I think we should close it. Hal, I don't know
if the person who got you the testdrive account can help you
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-01-25 19:05
---
Subject: Bug 28703
Author: rguenth
Date: Thu Jan 25 19:05:19 2007
New Revision: 121181
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121181
Log:
2007-01-25 Richard Guenther [EMAIL PROTECTED]
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-01-25 19:05
---
Subject: Bug 28651
Author: rguenth
Date: Thu Jan 25 19:05:19 2007
New Revision: 121181
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121181
Log:
2007-01-25 Richard Guenther [EMAIL PROTECTED]
--- Comment #1 from pcarlini at suse dot de 2007-01-25 19:13 ---
As far as I can see, in gcc4.0.x a special config/cpu/ia64/atomic_word.h
already existed... and used, or otherwise something was broken, the file has
been added with the below patch. As far as I can see, the
--- Comment #12 from geoffk at gcc dot gnu dot org 2007-01-25 19:18 ---
I'm working on this.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from geoffk at gcc dot gnu dot org 2007-01-25 19:20 ---
... at least, I think I have a patch which will fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
--- Comment #2 from pcarlini at suse dot de 2007-01-25 19:23 ---
Humm, maybe the fix is very simple: apparently these days in the ia64
atomic_word.h we don't really need cxxabi.h, only cxxabi_tweaks.h, for
__cxxabiv1::__guard. I'll give it a try...
--
pcarlini at suse dot de
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-01-25 19:25 ---
Subject: Bug 30272
Author: dfranke
Date: Thu Jan 25 19:25:01 2007
New Revision: 121182
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121182
Log:
2007-01-25 Daniel Franke [EMAIL PROTECTED]
PR
The following test case, when compiled with g++ -O, has a return
value of 1 (instead of the correct value of 0):
struct test
{
int type;
char buffer[4242]; /* should trigger pass-by-reference */
};
int flag = 0;
struct test
reset (void)
{
struct test retval;
retval.type = 1;
return
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-01-25 20:02
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-25 20:11 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from geoffk at gcc dot gnu dot org 2007-01-25 20:32 ---
Subject: Bug 25127
Author: geoffk
Date: Thu Jan 25 20:32:06 2007
New Revision: 121184
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121184
Log:
2007-01-24 Geoffrey Keating [EMAIL PROTECTED]
PR
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-25 21:15 ---
Subject: Bug 30437
Author: manu
Date: Thu Jan 25 21:15:34 2007
New Revision: 121186
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121186
Log:
2007-01-25 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-01-25 22:33 ---
Subject: Bug 28209
Author: dfranke
Date: Thu Jan 25 22:33:43 2007
New Revision: 121187
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121187
Log:
2007-01-25 Daniel Franke [EMAIL PROTECTED]
Backport
ecjx is a java program used as part of the gcj compilation process. Because it
is written in java and runs on the host, it needs a host version of gcj to
build it.
Here is the error I am getting:
make[3]: *** [ecjx] Error 127
make[3]: Leaving directory
--- Comment #1 from daney at gcc dot gnu dot org 2007-01-25 23:12 ---
This is actually contains the error from the build output this time:
i686-pc-linux-gnu-gcj -o ecjx -findirect-dispatch
--main=org.eclipse.jdt.internal.compiler.batch.GCCMain
Using both -fmudflap and -Wnested-externs generates spurious errors.
localhost$ touch tmp.c
localhost$ gcc -fmudflap -Wnested-externs -S tmp.c
built-in:0: warning: nested extern declaration of __mf_lookup_cache
built-in:0: warning: nested extern declaration of __mf_lc_shift
built-in:0:
--- Comment #4 from hald at kc dot rr dot com 2007-01-25 23:36 ---
(In reply to comment #3)
I reproduced this bug with 3.4.5, but all the 4.* compilers I tried worked
fine
(4.0.2, 4.0.3, 4.1.0, 4.1.1) so I think we should close it. Hal, I don't know
if the person who got you the
--- Comment #3 from schwab at suse dot de 2007-01-25 23:40 ---
Yes, config/cpu/ia64/atomic_word.h already existed before 4.2, but it wasn't
picked up until this:
2006-07-14 Benjamin Kosnik [EMAIL PROTECTED]
* configure.host: Simplify.
--
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-25 23:59 ---
Works in svn trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-26 00:00 ---
Andrew added caching a while back.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tromey at gcc dot gnu dot org 2007-01-26 00:01 ---
I think this is fixed now.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-26 00:01 ---
All done.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from geoffk at gcc dot gnu dot org 2007-01-26 00:04 ---
Subject: Bug 25127
Author: geoffk
Date: Fri Jan 26 00:03:28 2007
New Revision: 121190
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121190
Log:
2007-01-24 Geoffrey Keating [EMAIL PROTECTED]
PR
--- Comment #4 from pcarlini at suse dot de 2007-01-26 00:04 ---
(In reply to comment #3)
Yes, config/cpu/ia64/atomic_word.h already existed before 4.2, but it wasn't
picked up until this:
2006-07-14 Benjamin Kosnik [EMAIL PROTECTED]
* configure.host: Simplify.
I see.
--- Comment #16 from geoffk at gcc dot gnu dot org 2007-01-26 00:05 ---
This should be fixed now in the trunk and 4.2 branches.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-26 00:05 ---
Testing a fix.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2007-01-26 00:14 ---
Disregard sparc in my previos post, was already ok, sorry. In summary, in
4_1-branch, additional entries are needed in the atomic_word_dir switch for
alpha, ia64 and powerpc.
--
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-26 00:22 ---
Fixed in 4.3.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-01-26 00:23 ---
This is probably because the mingw math.h header does not support C99.
Francois, where does this header come from?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-26 00:24 ---
It turns out to be pretty hard to make jv-convert use the classpath
getopt code, since all gcj classes are built by the main compilation
and not the tools compilation (in libjava/classpath/).
I'm going to go for a
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-01-26
00:24 ---
CVS mingw runtime header _mingw.h has this, which avoids the problem:
# if ( __MINGW_GNUC_PREREQ(4, 3) __STDC_VERSION__ = 199901L)
# define __CRT_INLINE extern inline
--- Comment #16 from dmarkman at mac dot com 2007-01-26 01:05 ---
it looks like that suggested code doesn't work for x86_64 platform. I changed
ADDR declaration to
INTEGER *8 and gfortran -m64 percentval.f returns the following errors:
CALL SUB1( %VAL( ADDR ), SIZE )
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-26 01:05 ---
Subject: Bug 29594
Author: tromey
Date: Fri Jan 26 01:05:13 2007
New Revision: 121197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121197
Log:
PR libgcj/29594:
* gnu/gcj/convert/Convert.java
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-26 01:06 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
With GNU Fortran 95 (GCC) 4.3.0 20070125 (experimental), the programme
program main
integer size
integer*1 var
open (10, file=conftestval, status=unknown)
inquire (iolength=size) var
write (10, *) size
close (10)
end
compiled with the options
--- Comment #17 from dmarkman at mac dot com 2007-01-26 01:45 ---
after looking at the gcc/fortran/trans_types.c I tried to use
-fdefault-integer-8 switch
and everything was fine
--
dmarkman at mac dot com changed:
What|Removed |Added
Jonathan Brickman wrote:
as indicated by anyone who knows what I should be trying next! I tried
to send this via the GCC web bug report system, but I could not find any
way to attach this file, which the docs said is essential.
First file the bug report, you will then immediately be taken to
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-26 02:08 ---
Do we really want this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20631
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-26 02:23 ---
FWIW I don't think we want to fail outright if no suitable gcj is found.
The whole business with compiling and installing ecj.jar is a convenience,
not a strict necessity. The user can always make his own ecj1
The code generated for a ppc32 for the 1 line function f below is incorrect.
Not that it should matter but this is a cross compiler, built with cross-tool.
typedef struct {
unsigned char c;
unsigned int i:24;
} e_t;
f(e_t *p)
{
p-i= 8;
}
#include stdio.h
int
main(int
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-26 02:47 ---
Sorry for my ignorance, what is syntactically wrong with that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293
--- Comment #19 from m dot k dot edwards at gmail dot com 2007-01-26 02:53
---
Still generates bad code for snd_mask_refine in the gcc-4.1-20070115 snapshot.
I have verified that the patch claimed to fix this bug is in this snapshot. My
gcc is tuned for arm-926ejs, old ABI. -O1
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30595
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-26 03:37
---
I can reproduce this on non-darwin machine. Erik you were going to suggest a
patch? If you want, I will review this for you. I wonder if this is related
to changes I made to allow large iolengths, ie 64-bit
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-26 03:53 ---
This is not a bug, -malign-double changes the ABI. Stop using options that
change the ABI.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-26 03:54 ---
Please read the documentation about options like this, they explictly warn they
change the ABI.
Warning: if you use the -malign-double switch, structures containing the above
types will be aligned differently than
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-26 03:56 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.3 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-01-26 06:19
---
Can this PR be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30411
97 matches
Mail list logo
