--- Comment #3 from amodra at gmail dot com 2010-06-16 05:59 ---
Confirmed on powerpc-linux. check_fa tail calls check_fa_mid, ignoring the
fact that check_fa_mid is passed the address of a check_fa local var.
1510 check_fa:
1510: 94 21 ff e0 stwur1,-32(r1)
--- Comment #10 from wilson at codesourcery dot com 2010-06-16 06:30
---
Subject: Re: suboptimal MIPS widening multiply accumulate
On Wed, 2010-06-09 at 20:21 +, bernds at gcc dot gnu dot org wrote:
What do you think? Please let me know what your MIPS tests turned up.
I'm
--- Comment #13 from jakub at gcc dot gnu dot org 2010-06-16 06:55 ---
This looks wrong. The code in expand_one_stack_var_at (before dynamic stack
realignment) made perfect sense, if we gave a bigger alignment to some variable
(e.g. automatic array), it is useful to tell the expanders
This bug has originally been reported on Glibc bugtracker:
http://sourceware.org/bugzilla/show_bug.cgi?id=11670
Please look here first for a detailed description.
The __sigsetjmp function returns twice so it's not allowed to reuse stack space
of existing automatic variables after this function
--- Comment #1 from christian dot eggers at kathrein dot de 2010-06-16
07:17 ---
Created an attachment (id=20925)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20925action=view)
Preprocessed source
compile with arm-linux-gnueabi-gcc -mcpu=arm920t -Os -o test.o -c test.i
This
--- Comment #2 from christian dot eggers at kathrein dot de 2010-06-16
07:18 ---
Created an attachment (id=20926)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20926action=view)
Object file (for reference)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2010-06-16 08:31
---
Fixed in revision 160824.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-16 08:48
---
Joaquin, I'm trying to investigate this in some detail, and I think it would be
good if the LWG knew also about this performance issue with begin(), besides
579, I cannot find anywhere a discussion about
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-16 08:58 ---
you need to mark y and x volatile.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-16 09:02 ---
This is probably missing combiner patterns in sse.md.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from schwab at linux-m68k dot org 2010-06-16 09:06 ---
If the variable is not modified between setjmp and longjmp the compiler is
required to preserve its value.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-16 09:07 ---
CallTip.cxx: In member function 'void CallTip::DrawChunk(Surface*, int, const
char*, int, int, int, PRectangle, bool, bool)':
CallTip.cxx:87:6: error: control flow in the middle of basic block 64
CallTip.cxx:87:6:
--- Comment #22 from dominiq at lps dot ens dot fr 2010-06-16 09:13 ---
(In reply to comment #20)
Could the patch in comment #17 explain the following failures? ...
False alarm! AFAICT the failures where due to messed up libs for mpfr and mpc
while trying to update to mpfr 3.0. Sorry
$ cat ptr.c
#include stdio.h
struct a {
charb[100];
int a;
};
int main(int argc, char *argv[])
{
struct a *a = NULL;
void *ptr;
if (a-b)
puts(ok, not null #1);
if (a-b == NULL)
puts(ok, null ? #1);
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-16 09:21 ---
The miscompilation occurs between -finline-limit=300 (works) and =400
(Segmentation fault). This seems related to the inlining of the subroutine
'fourir2d' (called 4 times with =400) instead of 'fourir' (called 14
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-16 09:30 ---
class CallTip {
int tabSize;
int DrawChunk(int x);
int NextTabPos(int x);
};
int CallTip::NextTabPos(int x)
{
if (tabSize 0) {
x -= 5;
x = (x + tabSize) / tabSize;
}
}
int
--- Comment #1 from schwab at linux-m68k dot org 2010-06-16 09:35 ---
The first operand of - must be a valid pointer to an object.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-16 09:45 ---
The __cancel_arg variables are pseudos until ira, apparently during IRA the 2
stack slots chosen for those are shared between __cancel_arg vars and other
vars used later in the function. Do we need to act as if
Attempting to compile the following code:
module dealloc_test
implicit none
type test_type
integer, dimension(:), allocatable :: array
integer :: st
end type test_type
contains
subroutine test
type(test_type) :: foo
deallocate(foo%array, stat=foo%st)
end
--- Comment #2 from zilvinas dot valinskas at gmail dot com 2010-06-16
10:29 ---
I don't agree. This is an optimizer bug (dead code elimination don't know
much of GCC). Consider that there is a function like this:
$ cat ptr.h
struct a {
charb[100];
int a;
};
--- Comment #18 from sfilippone at uniroma2 dot it 2010-06-16 10:32 ---
(In reply to comment #17)
Dear All,
The attached source file contains the same kind of test as the original
testd15, and yet it fails. So, there's something missing from the patch, even
without considering the
--- Comment #19 from sfilippone at uniroma2 dot it 2010-06-16 10:32 ---
Created an attachment (id=20927)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20927action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-16 10:43 ---
can you say undefined behaviour ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44555
--- Comment #4 from schwab at linux-m68k dot org 2010-06-16 10:53 ---
Undefined behaviour.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-16 11:04 ---
Subject: Bug 44538
Author: rguenth
Date: Wed Jun 16 11:04:08 2010
New Revision: 160827
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160827
Log:
2010-06-16 Mikael Pettersson mi...@it.uu.se
PR
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-16 11:04
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-16 11:05 ---
Subject: Bug 44538
Author: rguenth
Date: Wed Jun 16 11:05:40 2010
New Revision: 160828
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160828
Log:
2010-06-16 Mikael Pettersson mi...@it.uu.se
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-16 11:23 ---
I'd argue it's a QOI issue that the C frontend via
c_objc_common_truthvalue_conversion should not convert
if (a-b)
to
if (0)
if the offset of b is zero.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-16 11:23 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-16 11:31 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-16 11:35 ---
Obvious patch, removing the premature (and bogus) optimization:
Index: c-common.c
===
--- c-common.c (revision 160826)
+++ c-common.c (working copy)
--- Comment #5 from jules at gcc dot gnu dot org 2010-06-16 11:41 ---
I am working on this.
--
jules at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-16 11:54 ---
Value range-propagation (VRP) does not work on disjoint ranges, so the compiler
does not actually know that argc can only be 1, 2 or 4. I think there is
already a PR about this but I cannot find it right now.
--
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-16 11:58 ---
(In reply to comment #3)
but it is an explicit specialization of the *definition* of the variable
No it is a specialization of the declaration. There are only specialization
of
declarations; never definitions.
--- Comment #5 from redi at gcc dot gnu dot org 2010-06-16 12:11 ---
(In reply to comment #4)
So what the above code actually means? Is it valid?
Yes, it's valid. It declares an explicit specialization, which inhibits the
implicit instantiation of the default specialization.
In
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-16 12:21 ---
The following check is to simplistic, it does not work for structures but only
for simple object names. - with structures, it gets more complicated as also
comparing the name of the last part-ref won't work - but one
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-06-16 12:22 ---
Subject: Bug 43905
Author: jamborm
Date: Wed Jun 16 12:21:56 2010
New Revision: 160832
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160832
Log:
2010-06-16 Martin Jambor mjam...@suse.cz
PR
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-16 12:31 ---
(In reply to comment #3)
but it is an explicit specialization of the *definition* of the variable
No it is a specialization of the declaration.
It is a declaration of a specialization :)
There are only
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-16 12:55 ---
Subject: Bug 44549
Author: janus
Date: Wed Jun 16 12:54:54 2010
New Revision: 160834
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160834
Log:
2010-06-16 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-16 12:56 ---
Fixed with r160834. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from bernds at gcc dot gnu dot org 2010-06-16 13:29 ---
Yes, the check for MULT is for cases where the definition is after the use in
basic-block order; I'd expect this can happen with crazy gotos and maybe in
other cases as well.
Could you retest the MIPS fixed-point
X-Bugzilla-Reason: CC
gcc built from recent gcc-4_5-branch ICE's compiling attached testcase for arm
with following options
-mthumb -O1 -fno-omit-frame-pointer
$ arm-oe-linux-uclibceabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-oe-linux-uclibceabi-gcc
X-Bugzilla-Reason: CC
--- Comment #1 from raj dot khem at gmail dot com 2010-06-16 14:04 ---
Created an attachment (id=20928)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20928action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-16 14:11 ---
Subject: Bug 44555
Author: rguenth
Date: Wed Jun 16 14:11:03 2010
New Revision: 160836
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160836
Log:
2010-06-16 Richard Guenther rguent...@suse.de
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-06-16 14:12 ---
Fixed on trunk, 3.3 works, so this is a regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2010-06-16 14:34 ---
(In reply to comment #1)
The following check is to simplistic, it does not work for structures but only
for simple object names. - with structures, it gets more complicated as also
comparing the name of the last
--- Comment #14 from hjl dot tools at gmail dot com 2010-06-16 14:36
---
The code in question is
offset -= frame_phase;
align = offset -offset;
align *= BITS_PER_UNIT;
if (align == 0)
align = STACK_BOUNDARY;
else if (align
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-16 14:57 ---
1) all the world isn't ix86/x86_64, this is generic code, so
MAX_SUPPORTED_STACK_ALIGNMENT is small on many targets
2) even when get_decl_align_unit returns something small, the decl might still
get a nicely aligned
module ice5
type::a_type
contains
procedure::a_subroutine_1
procedure::a_subroutine_2
end type a_type
contains
subroutine a_subroutine_1(this)
class(a_type)::this
real::res
res=this%a_subroutine_2()
end subroutine a_subroutine_1
subroutine a_subroutine_2(this)
--- Comment #16 from hjl dot tools at gmail dot com 2010-06-16 15:38
---
(In reply to comment #15)
2) even when get_decl_align_unit returns something small, the decl might still
get a nicely aligned slot (say offset 64). If it is known at this point
that virtual_stack_vars_rtx will
--- Comment #4 from hubicka at ucw dot cz 2010-06-16 16:13 ---
Subject: Re: [4.6 Regression]
gcc.c-torture/execute/frame-address.c
Confirmed on powerpc-linux. check_fa tail calls check_fa_mid, ignoring the
fact that check_fa_mid is passed the address of a check_fa local
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-06-16 16:14 ---
mine.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ro at gcc dot gnu dot org 2010-06-16 16:16 ---
Created an attachment (id=20929)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20929action=view)
gfortran -fdump-tree-original output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-06-16 16:25 ---
Patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01653.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44535
You can't use a typedef from a typename scope in a template
This is obviously a major bug and it means you can't access the typedefs of the
ISO standard library containers in order to use safe types to manipulate those
containers, when typename is such a container.
Here is the output of the
--- Comment #21 from jamborm at gcc dot gnu dot org 2010-06-16 17:01
---
Subject: Bug 44464
Author: jamborm
Date: Wed Jun 16 17:01:06 2010
New Revision: 160852
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160852
Log:
2010-06-15 Martin Jambor mjam...@suse.cz
PR
--- Comment #22 from jamborm at gcc dot gnu dot org 2010-06-16 17:02
---
This is now fixed on both the trunk and the 4.5 branch.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
On Jun 16, 2010, at 9:57 AM, gcc at razorcam dot com gcc-bugzi...@gcc.gnu.org
wrote:
You can't use a typedef from a typename scope in a template
This is obviously a major bug and it means you can't access the
typedefs of the
ISO standard library containers in order to use safe types to
--- Comment #1 from pinskia at gmail dot com 2010-06-16 17:04 ---
Subject: Re: New: you can't use a typedef from a typename scope in a template
On Jun 16, 2010, at 9:57 AM, gcc at razorcam dot com
gcc-bugzi...@gcc.gnu.org
wrote:
You can't use a typedef from a typename scope in
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2010-06-16 17:10 ---
Subject: Re: [4.5/4.6 Regression] incorrect error: Stat-variable at (1) shall
not be DEALLOCATEd within the same DEALLOCATE statement
On Wed, Jun 16, 2010 at 02:34:34PM -, kargl at gcc dot
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-16 17:13 ---
(In reply to comment #0)
This is obviously a major bug and it means you can't access the typedefs of
the
ISO standard library containers in order to use safe types to manipulate those
containers, when typename is
--- Comment #3 from gcc at razorcam dot com 2010-06-16 17:20 ---
I apologize. Thanks for your quick answers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44559
--- Comment #7 from dpovey at gmail dot com 2010-06-16 17:57 ---
The key thing here is that the value was initialized inside the class. So
there is no way to syntactically disambiguate a definition and a declaration of
the value outside the class (because normally C++ uses the
This test takes too long:
# time sh xxx.sh
real17m10.313s
user12m25.690s
sys 0m1.420s
# cat xxx.sh
/mnt/gnu/gcc/objdir-test/gcc/xgcc -B/mnt/gnu/gcc/objdir-test/gcc/
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr43058.c -g -O2 -S -o pr43058.s
--
Summary: gcc.dg/pr43058.c
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-16 19:50 ---
The problem is UNSPEC_CAST. There is no good way to model it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-16 20:00 ---
Well for one, you could have a splitter if the case which_alternative == 0 so
that an reg rename can do its magic.
Also what does UNSPEC_CAST really do? From the looks of it is just a move
which you could use a
Command line:
$ g++ -std=gnu++0x -flto testcase.C
testcase.C:2:12: internal compiler error: tree code 'lang_type' is not
supported in gimple streams
testcase.C
typedef decltype(nullptr) nullptr_t;
nullptr_t a;
Tested revisions:
r160687 - crash
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-16 20:39 ---
Confirmed.
It isn't valid for LANG_TYPE node to leak to the middle-end.
gdb) call debug_tree (expr)
lang_type 0xb77a3180 nullptr_t unsigned SI
size integer_cst 0xb7722288 type integer_type 0xb7739060
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-16 20:42 ---
You can cast 256bit to 128bit to get the lower 128bit. You can also
cast 128bit to 256bit with upper 128bit undefined. If I use union,
it will always generate 2 moves via memory.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-06-16 20:46 ---
(In reply to comment #4)
You can cast 256bit to 128bit to get the lower 128bit.
This way can be represented using vec_select. And then later on using a split
(after reload) turned into a move.
You can also cast
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-16 20:50 ---
Confirmed. Btw the same thing happens if you treat a type-bound function as if
it were a subroutine:
module ice5
type::a_type
contains
procedure::a_subroutine_1
procedure::a_subroutine_2
end type
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-16 20:58 ---
This is easily fixed by the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 160833)
+++
The ICE looks similiar to PR43221, but it may be different issue - this one
needs only one file to crash.
Command line:
$ gcc -O1 -flto -fstrict-aliasing -fgraphite-identity testcase.c
Compiler output:
$ gcc -O1 -flto -fstrict-aliasing -fgraphite-identity testcase.c -m32
testcase.c: In function
--- Comment #1 from zsojka at seznam dot cz 2010-06-16 21:04 ---
Created an attachment (id=20930)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20930action=view)
reduced testcase
To make it crash at x86_64-linux, the typedef has to be changed to:
typedef long long ll;
Command
--- Comment #6 from kretz at kde dot org 2010-06-16 21:21 ---
(In reply to comment #4)
You can also cast 128bit to 256bit with upper 128bit undefined.
If you cast from xmm to ymm after a 128bit instruction coded with VEX prefix
then the upper 128bit are actually guaranteed to be zero.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2010-06-16 21:30
---
This makes no sense at all. Rainer, I'm really sorry if it seems that I'm
shooting questions a bit at random, but I have a hard time imagining how to
narrow it down.
Can you try the following equivalent C code
--- Comment #6 from kargl at gcc dot gnu dot org 2010-06-16 21:51 ---
(In reply to comment #5)
This makes no sense at all. Rainer, I'm really sorry if it seems that I'm
shooting questions a bit at random, but I have a hard time imagining how to
narrow it down.
Can you try the
--- Comment #2 from mikpe at it dot uu dot se 2010-06-16 21:25 ---
With crosses to armv5tel-unknown-linux-gnueabi, gcc-4.3 and 4.4 work but a
recent 4.5 ICEs as described here.
This stopped ICEing in 4.6 with r160260, an ira/reload patch. However, that
was just an improvement fixing a
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-16 22:18 ---
Hm. Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from anthony dot penniston at hotmail dot com 2010-06-17
01:14 ---
(In reply to comment #1)
Value range-propagation (VRP) does not work on disjoint ranges, so the
compiler
does not actually know that argc can only be 1, 2 or 4. I think there is
already a PR about
--- Comment #11 from hp at gcc dot gnu dot org 2010-06-17 02:20 ---
Disappeared for cris-elf in (160828:r160836], which agrees i686-linux results
on gcc100 at http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01649.html
(160820) and
When compiling a 5 MB C file with 65337 functions, gcc takes over 700 MB of ram
compiling the file to assembly. Files with fewer functions (32769 and 16385)
take exponentially less time. A workaround is to split the file into multiple c
files and compile into intermediate files seperately.
tinycc
--- Comment #6 from amodra at gmail dot com 2010-06-17 04:13 ---
Hmm. Well, perhaps the thing to do is ensure we don't get a tail call by
making the same change as in
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01726.html
Index: gcc/testsuite/gcc.c-torture/execute/frame-address.c
--- Comment #1 from jvoss at altsci dot com 2010-06-17 04:14 ---
Created an attachment (id=20931)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20931action=view)
A c file that generates a c file that is the test case.
gcc -o gcc_64kgen1 gcc_64kgen1.c -Wall
./gcc_64kgen1
--- Comment #12 from wilson at codesourcery dot com 2010-06-17 04:29
---
Subject: Re: suboptimal MIPS widening multiply accumulate
On Wed, 2010-06-16 at 13:29 +, bernds at gcc dot gnu dot org wrote:
Could you retest the MIPS fixed-point testcases with the obvious fix? You
--- Comment #12 from kargl at gcc dot gnu dot org 2010-06-17 04:43 ---
(In reply to comment #11)
Disappeared for cris-elf in (160828:r160836], which agrees i686-linux results
on gcc100 at http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01649.html
(160820) and
--- Comment #13 from kargl at gcc dot gnu dot org 2010-06-17 05:08 ---
(In reply to comment #12)
(In reply to comment #11)
Disappeared for cris-elf in (160828:r160836], which agrees i686-linux
results
on gcc100 at http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01649.html
87 matches
Mail list logo
