_mm_cvtpi32x2_ps in xmmintrin.h could be made more efficient. the existing
version:
static __inline __m128 __attribute__((__always_inline__))
_mm_cvtpi32x2_ps(__m64 __A, __m64 __B)
{
__v4sf __zero = (__v4sf) _mm_setzero_ps ();
__v4sf __sfa = __builtin_ia32_cvtpi2ps (__zero, (__v2si)__A);
__v4
--- Comment #3 from jaco at kroon dot co dot za 2006-09-15 06:21 ---
Ok. My understanding of CXX ABI isn't that great. Some would say "I just code
with C/C++" but I also happen to know that that isn't true. Take what I say
here as "I'm a user of C/C++ and my understanding of everythin
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-15 06:12 ---
(In reply to comment #1)
The other thing is that I think this is a regression from when the ARM eabi
support was added.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-15 06:08 ---
Actually we have to becareful here.
What does the IA64 C++ ABI say about the arguments types to __cxa_vec_new, is
__cxa_cdtor_type really extern "C" or did they forget to specify the language
linkage?
--
pinskia
#ifdef __cplusplus
namespace __cxxabiv1
{
typedef __cxa_cdtor_return_type (*__cxa_cdtor_type)(void *);
extern "C"
{
#endif
// Allocate array.
void*
__cxa_vec_new(size_t __element_count, size_t __element_size,
size_t __padding_size, __cxa_cdtor_type constructor,
--- 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 mode
--- 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
__attribute__((vector_size(16))) int a = {1, 2};
--
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
|
:
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
--- 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
---
--- 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 #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=gcc&view=rev&rev=116962
Log:
2006-09-14 Andrew Pinski <[EMAIL PROTECTED]>
PR C
--- 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
Status|ASSIGNE
--- 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
opti
--- 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 #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 #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 prematur
--- 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 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 u
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--
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 #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=12274&action=view)
Patch to fix PR29030
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
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 #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...
Executi
--- 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
---
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
http://gcc.gnu.org/ml/gcc-testresu
--- 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
---
--- 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=gcc&view=rev&rev=116955
Log:
PR middle-end/28493
* builtins.c (expand_builtin
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- 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 #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 #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 -fno-s
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: 4.
Testcase:
#include
__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.
--
--- 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=12273&action=view)
assembly file for struct-layout-1_main.c generated on Darwin PPC at -m64
--
http://gcc.gnu.org/bu
--- 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=12272&action=view)
preprocessed file for struct-layout-1_main.c generated on Darwin PPC at -m64
--
http://gcc.gnu.or
--- 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=12271&action=view)
assembly file for struct-layout-1_y.c generated on Darwin PPC at -m64
--
http://gcc.gnu.org/bugzi
--- 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=12270&action=view)
preprocessed file for struct-layout-1_y.c generated on Darwin PPC at -m64
--
http://gcc.gnu.org/b
--- 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=12269&action=view)
assembly file for struct-layout-1_x.c generated on Darwin PPC at -m64
--
http://gcc.gnu.org/bugzi
--- 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=12268&action=view)
preprocessed file for struct-layout-1_x.c generated on Darwin PPC at -m64
--
http://gcc.gnu.org/b
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;,)
an
--- 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 an
--- 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=12267&action=view) [edit]
> current patch incarnation (still testing)
>
> At any rate, I must not se
--- 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
St
--- 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=gcc&view=rev&rev=116952
Log:
PR target/26504
* config/avr/avr.h (FRAME_POINTE
--- 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
Stat
--- 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=gcc&view=rev&rev=116951
Log:
PR middle-end/28884.
* doc/tm.texi (TARGET_FUNCTION
--- 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=gcc&view=rev&rev=116950
Log:
PR target/26504
* config/avr/avr.h (FRAME_POINTE
--- 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
Status|UNCON
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 #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.
--- 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 #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
Status|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=gcc&view=rev&rev=116948
Log:
libjava
PR boehm-gc/29068:
* boehm.cc (_Jv_GCAt
--- 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=12267&action=view)
current patch incarnation (still testing)
At any rate, I must not set SCHED_GROUP_P on the first insn of a sc
--- 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 s
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 /tmp/local/unix
--- 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
-
--- 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 #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 #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 2
### 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 #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 a
--- 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 functio
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
-
--- 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 #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 #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
> #pragma pack(4)
> struct ABC
> {
> double a;
> int b;
> bool c;
> };
> void Init(double& a)
> { a = 17
--- 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 ‘,’ or ‘...’
#include
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 ‘,’ or ‘...’ before
‘>’ token
tmp.cpp:5: error: wrong number of template arguments (1, should be 2)
/usr/i
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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 #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 ; else (void) 0;
(insn 19 18 20 (set (reg:HI 125)
(mem/s/j:HI (reg/v/f:SI 123 [ node ])
[2 .x+0 S2 A32])) -1 (nil)
;; if ((int) MEM
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 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
--
I would like the following snippet to crash due to bounds checking. Instead, it
prints a garbage value.
#include
#include
using std::vector;
main ()
{
vector x;
x.push_back(5);
x.pop_back();
printf ("%d\n", x.back ());
}
--
Summary: std::vector::back() does no bou
--- 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 proce
--- 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
#pragma pack(4)
struct ABC
{
double a;
int b;
bool c;
};
void Init(double& a)
{ a = 17.0; }
int main()
{
ABC A;
ABC B;
i
Compiling a .cpp file with the following contents triggers an internal compiler
error:
<<
struct Base {
template void method() { }
};
struct Left : public Base { };
struct Right: public Base { };
struct Join : public Left, publi
--- 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 scri
--- 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, o
--- 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.
--
http://gcc.gnu.org/bugzill
--- 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=12266&action=view)
work around
With some "*1" added, compilation pass !?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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) :-)
--
dsi
--- 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=12265&action=view)
Patch to provide the shape of the SPREAD intrinsic + testcase
(In reply to comment #1)
> Yes, it ap
--- 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 #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 #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=12264&action=view)
tar.bz2 containing logfiles for ICE using HP 'cc -O2'
configure.out: Output of 'configure'
boots
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./ -B/usr/local
--- 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, wro
--- 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
>---
>#pragm
--- 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 cha
Simple testcase:
#include
#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 and
--- 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 rwth-a
95 matches
Mail list logo
