--- Comment #9 from and_j_rob at yahoo dot com 2010-05-03 07:22 ---
Created an attachment (id=20540)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20540&action=view)
Was a C/C++ comparison
I found a similar problem while comparing C/C++ complexes, I'm on a x86_64 mac,
and was tryi
--- Comment #13 from jv244 at cam dot ac dot uk 2010-05-03 07:46 ---
these might be fixed in current trunk as a result of the fixes to PR43879
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--
libmudflap.c++/pass41-frag.cxx test case fails with -static [1] due to link
problem in libstdc++:
FAIL: libmudflap.c++/pass41-frag.cxx (-static) (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx (-static) compilation failed to produce
executable
The problem can be triggered with fo
--- Comment #1 from ubizjak at gmail dot com 2010-05-03 08:14 ---
The testcase:
#include
#include
int
main (int argc, char *argv[])
{
std::string myStr = "Hello, World!";
std::cout << myStr << std::endl;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4396
--- Comment #9 from ubizjak at gmail dot com 2010-05-03 09:01 ---
(In reply to comment #8)
> It may be a good idea by itself. However, since AMD64 uses movd instead
> of movq, some non-GNU assemblers may not support movq. Why change it
> when nothing is broken?
Indeed.
--
ubizjak a
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-05-03 09:16
---
Fixed long ago.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|4.6-20100501 (r158965) |[4.6 Regression] 4.6-
|bootstrap failure on ARM,
--- Comment #13 from rdsandiford at googlemail dot com 2010-05-03 09:53
---
Subject: Re: [4.5/4.6 regression] ICE in reload_cse_simplify_operands
"mkuvyrkov at gcc dot gnu dot org" writes:
> --- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-04-23 10:20
> ---
> The
--- Comment #14 from rsandifo at gcc dot gnu dot org 2010-05-03 09:55
---
Created an attachment (id=20541)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20541&action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-03 09:55 ---
Confirmed. This is a case where we'd have to do some interesting VRP and
jump-threading.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-03 09:59 ---
Well, this is another case where the predication by if (mData) makes this
hard to optimize. Not impossible, but hard.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |
Hello,
The attached code asserts that an ALLOCATABLE inner component starts its life
as ALLOCATED, which is contrary to everything I know about allocatables.
- log ---
[sfili...@donald bug16]$ gfortran -v
Using built-in specs.
COLLECT_GC
--- Comment #1 from sfilippone at uniroma2 dot it 2010-05-03 10:12 ---
Created an attachment (id=20542)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20542&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43969
$ gcc -v
Using built-in specs.
COLLECT_GCC=/tools/pkg/gcc/4.5.0/bin/gcc
COLLECT_LTO_WRAPPER=/tools/pkg/gcc/4.5.0/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: gcc-4.5.0/configure --enable-languages=c,c++
--disable-bootstrap --disable-nls --with-local
I just tried to compile the Linux kernel version linux-2.6.34-rc6
with the C compiler version 4.6 snapshot 20100501 and it said
init/main.c: In function 'do_one_initcall':
init/main.c:915:1: internal compiler error: vector VEC(ce_s,base) index domain
error, in do_structure_copy at tree-ssa-structa
--- Comment #1 from dcb314 at hotmail dot com 2010-05-03 10:24 ---
Created an attachment (id=20543)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20543&action=view)
gzipped C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43971
struct { int *b1; } *f1 ();
short v1[1];
struct S { int b2; };
void
foo (struct S *a1, union { char *b3; unsigned *b4; int *b5; } *a2)
{
int d;
switch (d)
{
case 0:
{
int c = a1->b2, i;
if (f1 () == 0)
*a2->b3++ = 2;
else if (((long) (f1 () - f1 (
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-03 10:34 ---
(value/u:DI 24:19029 @0x171db88/0x172c120)
offset 0
(reg:SI 4 si)
(mem/c:QI (value:DI 26:3872 @0x171dbb8/0x172c180) [11 %sfp+-1 S1 A8])
(mem:SI (value/u:DI 52:52 @0x171de28/0x172d4b0) [2 *D.2766_
--- Comment #2 from sfilippone at uniroma2 dot it 2010-05-03 10:37 ---
Created an attachment (id=20544)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20544&action=view)
Extended text case
With this and a fresh build at r158988 I get the following:
[sfili...@donald bug16]$ ./test
--- Comment #1 from mikpe at it dot uu dot se 2010-05-03 10:43 ---
Created an attachment (id=20545)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20545&action=view)
suggested fix for PR43964
Confirmed r158911 to be the cause of this bootstrap failure. Attached patch
should fix it
This code reduced from libiberty/regex.c
typedef unsigned char UCHAR;
void insert_op2 (UCHAR *loc, UCHAR *end)
{
UCHAR *pfrom = end;
UCHAR *pto = end + 1;
while (pfrom != loc)
*--pto = *--pfrom;
}
jbook2:~ jay$ alpha-dec-vms-gcc -c re.c
jbook2:~ jay$ alpha-dec-vms-gcc -c -O2 re.c
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-03 10:52
---
Before we do anything here, you should try to explain why the problem happens
only on alpha, because on x86_64 it doesn't and those symbols are exported
("V"). Are the symbols exported on alpha? Are we **really
--- Comment #53 from jv244 at cam dot ac dot uk 2010-05-03 10:57 ---
testcase in comment #40 now works. Comment #42 still fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #15 from loaden at gmail dot com 2010-05-03 11:11 ---
The problem is too serious! I have 4G memory, but not able to compile wxWidgets
2.8.10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #11 from rguenther at suse dot de 2010-05-03 11:16 ---
Subject: Re: [4.6 Regression] FAIL:
gcc.c-torture/compile/pr42196-2.c
On Sun, 2 May 2010, irar at il dot ibm dot com wrote:
> --- Comment #10 from irar at il dot ibm dot com 2010-05-02 12:12 ---
> Looks like
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43901
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43972
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-03 11:27 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #3 from ubizjak at gmail dot com 2010-05-03 11:46 ---
(In reply to comment #2)
> Before we do anything here, you should try to explain why the problem happens
> only on alpha, because on x86_64 it doesn't and those symbols are exported
> ("V"). Are the symbols exported on alp
--- Comment #4 from ubizjak at gmail dot com 2010-05-03 11:50 ---
As shown, these symbols are exported as "u":
`u'
The symbol is a unique global symbol. This is a GNU
extension to the standard set of ELF symbol bindings. For
such a symbol the dynamic
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-03 11:52
---
This is what I get on x86_64:
nm libstdc++.a | grep
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
U
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE
Comiling any shared library on Solaris with LDFLAGS "-Wl,-z,defs" to make sure
that there are no unresoloved symbols results in:
Undefined first referenced
symbol in file
main
/usr/local/lib/gcc/sparc-sun-solaris2.10
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-03 11:55 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
The following does not compile (minimal test case):
#include
int main()
{
int vec;
struct comparator
{
bool operator()(int a, int b) const { return a
struct comparator
{
bool operator()(int a, int b) const { return ahttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43975
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-03 12:06
---
Yes, in C++03 you cannot instantiate a template with a local type. C++1x will
be different.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #1 from ubizjak at gmail dot com 2010-05-03 12:09 ---
Confirmed with a cross from x86_64-pc-linux-gnu to alpha-dec-vms.
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from ubizjak at gmail dot com 2010-05-03 12:12 ---
(In reply to comment #5)
> This is what I get on x86_64:
> thus, seems a target problem to me.
Do you have any advice, where/how these symbols get exported? I would like to
analyze the failure, so we can blame some other
--- Comment #7 from paolo dot carlini at oracle dot com 2010-05-03 12:17
---
In locale-inst.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43968
--- Comment #12 from irar at il dot ibm dot com 2010-05-03 12:30 ---
> Well. For loops we'd have disqualified it as there is no vector
> type for the external def (well, the stmt inside the loop).
I don't think that's true. With -fno-tree-pre we get the same ICE for loop
vectorization
--- Comment #13 from rguenther at suse dot de 2010-05-03 12:35 ---
Subject: Re: [4.6 Regression] FAIL:
gcc.c-torture/compile/pr42196-2.c
On Mon, 3 May 2010, irar at il dot ibm dot com wrote:
> --- Comment #12 from irar at il dot ibm dot com 2010-05-03 12:30 ---
>
> > Well.
--- Comment #6 from numerical dot simulation at web dot de 2010-05-03
12:53 ---
Hi!
Though I love the fact that this code now compiles, I am still unsure whether
this is the right thing to have.
>From http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#502 I see
>that
the pro
--- Comment #7 from redi at gcc dot gnu dot org 2010-05-03 13:01 ---
I didn't realise there was a DR about this, confirm ...
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from redi at gcc dot gnu dot org 2010-05-03 13:02 ---
... and suspend until the issue is ready
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2010-05-03 13:46 ---
Hm, in expand_assignment (), around line 4408 in expr.c, we expand
MEM[base: pfrom_8, offset: 1]
to
(mem:QI (plus:DI (subreg/s:SI (reg/v/f:DI 108 [ pfrom ]) 0)
(const_int 1 [0x1])) [0 *pfrom_8 S1 A8])
IMO, the
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-03 14:38 ---
I've also bootstrapped the first patch today, unfortunately on i686-linux it
regresses forall_7.f90 testcase - gsi_skip_debug is called with after = 1
on sequence D.3267_429 = 125 + 5; (pointing at the only stmt in the
Source: https://bugs.webkit.org/show_bug.cgi?id=38045
Given the following code:
$ cat test.cpp
struct Foo
{
char __attribute__((aligned(4))) c[sizeof(int)];
};
char junk;
Foo f;
int main()
{
int *i = reinterpret_cast(&f.c);
*i = 0;
}
When compiled for ARM produces the warning:
$ ar
--- Comment #11 from brtnfld at hdfgroup dot org 2010-05-03 14:50 ---
(In reply to comment #10)
> Can this be closed? Is there something left to do here?
>
As of gfortran 4.4.4 (and 4.5.1) the program in comment #7 does not compile but
gives the same error:
Error: CHARACTER argument 'b
--- Comment #25 from zsojka at seznam dot cz 2010-05-03 14:56 ---
Created an attachment (id=20546)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20546&action=view)
next testcase, second part will follow
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
--- Comment #26 from zsojka at seznam dot cz 2010-05-03 15:02 ---
Created an attachment (id=20547)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20547&action=view)
next testcase
Reduced from libstdc++-v3/testsuite/23_containers/bitset/operations/1.cc
I am happy those testcases he
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-03 15:43 ---
Subject: Bug 43972
Author: jakub
Date: Mon May 3 15:42:43 2010
New Revision: 158989
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158989
Log:
PR debug/43972
* config/i386/i386.c (ix86_delegit
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-03 15:46 ---
Subject: Bug 43972
Author: jakub
Date: Mon May 3 15:46:43 2010
New Revision: 158990
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158990
Log:
PR debug/43972
* config/i386/i386.c (ix86_delegit
--- Comment #3 from ubizjak at gmail dot com 2010-05-03 16:12 ---
Can you try this patch:
--cut here--
Index: alpha.c
===
--- alpha.c (revision 158970)
+++ alpha.c (working copy)
@@ -842,7 +842,8 @@ alpha_legitimate
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-03 16:12 ---
Subject: Bug 43971
Author: rguenth
Date: Mon May 3 16:12:12 2010
New Revision: 158991
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158991
Log:
2010-05-03 Richard Guenther
PR tree-optimization/
--- Comment #27 from steven at gcc dot gnu dot org 2010-05-03 16:56 ---
Zdenek, has anyone told you how amazing your contribution is here? Wow!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
--- Comment #8 from ubizjak at gmail dot com 2010-05-03 17:25 ---
(In reply to comment #7)
> In locale-inst.o
Strange, on alpha it is defined in compatibility-ldbl.o.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43968
--- Comment #9 from paolo dot carlini at oracle dot com 2010-05-03 17:41
---
Ah yes, it's probably because of the strange workarounds put in place for long
double. Anyway, if you encounter special issues having to do with that, Jakub
is the reference person.
--
http://gcc.gnu.org/b
--- Comment #10 from ubizjak at gmail dot com 2010-05-03 17:44 ---
(In reply to comment #9)
> Ah yes, it's probably because of the strange workarounds put in place for long
> double. Anyway, if you encounter special issues having to do with that, Jakub
> is the reference person.
Added t
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #4 from kargl at gcc dot gnu dot org 2010-05-03 17:57 ---
Subject: Bug 43592
Author: kargl
Date: Mon May 3 17:57:14 2010
New Revision: 158998
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158998
Log:
2010-05-03 Steven G. Kargl
PR fortran/43592
*
This is a bug to keep track of the patches committed to the oldlto branch but
never merged to the trunk. The interesting patches to "salvage" are mostly
related to elimination of TREE_LIST.
--
Summary: Patches from oldlto branch to be salvaged
Product: gcc
Versio
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-03 18:08 ---
Created an attachment (id=20548)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20548&action=view)
List of commits to the oldlto branch upto the rename point
The attached list was generated with:
svn diff svn:/
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-03 18:09 ---
If real life allows, I'll give it another try for 4.6 - started twice already
but there are quite a few options to handle. However, if you feel like it, dig
in. Help is always welcome :)
Closing as dupe of PR31588.
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-05-03 18:09
---
*** Bug 43954 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|ICE: dependent_type_p, at |[4.5/4.6 regression] ICE:
|cp/pt.c:17404
--- Comment #7 from glarkin at FreeBSD dot org 2010-05-03 18:36 ---
(In reply to comment #6)
> So can someone please comment on this?
>
I recently encountered this problem while using gcc/gcj 4.5 with ecj-4.5.jar to
compile the pdftk utility (http://www.accesspdf.com/pdftk/) on FreeBSD
--- Comment #3 from glarkin at FreeBSD dot org 2010-05-03 18:37 ---
(In reply to comment #2)
> Experimenting with -save-temps I noticed that the .dummy resource is in the
> .jar generated by ecj which seems to point to it as the main suspect.
>
I believe that's correct - please see:
ht
I get this warning while compiling the program below with g++-4.4.3:
$ g++ -O2 -Wall test.cc
test.cc: In function ¡®int main()¡¯:
test:8: warning: dereferencing pointer ¡®¡¯ does break
strict-aliasing
rules
/usr/include/c++/4.4/bits/stl_list.h:214: note: initialized from here
I don't see
--- Comment #1 from musiphil at bawi dot org 2010-05-03 18:48 ---
Created an attachment (id=20549)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20549&action=view)
the source file that triggers the warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43978
--- Comment #2 from musiphil at bawi dot org 2010-05-03 18:48 ---
Created an attachment (id=20550)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20550&action=view)
the preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43978
--- Comment #2 from kirr at landau dot phys dot spbu dot ru 2010-05-03
19:23 ---
Daniel, thanks for reply.
As I see it, yes, PR31588 would be handy enhancement, but this bug is different
-- it's a _regression_ -- it used to work in 4.3 and stopped in 4.4.
And when I say "it used to wo
--- Comment #54 from jvdelisle at gcc dot gnu dot org 2010-05-03 19:24
---
We should get the case in comment 40 added to the test suite if not already so
we do not regress it later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-03 19:35 ---
(From update of attachment 20548)
>
>r124989 | olga | 2007-05-23 14:49:49 +0200 (Wed, 23 May 2007)
>-
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-03 19:36 ---
OK, that didn't work... I'll just comment per revision.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-03 19:45 ---
(In reply to comment #2)
On Monday 03 May 2010 21:23:26 you wrote:
> And when I say "it used to work" I don't mean generating dependencies for
> f90/f95 sources (PR31588 mentions e.g. USE), but only generating
> depe
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-03 19:47
---
Richard, can you have a look? It is the same as 42032?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-03 19:53
---
For sure cannot be reproduced with 4.5 and mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43978
Hello,
my gcc is my own built:
$ c++ -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.4.2/configure --prefix=/usr/local/gcc-4.4.2
--with-as=/usr/bin/gas --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld
--enable-shared --enable-threads --enable-languages=c++
--with
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-03 20:00 ---
I think you need -march=i486 on solaris for this to work. At least with 4.4.
Now with 4.5, it is a different story.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43980
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-03 20:03
---
I suspect this is just the usual issue with i386, which does not provide the
atomic builtins. You should try with, eg, -march=i486, and if the problem goes
away this is a duplicate of some other 30 PRs ;)
--
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-03 20:03 ---
Mine. I think fixing comment #0 is as easy as the following two-liner:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 158970)
--- Comment #15 from schwab at linux-m68k dot org 2010-05-03 20:17 ---
The patch is ok, please check it in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
--- Comment #1 from schwab at linux-m68k dot org 2010-05-03 20:26 ---
This isn't really a different bug.
*** This bug has been marked as a duplicate of 42909 ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #3 from schwab at linux-m68k dot org 2010-05-03 20:26 ---
*** Bug 42910 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42909
--- Comment #3 from kgardas at objectsecurity dot com 2010-05-03 20:30
---
Folks,
please close this. Indeed, when I add -march=i486 I get no linker errors
anymore. Thanks for your fast help! Karel
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43980
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-03 20:37
---
Ok
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UN
--- Comment #4 from steven at gcc dot gnu dot org 2010-05-03 20:46 ---
Created an attachment (id=20551)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20551&action=view)
Ported: r114283 r114291 r114307 r114348 r114396 r114397 r114400 r114401
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #17 from jason at gcc dot gnu dot org 2010-05-03 21:16 ---
Subject: Bug 43680
Author: jason
Date: Mon May 3 21:16:40 2010
New Revision: 159006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159006
Log:
PR c++/43680
gcc:
* c.opt (-fstrict-enums): New.
--- Comment #3 from kargl at gcc dot gnu dot org 2010-05-03 21:39 ---
I think my last intrinsic.texi patch fixed all of the
issues raised by James. Closing with fixed. If you
find an issue please open a new PR.
r
--- Comment #37 from mrs at gcc dot gnu dot org 2010-05-03 21:39 ---
First question to decide is what direction they want to go with it, that's an
LTO question. Once that is decided, if the direction to do is to change
darwin.c, I have given the 3 lines to do that, what remains undone w
--- Comment #4 from jason at gcc dot gnu dot org 2010-05-03 21:44 ---
Fixed for 4.5.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
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 #38 from howarth at nitro dot med dot uc dot edu 2010-05-03
22:01 ---
Mike,
I was more interested about the second option since you seem to indicate
that the first option would pessimize the the LTO code generation on i386
darwin. Or did I misunderstand that comment?
--
--- Comment #39 from steven at gcc dot gnu dot org 2010-05-03 22:15 ---
I still don't understand the 32 bits problem.
Without LTO, there is this code in the for 2008_0.i:
L_mumble$non_lazy_ptr:
.indirect_symbol _mumble
In the WPA code mumble is gone in the code for 2008
--- Comment #3 from wilson at codesourcery dot com 2010-05-03 22:28 ---
Subject: Re: suboptimal MIPS widening multiply accumulate
On Tue, 2010-04-27 at 09:33 +, rguenth at gcc dot gnu dot org wrote:
> For more general optimization you might want to move all this code to
> the tree
--- Comment #4 from wilson at gcc dot gnu dot org 2010-05-03 22:36 ---
Created an attachment (id=20552)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20552&action=view)
trivial solution for original problem
This fixes the original problem, but does not fix the new breakage caused
--- Comment #10 from mrs at gcc dot gnu dot org 2010-05-03 22:38 ---
Subject: Bug 43839
Author: mrs
Date: Mon May 3 22:37:50 2010
New Revision: 159009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159009
Log:
PR 43839
* testsuite/Makefile.am: Override automake
--- Comment #2 from rus at google dot com 2010-05-03 22:46 ---
It's not clear from the description what the problem is here. The profile mode
doesn't instrument either forward_list or slist at this point, so all
inclusions of should fall back to normal mode.
Could you please clarify t
--- Comment #40 from mrs at gcc dot gnu dot org 2010-05-03 22:47 ---
Jack, if I follow what you want, that's an LTO fix, I don't know the LTO code.
I don't know that that fix is even possible. I think one must do the LTO_SYM
fix, if I had to guess. I don't have the time to embark upon
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-03 23:06
---
Silvius, this is not a bug proper, instead an *enhancement* request: it seems
quite obvious to me, if only for consistency, that we want to provide
debug-mode and profile-mode versions of forward_list too, like
1 - 100 of 132 matches
Mail list logo
