--- Comment #4 from gzp at gmx dot net 2008-12-27 09:08 ---
No, no patches, however if I overwrite the libtool script in
i686-pc-linux-gnu/libmudflap directory with the following version, the problem
disappear:
$ libtool --version
ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.492 2008/01/30
--- Comment #1 from gzp at gmx dot net 2008-12-27 09:11 ---
ping, the problem still exist, due the combinations of the configure options
(static vs shared)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35377
--
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
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-27 09:21
---
To clarify: I don't see anything in the Standard forbidding the use of
rdbuf()->sgetn in the implementation of istream::read. Actually, I would argue
is the natural choice for carrying out the core work. Then,
--
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
--
ubizjak at gmail dot com changed:
What|Removed |Added
Summary|10% performance regression |[4.3/4.4 Regression] 10%
|since Nov 1 on Polyhedron's |pe
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|4.3.4 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-27 11:40 ---
With the patch in comment#2, I see two regressions:
[ibook-dhum] f90/bug% gfc
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:10: internal compiler
--
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
--- Comment #2 from amylaar at gcc dot gnu dot org 2008-12-27 12:16 ---
(In reply to comment #1)
> Is there a test case which shows the wrong-code
> behavior, and which can be checked against the
> new register allocator?
I don't know of any particular test case. If you
want one, I sug
--- Comment #4 from dominiq at lps dot ens dot fr 2008-12-27 13:00 ---
If I remove the assert gfortran.dg/repack_arrays_1.f90 passes, while
gfortran.dg/pr32601.f03 gives:
print *, c_loc(get_ptr()) ! { dg-error "has PRIVATE components" }
1
Error: Parameter 'get_ptr' to 'c_
--- Comment #2 from monaka at monami-software dot com 2008-12-27 13:23
---
Created an attachment (id=16990)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16990&action=view)
Preprocessed file with -E option.
Generated this attached file with options below:
i386-pc-mingw32-gcc -c
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-27 14:22 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
END OF YR SLASH:Blackberry/$350,iPhone/$250,Omnia/$470,SE-X1/$500
Sony Ericsson X1 - $500 USD
SONY PS3 (60GB) = $300 USD
Apple iPhone 16GB$250 USD
Blackberry Bold..$300 USD
Blackberry Storm.$350 USD
Samsung Omnia i900 (16GB)$470 USD
HTC Touch
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-12-27 14:25 ---
Take the testcase in comment #2, p is not a valid template argument because it
is not valid constant expression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 14:32 ---
How does this testcase fail?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37081
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 14:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 14:38 ---
Fixed by:
2008-09-09 Rainer Orth
* config/sol2.h (REGISTER_TARGET_PRAGMAS): Move ...
* config/i386/sol2.h (REGISTER_SUBTARGET_PRAGMAS): ... here.
* config/sparc/sol2.h (REGISTER_TARGET_PRA
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-27 14:41 ---
I don't get the warning on the trunk or the 4.3 branch on i386-darwin8.11.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37060
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-27 14:45 ---
*** Bug 37051 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-27 14:45 ---
*** This bug has been marked as a duplicate of 8995 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-27 14:49 ---
I think adding an option which warns about this is ok, just it cannot be
default because people try to compile C code with the C++ front-end all the
time :).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-27 14:51 ---
*** This bug has been marked as a duplicate of 38553 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-27 14:51 ---
*** Bug 37044 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-27
14:53 ---
Subject: Re: /usr/ccs/bin/ld: Unsatisfied symbols in gnu/gcj/tools/gcj_dbto
> Was this ever fixed?
I believe it is fixed, but I will have to do another build to be sure.
Dave
--
http://gcc.gnu.org/b
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-27 14:55 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-12-27 14:58
---
Any news on this bug, it is one of the last P1s for 4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022
As reported in PR 37027, VEC_EXTRACT_EVEN_EXPR and VEC_EXTRACT_ODD_EXPR print
out as <<< ??? >>> in the tree dumps after the tuples merge.
--
Summary: [4.4 Regression]
VEC_EXTRACT_EVEN_EXPR/VEC_EXTRACT_ODD_EXPR no longer
print out correctly in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
Version|4.3.3 |4.4.0
http://
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-27 15:04 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-27 15:26 ---
Subject: Bug 38639
Author: jakub
Date: Sat Dec 27 15:24:52 2008
New Revision: 142933
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142933
Log:
PR c++/38639
* pt.c (tsubst_omp_for_iterator): RE
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-27 15:39 ---
Subject: Bug 38633
Author: jakub
Date: Sat Dec 27 15:38:22 2008
New Revision: 142934
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142934
Log:
PR middle-end/38633
* tree-cfg.c (replace_block_v
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-27 15:41 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-27 15:41 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
[ Forwarded from http://bugs.debian.org/487406 ]
Enrico Zini reported the following bug (with testcase) to Debian: the attached
code compiled with -fPIC results in a segfault on ARM (old ABI; not on EABI).
It works fine on other architectures or on ARM with gcc 4.2.
I verified that the bug is pr
--- Comment #1 from tbm at cyrius dot com 2008-12-27 16:50 ---
Created an attachment (id=16991)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16991&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38642
[ Forwarded from http://bugs.debian.org/490173 ]
Mike Hommey reported the following bug to Debian:
GCC doesn't hide (visibility-wise) vtables and VTTs on ARM (EABI).
The problem can be seen on the following code:
-8<-
class A {
public:
int a;
virtual int v();
};
int A::v() {
--- Comment #1 from tbm at cyrius dot com 2008-12-27 17:15 ---
Forgot to say that this only happens with ARM EABI, not with ARM old ABI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38643
--- Comment #6 from danglin at gcc dot gnu dot org 2008-12-27 17:33 ---
I agree with Steve that this is a HP math lib bug. For Steve's test
program, we have the following code at -O1:
fldw 0(%r3),%fr12R
fcpy,sgl %fr12R,%fr4R
fcpy,sgl %fr13R,%fr5R
ldo -48
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-27 18:12 ---
While the original problem is fixed on trunk and 4.3, some more marker problems
popped up as I expected.
from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536#c4
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-27 19:39 ---
Subject: Bug 38641
Author: jakub
Date: Sat Dec 27 19:38:20 2008
New Revision: 142935
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142935
Log:
PR middle-end/38641
* gimple-pretty-print.c (dump
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-27 19:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 20:31 ---
else if (!saw_named_field)
{
error ("%Jflexible array member in otherwise empty struct", x);
TREE_TYPE (x) = error_mark_node;
}
Hmm, it explicitly look
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 20:45 ---
http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00357.html
Hmm, this is on purpose as far as I can tell.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36839
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #14 from andreast at gcc dot gnu dot org 2008-12-27 20:51
---
The original failures, closure_fn* have gone. So I didn't follow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022
--- Comment #4 from davejmurphy at me dot com 2008-12-27 21:46 ---
Created an attachment (id=16992)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16992&action=view)
preprocessed source for arm-eabi testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
--- Comment #5 from davejmurphy at me dot com 2008-12-27 21:48 ---
(From update of attachment 16992)
I've tripped over this bug on arm-eabi too, with this code, compiled as thumb.
extern int doStreamReadBlock(int *, char *, int size, int);
char readStream(int *s)
{
char c = 0;
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 21:48 ---
Confirmed, though -I- is obsolete.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-27 21:51 ---
(In reply to comment #5)
> (From update of attachment 16992 [edit])
> I've tripped over this bug on arm-eabi too, with this code, compiled as thumb.
Except this bug is about ppc sysv ABI and not really about ARM-eab
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 22:00 ---
Confirmed.
http://gcc.gnu.org/ml/libstdc++/2008-11/msg3.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-27 22:02 ---
*** This bug has been marked as a duplicate of 17920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-12-27 22:02
---
*** Bug 36796 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 2008-12-27 22:04 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 22:05 ---
*** This bug has been marked as a duplicate of 11407 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The -fschedule-insns2 optimisation causes wrong code to be emitted for the
following testcase. The assembly code loads a value from a stack frame which
has already been deallocated.
This is similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282 for
powerpc-eabi.
extern int doStreamReadBlock
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-12-27 22:05
---
*** Bug 36805 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from davejmurphy at me dot com 2008-12-27 22:10 ---
Created an attachment (id=16993)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16993&action=view)
preprocessed source for arm-eabi testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 22:08 ---
Closing as invalid as you should use CC rather than CFLAGS.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 22:12 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 22:14 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36720
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 22:26 ---
Confirmed, at least a regression for 4.3 and 4.4.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The following valid code snippet triggers an ICE on mainline when compiled
with "-O":
=
int foo()
{
volatile int a[1];
int i, *p = (int*)a;
a[0] = 1;
for (i = 0; i < 1; ++i)
if (p[i])
return -1;
return 0;
}
=
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=38645
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-12-27 22:55
---
> Why do you think this is invalid code? The C front-end accepts this code.
Well, I believed the error messages - although I should know better than to
trust the compiler ;-)
It would be nice if you implemented
--- Comment #10 from mikael at gcc dot gnu dot org 2008-12-27 23:05 ---
(In reply to comment #9)
> Closing, fixed on 4.4
>
Not yet ;-)
I'm at revision 142934, and I get this on x86_64-unknown-linux-gnu:
FAIL: gfortran.dg/fmt_g0_1.f08 -O0 execution test
FAIL: gfortran.dg/fmt_g0_1.f08
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 regression] ICE|[4.3/4.4 regression] ICE
|throwing fixed-point typ
The following invalid code snippet triggers an ICE since GCC 4.3.0:
=
template struct A;
template struct A
{
template struct B;
template struct B {};
};
=
bug.cc:3: error: parameter pack argument 'N ...'
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38646
The following invalid code snippet triggers an ICE since GCC 3.4.0:
=
template struct A {};
template struct A<__FUNCTION__, N> {};
A<0, 0> a;
=
bug.cc:5: internal compiler error: in unify, at cp/pt.c:13746
P
--
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=38647
The following invalid code snippet triggers an ICE on mainline:
char a[1];
int foo(
{
a = "";
return 0;
}
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
A similar code snippet triggers an ICE si
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-27 23:23 ---
Created an attachment (id=16994)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16994&action=view)
another attempt, regression-tested
Regression-tested, but with regressions :-(.
They are probably unrelated anyw
--
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=38648
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 23:33 ---
Confirmed, this was introduced by the tuples merge.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 23:36 ---
Confirmed, only ICEs with checking turned on.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 23:43 ---
I think we can make this valid GNU C++ by doing:
template struct A {};
template struct A<__FUNCTION__, N> {};
char a1[1];
A a;
--- CUT ---
Though 3.3 rejected it by not defining __FUNCTION__ in the toplevel.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 23:46 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
The following invalid code snippets are accepted on mainline:
struct A
{
A(...) = default;
};
struct A
{
A(const A&, ...) = default;
};
Apparently defaultable_fn_p in cp/class.c doesn't handle
--
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=38649
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 23:57 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-28 00:10 ---
Caused by r137361. When struct A {} is seen, it commits to tentative parse, so
cp_parser_parse_definitely succeeds eventhough the next token isn't = nor {,
but EOF.
--
jakub at gcc dot gnu dot org changed:
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-28 00:15 ---
Created an attachment (id=16995)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16995&action=view)
gcc44-pr38635.patch
Patch I'm going to test.
--
jakub at gcc dot gnu dot org changed:
What|Re
There is some strange behavior with #pragma omp for and volatiles:
=
void foo()
{
volatile int i, j = 1;
#pragma omp for
for (i = 0; i < j; i += 1)
;
}
=
bug.cc: In function 'void foo()':
bug.cc:4: internal compiler error: in
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38650
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-28 00:34 ---
Fixed for 4.4 since there has been no feedback in 3 months.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36609
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-28 00:40 ---
This works for me with 4.3.2 and the current trunk.
Does it work for you?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36523
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-28 00:57 ---
This works for the 4.3 branch, 4.3.2 and the current trunk. Does this work for
you now?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-28 01:04 ---
Make sure you either setup ld.so.conf correctly or set LD_LIBRARY_PATH.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-28 01:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-28 01:25 ---
Was fixed by:
2008-06-09 Michael Meissner
* config.gcc (i[34567]86-*-*): Put test in quotes to prevent
failure on some Bourne shells.
(x86_64-*-*): Ditto.
--
pinskia at gcc dot gnu dot
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-28 01:27 ---
Does this work now on the LTO branch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36468
1 - 100 of 153 matches
Mail list logo
