--- Comment #5 from laurent at guerby dot net 2009-01-02 12:51 ---
4.3.2-1 debian gnueabi and trunk rev 142984 do not ICE, waiting for
confirmation.
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #7 from q at ping dot be 2009-01-02 13:00 ---
Created an attachment (id=17021)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17021action=view)
Reduced test case part 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38660
--- Comment #8 from q at ping dot be 2009-01-02 13:01 ---
Created an attachment (id=17022)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17022action=view)
Reduced test case part 2
--
q at ping dot be changed:
What|Removed |Added
--- Comment #9 from q at ping dot be 2009-01-02 13:04 ---
I've reduced the test case. The call to siglongjmp() needs to be in a separate
file.
When the problem occurs the test program returns exit code 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38660
On 4.3.2-1 debian gnueabi:
gue...@gcc50:~$ gcc
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c -O0
-frtl-abstract-sequences
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c: In function
foo:
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c:35:
--- Comment #1 from laurent at guerby dot net 2009-01-02 13:17 ---
Similar failure for another test:
Executing on host: /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c -Os
-frtl-abstract-sequences
4.3.2 works at -O0/1/2/3 but trunk at rev 142984 works at -O0 and fail at
-O1/2/3
gue...@gcc50:~$ /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/ -O1 -w -c -o pr37433.o
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr37433.c
GCC 4.3.2-1 debian gnueabi and trunk at rev 142984 generate wrong code at -O2
and above for pr37868.c
gue...@gcc50:~$ /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/
/home/guerby/trunk/gcc/testsuite/gcc.dg/torture/pr37868.c -O2 -lm -o
./pr37868.exegue...@gcc50:~$
As shown on http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00092.html
neon tests scanning for vmov are failing on trunk:
FAIL: gcc.target/arm/neon/polytypes.c (test for excess errors)
FAIL: gcc.target/arm/neon/vget_lowf32.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9
--- Comment #1 from laurent at guerby dot net 2009-01-02 13:43 ---
Forgot the compile line used:
/home/guerby/build-142984/gcc/xgcc -B/home/guerby/build-142984/gcc/
-save-temps -O0 -mfpu=neon -mfloat-abi=softfp -c -o vget_lowf32.o
--- Comment #1 from rob1weld at aol dot com 2009-01-02 13:46 ---
Prior to changing gcc/config/i386/sol2-10.h:
u...@opensolaris:/usr/share/src/gcc_build# /usr/share/src/gcc_build/gcc/xgcc -v
-B/usr/share/src/gcc_build/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
--- Comment #6 from zadeck at naturalbridge dot com 2009-01-02 14:09
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Paolo Bonzini wrote:
Kenneth Zadeck wrote:
2009-01-01 Kenneth Zadeck zad...@naturalbridge.com
PR rtl-optimization/35805
--- Comment #1 from laurent at guerby dot net 2009-01-02 14:17 ---
gcc 4.3.2-1 on debian gnueabi and current trunk do not seem to generate wrong
code but may be I'm wrong in my setup to reproduce this problem?
gue...@gcc50:~$ cat pr38692.c
#include stdio.h
int main(void)
{
int
--- Comment #9 from tdragon at tdragon dot net 2009-01-02 14:23 ---
That patch seems to work fine, and I haven't seen any unwarranted errors
relating to static data members so far. Thank you very much for tracking this
down!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
--- Comment #7 from bonzini at gnu dot org 2009-01-02 14:26 ---
Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806
I think so. The global changed flag allows it to delete the case:
loop:
... - x // This is dead.
x- - ...
go to loop
it just is not
The following invalid code snippet triggers an ICE on the trunk:
=
union U
{
int i, j;
};
U u({1,2});
=
bug.cc:6: internal compiler error: in process_init_constructor_union, at
cp/typeck2.c:1101
Please submit a full bug report, [etc.]
--
Summary:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38698
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-02 14:39 ---
Subject: Bug 38690
Author: jakub
Date: Fri Jan 2 14:38:05 2009
New Revision: 143012
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143012
Log:
PR middle-end/38690
* tree-flow.h (op_code_prio,
The following valid code snippet triggers an ICE since GCC 4.2.0:
==
struct A
{
const char* p;
};
void foo()
{
__builtin_offsetof(struct A, p[0]);
}
==
bug.cc: In function 'void foo()':
bug.cc:8: internal compiler
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38699
The following valid code snippet triggers an ICE since GCC 4.1.0:
==
int foo()
{
L: return __builtin_expect ((__SIZE_TYPE__)L, 0);
}
==
bug.c: In function 'foo':
bug.c:3: internal compiler error: tree check: expected tree
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38700
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-02 14:44 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from s__nakayama at infoseek dot jp 2009-01-02 14:52 ---
If T is the name of a class, then each of the following shall have a name
different from T:
- every data member of class T;
This description is the one in ISO/IEC 14882:1998.
It was changed in ISO/IEC
The following invalid code snippet triggers an ICE on the trunk:
==
void foo() = default;
==
bug.cc:1: error: 'void foo()' cannot be defaulted
bug.cc:1: internal compiler error: Segmentation fault
Please submit a full bug
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38701
The following invalid code snippet triggers an ICE on the trunk:
=
enum E { e };
E operator |= (E, const E) = default;
=
bug5.cc:3: internal compiler error: in copy_fn_p, at cp/decl.c:9717
Please submit a
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38702
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
Current debian lenny comes with glibc-2.7 and does not provide __gnu_mcount_nc
which will come with 2.8 as discussed on gcc-patches here:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00319.html
But this means that all the tests from gcc testsuite using -p fail to link, eg:
Executing on host:
--- Comment #3 from laurent at guerby dot net 2009-01-02 15:17 ---
Still there with 4.3.2 and
gcc version 4.4.0 20081228 (experimental) [trunk revision 142939] (GCC)
Arnaud, do you have a generic expert handy to check wether this code is legal
or not? generic compiling but not an
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-02 15:20 ---
That seems invalid, not valid.
E.g. C says that for offsetof (type, member) for
static type t;
(t.member) evaluates to an address constant, which is not the case for
const char *p; field and p[0].
--
--- Comment #8 from zadeck at naturalbridge dot com 2009-01-02 15:20
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Paolo Bonzini wrote:
I think so. The global changed flag allows it to delete the case:
loop:
... - x // This is dead.
x- - ...
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-02 15:19 ---
This is a bug specific to the maverick set of chips.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-02 15:20 ---
Most likely needs to be skipped just like sparc as this is an unaligned access.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-02 15:29
---
CC-ing Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from zadeck at naturalbridge dot com 2009-01-02 15:34
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
On looking at the code, there is an issue with the first patch. I
should have been clearing solutions_dirty flag at the start of the
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-02 15:30
---
Likewise...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-02 15:36 ---
--with-cpu=pentium-m
Hmm, that might be the cause Testing with that option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38686
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-02 15:31
---
And again...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
#includeiostream
int main(int,char**){
const longdouble PiLD=3.1415926535897932384626433832795029L;
std::cout 3.1415926535897932384626433832795029std::endl;
std::cout.precision(70);
std::coutLD=PiLDstd::endl;
return 0;}
/*
Very bad
--- Comment #10 from bonzini at gnu dot org 2009-01-02 16:33 ---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
I will test this patch, but we still need to resolve your issues with my
approach.
The problem is that you're really doubling the cost of
--- Comment #3 from tromey at gcc dot gnu dot org 2009-01-02 16:33 ---
Changing component to pch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from tromey at gcc dot gnu dot org 2009-01-02 16:39 ---
Please report the bug in comment #2 separately.
Otherwise it is unlikely to be seen by the appropriate person.
Andrew is correct; this would probably be fixed if we had gcc
tell libcpp to use its diagnostic code.
--- Comment #3 from tromey at gcc dot gnu dot org 2009-01-02 16:44 ---
You can try -C to keep the comments.
In the original report you said you can't get a backtrace.
That makes it a lot harder :(
Could you try shrinking the test case somehow?
Or perhaps you could change the abort()
I turfed up an ICE with optimization, but the thing compiled fine without. To
reproduce, use the soon-to-be attached source and do:
madison.gams.com:/home/steve/lang/cpp/alpsBug$g++ -c AlpsTreeNode.ii
madison.gams.com:/home/steve/lang/cpp/alpsBug$g++ -O3 -c AlpsTreeNode.ii
AlpsTreeNode.cpp: In
--- Comment #1 from sdirkse at gams dot com 2009-01-02 16:49 ---
Created an attachment (id=17023)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17023action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38705
--- Comment #1 from pbrook at gcc dot gnu dot org 2009-01-02 17:01 ---
That's what dg-require-profiling does.
IMHO this is a deficiency in your glibc. It's very hard to distinguish between
something is subtly busted and my glibc sucks, so I'm not sure fixing this
is appropriate for fsf
--- Comment #1 from schwab at suse dot de 2009-01-02 17:02 ---
Depending on the actual value of DECIMAL_DIG this does not really look bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38704
--- Comment #6 from tromey at gcc dot gnu dot org 2009-01-02 17:04 ---
read_original_filename lexes a token, which hits EOF, which
causes the buffer to be popped.
This is sort of an odd scenario.
Perhaps working around it in preprocess_file is best.
--
tromey at gcc dot gnu dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-02 17:07 ---
Ok, I can reproduce the failure. The work around is removing
-with-arch=pentium-m.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from andreasmeier80 at gmx dot de 2009-01-02 17:08 ---
What is the status of this bug?
--
andreasmeier80 at gmx dot de changed:
What|Removed |Added
--- Comment #8 from andreasmeier80 at gmx dot de 2009-01-02 17:08 ---
What is the status of this bug?
--
andreasmeier80 at gmx dot de changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-01-02 17:17 ---
Seeing what tests gcc fail with stage1's gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38686
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-02 17:09 ---
Here is a reduced testcase:
t.c:
#include t.h
--- CUT ---
t.h:
#ifdef __PME__
#define _TLS_QUAL /*0123456790*/
#endif // __PME__
Compile with gcc t.c -isystem . -traditional-cpp.
--
pinskia at gcc dot gnu
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-02 17:11 ---
I can reproduce the abort on both i686-linux-gnu and i386-darwin8.11 with my
reduced testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-02 17:29 ---
Reducing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38705
--- Comment #2 from laurent at guerby dot net 2009-01-02 17:30 ---
The test already has:
/home/guerby/trunk/gcc/testsuite/gcc.dg/20021014-1.c
/* { dg-require-profiling -p } */
If configure tests the system compiler for profiling support it will of
course be fooled by a GCC changing
--- Comment #3 from joseph at codesourcery dot com 2009-01-02 17:35 ---
Subject: Re: testsuite __gnu_mcount_nc link error when
profiling on arm
On Fri, 2 Jan 2009, laurent at guerby dot net wrote:
I could not find a GLIBC 2.8 release in http://ftp.gnu.org/gnu/glibc/
nor in
Hi!
configured with: --host=alpha-linux-gnu --build=alpha-linux-gnu
--target=alpha-linux-gnu --enable-languages=c,c++ --with-system-zlib
Build fails with this error:
/bin/sh ../libtool --tag CXX --mode=compile /home/arthur/build/./gcc/xgcc
-shared-libgcc -B/home/arthur/build/./gcc -nostdinc++
--- Comment #5 from mmitchel at gcc dot gnu dot org 2009-01-02 18:05
---
Subject: Bug 33649
Author: mmitchel
Date: Fri Jan 2 18:04:28 2009
New Revision: 143014
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143014
Log:
PR 33649
* tree-ssa-pre.c (compute_antic):
--- Comment #6 from mmitchel at gcc dot gnu dot org 2009-01-02 18:08
---
Fixed.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
While trying to figure out what is causing bootstrap to fail with
--with-arch=pentium-m, I decided to test the testsuite with stage1's gcc and
found that gcc.c-torture/execute/20050121-1.c ICEs with -march=pentium-m, this
happens even with a normal compiled compiler.
--
Summary:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-02 18:19 ---
Forgot to add the ICE:
/home/pinskia/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c:33:
internal compiler error: in immed_double_const, at emit-rtl.c:548^M
--
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-02 18:21 ---
Confirmed at r134530 with the following reduced test case:
typedef unsigned int USItype __attribute__ ((mode (SI)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));
typedef USItype halffractype;
typedef
--- Comment #11 from zadeck at naturalbridge dot com 2009-01-02 18:21
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Paolo Bonzini wrote:
I will test this patch, but we still need to resolve your issues with my
approach.
The problem is that
--- Comment #5 from steven at gcc dot gnu dot org 2009-01-02 18:25 ---
The zero_extract:DI appears for the first time in the .163r.combine dump.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003
--- Comment #9 from aanisimov at inbox dot ru 2009-01-02 18:30 ---
(In reply to comment #7)
Ok, I can reproduce the failure. The work around is removing
-with-arch=pentium-m.
Not a good idea ;-). I found that reverting diff r137645:r137646 makes the
compilation finish and the
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-02 18:38 ---
Reduced testcase:
typedef int AlpsNodeIndex_t;
void writeRep(char* representation_, const int len) {
__builtin_memcpy(representation_ , len, sizeof(int));
}
struct AlpsTreeNode
{
AlpsNodeIndex_t index_;
--- Comment #12 from bonzini at gnu dot org 2009-01-02 18:38 ---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
StevenB talked me out of this because he considered it wrong to have
the client pass get conservative info. I agreed with him but I am
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-01-02 18:39
---
I think:
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
-funroll-loops
FAIL:
I think this is the cause of PR 38686 but I could be wrong.
Anyways gcc.c-torture/execute/memset-3.c fails with -march=pentium-m -O1
--
Summary: [4.4 Regression] gcc.c-torture/execute/memset-3.c Fails
with -march=pentium-m -O1
Product: gcc
--- Comment #9 from hp at gcc dot gnu dot org 2009-01-02 18:44 ---
See comment #5. The subsequent commits were AFAIK not addressing it. I don't
have time to experiment right now, and as the bug only appeared (at the time)
with separate patches, I'm making it SUSPENDED. CC:ers, feel
--- Comment #13 from stevenb dot gcc at gmail dot com 2009-01-02 18:45
---
Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806
On Fri, Jan 2, 2009 at 7:37 PM, Paolo Bonzini bonz...@gnu.org wrote:
At this point, if your patch costs say 0.3%, and removing all
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.4.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-02 18:46 ---
Also fails on i386-darwin with -march=pentium-m. Plus it works with 4.3.3 so
this is only a 4.4 regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-02 18:48 ---
This is also a regression from 4.3.2. It also ICEs on i386-darwin.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2009-01-02 18:48
---
Revision 137653 gave:
h...@gnu-3 gcc]$ cat /tmp/x.c
int
main ()
{
return 0;
}
[...@gnu-3 gcc]$ ./xgcc -B./ -S /tmp/x.c
/tmp/x.c: In function main:
/tmp/x.c:5: internal compiler error: in
--- Comment #14 from zadeck at naturalbridge dot com 2009-01-02 18:54
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Steven Bosscher wrote:
On Fri, Jan 2, 2009 at 7:37 PM, Paolo Bonzini bonz...@gnu.org wrote:
At this point, if your patch costs
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-02 18:57 ---
gcc.dg/compat//scalar-return-4_y.c fails the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38707
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37813
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-01-02 18:55
---
I think this is the same as PR 38708 really which I filed for memset-3.c case.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jv244 at cam dot ac dot uk 2009-01-02 18:57 ---
(In reply to comment #7)
Subject: Re: problem with contained subprocedure.
Hello,
This appears to be the problem. In any case, I just submitted a new archive
file. I hope this one's correct.
No... it is not.
--- Comment #13 from hjl dot tools at gmail dot com 2009-01-02 18:58
---
Adding -mtune=pentium-m will fail gcc.c-torture/execute/memset-2.c
with -O3 and gcc.c-torture/execute/memset-3.c with -O/-O2/-O3.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-02 19:01 ---
Adding -mtune=pentium-m will fail gcc.c-torture/execute/memset-2.c
with -O3 and gcc.c-torture/execute/memset-3.c with -O/-O2/-O3.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-02 19:02 ---
Oh, I see now, The current version of the defect reports can be found at
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html DR80.
I tried looking for it but I must have missed it.
--
pinskia at gcc
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
$ cat ice.f90
INTEGER, PARAMETER :: i = 42
INTEGER, PARAMETER :: array(1) = (/ 1 /)
INTEGER, PARAMETER :: unknown = array(shape(i))
END
$ gfortran-svn ice.f90
f951: internal compiler error: in find_array_section, at fortran/expr.c:1213
$ gfortran-svn --version
GNU Fortran (GCC) 4.4.0
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-01-02 19:26 ---
TRANSFER is one of the transformational intrinsics allowed in init-expressions
by F2003, thus requires simplification anyway. Close as dupe of PR29962?
--
dfranke at gcc dot gnu dot org changed:
What
--- Comment #17 from pinskia at gcc dot gnu dot org 2009-01-02 19:29
---
* gcc.target/i386/pr30315.c: New.
This testcase fails with -march=pentium-m turned on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
--- Comment #2 from lisp2d at lisp2d dot net 2009-01-02 19:37 ---
Quantity of correct bits is 64, the size of long double is 128 bits.
Half of quality is reached by usage of operations multiplication, divisions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38704
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-02 19:59 ---
Here is a reduced testcase:
_Complex char foo_char (int x) { }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38707
I don't know if this is the same bug as PR 38707 but it ICEs slightly
differently.
Anyways testcase:
_Complex short foo_char (int x) {return 0; }
[andrew-pinskis-computer-2:~] apinski% ~/local-gcc/bin/gcc t.c -march=pentium-m
-da -fdump-tree-final_cleanup
t.c: In function 'foo_char':
t.c:1:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0
Known to work||4.3.3 4.3.2
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-02 20:06 ---
Here is a testcase which ICEs with both the C and C++ front-end and is not
rejected by either of them:
struct A
{
const char* p;
};
void foo()
{
__builtin_offsetof(struct A, p[1]);
}
--- CUT ---
This is invalid
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-01-02 20:11
---
(In reply to comment #11)
That is a target issue, please file it as a separate bug.
It is filed as PR 38695.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37433
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-02 20:08 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2009-01-02 20:14 ---
(In reply to comment #2)
Quantity of correct bits is 64, the size of long double is 128 bits.
Half of quality is reached by usage of operations multiplication, divisions.
What does 'grep LDBL
1 - 100 of 174 matches
Mail list logo
