--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-04-26 06:17
---
I am going to un assign myself. I think we need a team effort here.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-04-26 06:14
---
I am also seeing this same issue with all the array intrinsics that accept a
mask if it is scalar and .false. At this point I am calling for some second
opinions here. The bad code is in the "s" version of each o
--- 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 no
--- 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 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): Cal
--- 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 targetm.mangle_decl_assem
--- 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=gcc&view=rev&rev=134693
Log:
2008-04-25 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstd
--- 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 #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 #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(bar)
1: _Z1f3barIXadL_Z3bazEEE
2: _Z1f3barILZ3bazEE
3: _Z1f3barIL_Z3bazEE
I think 3 is correct as the underscore is needed and the address is not
supplied..
b
--- 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(bar) but only because it is mangled incorrectly in the first
place.
So the real issue here is that the demangle only hand
--- 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 #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
http://docs.mandragor.org/files/Programming_languages/Cpp/libstdcpp_v3_Source_Documentat
--- 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 #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 #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 org
Here's an annoying regression:
-
struct S {
typedef double value_type;
};
--- 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=gcc&view=rev&rev=134682
Log:
PR testsuite/35843
* cfgexpand.c (pass_expan
--- 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 #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
--
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 reprodu
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?
--
Sum
--- 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=15532&action=view)
test code that exhibits the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36049
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 assem
--- 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
--- 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 #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=gcc&view=rev&rev=134680
Log:
2008-04-25 Tobias Burnus <[EMAIL PROTECTED]>
Da
--- 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 :).
--
h
--- 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:52 ---
*** Bug 30043 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- 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 #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 #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=gcc&view=rev&rev=134677
Log:
2008-04-25 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- 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),
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 reprodu
--- 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=gcc&view=rev&rev=134675
Log:
2008-04-25 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstd
--- 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 #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=gcc&view=rev&rev=134671
Log:
2008-05-25 Benjamin Kosnik <[EMAIL PROTECTED]>
Revert P
--- 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 #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
move_bloc
--- 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 #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 #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 #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 #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 #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 #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 #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
unsigned DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x2b4f85160780>
used u
[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 f
--- 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.
--
http://gcc.gnu
--- 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 col
--- 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 ch
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- 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 #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 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 $host/
--- 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=15531&action=view)
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
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++
A
--- 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=15530&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36045
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.ou
--- 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 u
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
wor
--- 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 -
--- 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
--- 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 po
--- 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 ne
--- 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 #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 i
--- 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 = i2-1
--- 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 unsign
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 a
--- 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
:
# VUSE
D.1307_34 = MEM[base: stack_base.2_4, o
--- 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 (mem:
--- 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?
--
http://g
--- 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)
77 matches
Mail list logo
