--- Comment #4 from dominiq at lps dot ens dot fr 2008-08-21 09:15 ---
Same thing here on i686-apple-darwin9.
> Does the patch work for you?
No! I still get:
FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-21 09:38 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|richard do
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37182
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-21 09:46 ---
It's a pure testsuite problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2008-08-21 09:53 ---
Does following patch fix your original problem?
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 139372)
+++ config/i386/i386.c (working copy
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-21 10:07 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|richard do
Since revision 139200 (rev. 139186 works) gcc.dg/matrix/transpose-3.c fails on
Darwin (see http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg01775.html),
minimal flags -fipa-matrix-reorg -O1 -fwhole-program:
[ibook-dhum] f90/bug% gfc -fipa-matrix-reorg -O1 -fwhole-program
/opt/gcc/_gcc_clean/gcc/te
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-21 11:23 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-08-21 11:24 ---
Subject: Bug 37182
Author: rguenth
Date: Thu Aug 21 11:22:52 2008
New Revision: 139374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139374
Log:
2008-08-21 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-21 11:25 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-21 11:26 ---
Subject: Bug 37181
Author: rguenth
Date: Thu Aug 21 11:25:28 2008
New Revision: 139375
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139375
Log:
2008-08-21 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net 2008-08-21
11:35 ---
It seems access control for templates is broken at a more basic level than the
reporter's testcase suggests; witness the following simplified testcase:
class A { typedef int X; };
template struct B
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-08-21 11:35 ---
Investigating.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net 2008-08-21
11:43 ---
This report is invalid. By 12.3.2,
"A conversion function is never used to convert a
(possibly cv-qualified) object to the (possibly
cv-qualified) same object type (or a reference to it)."
Comeau
--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net 2008-08-21
11:53 ---
Most likely related to bug 26693.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36734
--- Comment #3 from paolo dot carlini at oracle dot com 2008-08-21 11:58
---
Yes.
*** This bug has been marked as a duplicate of 26693 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #5 from paolo dot carlini at oracle dot com 2008-08-21 11:58
---
*** Bug 36734 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net 2008-08-21
12:00 ---
Still accepted by 4.4. Comeau concurs with reporter, and rejects saying:
line 15: error: class member designated by a
using-declaration must be visible in a direct base class
--
gcc-bugzilla a
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-08-21 12:02 ---
I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36817
--- Comment #2 from paolo dot carlini at oracle dot com 2008-08-21 12:04
---
*** This bug has been marked as a duplicate of 26698 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #16 from paolo dot carlini at oracle dot com 2008-08-21 12:04
---
*** Bug 36430 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #8 from joseph at codesourcery dot com 2008-08-21 12:05 ---
Subject: Re: [4.3 Regression] internal compiler error:
in compare_values_warnv
On Thu, 21 Aug 2008, cnstar9988 at gmail dot com wrote:
> ping.
> I can reproduce with gcc 4.3.2 RC1.
> It work well on gcc 4.2.4
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-08-21 12:07 ---
Fails with all of the 4.3 series, works for earlier releases. The problem is
still latent on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from gcc-bugzilla at contacts dot eelis dot net 2008-08-21
12:51 ---
Isolated and reproduced with GCC 4.4 on x86_64:
#include
#include
struct A
{
uint64_t p;
char m_ac[18];
A() { std::cout << "default constructed at " << this << '\n'; }
~A() {
--- Comment #10 from cnstar9988 at gmail dot com 2008-08-21 12:53 ---
I am sorry for wrong test for 4.3.0.
=
I rebuild my gcc 4.3.0 on 2.6.9-42.7AXsmp with gmp 4.2.3 + mpfr 2.3.1.
And make a test again. It works fail.
But the following co
Doesn't work, it still considers these warnings as errors:
$ gcc-4.3 x.c -c -Wall -Werror -Wno-error=pointer-sign
cc1: warnings being treated as errors
x.c: In function bar:
x.c:4: error: pointer targets in passing argument 1 of foo differ in
signedness
$ gcc-4.3 x.c -c -Wpointer-sign -Werror
Consider this code snippet:
cat x.c
struct test {
void *tst;
};
struct yy {
void **z;
};
int foo(struct test *x)
{
struct yy y[] ={
{ (void**) &x->tst }
};
return 0;
}
$ gcc x.c -c -pedantic
x.c: In function foo:
x.c:10: warning: init
--- Comment #1 from edwintorok at gmail dot com 2008-08-21 13:26 ---
Also -fdiagnostics-show-option doesn't show that the error is coming from
-pedantic:
$ gcc -Werror -pedantic x.c -c -fdiagnostics-show-option
cc1: warnings being treated as errors
x.c: In function foo:
x.c:10: error:
--- Comment #5 from hp at gcc dot gnu dot org 2008-08-21 13:28 ---
(In reply to comment #4)
> Same thing here on i686-apple-darwin9.
But was the failures you see too introduced with r139233?
I can't tell myself because I see no test-results for
i686-apple-darwin on gcc-testresults@ (hin
Gcc manual, "5.38.4 Constraints for Particular Machines" section:
"ARM familyconfig/arm/arm.h
fFloating-point register
wVFP floating-point register
FOne of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0,
4.0, 5.0 or
--- Comment #11 from rguenther at suse dot de 2008-08-21 13:48 ---
Subject: [PATCH] Fix PR36817
On Thu, 21 Aug 2008, cnstar9988 at gmail dot com wrote:
> I am sorry for wrong test for 4.3.0.
>
> =
> I rebuild my gcc 4.3.0 on 2.6.9-42.7AX
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-08-21 13:51
---
Subject: Bug 36817
Author: rguenth
Date: Thu Aug 21 13:50:30 2008
New Revision: 139385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139385
Log:
2008-08-21 Richard Guenther <[EMAIL PROTECTED]>
Compiling the attached preprocessed source using
g++-rep -march=native -fopenmp -Wall -frounding-math -c task_ice.cpp
gives an ICE.
Compiles fine if c_low is explicitly declared firstprivate in line 126,268 like
this:
#pragma omp task firstprivate(c_low)
--
Summary: ICE on valid:
Consider this code:
extern char *optarg;
extern char *optarg;
$ gcc testcase-min.i -c -Werror -Wredundant-decls -Wno-error=redundant-decls
-fdiagnostics-show-option
testcase-min.i:2: warning: redundant redeclaration of optarg
[-Wredundant-decls]
cc1: warnings being treated as errors
testcase-
--- Comment #1 from singler at gcc dot gnu dot org 2008-08-21 13:57 ---
Created an attachment (id=16119)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16119&action=view)
gzip compressed C++ code triggering the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37189
$ gcc dsputil_mmx.i -c -mmmx -O1
i386/h264dsp_mmx.c: In function
‘h264_h_loop_filter_chroma_intra_mmx2’:
i386/h264dsp_mmx.c:542: internal compiler error: in
inline_secondary_memory_needed, at config/i386/i386.c:21849
--
Summary: ICE in inline_secondary_memory_needed, at
--- Comment #1 from pluto at agmk dot net 2008-08-21 14:31 ---
Created an attachment (id=16120)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16120&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37191
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-08-21 15:13 ---
Created an attachment (id=16121)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16121&action=view)
Following patch should fix it, I will test it ASAP
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37094
--- Comment #6 from dominiq at lps dot ens dot fr 2008-08-21 15:33 ---
> But was the failures you see too introduced with r139233?
It is not in r139096, but appeared in r139293. So it is the right window, but I
don't have anything in between. From what I have seen it looks more like a
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-21 16:01 ---
This is fixed in GCC 4.4
~/139373M/build/gcc/cc1 -Werror -Wredundant-decls -Wno-error=redundant-decls
test.c
test.c:2: warning: redundant redeclaration of optarg
test.c:1: note: previous declaration of optarg was h
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-21 16:02 ---
Thanks for the report anyway!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37190
--- Comment #3 from edwintorok at gmail dot com 2008-08-21 16:08 ---
(In reply to comment #2)
> Thanks for the report anyway!
>
Ok, when is GCC 4.4 scheduled to be released?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37190
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-21 16:12 ---
This is confirmed in trunk. Weird because the pedwarn is not conditional on
pedantic, so it should be given even without pedantic. This means that
-pedantic is changing something at a higher level.
--
manu at gcc do
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-21 16:15 ---
Confirmed in trunk. This should be easy to fix for GCC 4.4.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-21 16:18 ---
(In reply to comment #3)
>
> Ok, when is GCC 4.4 scheduled to be released?
>
This is the last status report:
http://gcc.gnu.org/ml/gcc/2008-08/msg00131.html
Quoting: "We will probably stay until Stage 3 until we fee
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-21 16:53 ---
This happens also in trunk.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from eric dot weddington at atmel dot com 2008-08-21 17:07
---
Patch did not fix any those regressions for the AVR:
FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
FAIL: gcc.dg/weak/weak-12.c scan-assem
--- Comment #8 from eric dot weddington at atmel dot com 2008-08-21 17:13
---
(In reply to comment #7)
> Patch did not fix any those regressions for the AVR:
>
Stupid me: There were problems when it tried to patch that I didn't notice.
Fixing that and retesting...
--
http://gcc.
Consider these two minimal files:
p1.c:
#define _GNU_SOURCE
#include
p2.c:
#include
They compile just fine by themselves.
Now trying --combine:
$ gcc --combine -c p1.c p2.c
In file included from /usr/include/sys/types.h:220,
from p2.c:1:
/usr/include/sys/select.h:109: error: c
--- Comment #1 from edwintorok at gmail dot com 2008-08-21 17:48 ---
Created an attachment (id=16122)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16122&action=view)
preprocessed source
Generated with:
gcc --combine p1.c p2.c -c -save-temps
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-21 17:50 ---
This sounds like a glibc bug really. glibc's headers has invalid C in it :).
>why does --combine
Because GCC checks that the prototypes are compatible across translational
units with --combine and errors out if th
--- Comment #3 from edwintorok at gmail dot com 2008-08-21 17:52 ---
(In reply to comment #2)
> This sounds like a glibc bug really. glibc's headers has invalid C in it :).
>
> >why does --combine
> Because GCC checks that the prototypes are compatible across translational
> units wit
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-21 17:56 ---
>Compiling the sources separately works, and they are valid C separately.
Well they are valid if compiled separately but once you link them, they become
invalid C :). This is one place where the C standard says the
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-21 17:57 ---
> IMHO LTO should deal with situations like this, or make an exception for
> system headers.
No glibc should be fixed instead really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37192
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-21 18:04 ---
There are several bugs here:
1) -Wno-error=pendatic does not work. But neither does -Werror=pedantic or
-no-pedantic, so this is a feature request. We would need to implement
-Wpedantic as a synonym of -pedantic. I hav
--- Comment #7 from thomas dot mcguire at gmx dot net 2008-08-21 18:43
---
Just want to add my support for this feature.
I had quite some bugs which I would have discovered earlier if this warning
here was implemented.
In particular, in KDE4/Qt4, lots of virtual functions were removed
--- Comment #9 from eric dot weddington at atmel dot com 2008-08-21 19:04
---
(In reply to comment #7)
> Patch did not fix any those regressions for the AVR:
>
> FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
> FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
> FAI
--- Comment #8 from pluto at agmk dot net 2008-08-21 19:04 ---
why just not to use -Woverloaded-virtual?
$ g++ reimpl.cpp -Wall -c -Woverloaded-virtual
reimpl.cpp:1: warning: 'virtual void A::foo() const' was hidden
reimpl.cpp:2: warning: by 'void B::foo()'
--
http://gcc.gnu.org/
--- Comment #10 from dominiq at lps dot ens dot fr 2008-08-21 19:06 ---
I have had a closer look to the failures on i686-apple-darwin9 and they are due
to the replacement of '.weak_definition' with '.indirect_symbol' in the
assembly code (the regexp problem seems related to different eng
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-21 19:07 ---
Subject: Bug 30457
Author: manu
Date: Thu Aug 21 19:05:46 2008
New Revision: 139406
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139406
Log:
2008-08-21 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR 30
The following program is valid and compiles with g95, f95, ifort, ...
with gfortran it fails with:
i = 4
1
Error: Symbol 'i' at (1) has no IMPLICIT type
module m
implicit none
integer :: i
end module m
use m, only: i, j=>i, k=>i
implicit none
j = 5
k = 3
i = 4
if(i /= k .or. j /= k .or. i /
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-21 19:12 ---
We warn now about "register", the other cases are not warned following the
rationale given here:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00819.html
Fixed in GCC 4.4
--
manu at gcc dot gnu dot org changed:
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-21 19:12 ---
Thanks for the report!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30457
--- Comment #9 from thomas dot mcguire at gmx dot net 2008-08-21 19:15
---
> why just not to use -Woverloaded-virtual?
Because that does not help if the virtual function was completely removed from
the base class. We actually do use -Woverloaded-virtual, btw.
--
http://gcc.gnu.org
Seeing a degradation in cpu2000 benchmark 252.eon that is caused by
autovectorization of a simple loop in function ggSpectrum::Set(float).
Here's a simple C version.
void ggSpectrum_Set(float * data, float d) {
int i;
for (i = 0; i < 8; i++)
data[i] = d;
}
When compiled with -O3 -mc
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-21 19:32 ---
Confirmed, this is true for the Cell too. In fact is bad for the cell because
of:
stfs 1,16(1)
cmpwi 7,0,0
li 0,16
slwi 9,9,2
li 11,0
add 9,3,9
lvewx 0,1,0
--- Comment #11 from hp at gcc dot gnu dot org 2008-08-21 20:05 ---
Ok, I see why it doesn't work for you guys now: there's another bug; the weak
handling is buggily put inside code gated by #ifdef ASM_OUTPUT_EXTERNAL.
Simply moving it after that hunk should work. But I also see a wart
In the following inline assembly statement (the second one in the attached
program), the operands %0 and %5 are stored in exactly the same memory address
-44(%ebp), even though they refer to different variables (and all the output
constraints have the earlyclobber modifier).
asm(" shrdl %6, %4,
--- Comment #1 from jdemeyer at cage dot ugent dot be 2008-08-21 21:16
---
Created an attachment (id=16123)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16123&action=view)
Source code which shows the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37195
--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-21 21:26 ---
Is this still an issue nowadays?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20112
--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-21 21:31 ---
I think the gfortran part is fixed by PR 29635. The rest has to be solved in
gdb. Other debugers seem to have also some problems, e.g. Intel's idb, cf.
http://gcc.gnu.org/ml/fortran/2008-08/msg00128.html
--
http:
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-21 21:42 ---
This works for i668-darwin with the trunk:
(gdb) p a
$1 = (REF TO -> ( real*4 )) @0x2004: 1
Current language: auto; currently fortran
(gdb) p b
$2 = (REF TO -> ( real*4 )) @0x2000: 2
GNU gdb 6.3.50-20050815 (Apple
Follow the steps on either:
http://xinutec.org/~pippijn/files/txt/46e78059d1e42f9381587ea2ab502f2b.txt
https://gist.github.com/56744b9f0a5b0d69b83e
on FreeBSD. Dwarf debug information is wrong, but this only happens on FreeBSD
and only if the compiling (-S) and assembling (-c) step are split. It
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-21 22:32 ---
The issue is here:
g++ -g -c test.s -o test.o
Don't use -g with assembly code that already has debugging info in it. Also I
think this was just fixed on the trunk of binutils lately where it checks to
make sure th
--- Comment #2 from pip88nl at gmail dot com 2008-08-21 22:56 ---
It works if -g is omitted on the assembling step. Still, the debug information
from the asm should not conflict with the original debug information, should
it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37196
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-21 23:02 ---
(In reply to comment #2)
> It works if -g is omitted on the assembling step. Still, the debug information
> from the asm should not conflict with the original debug information, should
> it?
And at that point, this
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-21 23:03 ---
see http://sourceware.org/bugzilla/show_bug.cgi?id=6656 also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37196
--- Comment #2 from tristan at wibberley dot org 2008-08-22 00:22 ---
Created an attachment (id=16124)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16124&action=view)
ice when NO_ICE is not defined
This is the same source as in my original report but as an attachment.
--
htt
--- Comment #4 from cnstar9988 at gmail dot com 2008-08-22 00:31 ---
works well on 4.2.4, 4.3.0, 4.3.2-RC1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37125
--- Comment #2 from mhesseli at fulcrummicro dot com 2008-08-22 01:01
---
Over the past month I have been trying to make a largish Java project
accessible from Perl using SWIG and GCJ. I have been very pleased with the way
GCJ allowed me to accomplish this. Unfortunately, late in the pr
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35519
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Target Milestone|4.4.0 |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34932
--- Comment #12 from hp at gcc dot gnu dot org 2008-08-22 02:16 ---
Created an attachment (id=16125)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16125&action=view)
Patch, take 2.
Against r139233.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #13 from hp at gcc dot gnu dot org 2008-08-22 02:24 ---
Patch in comment #12 is as previously mentioned, except because of Darwin's
weird symbol handling, the symbol_ref's didn't pass through the same way as
other operands, so it has to mark weak references "manually". (No,
--- Comment #14 from eric dot weddington at atmel dot com 2008-08-22 03:37
---
I tried testing with 139423, but I'm getting a separate error during build:
../../../../gcc/libgcc/../gcc/libgcc2.c: In function '__mulsc3':
../../../../gcc/libgcc/../gcc/libgcc2.c:1831: internal compiler er
--- Comment #2 from regehr at cs dot utah dot edu 2008-08-22 03:57 ---
(In reply to comment #1)
> Does following patch fix your original problem?
Yes looks good. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37184
--- Comment #6 from jorn dot amundsen at ntnu dot no 2008-08-22 06:18
---
Compiling and testing against gcc 4.4 snapshot 20080808 still results in 7 ICEs
(1 and 3-7 as of 4.3.1):
lnInclude/wrapper.cpp:320: internal compiler error: Illegal instruction
interpolation/surfaceInterpolation/
: invalid expression as
operand
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED] gcc]$ ./xgcc --version
xgcc (GCC) 4.4.0 20080821 (experimental) [trunk revision 139403]
--
Summary: -msse4
--- Comment #8 from nightstrike at gmail dot com 2008-08-22 06:47 ---
I can confirm this bug (seeing as how the one I wrote got duped to here). Can
someone update the status to confirmed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
90 matches
Mail list logo
