--- Comment #3 from mt at debian dot org 2009-02-05 23:04 ---
I should have added that this worked fine on 4.2 and was broken as of 4.3.1 at
least, earlier versions (> 4.2) untested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39115
--- Comment #3 from gnu_andrew at member dot fsf dot org 2009-02-05 23:09
---
Committed to GNU Classpath for 0.98.
CVSROOT:/sources/classpath
Module name:classpath
Changes by: Andrew John Hughes 09/02/05 22:54:11
Modified files:
. : ChangeLog
--- Comment #10 from jakub at gcc dot gnu dot org 2009-02-05 23:39 ---
Just s/class ios_base/struct ios_base/ if you don't want 4.3 to reject it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-02-06 00:29 ---
Subject: Bug 38991
Author: kkojima
Date: Fri Feb 6 00:29:03 2009
New Revision: 143978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143978
Log:
PR target/38991
* config/sh/predicates.md (ge
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Target Milestone|--- |4.3.4
http:/
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-02-06 01:23
---
Not a gcc bug so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-06 01:35 ---
> tv = my_tv_maker(434.23); // over-write previous tv.
This needs to have a space for the return value as tv can be accessed via
my_tv_maker as the address of it was passed to an extern function.
Think of:
exte
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 01:37 ---
I don't get a segfault on the trunk but I do get an error message:
t.cc: In instantiation of 'const int junk::value':
t.cc:6: instantiated from here
t.cc:4: error: no matching function for call to 'junk::test(int)'
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 01:42 ---
r11 is saved by the caller so this is the generated code is valid.
Since nothing else uses r11 in the inline-asm, the code is correct.
>From the i386.h header:
The value is zero if the register is not call used o
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-06 01:45 ---
(In reply to comment #3)
> Are the casts actually needed in this case? It seems the get introduced very
> early on, the .original dump already has:
Yes because char = char + char is really char = (char)((int)char +
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-06 01:45 ---
*** Bug 39068 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The inline assembly can end up generating instructions of the form
mulq %rax when the two operands should be distinct (i.e. one should not compute
%rax * %rax, a square but a product of two different numbers).(The x86 mulq
instruction will compute the product of the operand with the %rax register)
--- Comment #1 from fabrice at mocana dot com 2009-02-06 01:50 ---
Created an attachment (id=17257)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17257&action=view)
preprocessed file
Note that all multiplicands are distinct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3911
--- Comment #2 from fabrice at mocana dot com 2009-02-06 01:51 ---
Created an attachment (id=17258)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17258&action=view)
generated assembly
note the mulq %rax instruction towards the end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-06 01:51 ---
(In reply to comment #4)
> Yes because char = char + char is really char = (char)((int)char + (int)char);
Let me expand on that. ((char)CHAR_MAX) + 1 is well defined and there is no
overflow that occurs. Since GCC
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-06 01:58 ---
b[1] is uninitialized.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 02:11 ---
Works on the trunk:
bl _Z11my_tv_makerf
nop
mr 3,31
bl _ZN2TV4getTEv
nop
tv = my_tv_maker (4.34230010986328125e+2); [return slot optimization]
D.1758 = getT (&tv);
--
--- Comment #2 from rob1weld at aol dot com 2009-02-06 02:15 ---
There really is some trouble with the scripts in this area.
As you might expect simply restarting the make simply repeats the
trouble, shows the same errors and ends the build.
If you restart the build with "gmake -i -k"
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 02:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 02:25 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
>From this thread:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00271.html
Compiling with -c -g -O2 -Wall from r143978, I only get one warning, but should
get two.
struct A
{
int j;
int i;
};
void foo()
{
char buf[sizeof(struct A)];
// warns
((struct A*)buf)->i = 1;
// does not
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-06 02:41 ---
This is looks like PR 29039.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 02:46 ---
Do you know what temporary files are being used here? Is it an issue with the
driver or with the reader?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39042
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-06 03:36 ---
LTO creates huge temporary assembly files, some of which > 2GB.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39042
--- Comment #4 from fabrice at mocana dot com 2009-02-06 03:48 ---
(In reply to comment #3)
> b[1] is uninitialized.
Yes, initializing b[1] makes the problem go away in the snippet. I see this
problem in a much larger program but I can't reproduce it in a simple context.
Feel free to cl
--- Comment #11 from nightstrike at gmail dot com 2009-02-06 04:21 ---
Created an attachment (id=17259)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17259&action=view)
Kai's attempt
This patch has a few caveats:
You can't use the winsup link hack to work around the issue that Co
--- Comment #5 from fabrice at mocana dot com 2009-02-06 04:24 ---
(In reply to comment #4)
> Yes, initializing b[1] makes the problem go away in the snippet. I see this
> problem in a much larger program but I can't reproduce it in a simple context.
> Feel free to close the bug as inval
This is a bug report for gcc 4_3 branch. I will attach a test case, slightly
reduced from zlib code. When compiling this test case for the x86_64-linux
target with -O2 -fomit-frame-pointer, I see this at the start of the function:
adler32:
pushq %rbp
movq%rdi, %rax
--- Comment #1 from ian at airs dot com 2009-02-06 05:53 ---
Created an attachment (id=17260)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17260&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
--- Comment #2 from valery_reznic at yahoo dot com 2009-02-06 07:12 ---
(In reply to comment #1)
> r11 is saved by the caller so this is the generated code is valid.
> Since nothing else uses r11 in the inline-asm, the code is correct.
The problem is not that r11 not saved at stack, but
--- Comment #28 from bonzini at gnu dot org 2009-02-06 07:33 ---
Subject: Bug 35659
Author: bonzini
Date: Fri Feb 6 07:33:05 2009
New Revision: 143980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143980
Log:
2009-02-06 Paolo Bonzini
PR tree-optimization/35659
101 - 132 of 132 matches
Mail list logo
