--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-17 07:33 ---
Not a regression:
gfortran ice.f90
ice.f90: In function 'xmain':
ice.f90:8: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2846
Please submit a full bug report,
with preprocessed source
--- Comment #1 from tammer at tammer dot net 2008-12-17 07:29 ---
Created an attachment (id=16914)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16914&action=view)
build log of sample
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38547
Hello,
I get the following duplicate symbols with g++ on AIX.
g++ (GCC) 4.2.4
g++ hello.cpp -o hello (hello.cpp is just a cout hello world...)
ld: 0711-224 WARNING: Duplicate symbol: .__divdi3
ld: 0711-224 WARNING: Duplicate symbol: .__moddi3
ld: 0711-224 WARNING: Duplicate symbol: .__udivdi3
ld
--- Comment #30 from steven at gcc dot gnu dot org 2008-12-17 07:01 ---
I think redoing this with 4.4.0 would be useful, to check if new code (like
IRA) uses this kind of non-linear algorithms. But the register renaming patch
hasn't changed between 4.3 and 4.4, so I would compile with
-
--- Comment #29 from jv244 at cam dot ac dot uk 2008-12-17 06:50 ---
doing the original testcase again at -O3 has been a useful exercise i think.
13.5h is spent in rename_registers, 2h in tree operand scan, ~1h in inline
heuristics, and 20min in expand. (Note that this is a 4.3 based com
I configured with:
CONFIG_SHELL=/usr/bin/bash CFLAGS="-O9 -maltivec -mabi=altivec" CXXFLAGS="-g
-O9 -maltivec -mabi=altivec" CFLAGS_FOR_TARGET="-O9 -maltivec -mabi=altivec"
LIBCFLAGS="-g -O9 -maltivec -mabi=altivec" LIBCXXFLAGS="-g -O9 -maltivec
-mabi=altivec" LIBGCC2_CFLAGS="-g -O9 -maltivec -mab
Dear all,
I've notice that the following code does not compile with g++ 4.4.0 (trunk).
It seems to be a regression from g++ 4.3.2, which compiles this code
successfully.
$ cat error.c
class A;
class B
{
void foo(int A,
const A*);
};
$ g++ -Wextra -Wall -c error.cc
error.cc:6: error
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from steven at gcc dot gnu dot org 2008-12-16 23:03 ---
This is not fixable. When a bug is filed, messages are sent out and picked up
by archive mirrors. This is desirable for GCC the project but probably less so
for individual GCC users.
--
steven at gcc dot gnu dot
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
The optimizer at -O3 for x86_64 finds opportunities to generate the "adc" (add
with carry) instruction to avoid a conditional branch. However, the dst of the
adc can only be in a register. The optimizer misses a chance to use "adc" with
the destination in memory, and will instead use a conditiona
--- Comment #2 from m dot j dot thayer at googlemail dot com 2008-12-16
21:48 ---
I just generally don't like having my e-mail address visible on public web
pages. Among other things, it provides food for spam-bots.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38475
GCC 4.3.2 failed to compile code with vairadic template function
specialization.
Here is the code causing the problem:
template< typename ... T > void foo( T ... args );
template<> void foo( int, double ){}
int main()
{
foo( 0, 0.0 );
return 55;
}
I got the following error msg:
test.cpp:3: e
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 20:40 ---
we have:
unsigned short foobar;
int i = (int)foobar;
if (i > 99)
if (foobar <= 99)
access array[i];
so i can never be negative and foobar will never be greater than 99.
This is both a missed optimization deali
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 20:38 ---
I want to say this is a duplicate of bug 38367.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 20:37 ---
Why do you want this, this is an free source project after all?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38475
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|4.3.4 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #28 from pinskia at gcc dot gnu dot org 2008-12-16 19:32
---
The stack heuristic is new for 4.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-16 19:21 ---
This has been fixed since 4.3.0:
t.cc:7: error: declaration of 'typedef struct X A::X'
t.cc:2: error: changes meaning of 'X' from 'struct X'
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-16 19:18 ---
Not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fai
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-16 19:18 ---
Simple testcase:
extern int& i;
int& i; // ERROR: this is not ok
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from zadeck at naturalbridge dot com 2008-12-16 18:43
---
and how would you ask that question in a machine independent way?
I am going to find the shift sequence and if it has a set or clobber of any
currently live hard reg, i will reject the sequence.
I am working on
--- Comment #15 from hjl dot tools at gmail dot com 2008-12-16 18:41
---
Is that safe to call find_shift_sequence when CC register is live?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-16 17:39
---
Not a bug. You need to write your macro like this:
#define burst_copy(dst,src,len) {\
unsigned t1, t2, t3; \
__asm__ __volatile__ ( \
"1: \n\t" \
"ldmia %1!,{r3-r6} \n\t" \
"stmia %0!,{r3-r6} \n\t" \
--- Comment #14 from hjl dot tools at gmail dot com 2008-12-16 17:18
---
Here is the original patch which caused this regression:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01582.html
Here is the one checked in:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00744.html
--
hjl dot
--- Comment #2 from rearnsha at gcc dot gnu dot org 2008-12-16 17:12
---
Confirmed. This appears to be a bug in the register-renaming pass, where the
insn
(insn:HI 84 79 82 8 proc/sysinfo.c:890 (parallel [
(set (reg:CC_NOOV 24 cc)
(compare:CC_NOOV (minus:SI
--- Comment #4 from dberlin at gcc dot gnu dot org 2008-12-16 17:00 ---
Subject: Re: [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register
pressure several times
Yes, that looks like a bug.
There are also numerous ways in which the placement can be improved.
A few people had t
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-16 16:57 ---
In particular, the problem is in linearize_expr_tree. The |s are already
perfectly linearized (in all but the innermost recursive linearize_expr_tree
binlhsisreassoc is 1 and binrhsisreassoc is 0, in the innermost bot
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-16 16:45
---
I'm unable to reproduce this with any of svn-trunk, gcc-4.1.3 (debian),
gcc-4.3.3 (SVN) or gcc-4.3.2 (debian). The loop essentially reads as
mov r7, #1
mov r6, #0
L5:
...
add r6, r6, #1
cmp r7, r6
--- Comment #1 from hariharans at gcc dot gnu dot org 2008-12-16 16:35
---
This has been fixed on 4.4.0 (trunk)
--
hariharans at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #27 from jv244 at cam dot ac dot uk 2008-12-16 16:29 ---
the slow routines at -O3 are related to compute_may_aliases, at the point I
interupted the profiling, this routine had called add_virtual_operand 200M
times.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #26 from steven at gcc dot gnu dot org 2008-12-16 16:26 ---
I am going to work on the -O0 problems a bit.
The operand scanner is the problem at -O3. Richi, this is one you may want to
try on the alias improvements branch, if most of the time is spent on virtual
SSA names (I
--- Comment #25 from jv244 at cam dot ac dot uk 2008-12-16 16:17 ---
doing some more profiling, the -O0 problem is to a large extend due to
compute_inline_parameters and estimate_stack_frame_size. Spending 10-30min just
on estimating the stack_frame_size on something that can't be reason
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-16 16:03 ---
If the subroutine
subroutine xmain()
call foo(func("_"//bar()))
end subroutine xmain
is replaced with
subroutine xmain()
character (len=2) :: zz(2)
zz=func("_"//bar())
call foo(zz)
end subroutine xmain
the code co
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|4.4.0 |4.3.3
Version|4.4.0 |4.3.2
http://
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-16 15:35 ---
Yes, confirmed.
The offending line is:
call foo(func("_"//bar()))
In trans-expr.c, se->loop is NULL in the gcc_assert:
2844 else if (sym->result->attr.dimension)
2845 {
2846 gcc_assert (se->
--- Comment #13 from jakub at gcc dot gnu dot org 2008-12-16 15:05 ---
Not doing this optimization if added_clobbers_hard_reg_p would basically kill
it on i386/x86_64 except for constant values, all the shifts clobber hard
registers. But typically flags register is only live for very sh
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-16 14:58 ---
Sounds similar to PR 32183.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #13 from tim at bishnet dot net 2008-12-16 14:29 ---
Could this change be merged down to the 4.3 branch? Currently 4.3.2 release is
still broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32581
--- Comment #24 from jv244 at cam dot ac dot uk 2008-12-16 14:20 ---
(In reply to comment #23)
reduced testcase timings at -O0 and -O3. Tree operand scan anybody?
> time gfortran -O0 -ffree-line-length-512 -c -ftime-report testcase_reduced.f90
Execution times (seconds)
garbage collect
--- Comment #23 from jv244 at cam dot ac dot uk 2008-12-16 14:17 ---
Created an attachment (id=16913)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16913&action=view)
reduced testcase
just so we talk about the same file, I've reduced the testcase to more
managable sizes. This one
--- Comment #2 from thutt at vmware dot com 2008-12-16 14:03 ---
(In reply to comment #1)
> The reason why they are saved is so that you can have a good way of debugging
> noreturn functions.
>
Can you please elaborate? How is saving these registers, which will never be
restored, going
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-16 13:49 ---
The culprit is tree-ssa-reassoc.c, with -fno-tree-ssa-reassoc the generated
code is comparable to 3.4.
For some reason it decides:
Transforming err_10 = __err_3 | __err_8;
into err_10 = __err_8 | __err_3;
(no idea wha
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-16 13:45 ---
Looks like something along the lines of gcse.c:can_assign_to_reg_p() is called
for here in replace_read.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
--- Comment #22 from steven at gcc dot gnu dot org 2008-12-16 13:41 ---
We may be better off with a slightly reduced test case for the -O3 report.
It's not difficult to cut out ~8000 lines (like I did yesterday) and still have
a huge test case (and the horendous compile times to go with
--- Comment #9 from leonid at volnitsky dot com 2008-12-16 13:21 ---
(In reply to comment #8)
>> int16_t* ip = (int16_t*)&m1;
> That is violating C/C++ aliasing rules
The code that you quote is not part of the reported bug. It was quick and
dirty hack. But that was it. Add
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-16 13:09 ---
The problem is that CSE2 extends the live range of CC register, so before DSE1
we have in _ZN11rot_mx_infoC1ERK6rot_mx function:
(insn 15 14 16 2 pr37922.C:469 (set (reg:CC 17 flags)
(compare:CC (reg/v:SI 75 [
--- Comment #21 from jv244 at cam dot ac dot uk 2008-12-16 12:48 ---
(In reply to comment #16)
> Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me.
btw, that routine only has 3800 user variables, the rests are FE generated
temporaries (which should have a limited lifetime
--- Comment #10 from jakub at gcc dot gnu dot org 2008-12-16 12:48 ---
Created an attachment (id=16912)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16912&action=view)
pr37922.C
Testcase with a bunch of unneeded namespaces removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #20 from jv244 at cam dot ac dot uk 2008-12-16 12:47 ---
(In reply to comment #19)
> Re. comment #18, I'd say "brilliant" if it wasn't such a poor performance :-)
I agree... quite an achievement not to crash in such a case.
> Did you manage to get a time report out of that
--- Comment #19 from steven at gcc dot gnu dot org 2008-12-16 12:45 ---
Re. comment #18, I'd say "brilliant" if it wasn't such a poor performance :-)
Did you manage to get a time report out of that run?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #6 from rearnsha at gcc dot gnu dot org 2008-12-16 12:12
---
Fixed on trunk
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Statu
Dear all,
I would like to post a fault report for the GNU C/C++ compiler 4.3.0.
Used invokation line for the GNU C++ compiler:
gcc -c -x c++ -ansi -Wall -Werror -mcpu=603e -fverbose-asm -mbig
-mmultiple -mstring -mstrict-align -meabi -msdata -fno-common
-fno-exceptions -fno-rtti -O3 -fno
--- Comment #9 from jakub at gcc dot gnu dot org 2008-12-16 12:08 ---
Indeed, -O2 -fpic returns 2, -O2 -fpic -fno-dse returns 0. The difference
between the two are just 4 successful replace_read changes, like:
movq%rdx, 224(%rsp) # D.4704, proper_r
- shrq$32, %rdx
Dear all,
I would like to post a fault report for the GNU C/C++ compiler 4.3.0.
Used invokation line for the GNU C++ compiler:
gcc -c -x c++ -ansi -Wall -Werror -mcpu=603e -fverbose-asm -mbig
-mmultiple -mstring -mstrict-align -meabi -msdata -fno-common
-fno-exceptions -fno-rtti -O3 -fno
--- Comment #5 from rearnsha at gcc dot gnu dot org 2008-12-16 12:04
---
Subject: Bug 37436
Author: rearnsha
Date: Tue Dec 16 12:03:41 2008
New Revision: 142778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142778
Log:
PR target/37436
* arm.c (arm_legitimate_index): Only accep
Dear all,
I would like to post a fault report for the GNU C/C++ compiler 4.3.0.
Used invokation line for the GNU C++ compiler:
gcc -c -x c++ -ansi -Wall -Werror -mcpu=603e -fverbose-asm -mbig
-mmultiple -mstring -mstrict-align -meabi -msdata -fno-common
-fno-exceptions -fno-rtti -O3 -fno
--- Comment #18 from jv244 at cam dot ac dot uk 2008-12-16 11:58 ---
(In reply to comment #17)
> BTW, the -O3 compilation is still running (for 17h now).
finished successfully after 23h...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #4 from mayor1 at uralweb dot ru 2008-12-16 11:34 ---
Subject: Re: namespace, ,
On 15 Dec 2008 17:40:49 -
"jakub at gcc dot gnu dot org"
wrote:
>
>
> --- Comment #1 from jakub at gcc dot gnu dot org
> 2008-12-15 17:40 ---
> Why is that considered a bug?
--- Comment #5 from doko at ubuntu dot com 2008-12-16 08:49 ---
The most recent complete build logs can be seen at
http://buildd.debian.org/fetch.cgi?&pkg=gcc-snapshot&ver=20081130-1&arch=armel&stamp=1228429623&file=log
http://launchpadlibrarian.net/20414304/buildlog_ubuntu-jaunty-armel
60 matches
Mail list logo
