--- Comment #5 from rob1weld at aol dot com 2009-03-18 06:19 ---
Nearly perfect results: (better than the Trunk last week)
Results for 4.4.0 20090313 (experimental) [melt-branch revision 144923] (GCC)
testsuite on i686-unknown-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg0
--- Comment #18 from jason at gcc dot gnu dot org 2009-03-18 03:29 ---
I can't imagine an implementation of memcpy that would break when the two
addresses are the same, it just doesn't work if one is offset but overlapping.
So the valgrind warning is pedantically correct, but I think it
--- Comment #11 from hjl dot tools at gmail dot com 2009-03-18 02:46
---
(In reply to comment #10)
> Looks like I should punt and force "#define FRAME_POINTER_REQUIRED
> cfun->calls_alloca" or "#define FRAME_POINTER_REQUIRED
> cfun->has_nonlocal_label".
> Apparently this is *not* one of
--- Comment #8 from hjl dot tools at gmail dot com 2009-03-18 02:42 ---
*** Bug 39486 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-18 02:42 ---
It works with revision 144919.
*** This bug has been marked as a duplicate of 39412 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-18 02:39 ---
I believe this is a dup of PR 39412. Please try revision 144909.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from hp at gcc dot gnu dot org 2009-03-18 02:30 ---
Looks like I should punt and force "#define FRAME_POINTER_REQUIRED
cfun->calls_alloca" or "#define FRAME_POINTER_REQUIRED
cfun->has_nonlocal_label".
Apparently this is *not* one of the cases where "The compiler recognize
--- Comment #5 from hp at gcc dot gnu dot org 2009-03-18 01:59 ---
(In reply to comment #4)
> Going back through the old run logs. Is this how it shows up?
I'm now thinking *less* that this has similar causes to that of PR38609, since
for this target it happens at all optimization leve
--- Comment #1 from cneil at yahoo dot com 2009-03-18 01:58 ---
Created an attachment (id=17482)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17482&action=view)
link_map.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39486
When compiling elfutils-0.140, I encountered the following ICE:
x86_64-pc-linux-gnu-gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -I. -I.. -I. -I.
-I./../libelf -I./../libebl -I./../libdw -I.. -I./../lib -Wall -Wshadow
-Wunused -Wformat=2 -std=gnu99 -march=amdfam10 -O3 -pipe -ggdb
-fstack-protector -MT lin
A regression from 4.3 for GNU C++ 4.4.0 20090317 (experimental)
-PASS: gdb.cp/classes.exp: calling method for small class
+XFAIL: gdb.cp/classes.exp: calling method for small class (PRMS 2972)
---
Breakpoint 1, main () at
--- Comment #10 from eric dot rannaud at gmail dot com 2009-03-17 22:48
---
Witnessed in g++ 4.3.2
g++ (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)
--
eric dot rannaud at gmail dot com changed:
What|Removed |Added
--
--- Comment #4 from rob1weld at aol dot com 2009-03-17 22:30 ---
(In reply to comment #3)
> I applied a slightly simplified variant of melt-patch-2.patch above as
> rev144917
>
> Thanks Rob. It probably works!
Great. The code may receive a better following if there were fewer warnings.
--- Comment #4 from dodji at gcc dot gnu dot org 2009-03-17 22:10 ---
Subject: Re: New: ICE caused by default template argument
FWIW, on gcc 4.3.2, I get the error:
test.cc: In function 'void breakMe()':
test.cc:17: error: a cast to a type other than an integral or
enumeration type c
--- Comment #8 from rwild at gcc dot gnu dot org 2009-03-17 21:23 ---
Subject: Bug 37805
Author: rwild
Date: Tue Mar 17 21:23:28 2009
New Revision: 144920
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144920
Log:
gcc/
Revert
2008-10-14 Jakub Jelinek
P
--- Comment #10 from rwild at gcc dot gnu dot org 2009-03-17 21:29 ---
Fixed.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from rwild at gcc dot gnu dot org 2009-03-17 21:26 ---
Subject: Bug 37805
Author: rwild
Date: Tue Mar 17 21:25:59 2009
New Revision: 144921
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144921
Log:
gcc/
PR middle-end/37805
* opts.c (print_specific
--- Comment #3 from dodji at gcc dot gnu dot org 2009-03-17 21:25 ---
I am closing this bug as it seems to have been fixed.
Feel free to re-open it if it appears that I am wrong.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dodji at gcc dot gnu dot org 2009-03-17 21:24 ---
Created an attachment (id=17481)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17481&action=view)
The dwarf output of the test case above
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11208
--- Comment #1 from dodji at gcc dot gnu dot org 2009-03-17 21:23 ---
Created an attachment (id=17480)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17480&action=view)
Test case to compile.
Compiling this test case with debug info and without optimization shows that:
1/DW_TAG_memb
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-17 21:22
---
* cp/method.c (use_thunk): Change is_thunk from crtl to cfun.
in ChangeLog is incorrect. It should be
* method.c (use_thunk): Change is_thunk from crtl to cfun.
in cp/ChangeLog.
--
ebotcazou at gcc dot gnu
--- Comment #7 from paolo dot carlini at oracle dot com 2009-03-17 20:50
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo at gcc dot gnu dot org 2009-03-17 20:49 ---
Subject: Bug 39475
Author: paolo
Date: Tue Mar 17 20:49:23 2009
New Revision: 144919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144919
Log:
/cp
2009-03-17 Paolo Carlini
PR c++/39475
* s
--- Comment #3 from dougkwan at google dot com 2009-03-17 20:20 ---
Patch checked into trunk.
--
dougkwan at google dot com changed:
What|Removed |Added
Statu
--- Comment #2 from dougkwan at gcc dot gnu dot org 2009-03-17 20:18
---
Subject: Bug 39378
Author: dougkwan
Date: Tue Mar 17 20:18:21 2009
New Revision: 144918
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144918
Log:
2009-03-12 Jing Yu
PR middle-end/39378
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-17 19:46 ---
The updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00815.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #4 from hjl dot tools at gmail dot com 2009-03-17 19:17 ---
(In reply to comment #3)
> Is it really so hard to change UEFI apps?
You can take a look at testcases in gcc.target/x86_64/abi/callabi.
They have to use macros, like
---
static
void CALLABI_CROSS do_cpy (char *s, .
--- Comment #3 from basile at starynkevitch dot net 2009-03-17 19:07
---
I applied a slightly simplified variant of melt-patch-2.patch above as
rev144917
Thanks Rob. It probably works!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
--- Comment #5 from ubizjak at gmail dot com 2009-03-17 18:58 ---
Fixed in trunk.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #4 from uros at gcc dot gnu dot org 2009-03-17 18:55 ---
Subject: Bug 39482
Author: uros
Date: Tue Mar 17 18:55:40 2009
New Revision: 144915
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144915
Log:
PR target/39482
* config/i386/i386.md (*truncdfsf_m
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-17 17:57 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-17 17:56 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #14 from jakub at gcc dot gnu dot org 2009-03-17 17:56 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 17:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 17:55 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-17 17:53 ---
Subject: Bug 39474
Author: jakub
Date: Tue Mar 17 17:53:01 2009
New Revision: 144914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144914
Log:
PR debug/39474
* tree-ssa-live.c (remove_unused_l
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 17:52 ---
Subject: Bug 37890
Author: jakub
Date: Tue Mar 17 17:52:08 2009
New Revision: 144913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144913
Log:
PR debug/37890
* name-lookup.c (do_namespace_alia
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-17 17:49 ---
Subject: Bug 39471
Author: jakub
Date: Tue Mar 17 17:49:28 2009
New Revision: 144911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144911
Log:
PR debug/39471
* dwarf2out.c (dwarf2out_imported
--- Comment #2 from rob1weld at aol dot com 2009-03-17 17:48 ---
Created an attachment (id=17479)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17479&action=view)
A patch to ignore NULL "*mi->iniframp" from VEC_iterate() - shortcuts the issue
I am very unfamiliar with this branch
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-17 17:46 ---
Subject: Bug 39443
Author: jakub
Date: Tue Mar 17 17:46:23 2009
New Revision: 144910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144910
Log:
PR middle-end/39443
* optabs.c (set_user_assemble
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-17 17:44 ---
Subject: Bug 39412
Author: jakub
Date: Tue Mar 17 17:43:52 2009
New Revision: 144909
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144909
Log:
PR debug/39412
* dwarf2out.c (gen_inlined_enumera
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 17:42 ---
Is it really so hard to change UEFI apps?
The thing is that by adding the -mabi= option you pessimize x86_64 gcc even
more than the attribute patches have done. Now at least DEFAULT_ABI ==
SYSV_ABI
or DEFAULT_ABI != S
--- Comment #6 from janis at gcc dot gnu dot org 2009-03-17 17:36 ---
Subject: Bug 38526
Author: janis
Date: Tue Mar 17 17:35:55 2009
New Revision: 144908
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144908
Log:
gcc/
PR testsuite/38526
* Makefile.in (site.exp):
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-17 17:35 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00797.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #4 from joel at gcc dot gnu dot org 2009-03-17 17:32 ---
Going back through the old run logs. Is this how it shows up?
FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O0
FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O1
FAIL: gcc.c-torture/execute/b
--- Comment #3 from hp at gcc dot gnu dot org 2009-03-17 17:13 ---
(In reply to comment #2)
> Is there anything I can do to help with this?
If you could bisect the behaviour to a svn revision range, that might give a
clue.
See the description of the aforementioned bug (where it's unfort
--- Comment #4 from leo at marco dot de 2009-03-17 16:47 ---
Subject: Re: gcc generates incorrect trampoline code in
thumb mode
laurent at guerby dot net wrote:
> --- Comment #3 from laurent at guerby dot net 2009-01-02 12:29 ---
> This needs a testcase
>
>
Testcase:
void
--- Comment #1 from basile at starynkevitch dot net 2009-03-17 16:39
---
Bug confirmed.
The bug seems to appear on x86 (not amd64) when configure-ing with
--prefix=/usr/
A very temporary workaround could be to configure with --prefix=/usr/local/
--
http://gcc.gnu.org/bugzilla/sho
Compiling melt-branch revision 144904 with gcc 4.4.0 (Trunk),
4.3, or 4.1 results in a Segmentation fault in the modded 'cc1'
basilys_extra_marking() function.
Here is the "regular output" of where it fails:
Compiling ../../melt-branch/gcc/warmelt-outobj-0.c with -g
-fkeep-inline-functions -DIN_G
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
--- Comment #2 from basile at starynkevitch dot net 2009-03-17 15:57
---
Thanks. Patch commited as rev 144905 of MELT branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
--- Comment #3 from ubizjak at gmail dot com 2009-03-17 15:51 ---
(In reply to comment #2)
> See the third paragraph of the preceding comment to
> inline_secondary_memory_needed.
Oh, well. trunc* patterns violate this rule.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
--- Comment #1 from rob1weld at aol dot com 2009-03-17 15:45 ---
Created an attachment (id=17478)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17478&action=view)
Patch ggc-zone.c to support ggc_collect_1()'s call to
ggc_mark_roots_extra_marking()
--
http://gcc.gnu.org/bugzill
--- Comment #2 from ubizjak at gmail dot com 2009-03-17 15:43 ---
See the third paragraph of the preceding comment to
inline_secondary_memory_needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
This is a "blocker" but I only set the "Severity" to "major" since I
used a non-default configure option, _and_ I have the patch included.
Configuring with "--with-gc=zone" fails due to a coding error in ggc-zone.c .
Apply the patch to fix this. If the patch is OK, remove comment lines "/* */".
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-17 15:26 ---
Actually it seems the problem is the combination of int -> float conversion
and a call. Either alone doesn't trigger the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.3 4.4.0
Known to work||4.2.4
extern double log (double __x);
double foo(unsigned long int m_liOutputBufferLen)
{
return log((double)m_liOutputBufferLen);
}
ICEs with -mno-sse2
./cc1 -quiet t.i -mno-sse2
t.i: In function 'foo':
t.i:5: internal compiler error: in inline_secondary_memory_needed, at
config/i386/i386.c:25478
Pl
--- Comment #12 from swagiaal at redhat dot com 2009-03-17 15:17 ---
(In reply to comment #9)
> I no longer see any DWARF problem there but Archer C++ still does not work
> with
> g++-4.4. Assuming an Archer bug due to the new DW_TAG_lexical_block block.
>
Yes there are a couple I am
--- Comment #2 from ramana dot r at gmail dot com 2009-03-17 14:40 ---
This appears to be fixed on mainline on gcc version 4.4.0 20090317
(experimental) (GCC).
output obtained
42 69 105
42 69 105
--
ramana dot r at gmail dot com changed:
What|Removed
--- Comment #3 from sam at gcc dot gnu dot org 2009-03-17 14:28 ---
This is not a bug. The compiler really has no way to distinguish between the
following two interpretations for "Put (Get_Name (7))":
1- Get_Name (7) is a call to Get_Name with argument 7, which returns a String
2- G
--- Comment #18 from ramana dot r at gmail dot com 2009-03-17 14:27 ---
This commit here
http://gcc.gnu.org/viewcvs?view=rev&revision=143942 which is essentially a
backport of the patch http://gcc.gnu.org/viewcvs?view=rev&revision=137235 . If
this fixes the problem, then the bug can be
--- Comment #7 from js-gcc at webkeks dot org 2009-03-17 14:05 ---
> Since I wasn't able to get a cross tool chain running (and www.mingw.org
> doesn't seem to support that with the current gcc versions)
Please have a look at the Portfiles I gave you a link to, they include all the
stuf
--- Comment #2 from joel at gcc dot gnu dot org 2009-03-17 14:02 ---
Yes.
See http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00362.html.
We also cross post them to an RTEMS tool list and apparently the run on 12
March
resulted in a log that was too large for gcc-testresults.
htt
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-03-17 13:46
---
Cold case analysis time. Have you seen this problem in recent releases of GCC?
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from paolo dot carlini at oracle dot com 2009-03-17 13:35
---
Jason, could you maybe double check this one too?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #16 from paolo dot carlini at oracle dot com 2009-03-17 13:34
---
Correction: technically 4_2-branch is still open, but no further releases are
expected and will be definitely closed as soon as the 4_4-branch is created
(very soon)
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from irar at il dot ibm dot com 2009-03-17 13:33 ---
(In reply to comment #2)
> Or like the following, which is just a bunch of reductions of two elements
> float data[1024];
> void foo(void)
> {
> int i;
> for (i = 1; i < 1024; ++i)
> data[i] = data[i] + data[i-1]
--- Comment #15 from paolo dot carlini at oracle dot com 2009-03-17 13:32
---
To be clear, I'm not sure this is invalid, I agree with you that we should
understand the issue in better detail. I'll make sure we do the additional
investigation.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #14 from fpbeekhof at gmail dot com 2009-03-17 13:28 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #13 from paolo dot carlini at oracle dot com 2009-03-17
> 13:26 ---
> If it affects only
--- Comment #13 from paolo dot carlini at oracle dot com 2009-03-17 13:26
---
If it affects only 4_2-branch would be zero, because it's no longer maintained
;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #12 from paolo dot carlini at oracle dot com 2009-03-17 13:25
---
Apparently, mainline and 4_3-branch do not call memcpy, expand the operator
inline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #10 from paolo dot carlini at oracle dot com 2009-03-17 13:15
---
The component would be c++, because that is a C++ thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #11 from fpbeekhof at gmail dot com 2009-03-17 13:19 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #10 from paolo dot carlini at oracle dot com 2009-03-17
> 13:15 ---
> The component would
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-17 13:12 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #4 from hjl at gcc dot gnu dot org 2009-03-17 13:12 ---
Subject: Bug 39477
Author: hjl
Date: Tue Mar 17 13:11:58 2009
New Revision: 144904
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144904
Log:
2009-03-17 H.J. Lu
Backport from mainline:
2009-0
--- Comment #9 from fpbeekhof at gmail dot com 2009-03-17 13:11 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #8 from paolo dot carlini at oracle dot com 2009-03-17 12:33
> ---
> Yes, if there is a bu
--- Comment #3 from hjl at gcc dot gnu dot org 2009-03-17 13:10 ---
Subject: Bug 39477
Author: hjl
Date: Tue Mar 17 13:10:24 2009
New Revision: 144903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144903
Log:
2009-03-17 H.J. Lu
PR target/39477
* doc/extend.t
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-03-17 13:09
---
Btw, it looks like internal IRA data-structures can be shrinked on 64bit
platforms by avoiding padding between pointer and integer members a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-17 12:59 ---
The patch is at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00759.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-03-17 12:58
---
For trunk -O1 I see
CPU: AMD64 processors, speed 1000 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask
of 0x00 (No unit mask) count 10
samples %symbol na
--- Comment #6 from hjl dot tools at gmail dot com 2009-03-17 12:57 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 12:55
---
Sorry, CC-ed Jakub instead of Jason ;)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #5 from hjl at gcc dot gnu dot org 2009-03-17 12:55 ---
Subject: Bug 39476
Author: hjl
Date: Tue Mar 17 12:55:18 2009
New Revision: 144902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144902
Log:
2009-03-17 H.J. Lu
PR target/39476
* config/i386/
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-17 12:55
---
Jason, are you willing to help triaging this one?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from hjl dot tools at gmail dot com 2009-03-17 12:52 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #6 from hjl at gcc dot gnu dot org 2009-03-17 12:51 ---
Subject: Bug 39473
Author: hjl
Date: Tue Mar 17 12:50:52 2009
New Revision: 144901
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144901
Log:
2009-03-16 H.J. Lu
PR target/39473
* config/i386/
--- Comment #1 from receive-spam at yandex dot ru 2009-03-17 12:42 ---
Oops, asterisk before "import" should be removed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39481
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-03-17 12:42
---
Vlad, for the second testcase I see
-O0:
expand: 0.78 (19%) usr 0.04 ( 5%) sys 0.83 (16%) wall
44335 kB (49%) ggc
integrated RA : 1.05 (25%) usr 0.03 ( 4%) sys 1.13 (22%) w
Test program:
*import java.util.StringTokenizer;
public class gcjbug {
public static void main(String[] args) {
StringTokenizer t = new StringTokenizer("#a=1 #b=2");
for (int i = 0; i < 2; i++) {
if (t.hasMoreTokens())
System.out.println(t.nextToken
--- Comment #8 from paolo dot carlini at oracle dot com 2009-03-17 12:33
---
Yes, if there is a bug, certainly it is not in libstdc++. Also, please find
somebody able to reproduce it, I can't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-17 12:28 ---
Created an attachment (id=17477)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17477&action=view)
gcc44-local-imported-decl.patch
Yeah, I know, found that out already during my regtest. Here is what I'm
bootst
--- Comment #10 from jan dot kratochvil at redhat dot com 2009-03-17 12:24
---
ICE: Comment 7 patch (applied together with the Comment 3 patch) on:
namespace A
{
class B
{
};
};
extern void g ();
vo
--- Comment #7 from fpbeekhof at gmail dot com 2009-03-17 12:21 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 11:28
> ---
> By the way, I don't s
--- Comment #6 from falk at debian dot org 2009-03-17 12:10 ---
(In reply to comment #1)
> calling memcpy with exactly overlapping operands is safe (obviously).
It's not safe at all. A memcpy implementation might use a "prefetch with write
intent" instruction that allocates a cache line
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-17 11:41
---
This isn't something that should be fixed in the back-end, but most likely an
enhancement to a pass such as ifcvt. To handle this case we would have to
teach ifcvt about dominated conditions and conditional compar
--- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 11:28
---
By the way, I don't see what could be possibly wrong in libstdc++: can you
please tell us which specific line of code you are suspecting? Certainly, not
the entire swap implementation, which is definitely the c
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-03-17 11:19
---
(In reply to comment #6)
> foo:
> mov r3, r0
> cmn r1, r0
> rsbeq r0, r1, r0
> rsbne r0, r3, r1
> bx lr
This appears to be the code generated at -O1 and alt
--- Comment #4 from fpbeekhof at gmail dot com 2009-03-17 11:15 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #2 from paolo dot carlini at oracle dot com 2009-03-17 11:04
> ---
> by the way, I cannot
--- Comment #3 from fpbeekhof at gmail dot com 2009-03-17 11:13 ---
Subject: Re: generated memcpy causes trouble in assignment
rguenth at gcc dot gnu dot org wrote:
> --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-17 10:59
> ---
> calling memcpy with exactly ove
1 - 100 of 125 matches
Mail list logo
