--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-18 06:34 ---
Subject: Bug 33231
Author: burnus
Date: Tue Sep 18 06:34:30 2007
New Revision: 128570
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128570
Log:
2007-09-18 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-18 06:34 ---
FIXED on the trunk (4.3).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinakee dot b at xius dot com 2007-09-18 07:05 ---
Created an attachment (id=14218)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14218action=view)
The attachment is the zip of preprocessed file of the source file.
Since the file size was more than that
--- Comment #23 from rask at gcc dot gnu dot org 2007-09-18 07:14 ---
configure:10398: error: unrecognizable insn:
(insn 105 104 106 2 (set (subreg:QI (reg/f:HI 52) 0)
(subreg:QI (label_ref:HI 57) 0)) -1 (nil))
configure:10398: internal compiler error: in extract_insn, at
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-18 08:26
---
This is because, in gfc_use_derived (symbol.c), when checking whether a derived
type is in the current unit or a parent unit, we check (sym-components !=
NULL) and if it's true, we take it to mean that the
--- Comment #11 from rguenther at suse dot de 2007-09-18 08:44 ---
Subject: Re: [4.1/4.2/4.3 Regression] g++-4.1: out of memory
with -O1/-O2
On Tue, 18 Sep 2007, alexander at kogan dot nnov dot ru wrote:
--- Comment #10 from alexander at kogan dot nnov dot ru 2007-09-18 04:58
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-18 08:46 ---
Subject: Bug 33340
Author: rguenth
Date: Tue Sep 18 08:46:23 2007
New Revision: 128571
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128571
Log:
2007-09-18 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from alexander at kogan dot nnov dot ru 2007-09-18 09:07
---
What do u mean 'not completely'?
Can I try this fix?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #13 from rguenther at suse dot de 2007-09-18 09:11 ---
Subject: Re: [4.1/4.2/4.3 Regression] g++-4.1:
out of memory with -O1/-O2
On Tue, 18 Sep 2007, alexander at kogan dot nnov dot ru wrote:
--- Comment #12 from alexander at kogan dot nnov dot ru 2007-09-18 09:07
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-18 09:19 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Gcc's friend-mechanism seems to expand to nested classes as well, although
the C++ standard explicitly tells differently.
The following example is almost straight from the C++ standard (11.4/2). The
only change is that inheritance is commented out for class X (in order to
remove the first error
Following a discussion on IRC with FX Coudert, I think the number of digits
printed by default in formatted output should be increased by one. Otherwise
the logic of the test case large_real_kind_form_io_2.f90 is flawed as shown by
the attached code. Its output on AMD64 is
real(4)
default
--- Comment #14 from alexander at kogan dot nnov dot ru 2007-09-18 09:55
---
Ok. Do you mean the attached test doesn't work even with this fix? But are
there plans to eliminate this problem completely?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #1 from dominiq at lps dot ens dot fr 2007-09-18 09:47 ---
Created an attachment (id=14219)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14219action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33469
The following code compiles cleanly with 4.2.1. The expected output is C but
the executable outputs B.
#include iostream
using namespace std;
struct A
{
virtual ~A() { }
virtual void f() { cout A; }
};
struct B : public A
{
virtual void f() { cout B; }
};
struct C :
--- Comment #1 from pcarlini at suse dot de 2007-09-18 10:55 ---
Janis, is it possible to have a regression hunt? Thanks in advance.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #15 from rguenther at suse dot de 2007-09-18 10:58 ---
Subject: Re: [4.1/4.2/4.3 Regression] g++-4.1:
out of memory with -O1/-O2
On Tue, 18 Sep 2007, alexander at kogan dot nnov dot ru wrote:
--- Comment #14 from alexander at kogan dot nnov dot ru 2007-09-18 09:55
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-09-18 11:22
---
Subject: Bug 31863
Author: rguenth
Date: Tue Sep 18 11:22:47 2007
New Revision: 128573
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128573
Log:
2007-09-18 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-18 11:31
---
(In reply to comment #2)
One thing that comes to mind is the following patch. It allows derived types
with zero components to be accepted, but I fear that it might make us accept
invalid code with empty
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-18 11:00 ---
No, B is correct.
A Aref = Binst;
Aref = Cinst;
is the same as:
Binst = (A)Cinst;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-09-18 11:58
---
Note that the double virtual inheritance in the Serializer template creates the
exponential behavior. You can fix this at the source level by instead
doing
template class Key, class Head
class SerializerKey,
--- Comment #2 from photon at seznam dot cz 2007-09-18 12:01 ---
(In reply to comment #1)
No, B is correct.
A Aref = Binst;
Aref = Cinst;
is the same as:
Binst = (A)Cinst;
Binst = (A)Cinst would not compile (C is not derived from B).
--
photon at seznam
--- Comment #1 from bero at arklinux dot org 2007-09-18 12:26 ---
Created an attachment (id=14220)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14220action=view)
bzip2-ed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33471
Granted, the compiler flags I've used for testing are asking for trouble...
$ gcc -march=pentium4 -mfpmath=sse,387 -o mplayer.o mplayer.i
mplayer.c: In function 'main':
mplayer.c:3750: error: unrecognizable insn:
(insn 5170 5169 5171 674 mplayer.c:3552 (set (reg:SF 258 [ D.19380 ])
This bug happens on a cross-compiler targetting x86_64-pc-mingw32, but not on a
native x86_64-linux compiler. Both compilers are built with SVN trunk from the
same revision (128540).
Witn -m64, it doesn't error out at -O0, there is an ICE at -O1 and a different
error at -O2. With -m32,
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-18 12:56 ---
We substitute into the invariant address retval.a[0] *this, which results
in a non-invariant address.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-09-18 13:16
---
I can still see the ICE with -O2 -ftree-loop-linear and the testcase from
comment
2 on trunk (x86_64):
t.i: In function 'lsp_weight_quant':
t.i:3: internal compiler error: in lambda_loopnest_to_gcc_loopnest, at
--- Comment #2 from rask at gcc dot gnu dot org 2007-09-18 13:26 ---
Fixed as of revision 128577.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-18 13:02 ---
Still fails.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-09-18 13:17
---
Sebastian, can you have a look at this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-18 13:25 ---
Subject: Bug 33388
Author: rask
Date: Tue Sep 18 13:24:44 2007
New Revision: 128577
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128577
Log:
PR target/33388
PR target/33397
*
--- Comment #1 from rask at gcc dot gnu dot org 2007-09-18 13:25 ---
Subject: Bug 33397
Author: rask
Date: Tue Sep 18 13:24:44 2007
New Revision: 128577
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128577
Log:
PR target/33388
PR target/33397
*
--- Comment #4 from rask at gcc dot gnu dot org 2007-09-18 13:28 ---
Fixed with revision 128577.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-18 13:34 ---
With bug 33388 and bug 33397 fixed, the fix for bug 32154 fixes this one as
well (as of revision 128577).
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rswan at signetic dot ca 2007-09-18 13:38 ---
Created an attachment (id=14221)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14221action=view)
testcase archive
Extract archive. Invoke make within gch_bug directory. Bug seen in generated
main.d dependency
--- Comment #3 from ubizjak at gmail dot com 2007-09-18 13:48 ---
Insn constraint for following insn should be fixed:
(define_insn *floatdimode2_i387
[(set (match_operand:MODEF 0 register_operand =f,f)
(float:MODEF
(match_operand:DI 1 nonimmediate_operand m,?r)))]
Hello;
GCC does not correctly generate dependencies correctly with g++ -MD when
precompiled headers are used. I've attached an example which generates main.d
while compiling main.cpp. main.cpp includes include/bink.h. When the include
path contains the precompiled bink.h.gch (only), main.d does
--- Comment #2 from ubizjak at gmail dot com 2007-09-18 13:40 ---
Caused by X86_USE_VECTOR_CONVERTS or X86_TUNE_INTER_UNIT_CONVERSIONS patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2007-09-18 14:03 ---
Sorry, this is already fixed in latest SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from paolo at gcc dot gnu dot org 2007-09-18 14:35 ---
Subject: Bug 33464
Author: paolo
Date: Tue Sep 18 14:35:42 2007
New Revision: 128578
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128578
Log:
/cp
2007-09-18 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #2 from pcarlini at suse dot de 2007-09-18 14:36 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #3 from photon at seznam dot cz 2007-09-18 15:12 ---
(In reply to comment #1)
No, B is correct.
A Aref = Binst;
Aref = Cinst;
is the same as:
Binst = (A)Cinst;
The compiler treats this case as Ainst = (A) Cinst.
--
photon at seznam dot cz
--- Comment #1 from paolo at gcc dot gnu dot org 2007-09-18 15:38 ---
Subject: Bug 33463
Author: paolo
Date: Tue Sep 18 15:38:02 2007
New Revision: 128582
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128582
Log:
/cp
2007-09-18 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #2 from pcarlini at suse dot de 2007-09-18 15:40 ---
Fixed in mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini
--- Comment #1 from jakub at gcc dot gnu dot org 2007-09-18 15:34 ---
--- gcc/cp/error.c.jj 2007-09-11 12:43:28.0 +0200
+++ gcc/cp/error.c 2007-09-18 17:25:14.0 +0200
@@ -2054,6 +2054,15 @@ dump_expr (tree t, int flags)
dump_type (t, flags);
break;
--- Comment #2 from pcarlini at suse dot de 2007-09-18 15:39 ---
Thanks a lot Jakub, I'm going to do exactly that but as part of
cxx_pretty_print.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33462
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2007-09-18
15:59 ---
Confirmed.
Also breaks bootstrap if CFLAGS is set to -O3.
I couldn't reproduce this with 4.1 so reported against = 4.1.0 is probably
typo.
Can be reproduced in a cross compiler.
--
belyshev at depni
Build failure in target libiberty:
/home/rask/build/gcc-bfin-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-bfin-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/targ-include
On 18 Sep 2007 15:34:16 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
+case VA_ARG_EXPR:
+ pp_cxx_identifier (cxx_pp, __builtin_va_arg);
I would not use __builtin_va_arg here since this diagnostic, I would
just use va_arg.
Thanks,
Andrew Pinski
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-18 16:40 ---
Subject: Re: [4.1/4.2/4.3 regression] Broken diagnostic: 'va_arg_expr' not
supported by dump_expr
On 18 Sep 2007 15:34:16 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
+case VA_ARG_EXPR:
+
--- Comment #3 from william dot adams at dot dot state dot fl dot us
2007-09-18 17:24 ---
4.2.1 had other build problems.
but this particular one appeared after i upgraded binutils to 2.18.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-18 17:56 ---
confirmed.
The problem is found in decl.c(top_val_list) at lines 404-411, which
are
signed int tmp;
msg = gfc_extract_int (expr, tmp);
gfc_free_expr (expr);
if (msg != NULL)
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-18 17:56 ---
A compiler comparison:
real(4) gfortran g95 NAGf95 ifort sunf95 openf95
default 808 0808 808 0 0
1PG20.6 18811881 1881 1881 18811881
1PG20.7 808 808808 808 808
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
--- Comment #4 from paolo at gcc dot gnu dot org 2007-09-18 18:05 ---
Subject: Bug 33462
Author: paolo
Date: Tue Sep 18 18:05:40 2007
New Revision: 128584
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128584
Log:
/cp
2007-09-18 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #5 from pcarlini at suse dot de 2007-09-18 18:06 ---
Fixed in mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
--- Comment #1 from pcarlini at suse dot de 2007-09-18 18:29 ---
*** This bug has been marked as a duplicate of 33477 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2007-09-18 18:29 ---
*** Bug 33478 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33477
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 18:02 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 05:56:36PM -, kargl at gcc dot gnu dot org wrote:
The problem is found in decl.c(top_val_list) at
As noted in:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00818.html
With this configuration:
../trunk/configure --prefix=/home/ddaney/gccsvn/trunk-install
--target=mipsel-linux --build=mipsel-linux --host=mipsel-linux
--with-gmp=/home/ddaney/mp --with-mpfr=/home/ddaney/mp --with-arch=sb1
--- Comment #1 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** This bug has been marked as a duplicate of 33475 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** Bug 33476 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
--- Comment #1 from bangerth at dealii dot org 2007-09-18 18:59 ---
Confirmed.
A simpler to understand testcase is this one (all crud removed):
-
class A {
class B { };
friend class X;
};
class X {
A::B mx;
class Y : A::B {
A::B my;
};
};
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
--- Comment #4 from bangerth at dealii dot org 2007-09-18 18:48 ---
To be quite clear: you can re-associate references (unlike pointers), so
when you do Ainst = Cinst, you copy the A-part of Cinst, but you still have
a 'B' whose 'A' component has just been overwritten.
W.
--
--- Comment #2 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** This bug has been marked as a duplicate of 33475 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-09-18 18:47 ---
No this is not fixed. The error message is incorrect. Most users will not use
__builtin_va_arg directly, they will be using va_arg. So when they see
__builtin_va_arg, it will confuse them. Can you please change
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.
During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived
--- Comment #2 from bangerth at dealii dot org 2007-09-18 18:41 ---
*** Bug 33477 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
--- Comment #1 from daney at gcc dot gnu dot org 2007-09-18 18:48 ---
SyncTest never completes. When it gets into this state the threads are in the
followin state:
(gdb) thread 6
[Switching to thread 6 (Thread 758265024 (LWP 29566))]#0 0x2ce68fac in
pthread_cond_wait@@GLIBC_2.3.2 ()
--- Comment #1 from pcarlini at suse dot de 2007-09-18 19:04 ---
*** This bug has been marked as a duplicate of 33475 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2007-09-18 19:04 ---
*** Bug 33481 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
--- Comment #8 from bangerth at dealii dot org 2007-09-18 19:13 ---
This works with a snapshot from yesterday.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-09-18 19:16 ---
Can you try to come up with an example that is self-contained,
i.e. only contains those parts of the Tiny Vector Matrix library
that are really used (or none at all)?
W.
--
bangerth at dealii dot org changed:
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 19:16 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 06:02:03PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
The problem is found in
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 19:26 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 07:16:42PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
Ugh. I have a patch that would
--- Comment #7 from pcarlini at suse dot de 2007-09-18 19:06 ---
If Gaby agree with that change, I'm ok with it.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #24 from eweddington at cso dot atmel dot com 2007-09-18 19:06
---
Subject: RE: [avr-gcc] Optimization decrease performance of
struct assignment.
--- Comment #23 from rask at gcc dot gnu dot org
In define_insn_and_split *movhi, add the line
LABEL_REF !=
--- Comment #4 from pcarlini at suse dot de 2007-09-18 19:04 ---
*** Bug 33480 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|x86_64-suse-linux-gnu |
GCC host triplet|x86_64-suse-linux-gnu |
GCC target
--- Comment #1 from pcarlini at suse dot de 2007-09-18 19:04 ---
*** This bug has been marked as a duplicate of 33475 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #8 from paolo at gcc dot gnu dot org 2007-09-18 19:42 ---
Subject: Bug 33462
Author: paolo
Date: Tue Sep 18 19:42:42 2007
New Revision: 128585
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128585
Log:
cp/
2007-09-18 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #25 from rask at gcc dot gnu dot org 2007-09-18 19:49 ---
c:/avrdev/gcc/gcc-4.3-20070914/libobjc/Object.m:66: error: unrecognizable
insn:
(insn 54 4 55 2 c:/avrdev/gcc/gcc-4.3-20070914/libobjc/Object.m:65 (set
(reg:QI 22 r22 [ D.2345 ])
(subreg:QI (const:HI
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 20:07 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 07:26:22PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
If I'm not mistaken, this will
Testcase (test1.c):
#include emmintrin.h
__m128i test_fn1(__m128i x)
{
__m128i y;
return _mm_srl_epi64(x,_mm_set_epi32(0,0,31,31));
}
gcc -O1 -c test1.c
/tmp/ccBc8BO7.s: Assembler messages:
/tmp/ccBc8BO7.s:7: Error: suffix or operands invalid for `psrlq'
gcc -O1 -S test1.s
test_fn1:
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-18 21:03
---
(In reply to comment #6)
FX, which version of gfortran are you using? I cannot reproduce it (with
valgrind) under x86_64-openSUSE-10.3b3 with today's gfortran 4.3 (Rev. 128538)
- neither for -m32 nor -m64.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-18 21:25
---
Subject: Bug 31119
Author: fxcoudert
Date: Tue Sep 18 21:25:40 2007
New Revision: 128587
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128587
Log:
PR fortran/31119
* trans-array.c
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-18 21:34
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-09-18 21:54 ---
These all appear to be fails from missing C99 math functionality: tanl, etc.
So, maybe something with libmath config, config for C99 functions?
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-18
22:24 ---
Subject: Re: FAIL: abi_check
So, maybe something with libmath config, config for C99 functions?
Think so, I see asinf isn't found, yet it's there. I'm going
to remove -j 2 from my make script. That
--- Comment #2 from Hans dot Boehm at hp dot com 2007-09-18 22:26 ---
I assume the LOCKED bit in *he is actually set when gdb looks at it? What does
the rest of the hash entry look like? That might give you a hint as to the
culprit.
Clearly someone sets the LOCKED bit on a hash entry
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-18 22:49 ---
Subject: Bug 32822
Author: bkoz
Date: Tue Sep 18 22:49:24 2007
New Revision: 128589
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128589
Log:
2007-09-17 Benjamin Kosnik [EMAIL PROTECTED]
Chalathip
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-18 22:49 ---
Subject: Bug 32819
Author: bkoz
Date: Tue Sep 18 22:49:24 2007
New Revision: 128589
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128589
Log:
2007-09-17 Benjamin Kosnik [EMAIL PROTECTED]
Chalathip
1 - 100 of 123 matches
Mail list logo
