On attached test case GCC keeps the index range checks in
Vector::getValue although they're always true due to loop conditions
# GNU C++ (GCC) version 4.5.0 (mingw32)
# options passed: -fpreprocessed yy5.ii -march=atom -mtune=atom -O2 -Wall
--
Summary: redundant checks not
--- Comment #1 from hartmut dot schirmer at arcormail dot de 2010-05-03
06:19 ---
Created an attachment (id=20538)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20538action=view)
Test case
foo() uses a get method without checks and is ok, checks not optimized away in
bar()
--
--- Comment #2 from hartmut dot schirmer at arcormail dot de 2010-05-03
06:19 ---
Created an attachment (id=20539)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20539action=view)
Assembler listing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43966
In section 4.1 (Routines for integer arithmetic) of the internal gcc manual
(gccint), __udivmodti3 is spelled __udivti3. I believe this is a typo
--
Summary: __udivmodti3 is spelled __udivti3
Product: gcc
Version: unknown
Status: UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-03 06:59 ---
No there are two different functions. __udivmodti3 computes both the mod and
the division in one function while __udivti3 computes just the division.
GCC by defaults emits the divmod one if there is not hardware
--- 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=20540action=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
--- 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
--- Comment #1 from ubizjak at gmail dot com 2010-05-03 08:14 ---
The testcase:
#include string
#include iostream
int
main (int argc, char *argv[])
{
std::string myStr = Hello, World!;
std::cout myStr std::endl;
return 0;
}
--
--- 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 at
--- 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
--
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 gcc-bugzi...@gcc.gnu.org writes:
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-04-23
--- 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=20541action=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.
--- 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=20542action=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
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
--- 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=20543action=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
--- 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=20544action=view)
Extended text case
With this and a fresh build at r158988 I get the following:
[sfili...@donald bug16]$
--- 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=20545action=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
--- 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
--- 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 alpha?
--- 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
--- 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
The following does not compile (minimal test case):
#include algorithm
int main()
{
int vec;
struct comparator
{
bool operator()(int a, int b) const { return ab; }
};
std::sort(vec, vec, comparator());
}
Result is:
test.cpp: In function int main():
test.cpp:13:
--- 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
--- 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
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_castint *(f.c);
*i = 0;
}
When compiled for ARM produces the warning:
--- 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
--- 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=20546action=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=20547action=view)
next testcase
Reduced from libstdc++-v3/testsuite/23_containers/bitset/operations/1.cc
I am happy those testcases
--- 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=gccview=revrev=158989
Log:
PR debug/43972
* config/i386/i386.c
--- 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=gccview=revrev=158990
Log:
PR debug/43972
* config/i386/i386.c
--- 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 @@
--- 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=gccview=revrev=158991
Log:
2010-05-03 Richard Guenther rguent...@suse.de
PR
--- 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.
--
--- 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 to
--
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=gccview=revrev=158998
Log:
2010-05-03 Steven G. Kargl ka...@gcc.gnu.org
PR
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
--- 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=20548action=view)
List of commits to the oldlto branch upto the rename point
The attached list was generated with:
svn diff
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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:
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 ¡®anonymous¡¯ does break
strict-aliasing
rules
/usr/include/c++/4.4/bits/stl_list.h:214: note: initialized from here
I don't
--- 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=20549action=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=20550action=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
--- 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
--- 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++
--- 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
--- 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
--- 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=20551action=view)
Ported: r114283 r114291 r114307 r114348 r114396 r114397 r114400 r114401
--
--- 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=gccview=revrev=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.
--- 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
--- 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
--
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
--- 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
1 - 100 of 135 matches
Mail list logo
