--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Summary|[4.1/4.2 regression] Ada ICE|[4.1/4.2
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-14 06:38 ---
(In reply to comment #2)
Adding:
To finish_pseudo_destructor_expr fixes this bug.
This caused two regressions which I still need to look into, both are ICEs.
--
--- Comment #3 from tdalman at project-psi dot org 2006-09-14 06:40 ---
Thanks for clarification. Nevertheless, your wording, Andreas, is exactly what
I would have expected in the error message.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
--- Comment #2 from P dot Schaffnit at access dot rwth-aachen dot de
2006-09-14 07:42 ---
Hi!
My PATH was indeed set wrong! (sorry about that...). It seems to work now
(well, I mean it goes further...).
Thanks a lot for your help!
Philippe
--
P dot Schaffnit at access dot
Simple testcase:
#include stdio.h
#pragma pack(4)
struct ABC
{
double a;
int b;
bool c;
};
int main()
{
ABC A;
ABC B;
int C;
ABC D;
printf(A - %p; B - %p; C - %p; D - %p\n, A, B, C, D);
return 0;
}
compiled with:
gcc test.cpp -lstdc++
Variable D is aligned on 4 bytes
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-14 08:05 ---
#pragma pack(4)
Variable D is aligned on 4 bytes and should be 8.
No you said to align it to 4 bytes by that pack statement.
This is not a bug.
Why do you think otherwise?
--
pinskia at gcc dot gnu dot org
--- Comment #2 from dsiata at poczta dot onet dot pl 2006-09-14 08:14
---
Subject: Re: wrong alignment with pragma pack(4)
U¿ytkownik pinskia at gcc dot gnu dot org [EMAIL PROTECTED] napisa³:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-14 08:05
---
#pragma
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-14 08:19 ---
(In reply to comment #2)
Because double have to be aligned on 8 on sparc or bus error occurs.
Note that first member of the structure is double. So now I'm not able to
assign any value to D.a.
Wrong, wrong,
When using HP ANSI C compiler with CFLAGS (and CXXFLAGS) set to -O2 or -O3 for
bootstrap, xgcc does ICE during first compilation of gcc/libgcov.c.
This does work when CFLAGS/CXXFLAGS unset, or set to -O0 or -O1 (thus severity
minor).
Works for gcc-3.4.5.
Errormessage is:
./xgcc -B./
--- Comment #1 from michael dot haubenwallner at salomon dot at 2006-09-14
08:27 ---
Created an attachment (id=12264)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12264action=view)
tar.bz2 containing logfiles for ICE using HP 'cc -O2'
configure.out: Output of 'configure'
--- Comment #15 from aph at gcc dot gnu dot org 2006-09-14 08:27 ---
I don't think this bug has anything to do with excess precision. Valgrind
shows that, when compiled at -O2, we are reading from uninitialized memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-14 08:30 ---
This is why bootstrap exists in the first place.
You should report this bug to HP and not us as we cannot fix HP's compiler.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-09-14
08:45 ---
Created an attachment (id=12265)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12265action=view)
Patch to provide the shape of the SPREAD intrinsic + testcase
(In reply to comment #1)
Yes, it
--- Comment #4 from dsiata at poczta dot onet dot pl 2006-09-14 08:57
---
(In reply to comment #3)
OK. Now I see it's new feature in 4.0 or 4.1 series.
I have GPF in similar code but for now I cannot reproduce it on simple case...
Thank you. Now I know to not use pack(4) :-)
--
--- Comment #4 from mathieu dot courtois at free dot fr 2006-09-14 09:05
---
Created an attachment (id=12266)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12266action=view)
work around
With some *1 added, compilation pass !?
--
--- Comment #5 from mathieu dot courtois at free dot fr 2006-09-14 09:08
---
I try as soon as possible.
Thanks for your help.
This subroutine is one of an open-source project which contains about 1.000.000
lines of fortran : http://www.code-aster.org.
--
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-09-14
09:09 ---
This is most likely related to (or identical with) PR21918.
Martin, that is spot on. In fact, Tobi's patch works fine; albeit a bit more
verbosely. Also, the locii need to be indirectly referenced,
--- Comment #22 from mkoeppe at gmx dot de 2006-09-14 10:12 ---
(In reply to comment #21)
Update 2 for gcc-4.2
I now successfully bootstrapped gcc-4.2-20060909, using native, i.e.
ms-patched, binutils!
After applying some hotfixes to interix, fixing the shell
Compiling a .cpp file with the following contents triggers an internal compiler
error:
struct Base {
templateclass C void method() { }
};
struct Left : public Base { };
struct Right: public Base { };
struct Join : public Left, public Right { };
voidfunction()
{
--- Comment #5 from dsiata at poczta dot onet dot pl 2006-09-14 10:46
---
(In reply to comment #3)
And what with such example:
#include stdio.h
#pragma pack(4)
struct ABC
{
double a;
int b;
bool c;
};
void Init(double a)
{ a = 17.0; }
int main()
{
ABC A;
ABC
--- Comment #4 from tobi at gcc dot gnu dot org 2006-09-14 10:59 ---
The difference is that 'end' appears in other contexts, see e.g. the difference
between these two testcases:
[EMAIL PROTECTED]:~/src/pr/28526 cat t.f90
module m
public function
interface function
module
I would like the following snippet to crash due to bounds checking. Instead, it
prints a garbage value.
#include stdio.h
#include vector
using std::vector;
main ()
{
vectorint x;
x.push_back(5);
x.pop_back();
printf (%d\n, x.back ());
}
--
Summary:
--- Comment #1 from pcarlini at suse dot de 2006-09-14 11:14 ---
In order to catch this kind of run-time problem you want debug-mode: just
recompile your code with -D_GLIBCXX_DEBUG.
--
pcarlini at suse dot de changed:
What|Removed |Added
This code produces this output:
struct s {
unsigned x : 16;
};
int f(struct s *node)
{
int a = 0;
do
a++;
while ((--node)-x == a);
return a;
}
li r2,0
L2:
lhzu r0,-4(r3)
addi r2,r2,1
rlwinm r0,r0,0,0x
cmpw cr7,r0,r2
beq+ cr7,L2
--- Comment #1 from bonzini at gnu dot org 2006-09-14 12:07 ---
The sole difference in the IR is
;; if ((int) node-x == a) goto L0; else (void) 0;
(insn 19 18 20 (set (reg:HI 125)
(mem/s/j:HI (reg/v/f:SI 123 [ node ])
[2 variable.x+0 S2 A32])) -1 (nil)
;; if
--- Comment #2 from zadeck at naturalbridge dot com 2006-09-14 12:51
---
Subject: Re: useless clrlwi instruction produced for 16-bit
bitfield
bonzini at gnu dot org wrote:
--- Comment #1 from bonzini at gnu dot org 2006-09-14 12:07 ---
The sole difference in the IR is
--- Comment #4 from patchapp at dberlin dot org 2006-09-14 13:00 ---
Subject: Bug number pr21061
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/2006-09/msg00551.html
--
#include utility
template typename T struct X { };
struct A
{
void f( X std::pair int, int v = X std::pair int, int () );
};
$ g++ tmp.cpp -Wall -c
tmp.cpp:5: error: expected #8216;,#8217; or #8216;...#8217; before
#8216;#8217; token
tmp.cpp:5: error: wrong number of template
--- Comment #1 from pluto at agmk dot net 2006-09-14 13:49 ---
reduced testcase:
template typename T struct X { };
template typename T, typename U struct Y { };
struct A
{
void f( X Y int, int v = X Y int, int () );
};
tmp.cpp:5: error: expected #8216;,#8217; or
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-14 14:56 ---
(In reply to comment #5)
(In reply to comment #3)
And what with such example:
#include stdio.h
#pragma pack(4)
struct ABC
{
double a;
int b;
bool c;
};
void Init(double a)
{ a = 17.0; }
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-14 14:59 ---
There is a Defect report about the comma in default arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29084
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-14 15:00 ---
In fact this is a dup of bug 57 which is still SUSPENDED because the defect
report has not been resolved yet.
*** This bug has been marked as a duplicate of 57 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #31 from pinskia at gcc dot gnu dot org 2006-09-14 15:00
---
*** Bug 29084 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-09-14
15:23 ---
module m
public function
interface function
module procedure foo4
end interface
contains
subroutine foo4
end subroutine foo4
function foo5
foo5 = 0
end function foo5
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-14 15:33 ---
This is invalid code, 3.3.3 and before gave the following error:
t.cc: In function `void function()':
t.cc:13: error: `Base' is an ambiguous base of `Join'
Which is correct.
Also we don't get an ICE if we try with
### How to create bug situation.
[EMAIL PROTECTED]:~/code/test$ ls
q.c stable.h w.c
[EMAIL PROTECTED]:~/code/test$ cat stable.h
namespace {
int qwerty;
}
[EMAIL PROTECTED]:~/code/test$ cat q.c
#include stable.h
int main(){return 0;}
[EMAIL PROTECTED]:~/code/test$ cat w.c
#include stable.h
--- Comment #2 from raymond at corvil dot com 2006-09-14 15:58 ---
Line 13 in the sample code is invalid code but line 14 is valid (Base is an
unambiguous base class of Left). Deleting line 13 leaves code that compiles
cleanly with gcc-3.3.5 (i386-portbld-freebsd4.8, gcc version 3.3.5
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-14 16:01 ---
This is a dup of bug 10591 which will be fixed with the release of 4.2.0.
*** This bug has been marked as a duplicate of 10591 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #26 from pinskia at gcc dot gnu dot org 2006-09-14 16:01
---
*** Bug 29085 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2006-09-14 16:45 ---
Have developed the above patch a tad and intend to submit tonight
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
the exact version of GCC is 4.1.1
the system type is sparc-sun-solaris2.8
the options given when GCC was configured/built:
--prefix=/tmp/local/unixutil/gcc-4.1.1
--with-local-prefix=/usr/local/myCompanyName
(myCompanyName is not the exact wording)
(also, there is a symlink
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-09-14 17:54 ---
(In reply to comment #8)
There might be problems if no matching set can be found in the current
basic block. I'll have to think about how to best check for this.
I'm currently leaning to add a field in struct
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-09-14 18:03
---
Created an attachment (id=12267)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12267action=view)
current patch incarnation (still testing)
At any rate, I must not set SCHED_GROUP_P on the first insn of a
--- Comment #6 from tromey at gcc dot gnu dot org 2006-09-14 18:06 ---
Subject: Bug 29068
Author: tromey
Date: Thu Sep 14 18:06:04 2006
New Revision: 116948
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116948
Log:
libjava
PR boehm-gc/29068:
* boehm.cc
--- Comment #7 from tromey at gcc dot gnu dot org 2006-09-14 18:07 ---
Fix checked din.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-14 18:36 ---
No feedback in 3 months.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2006-09-14 20:05 ---
Iguchi-san and Tobi,
This has proven to be an absorbing bug and is indicative of a rather serious
malaise in the gfortran parser. As I surmised in the previous comment, it is
the assignments that are the culprits.
In gcc/cp/typeck.c there are these messages:
pedwarn (ISO C++ forbids %sing an enum,
(code == PREINCREMENT_EXPR || code == POSTINCREMENT_EXPR)
? increment : decrement);
error (cannot %s a pointer to incomplete type %qT,
((code == PREINCREMENT_EXPR
|| code ==
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-14 20:40 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from aesok at gcc dot gnu dot org 2006-09-14 21:11 ---
Subject: Bug 26504
Author: aesok
Date: Thu Sep 14 21:11:33 2006
New Revision: 116950
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116950
Log:
PR target/26504
* config/avr/avr.h
--- Comment #3 from kazu at gcc dot gnu dot org 2006-09-14 21:15 ---
Subject: Bug 28884
Author: kazu
Date: Thu Sep 14 21:15:12 2006
New Revision: 116951
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116951
Log:
PR middle-end/28884.
* doc/tm.texi
--- Comment #4 from kazu at gcc dot gnu dot org 2006-09-14 21:15 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from aesok at gcc dot gnu dot org 2006-09-14 21:19 ---
Subject: Bug 26504
Author: aesok
Date: Thu Sep 14 21:19:10 2006
New Revision: 116952
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116952
Log:
PR target/26504
* config/avr/avr.h
--- Comment #16 from aesok at gcc dot gnu dot org 2006-09-14 21:39 ---
Change Status to FIXED.
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from amylaar at gcc dot gnu dot org 2006-09-14 21:43
---
(In reply to comment #10)
Created an attachment (id=12267)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12267action=view) [edit]
current patch incarnation (still testing)
At any rate, I must not set
--- Comment #9 from sje at cup dot hp dot com 2006-09-14 22:37 ---
I don't see any way to delete a block without deleting the attached jumptable
so the only fix I can see is to not delete the block in the first place. The
block is being deleted on IA64 because it is a 'then block' on
I see a number of failures in the gcc.dg-struct-layout-1 testcases when
executed after
being compiled at -m64. The exact failures are listed at...
http://gcc.gnu.org/ml/gcc/2006-09/msg00211.html
I have modified gcc.dg/compat/struct-layout-1_test.h to just contain...
T(94,struct atal16{}a;,)
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-09-14
22:54 ---
Created an attachment (id=12268)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12268action=view)
preprocessed file for struct-layout-1_x.c generated on Darwin PPC at -m64
--
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-14
22:55 ---
Created an attachment (id=12269)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12269action=view)
assembly file for struct-layout-1_x.c generated on Darwin PPC at -m64
--
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2006-09-14
22:56 ---
Created an attachment (id=12270)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12270action=view)
preprocessed file for struct-layout-1_y.c generated on Darwin PPC at -m64
--
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2006-09-14
22:56 ---
Created an attachment (id=12271)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12271action=view)
assembly file for struct-layout-1_y.c generated on Darwin PPC at -m64
--
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2006-09-14
22:57 ---
Created an attachment (id=12272)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12272action=view)
preprocessed file for struct-layout-1_main.c generated on Darwin PPC at -m64
--
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-09-14
22:58 ---
Created an attachment (id=12273)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12273action=view)
assembly file for struct-layout-1_main.c generated on Darwin PPC at -m64
--
Testcase:
#include stdlib.h
__attribute__((vector_size(16))) int a = {1, 2};
int main(void)
{
int *b = (int*)a;
if (b[0] != 1)
abort ();
if (b[1] != 2)
abort ();
if (b[2] != 0)
abort ();
if (b[3] != 0)
abort ();
return 0;
}
The VECTOR_CST has only two elements.
Testcase:
#define vector __attribute__((vector_size(16)))
vector int a = (vector int){1, 2, 0, 0};
If I used a typedef instead, it works.
--
Summary: vector int a = (vector int) { 1,1,2,2} is rejected as
non constant
Product: gcc
Version:
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2006-09-14
23:03 ---
I forget to mention the other build command of...
sw/src/fink.build/gcc4-4.1.999-20060911/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.999-20060911/darwin_objdir/gcc/ -w
-DSKIP_DECIMAL_FLOAT
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-14 23:05 ---
(In reply to comment #0)
If I used a typedef instead, it works.
In that the following works:
typedef vector int vec_int;
vec_int a = (vec_int){1, 2, 0, 0};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29092
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-14 23:07 ---
The C++ front-end produces:
a:
.long 1
.long 2
.zero 8
While the C front-end does not have .zero there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29091
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2006-09-14
23:10 ---
FYI, as a stab in the dark, I tried re-executing each of the build commands
above with -fno-common and that doesn't eliminate the abort on the test case.
--
--- Comment #21 from jason at gcc dot gnu dot org 2006-09-14 23:13 ---
Subject: Bug 28493
Author: jason
Date: Thu Sep 14 23:13:30 2006
New Revision: 116955
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116955
Log:
PR middle-end/28493
* builtins.c
--- Comment #6 from tromey at gcc dot gnu dot org 2006-09-14 23:19 ---
I think the PR 13212 fix probably fixed this on svn trunk.
Can one of you try that?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
The testcase gcc.dg/debug/dwarf2/dwarf-file1.c fails on i686 (and others)
GNU/Linux:
http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00664.html
http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00663.html
http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00662.html
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-14 23:57 ---
In fact it fails on all targets that have DWARF2_ASM_LINE_DEBUG_INFO as true.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2006-09-15
01:32 ---
Andrew,
To answer my own question, the following is from tonight's gcc make check
using the original
version of your patch which only impacted the
rs6000_darwin64_record_arg_advance_recurse...
This testcase:
/* f.c */
extern double exp (double);
extern float strtof(const char*, char**);
inline float expf (float x)
{return (float) exp (x);}
int main (int argc, char** argv)
{
float f;
if (argc 1)
{
f = strtof (argv[1], (void*)0);
printf (%g\n, expf(f));
}
return
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2006-09-15
02:40 ---
Created an attachment (id=12274)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12274action=view)
Patch to fix PR29030
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
--
bdavis at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot
|dot org
--- Comment #4 from patchapp at dberlin dot org 2006-09-15 03:00 ---
Subject: Bug number PR29053
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/2006-09/msg00571.html
--
--- Comment #2 from bdavis at gcc dot gnu dot org 2006-09-15 03:01 ---
This problem is very intriguing. For a first attempt I plan on adding a splay
tree to constructors that need 'by element' access. This may allow this
problem to be taken care of without changing every routine that
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-15 03:21 ---
Is TARGET_C99_FUNCTIONS set for the mingw32 target?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-09-15
03:34 ---
(In reply to comment #1)
Is TARGET_C99_FUNCTIONS set for the mingw32 target?
It is set in my local development tree, and I was planning to set it in
mingw32.h config file, but I may be a bit
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-15 03:42 ---
(In reply to comment #2)
It is set in my local development tree, and I was planning to set it in
mingw32.h config file, but I may be a bit premature :(
If you are defining expf with TARGET_C99_FUNCTIONS set to 1,
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-09-15
03:51 ---
(In reply to comment #3)
If you are defining expf with TARGET_C99_FUNCTIONS set to 1, then you have to
use -fno-builtin-exp.
So just to make sure this is with TARGET_C99_FUNCTIONS set to 1?
Yes.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-15 04:06 ---
This is not a bug in GCC. There is no benifit for the user if
TARGET_C99_FUNCTIONS is defined and the C99 math functions are just wrappers
around the C89 functions. Really TARGET_C99_FUNCTIONS is only used for
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-09-15 04:37
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-15 04:50 ---
Subject: Bug 29002
Author: pinskia
Date: Fri Sep 15 04:50:04 2006
New Revision: 116962
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116962
Log:
2006-09-14 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-15 04:50 ---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-15 05:31 ---
Janis could you do a regression hunt on this bug?
Thanks.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
:
unix/-m32
unix/-m64
Running target unix/-m32
Running
/sw/src/fink.build/gcc4-4.1.999-20060914/gcc-4.2-20060914/gcc/testsuite/gcc.dg/dg.exp
...
PASS: gcc.dg/array-9.c (test for errors, line 7)
PASS: gcc.dg/array-9.c (test for excess errors)
=== gcc Summary for unix/-m32
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||3.3.3 3.4.0 4.0.0 4.1.0
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-15 05:35 ---
3.2.3 on x86 with -msse (since we did not have generic vectors until 3.3)
works.
And 3.3.3 fails (even with -msse).
Note a better testcase is something like:
#include stdlib.h
__attribute__((vector_size(16))) int a
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-15 05:40 ---
This is most likely an ABI issue where one side of the function call thinks one
thing and the other side thinks another about placement of the arguments. This
shows up a lot in the darwin back-end even in 32bit
94 matches
Mail list logo
