--- Comment #2 from ubizjak at gmail dot com 2008-04-25 06:27 ---
You need to backport http://gcc.gnu.org/viewcvs?view=revrevision=128549
*** This bug has been marked as a duplicate of 26449 ***
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #25 from ubizjak at gmail dot com 2008-04-25 06:27 ---
*** Bug 36039 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #26 from ubizjak at gmail dot com 2008-04-25 06:29 ---
Reopened.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #22 from KnowlesPJ at Cardiff dot ac dot uk 2008-04-25 08:10
---
Yes, this was the silver bullet. With
Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../configure --prefix=/opt/gcc
Thread model: posix
gcc version 4.4.0 20080424 (experimental) (GCC)
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-25 08:44 ---
The implementation is written so it is also reasonable on targets like the AVR
which only has 8bit registers...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 08:42 ---
Also the ABI specifies that function arguments in registers are sign/zero
extended according to their sign to the full width of the registers, maybe what
calles
this function is not adhering to this?
--
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-25 09:21 ---
The alias sets seem to be wrong already in the *.expand dump:
(insn 7 6 8 3 pr36013.c:6 (set (reg/f:DI 58 [ D.1430 ])
(mem/f:DI (reg/v/f:DI 59 [ p ]) [4 S8 A64])) -1 (nil))
(insn 8 7 9 3 pr36013.c:6 (set
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 09:24 ---
We seem to use some interesting pointer induction variable for the exit test...
-fno-ivopts fixes it I suppose. The loop in question ends up being expanded
from
bb 3:
# VUSE SMT.26_37
D.1307_34 = MEM[base:
For the following programm gcc produces wrong code. To pass the struct colour
by value gcc reads 8 bytes although the struct has a size of 6. This causes
reads after allocated memory. In the example program the memory is mmap'ed and
the last element passed. The 8 byte read crosses page boundaries
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-25 09:51 ---
D.1374_18 = D.1373_17 * 0x0fff8;
D.1375_19 = (long long int *) D.1374_18;
This looks wrong.
So does this:
# ivtmp.36_25 = PHI 0B(2), ivtmp.36_16(3)
Both of those really should be in unsigned
--- Comment #8 from ubizjak at gmail dot com 2008-04-25 09:55 ---
The problem is indeed in trisolve:
subroutine trisolve(x,i1,i2)
integer :: i1 , i2
real(dpkind),dimension(i2)::x
integer :: i
x(i1) = gi(i1)* x(i1)
do i = i1+1 , i2
x(i) = gi(i)*(x(i)-au1(i-1)*x(i-1))
enddo
do i =
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-04-25 10:23 ---
Not hoisting the load from x(i) is a missed PRE opportunity. Complete testcase
for the second loop:
subroutine trisolve2(x,i1,i2,nxyz)
integer :: nxyz
real,dimension(nxyz):: au1
real,allocatable,dimension(:) :: gi
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-25 10:06 ---
if (u TREE_CODE (u) == VAR_DECL DECL_BASED_ON_RESTRICT_P (u))
u = DECL_GET_RESTRICT_BASE (u);
in internal_get_tmp_var looks wrong to me. That together with
find_single_pointer_decl not respecting
--- Comment #3 from pcarlini at suse dot de 2008-04-25 10:35 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01064.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
--- Comment #10 from ubizjak at gmail dot com 2008-04-25 11:07 ---
(In reply to comment #9)
Not hoisting the load from x(i) is a missed PRE opportunity. Complete
testcase
for the second loop:
This is actually the first loop.
Just for reference: -O2 -funroll-loops flags are
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-25 11:37 ---
The patch didn't come with any testcases, so it is hard to find out what
exactly is supposed to mean DECL_BASED_ON_RESTRICT_P on a decl. Is that
supposed to
be on the same level of indirection as some TYPE_RESTRICT
--- Comment #3 from earthengine at gmail dot com 2008-04-25 11:53 ---
(In reply to comment #1)
Since there is no 4.3.1 release, only 4.3.0, can I assume you mean 4.3.0 for
the Reported Against field?
libtool issues should be fixed in libtool if possible, and not hacked around
in
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-04-25 12:05
---
Please post the link commands that expose the self reference
(the libtool --mode=link stuff and whatever it generates).
Also how exactly you configure GCC. Also please post
cd $host/libstdc++-v3 ./libtool
It would be nice to have an intrinsic function to generate a user-requested
backtrace, like ifort's TRACEBACKQQ. Of course this would be a non-standard
extension, but a useful one which many other compilers also provide.
There has already been some discussion on this in PR30498, with suggested
--- Comment #4 from intvnut at gmail dot com 2008-04-25 12:29 ---
Is there a mechanism to provide different implementations based on the target
(or in this case, class of target)? The byte count approach certainly is more
appropriate for 8-bit targets, sure, but what about the rest of
Compile as
g++ -O2 -m64 h.ii ./a.out
The code should print 2; it does so with GCC 3.4.6, GCC 4.1.2 and GCC 4.2.1.
It prints 1.27688e-161 (or any other random value) with GCC 4.3; valgrind
complains about
==14214== Invalid read of size 8
==14214==at 0x4007F0: HD::e(int) const (in a.out)
--- Comment #1 from gcc at axel-naumann dot de 2008-04-25 13:41 ---
Created an attachment (id=15530)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15530action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36045
See attached test case.
--
Summary: Demangler fails on templates with non-type reference
parameters
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
--- Comment #1 from jjk at acm dot org 2008-04-25 13:57 ---
Created an attachment (id=15531)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15531action=view)
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
--- Comment #5 from earthengine at gmail dot com 2008-04-25 14:12 ---
(In reply to comment #4)
Please post the link commands that expose the self reference
(the libtool --mode=link stuff and whatever it generates).
Also how exactly you configure GCC. Also please post
cd
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 14:49 ---
*** This bug has been marked as a duplicate of 36017 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-25 14:49 ---
*** Bug 36045 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-25 14:52 ---
It should be possible to have an alternate implementation in libgcc2.c by means
of just selecting on a proper architecture define or the size of the argument
mode.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-25 14:55 ---
Hmm, didn't we fix this? ...
movw$115, (%rax)
movw$122, 2(%rax)
movw$98, 4(%rax)
movq(%rax), %rdi
callprint_colour
--
rguenth at gcc dot gnu dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 14:59 ---
Ahm, not exactly a dup of PR31309.
Shorter (non-runtime) testcase:
struct colour
{
unsigned short red;
unsigned short green;
unsigned short blue;
};
void print_colour(struct colour col);
void foo(struct
--- Comment #57 from oblivian at users dot sourceforge dot net 2008-04-25
15:00 ---
I don't have permissions to change the status, but it looks like bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33503 is a dup or at least related
if someone wants to clean it up.
--
[EMAIL PROTECTED]:~/cc$ echo 'int main(void) { return 0; }' file.c
[EMAIL PROTECTED]:~/cc$ m68k-linux-gnu-gcc -o file file.c -static -pg
/tmp/ccw33VYP.o: In function `main':
file.c:(.text+0x6): relocation truncated to fit: R_68K_PC16 against `.data'
collect2: ld returned 1 exit status
It works
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-25 15:08 ---
The problem is that struct colour is laid out like
arg 0 parm_decl 0x2b4f8506e2d0 c
type pointer_type 0x2b4f85160780 type record_type 0x2b4f85160540
colour
unsigned DI
size
--- Comment #4 from matz at gcc dot gnu dot org 2008-04-25 15:12 ---
That's the layout of 'c', a pointer variable. We don't see the layout
of the record_type here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-25 15:17 ---
Forget that. load_register_parameters converts
(mem/s:BLK (reg/v/f:DI 58 [ c ]) [0 S6 A16])
to
(mem/s:BLK (reg/v/f:DI 58 [ c ]) [0 S6 A16])
here:
else if (partial == 0 || args[i].pass_on_stack)
--- Comment #1 from bonzini at gnu dot org 2008-04-25 15:21 ---
*** This bug has been marked as a duplicate of 35752 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #58 from bonzini at gnu dot org 2008-04-25 15:21 ---
*** Bug 33503 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-25 15:29 ---
Errm. change_address_1 simply builds a DImode mem (with alignment
info properly retained)
#0 0x005e80c2 in adjust_address_1 (memref=0x2b0751d81520,
mode=DImode, offset=0, validate=0, adjust=1)
at
--- Comment #3 from sje at cup dot hp dot com 2008-04-25 15:34 ---
Fixed with patch that removes the bad check.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-25 15:43 ---
So, the problem is in move_block_to_reg that copies the argument piecewise
to regs like
for (i = 0; i nregs; i++)
emit_move_insn (gen_rtx_REG (word_mode, regno + i),
operand_subword_force
--- Comment #8 from matz at gcc dot gnu dot org 2008-04-25 16:15 ---
FWIW, I think the error is in the caller of move_block_to_reg.
move_block_to_reg can make use of a load_multiple instruction, which really
loads full regs. I.e. it would be unreasonable to require changes in
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-04-25 16:20 ---
Index: calls.c
===
--- calls.c (revision 134659)
+++ calls.c (working copy)
@@ -2708,7 +2708,7 @@ expand_call (tree exp, rtx target, int i
--- Comment #7 from bkoz at gcc dot gnu dot org 2008-04-25 16:53 ---
Subject: Bug 35887
Author: bkoz
Date: Fri Apr 25 16:52:57 2008
New Revision: 134671
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134671
Log:
2008-05-25 Benjamin Kosnik [EMAIL PROTECTED]
Revert PR
--- Comment #4 from bunk at stusta dot de 2008-04-25 17:38 ---
Works with 4.3-20080424, so whatever it was it seems to be already fixed.
--
bunk at stusta dot de changed:
What|Removed |Added
--- Comment #8 from bkoz at gcc dot gnu dot org 2008-04-25 18:38 ---
Subject: Bug 35887
Author: bkoz
Date: Fri Apr 25 18:37:22 2008
New Revision: 134675
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134675
Log:
2008-04-25 Benjamin Kosnik [EMAIL PROTECTED]
PR
The code snippet below compiles correctly without optimization, but with the
optimization flag turned on (at least with -O2) the compiler wrongly assumes
that the register %edx was not modified by the inline assembly statement.
The bug can be reproduced by issuing the following command.
To
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-25 19:01 ---
that the register %edx was not modified by the inline assembly statement.
Yes that is because your constraints only say the inline-asm reads the value
and not modifies it.
: : a (d1), c (d2), d
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-04-25 20:12 ---
Subject: Bug 35960
Author: tkoenig
Date: Fri Apr 25 20:11:19 2008
New Revision: 134677
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134677
Log:
2008-04-25 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #13 from bunk at stusta dot de 2008-04-25 20:46 ---
Rask, what is the status of your patch?
It would be nice if this bug was fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-04-25 20:52 ---
*** This bug has been marked as a duplicate of 17308 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-25 20:52 ---
*** Bug 30043 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jlima at sim dot ul dot pt 2008-04-25 20:56 ---
If this is the expected behavior... then ok.
I saw this as a bug because it is not possible to add the register to the
clobbered registers list (gcc will complain with: error: can't find a register
in class 'DREG' while
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-25 20:59 ---
It often required to modify/reuse an input register inside the inline assembly
statement.
Just a temporary variable then. The compiler will do its job. Make sure you
mark it as an early clobber too :).
--
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-04-25 21:15 ---
Subject: Bug 35156
Author: dfranke
Date: Fri Apr 25 21:14:49 2008
New Revision: 134680
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134680
Log:
2008-04-25 Tobias Burnus [EMAIL PROTECTED]
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-04-25 21:24 ---
Fixed on trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from zadeck at naturalbridge dot com 2008-04-25 21:34
---
any regressions, if any exist at all, must be addressed by vlad's new register
allocator.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
The m68k build outputs bad assembly code around an inline assembly block.
Compiling the attached file with gcc 4.3.0 and binutils 2.18 for
--target=m68k-unknown-uclinux-uclibc on --host=i486-linux-gnu, I get:
Error: junk at end of line, first unrecognized character is `|'
I won't attach the
--- Comment #1 from kendallc at vxitech dot com 2008-04-25 21:56 ---
Created an attachment (id=15532)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15532action=view)
test code that exhibits the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36049
Hi,
It would be great if ? warned when it got a (presumably accidental) assignment
like if statements do; e.g.
$ cat test.c
int main (void)
{
int i;
return (i = 20) ? 10 : 15;
}
$ gcc-4.3 -Wall test.c
It seems like this would be quite a common mistake?
--
The code snippet below compiles correctly without optimization, but with the
optimization flag turned on (at least with -O2) the compiler wrongly assumes
that the register %edx was not modified by the inline assembly statement.
The bug can be reproduced by issuing the following command.
To
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-25 22:23 ---
*** This bug has been marked as a duplicate of 36048 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-25 22:23 ---
*** Bug 36051 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36048
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-04-25 23:15 ---
Subject: Bug 35843
Author: hubicka
Date: Fri Apr 25 23:14:40 2008
New Revision: 134682
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134682
Log:
PR testsuite/35843
* cfgexpand.c
Here's an annoying regression:
-
struct S {
typedef double value_type;
};
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-25 23:55 ---
This warning is correct, and not really bogus as the qualification is ignored
on the return value here even though not explicitly written by the user in the
function declaration.
--
pinskia at gcc dot gnu dot
--- Comment #2 from bangerth at math dot tamu dot edu 2008-04-26 00:01
---
Subject: Re: type qualifiers ignored warning
This warning is correct, and not really bogus as the qualification is ignored
on the return value here even though not explicitly written by the user in the
--- Comment #2 from bangerth at dealii dot org 2008-04-26 00:22 ---
Confirmed. The demangler gets a valid symbol it can't demangle.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2008-04-26 00:25 ---
By the way, the return code of __cxa_demangle is
-2: mangled_name is not a valid name under the C++ ABI mangling rules.
as per
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-26 00:39 ---
This is expected, we should not be demangling types with __cxa_demangle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-26 00:47 ---
Ok, this is a generic demangler issue, we don't demangle _Z1f3barILZ3bazEE
either.
Which is f(barbaz) but only because it is mangled incorrectly in the first
place.
So the real issue here is that the demangle only
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-26 00:53 ---
so all three versions mangle it differently
if we have f(barbaz)
1: _Z1f3barIXadL_Z3bazEEE
2: _Z1f3barILZ3bazEE
3: _Z1f3barIL_Z3bazEE
I think 3 is correct as the underscore is needed and the address is not
--- Comment #7 from ian at airs dot com 2008-04-26 00:57 ---
See bug #16240 for some background.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
--- Comment #2 from kendallc at vxitech dot com 2008-04-26 01:40 ---
Marking my own bug as invalid because it looks like gas should accept | as a
comment. I guess this is a binutils problem.
--
kendallc at vxitech dot com changed:
What|Removed
--- Comment #6 from bkoz at gcc dot gnu dot org 2008-04-26 02:22 ---
Subject: Bug 35922
Author: bkoz
Date: Sat Apr 26 02:21:37 2008
New Revision: 134693
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134693
Log:
2008-04-25 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-04-26
03:17 ---
(In reply to comment #1)
What is the status on this? Does reverting the langhooks.c change remanifest
PR27067?
No. PR27067 is fixed by
cp/mangle.c (mangle_decl): Call
--- Comment #3 from aaronavay62 at aaronwl dot com 2008-04-26 04:13 ---
(In reply to comment #2)
(In reply to comment #1)
What is the status on this? Does reverting the langhooks.c change
remanifest
PR27067?
No. PR27067 is fixed by
cp/mangle.c (mangle_decl): Call
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-04-26 04:27
---
This problem is worse then thought. It also extends to the SUM intrinsic which
uses a similar code pattern. When MASK is a scalar and false the code that
should traverse the destination array and set the values
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-26 05:20 ---
(In reply to comment #2)
Also the ABI specifies that function arguments in registers are sign/zero
extended according to their sign to the full width of the registers, maybe
what
calles
this function is not
78 matches
Mail list logo
