--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-09-27 05:51 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-09-27 05:49 ---
what happening here is:
xmm0xmm1
movss _a, %xmm1 {?, ?, ?, ?}{a, 0, 0, 0}
movss _b, %xmm0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
05:33 ---
The bug for this code is because ix86_expand_vector_init_duplicate does widen
in GPRs first and then
in into the vector register.
Mainly:
/* Replicate the value once into the next wider mode and rec
--- Additional Comments From ian at airs dot com 2005-09-27 05:33 ---
Eric, your patch which caused the quadratic behaviour is here:
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01358.html
I know this is a real long-shot, but do you have any recollection of what
problem you were solv
--- Additional Comments From ian at airs dot com 2005-09-27 05:10 ---
The code in combine is no better than it ever was. What has changed is this
patch:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02021.html
which causes the optimization of incrementing a memory location to be done
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
05:08 ---
The issue is in ix86_expand_vector_init.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24074
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
05:07 ---
The issue is in ix86_expand_vector_init.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24073
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
05:06 ---
This is an issue in ix86_expand_vector_init.
--
What|Removed |Added
Component|middl
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
04:52 ---
>From the looks of it, (vector short){ x, x, x, x, x, x, x, x } has the same
>issue too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24076
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
04:47 ---
A better way to optimize this was shown in
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00546.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24076
Take the following code:
#define vector __attribute__((__vector_size__(16)))
vector char bar (char x) {
return (vector char){
x, x, x, x, x, x, x, x,
x, x, x, x, x, x, x, x
};
}
We currently produce crappy code:
pushl %edx
movzbw 8(%esp), %ax
movl%eax,
--- Additional Comments From flash at pobox dot com 2005-09-27 04:38
---
Created an attachment (id=9816)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9816&action=view)
Preprocessed source file
PalmSource bug #110057.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24075
Setup: arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3 built with crosstool-0.29,
running on
proprietary ARM hardware. Does not happen with CodeSourcery's 3.4.3
arm-none-linux-gnueabi
2005Q1B, so it's possible that this bug is of historical interest only. On the
other hand, I don't have a
non
--
What|Removed |Added
GCC target triplet||i786-pc-darwin7.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24073
Take the following code:
#define vector __attribute__((vector_size(16)))
float a; float b;
vector float fb(void) { return (vector float){ 0,0,b,a};}
Currently we produce:
movss _a, %xmm1
movss _b, %xmm0
unpcklps%xmm1, %xmm0
movaps %xmm0, %xmm1
--
What|Removed |Added
Keywords||ssemmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24073
Take the following example:
#define vector __attribute__((vector_size(16)))
float a; float b;
vector float f(void) { return (vector float){ a, b, 0.0, 0.0}; }
---
Currently we get:
subl$12, %esp
movss _b, %xmm0
movss _a, %xmm1
unpcklps%xmm0, %xmm1
--- Additional Comments From raj dot khem at gmail dot com 2005-09-27
03:20 ---
This is still exhibited on mainline gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9703
--- Additional Comments From raj dot khem at gmail dot com 2005-09-27
03:12 ---
This bug is fixed on mainline. 3.4 branch however has it still.
May be it can be closed for mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11825
--- Additional Comments From raj dot khem at gmail dot com 2005-09-27
03:09 ---
This is fixed in GCC 3.4.4 as well as on mainline. This can be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11826
--- Additional Comments From raj dot khem at gmail dot com 2005-09-27
03:00 ---
I verified that this is fixed in GCC 3.4, 4.0 as well as on mainline. So this
can be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11831
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
02:39 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
02:37 ---
Works on the 3.4 branch.
--
What|Removed |Added
Known to work|4.0.0 3.3.6
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
01:52 ---
Confirmed, I have not tried 3.4 either to see if this is a bug there too.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
01:44 ---
I need to double check the 3.4 branch but this is only a 3.4 regression.
Both 3.3.3 and 4.0.0 and above give:
t.cc:2: error: conflicting types for `volatile unsigned int i'
t.cc:1: error: previous declaratio
--
What|Removed |Added
Keywords||diagnostic
Known to fail||3.4.0
Known to work|
extern volatile signed int i;
volatile unsigned int i = 0;
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc:2: error: conflicting declaration 'volatile unsigned int i'
foo.cc:1: error: 'i' has a previous declaration as `volatile int i'
foo.cc:2: error: type mismatch with previous external decl o
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
01:24 ---
I need to try FSF 4.0.2 because redhat's compiler is known not to be clean.
But currently I can confirm this fails on the mainline and works with 4.0.0
20050301 and 3.3.6.
--
What|Remove
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
01:16 ---
Likewise for .s files:
@@ -1502,7 +1502,7 @@
.byte 0x3 # Start new file
.uleb128 0x8b # Included from line number 139
.file 17 "/usr/include/bits/stdio_lim.h"
- .uleb128
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
01:12 ---
The difference between 32 and 64bit:
--- 64 2005-09-27 03:10:18.552798040 +0200
+++ 32 2005-09-27 03:10:26.250627792 +0200
@@ -1,7 +1,7 @@
Dump of debug contents of section .debug_line:
- Length:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-27
01:08 ---
Hmm, I think this should have been fixed by PR 20253. I don't have any FSF
4.0.x compiler after that.
Double hmm, it works with 32 bits but not 64bits on the mainline.
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-09-27 00:44
---
Kevin,
can you try out the various testcases from this report and see whether your
compiler fails any of them?
W.
--
What|Removed |Added
---
--
What|Removed |Added
Attachment #9815|double intialization patch |force intialization patch
description||
http://gcc.gnu.org/bugzilla/show_b
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-26 23:24
---
Created an attachment (id=9815)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9815&action=view)
double intialization patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071
--
What|Removed |Added
CC||ebotcazou at libertysurf dot
||fr
http://gcc.gnu.org/bugzilla/s
The patch for 22309 kills Solaris 2.6, 2.7, 2.8, and 2.9. The failure mode is as
follows:
FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
FAIL: ext/mt_allocator/check_delete.cc execution test
FAIL: ext/mt_allocator/check_new.cc execution test
FAIL: ext/mt_allocator/deallocate_
--- Additional Comments From kev dot gilbert at cdu dot edu dot au
2005-09-26 23:17 ---
Whilst this bug has been marked as resolved, I am still experiencing the same
problems (with arts-1.4.91 - the version shipped with KDE 35. Beta 1).
My gcc version info : gcc (GCC) 4.1.0 20050
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-26 23:03
---
André,
Any chance you can detail how I can reproduce your failure?
thanks,
benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
--- Additional Comments From jimb at redhat dot com 2005-09-26 22:57
---
Created an attachment (id=9814)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9814&action=view)
Preprocessed input file for the bug report.
This is the result of preprocessing bad-macro-file.c on my machine.
When passed the -g3 flag, GCC can generate Dwarf macro info that contains bad
file numbers.
The test input file bad-macro-file.i is included at the bottom.
$ gcc --version
gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the s
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
22:48 ---
Just a note:
I was able to profiledbootstrap on x86_64-pc-linux-gnu (but that was over a
week ago).
On powerpc-darwin, it failed, and I got PR 23396 out of it, from what I heard
from someone else using
a
--- Additional Comments From mckinlay at redhat dot com 2005-09-26 22:41
---
Please ignore this patch, I attached it to the wrong bug. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24057
--- Additional Comments From mckinlay at redhat dot com 2005-09-26 22:36
---
AC_PROG_CXX is, presumably, needed by classpath in order to build the Qt peers.
Although this is not the default configuration, it means we can't remove
AC_PROG_CXX.
The libjava configure gets around this issue
--- Additional Comments From atavory at gmail dot com 2005-09-26 22:22
---
(In reply to comments #2 and #3:
Actually, on second thought, I'm not sure we should give up consistency so
easily
only because the it = t.erase(it) idiom cannot be meaningfully used together
with
unordered cont
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26
22:07 ---
Unless the common infrastructure bb frequency and edge probabilities have been
updated to reflect builtin_expect, http://gcc.gnu.org/ml/gcc-patches/2005-
09/msg00370.html probably won't fix this problem.
-
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26
21:49 ---
Created an attachment (id=9811)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9811&action=view)
dwarf2out.i
Here's the .i. It results in a little "noise" in the form of some warnings
during the compi
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 20:46 ---
(In reply to comment #4)
> So this about the following:
> int f(a)
> int a;
> {
> return a;
> }
> int f(int);
>
> Which is questionable.
>
> So I don't think this is not an inappropriate warnin
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26
20:28 ---
Until I attach a .i file, this could be reproduced by anyone with a copy of
the mainline source and the gcda/gcno attachments I've already provided.
You'd need to to something like this:
.../build-gcc-ml
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26
20:14 ---
When I first saw it, it was with "stage1/xgcc -B stage1", however I've since
done a non-profiled bootstrap of mainline, and the resulting gcc exhibits the
same problem.
Working on getting the .i attached.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
20:06 ---
Subject: Bug 23677
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 20:06:37
Modified files:
gcc/fortran: ChangeLog
gcc/testsuite : C
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
20:02 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
20:01 ---
Is gcc really being used or is "stage1/xgcc -B stage1" being used?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
19:59 ---
This is not a regression.
--
What|Removed |Added
Keywords|
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26
19:58 ---
Created an attachment (id=9810)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9810&action=view)
dwarf2out.gcno
Attached dwarf2out.gcno
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-26
19:58 ---
libffi bug that Gary found while doing builds on PPC64
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01605.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
--- Additional Comments From steinmtz at us dot ibm dot com 2005-09-26
19:57 ---
Created an attachment (id=9809)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9809&action=view)
dwarf2out.gcda
Attached dwarf2out.gcda
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
19:55 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
19:55 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 19:54 ---
(In reply to comment #4)
> Because one file uses K&R style function defintions and the other uses a
prototype which is ANSI/ISO
> style.
> Simple example:
[snip]
> So I don't think this is not an
--
What|Removed |Added
Component|gcov/profile|rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
Ran into an ice today while attempting a profiled bootstrap of mainline:
/> gcc -c -O2 -fprofile-use -freorder-blocks-and-partition dwarf2out.i
dwarf2out.c: In function âoutput_call_frame_infoâ:
dwarf2out.c:2410: internal compiler error: in make_edges, at cfgbuild.c:350
Please submit a full bug re
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
19:48 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
19:46 ---
I really want to say this is a bug in their code as
x_alloc_nearest_color_for_widget's prototype is in the source file which is bad
form really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
19:41 ---
Because one file uses K&R style function defintions and the other uses a
prototype which is ANSI/ISO
style.
Simple example:
file1.c:
int f(int);
---
file2.c:
int f(a)
int a;
{
return a;
}
---
Compile it
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
19:41 ---
Subject: Bug 23847
CVSROOT:/cvs/gcc
Module name:gcc
Branch: apple-local-200502-branch
Changes by: [EMAIL PROTECTED] 2005-09-26 19:40:51
Modified files:
gcc
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:37
---
(In reply to comment #1)
> This is resolved by
>
> http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
>
> Paul T
PS The testcase checks the character sequence, rather than default character
type:
! { dg-
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:35
---
This is resolved by http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20903
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:34
---
This is resolved by http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20902
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:33
---
This is resolved by
http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20901
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:32
---
This is resolved by http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20900
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:31
---
This will be resolved by:
http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20899
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
19:31 ---
Actually this is where C standard is werid really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:30
---
This will be resolved by
http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20890
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:29
---
Sorted in:
http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20835
--
What|Removed |Added
Summary|Unconditional warning when |Unconditional warning when
|using -fwhole-program |using -combine
http://gcc.gnu.org/
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:28
---
> I have a patch for 3 and will try to sort out 6 (+pr21986) as soon as I have a
> moment.
Both sorted in
http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html
Paul T
--
Bug 16404 depends on bug 18870, whi
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 19:25 ---
Created an attachment (id=9808)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9808&action=view)
xlwmenu.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 19:25 ---
Created an attachment (id=9807)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9807&action=view)
xterm.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-26 19:24
---
Patch posted on fortran list:
http://gcc.gnu.org/ml/fortran/2005-09/msg00400.html
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23446
When trying to compile the attached preprocessed files using
gcc -c -fwhole-program --combine xterm.i xlwmenu.i
These warnings are produced unconditionally:
/home/dann/build/Emacs-CVS/emacs/lwlib/xlwmenu.c:57: warning: prototype for
'x_alloc_nearest_color_for_widget' follows non-prototype definit
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
19:20 ---
Subject: Bug 23268
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 19:19:43
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
19:20 ---
Subject: Bug 22585
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 19:19:43
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
19:20 ---
Subject: Bug 22576
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 19:19:43
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
19:13 ---
Subject: Bug 23847
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 19:12:34
Modified files:
gcc: ChangeLog
gcc/config/rs6000:
--- Additional Comments From bangerth at dealii dot org 2005-09-26 19:00
---
The testcase in comment #3 shows an ice-on-invalid. The testcase in
comment #7 is valid, and ices anyway.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
18:44 ---
Subject: Bug 23942
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 18:44:23
Modified files:
gcc: Makefile.in
Log message:
PR
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
18:43 ---
Subject: Bug 23942
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 18:43:09
Modified files:
gcc: ChangeLog tree-scalar-evolution.c
L
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
18:18 ---
Subject: Bug 23831
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 18:17:54
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
18:16 ---
Subject: Bug 23831
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 18:16:11
Modified files:
gcc: ChangeLog simplify-rtx.c
Log messag
--- Additional Comments From phython at gcc dot gnu dot org 2005-09-26
17:31 ---
So this is an ice-on-valid and an ice-on-invalid bug then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
17:26 ---
Subject: Bug 24055
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 17:25:49
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-26
17:21 ---
Subject: Bug 24055
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-26 17:21:02
Modified files:
gcc: ChangeLog
gcc/config/i386: i
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-26
16:56 ---
This works at -O on x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24053
--- Additional Comments From kazu at gcc dot gnu dot org 2005-09-26 16:13
---
Slightly reduced to:
extern void abort (void) __attribute__((noreturn));
struct S
{
int a, b, c;
};
void
foo2 (struct S x, struct S y)
{
if (x.b != 4)
abort ();
}
void
bar2 (struct S x, struct S y)
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-26
16:01 ---
> no ICE on x86 and x86_64, must be sparc specific.
> I agree, I generated the ADA compiler on a x86 and it works.
Confirmed. strict-alignment specific I presume.
--
What|Removed
--
What|Removed |Added
Keywords||alias
Last reconfirmed|2005-05-26 12:37:22 |2005-09-26 15:42:20
date|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
15:38 ---
Even -Wstrict-aliasing=2 does not warn.
--
What|Removed |Added
Last reconfirmed|2005-05-27
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
15:24 ---
The note in the documention should be expanded to say approximately
"-fomit-frame-pointer does
nothing for the function main as it is the entry point and the need for
realigning the stack is needed".
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-26
15:21 ---
I think the patch at
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00370.html
will fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9240
--- Additional Comments From chris at bubblescope dot net 2005-09-26 13:47
---
Sorry, you are of course changing the second value, which is fine. It's the
first one you shouldn't change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24064
1 - 100 of 125 matches
Mail list logo
