Re: Bug in expand_builtin_setjmp_receiver ?
On 22 October 2010 20:17, Ian Lance Taylor i...@google.com wrote: Frederic Riss frederic.r...@gmail.com writes: OK... what's the best way forward on this? Do we just leave it as it is and wait until an official port needs complains about it? Should it be filled in bugzilla? Did you just happen to come across this, or is this relevant for a port you are working on? I came accross that while working on a port, however I don't know if/when it will be opened. I suppose that if the port wants to be integrated one day, then a fix for that issue might be part of the patch series for that port? If you are not working on a port, then I think the best think to do right now is to add a FIXME comment in the source code. I'll llet you decide if you want to do that. Thanks, Fred
combiner
In my port I get to such a situation:
(insn 60 59 61 4 a.c:65 (set (subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0)
(zero_extract:SI (subreg:SI (reg/v:DI 138 [ v4hi1 ]) 4)
(const_int 16 [0x10])
(const_int 16 [0x10]))) 53 {extzv} (nil))
(insn 61 60 62 4 a.c:65 (set (reg:BI 159)
(gtu:BI (reg:HI 129 [ __prephitmp_4 ])
(reg/v:HI 143 [ usiThresh ]))) 94 {cmprr_hi_gtu} (nil))
The patterns for these are:
(define_insn extzv
[(set (match_operand:SI 0 register_operand =d)
(zero_extract:SI (match_operand:SI 1 register_operand d)
(match_operand:SI 2 immediate_operand U06)
(match_operand:SI 3 immediate_operand U06)))]
extractua\t %2, %3, %1, %0 %!
)
and
(define_insn cmprr_hi_code
[(set (match_operand:BI 0 register_operand =c)
(any_cond_rr:BI (match_operand:HI 1 register_operand d)
(match_operand:HI 2 register_operand d)))]
cmpcode %2.L, %1.L, %0:%I0 %!
)
I want the combiner to combine both insns since I have an intruction
which can compare from an HI partial register.
I am trying to write an insn pattern for that but the combiner does not use i.
I thought about something like:
(define_insn cmprr_hi_code_1
[(set (match_operand:BI 0 register_operand =c)
(any_cond_rr:BI (zero_extract:SI (match_operand:DI 1
register_operand d)
(const_int 16) (const_int 16))
(match_operand:HI 2 register_operand d)))]
cmpcode %2.L, %1.L, %0:%I0 %!
)
but it does not work.
Can someone please help?
Thanks, Roy.
Constant propagation and CSE
Hi, The constant propagation pass propagates constants into the instructions that accept immediates. I'm trying to find if there's some CSE pass in GCC that would be able to undo this effect when the constant is used more than once in the function. I looked at the CSE code (4.5 branch) and I don't think this is currently possible. If the code uses a bunch of big constants, the effect on code size might be quite sensible. I hacked around that in a quite horrible manner: I arranged for the immediate alternative of some insn patterns to be invalid during the 'cprop' passes. That way cprop doesn't put the immediate into the instructions, but if the constant is used only once it will be propagated into the instruction by the 'combine' pass. This seems excessively hackish to me, I wanted to know if there's some better/standard way to handle that issue. Thanks, Fred
Re: peephole2: dead regs not marked as dead
Paolo Bonzini schrieb:
On 10/22/2010 01:16 PM, Georg Lay wrote:
Then the first insn gets split after reload and before peephole2:
(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
(and:SI (reg:SI 4 d4 [ x ])
(const_int -98305 [0xfffe7fff]))) 143
{*and3_zeroes.insert.{SI}.ic}
(nil))
(insn 23 22 21 2 peep2.c:5 (set (reg:SI 15 d15)
(xor:SI (reg:SI 15 d15)
(reg:SI 4 d4 [ x ]))) 39 {*xorsi3} (nil))
(insn 21 23 10 2 peep2.c:5 (set (reg:SI 4 d4)
(reg:SI 15 d15)) 2 {*movsi_insn} (nil))
(call_insn/j 10 21 11 2 peep2.c:5 (parallel [
(set (reg:SI 2 d2)
(call (mem:HI (symbol_ref:SI (f) [flags
0x41]function_decl
0xb76b3280 f) [0 S2 A16])
(const_int 0 [0x0])))
(use (const_int 1 [0x1]))
]) 92 {call_value_insn} (nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 4 d4))
(nil)))
;; End of basic block 2 - ( 1)
;; lr out 2 [d2] 26 [SP] 27 [a11]
;; live out 2 [d2] 26 [SP] 27 [a11]
;; Succ edge EXIT [100.0%] (ab,sibcall)
(barrier 11 10 20)
D15, is not marked as dead
True. It should have had a REG_DEAD note. Are you using 4.6 (which
scans forwards in peephole2 and requires REG_DEAD notes) or 4.5 (which
scans backwards)? If the latter, the absence of the note could be a red
herring, because 4.5 didn't need REG_DEAD notes so it didn't compute them.
It is a target port of 4.5.1. I just skimmed peep2_reg_dead_p and it looks
backward. So this function will never see that D15 dies and report D15 as alive.
What's your definition of CALL_USED_REGISTERS,
CALL_REALLY_USED_REGISTERS, EPILOGUE_USES? Is d15 in any of them?
D15 is not an element of any of them. D15 is call-saved and will get restored in
the RET-instruction of the callee which is tail-called in this particular case.
But even if f is not being tail-called D15 is not reported as dead. In that case
the insns after the call are (D2 is the return register, returning 1+f(...))
(insn 17 12 20 2 peep2.c:11 (set (reg/i:SI 2 d2)
(plus:SI (reg:SI 2 d2)
(const_int 1 [0x1]))) 6 {*addsi3} (nil))
(insn 20 17 28 2 peep2.c:11 (use (reg/i:SI 2 d2)) -1 (nil))
(jump_insn 29 28 30 2 peep2.c:11 (return) -1 (nil))
(barrier 30 29 23)
As far as 4.6 is concerned, I have not tried it yet. I do not know how stable
the releases are and how much work it is to switch from 4.5 to 4.6.
Georg Lay
Is it possbile to hack I386 backend to make all function calls to be indirect function calling?
Hi, I meet a requirement to make all function calls to be indirect function calling ( for I386 GCC compiler). I am not familiar with frontend, so my first idea is to hack it from backend, change the asm output for call and call_value insn patterns, generate a related varible in data section, and when output call insn, output indirect call. For example, for function A, I create a g_stub_function_ptr_A varible in data section, with initialized value A, and when output call insn A, output (I am not familiar with X86 instruction set, so I assume that there is CALL EAX instruction): MOV EAX, g_stub_function_ptr_A CALL EAX Will this idea works? Any comments are welcome! Ps: the orignal requirement is to make function stubs for unit test. Assume the top level function is A, and it calls B,C,D functions, B calls E, E calls F So when testing function A, one needs to care the all call chains of A, which makes the unit test hard to implement. Now I have a scratch idea: make all function calls to be indirect call, in other words, make all function calls to be function pointer call. So when testing function A, one can make stubs for B,C,D, and change the called B,C,D to be one's own defined B,C,D stubs, via asigning the function pointer to be one's own.
Re: peephole2: dead regs not marked as dead
On 10/25/2010 11:35 AM, Georg Lay wrote:
(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
(and:SI (reg:SI 4 d4 [ x ])
(const_int -98305 [0xfffe7fff]))) 143
{*and3_zeroes.insert.{SI}.ic}
(nil))
(insn 23 22 21 2 peep2.c:5 (set (reg:SI 15 d15)
(xor:SI (reg:SI 15 d15)
(reg:SI 4 d4 [ x ]))) 39 {*xorsi3} (nil))
(insn 21 23 10 2 peep2.c:5 (set (reg:SI 4 d4)
(reg:SI 15 d15)) 2 {*movsi_insn} (nil))
(call_insn/j 10 21 11 2 peep2.c:5 (parallel [
(set (reg:SI 2 d2)
(call (mem:HI (symbol_ref:SI (f) [flags
0x41]function_decl
0xb76b3280 f) [0 S2 A16])
(const_int 0 [0x0])))
(use (const_int 1 [0x1]))
]) 92 {call_value_insn} (nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 4 d4))
(nil)))
;; End of basic block 2 - ( 1)
;; lr out 2 [d2] 26 [SP] 27 [a11]
;; live out 2 [d2] 26 [SP] 27 [a11]
;; Succ edge EXIT [100.0%] (ab,sibcall)
(barrier 11 10 20)
D15, is not marked as dead
True. It should have had a REG_DEAD note. Are you using 4.6 (which
scans forwards in peephole2 and requires REG_DEAD notes) or 4.5 (which
scans backwards)? If the latter, the absence of the note could be a red
herring, because 4.5 didn't need REG_DEAD notes so it didn't compute them.
It is a target port of 4.5.1. I just skimmed peep2_reg_dead_p and it looks
backward.
In this case, as I mentioned the function _doesn't need_ a note to see
that D15 dies. There's no such thing as a register that is naturally
dead because the function ends and needs special treatment. Liveness
is computed like everything else from data flow and, when scanning
backwards, can be computed simply from the defs and uses of each
instruction. The notes are not necessary, so their absence is (as I
also have mentioned above already) a red herring.
The definition of liveness is lr_before = lr_after - def + use, which gives:
at the end of basic block lr from dump file = {2,26,27}
insn 10 def = {2}, use = {4} lr before insn 10 = {4,26,27}
insn 21 def = {4}, use = {15} lr before insn 21 = {15,26,27}
insn 23 def = {15}, use = {4,15} lr before insn 23 = {4,15,26,27}
insn 22 def = {15}, use = {4} lr before insn 22 = {4,26,27}
When GCC matches the peephole against 21+23, peep2_reg_dead_p(2, reg)
should test reg against lr before insn 10. This is {4,26,27}. You
have to set a breakpoint in df_simulate_one_insn_backwards and see which
part of my theory above is incorrect.
Paolo
Re: Constant propagation and CSE
On 10/25/2010 10:46 AM, Frederic Riss wrote: Hi, The constant propagation pass propagates constants into the instructions that accept immediates. I'm trying to find if there's some CSE pass in GCC that would be able to undo this effect when the constant is used more than once in the function. I looked at the CSE code (4.5 branch) and I don't think this is currently possible. If the code uses a bunch of big constants, the effect on code size might be quite sensible. I hacked around that in a quite horrible manner: I arranged for the immediate alternative of some insn patterns to be invalid during the 'cprop' passes. That way cprop doesn't put the immediate into the instructions, but if the constant is used only once it will be propagated into the instruction by the 'combine' pass. This seems excessively hackish to me, I wanted to know if there's some better/standard way to handle that issue. You need to teach constant propagation to look at insn costs, like fwprop does. Alternatively, try rearranging passes (e.g. swapping GCSE and fwprop) so that you can delete the local copy propagation completely. :) Paolo
Re: Is it possbile to hack I386 backend to make all function calls to be indirect function calling?
redriver jiang jiang.redri...@gmail.com writes: Hi, I meet a requirement to make all function calls to be indirect function calling ( for I386 GCC compiler). I am not familiar with frontend, so my first idea is For x86-64 using the large code model (-mcmodel=large) will result in all function calls being indirect. If you want to do it for 32bit you could probably extend the implementation of this feature. -Andi
Re: Discussion about merging Go frontend
On 10/24/2010 10:52 PM, Ian Lance Taylor wrote: It's hard for me to believe that BFD is the correct answer. It's poorly designed for the kinds of things the compiler needs to do. Any program which links against BFD effectively links in the GNU linker. It sounded from your mail like all the compiler needs to do is to read the binary contents of a named section. Isn't that something that BFD does well? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
movmemm pattern
Question on movmemm:
Given
extern int *i, *j;
void foo (void) { memcpy (i, j, 10); }
I would expect to see argument 4 (the shared alignment) to be sizeof(int) since
both argument are pointers to int. What I get instead is 1. Why is that?
If I have
extern int i[10], j[10];
then I do get larger alignment as expected.
paul
Re: Bug in expand_builtin_setjmp_receiver ?
Frederic Riss frederic.r...@gmail.com writes: On 22 October 2010 20:17, Ian Lance Taylor i...@google.com wrote: Frederic Riss frederic.r...@gmail.com writes: OK... what's the best way forward on this? Do we just leave it as it is and wait until an official port needs complains about it? Should it be filled in bugzilla? Did you just happen to come across this, or is this relevant for a port you are working on? I came accross that while working on a port, however I don't know if/when it will be opened. I suppose that if the port wants to be integrated one day, then a fix for that issue might be part of the patch series for that port? If you have a patch that works for your port, and a good argument to support it, and an explanation for why it doesn't affect current ports, that is sufficient to send a patch. Thanks. Ian
Re: Discussion about merging Go frontend
Mark Mitchell m...@codesourcery.com writes: On 10/24/2010 10:52 PM, Ian Lance Taylor wrote: It's hard for me to believe that BFD is the correct answer. It's poorly designed for the kinds of things the compiler needs to do. Any program which links against BFD effectively links in the GNU linker. It sounded from your mail like all the compiler needs to do is to read the binary contents of a named section. Isn't that something that BFD does well? BFD will get the job done. But I don't think it's a good choice for releasing a program like gcc. BFD is in effect an internal library for the linker and the GNU binutils, and it's also used by the assembler. It doesn't really maintain source compatibility across releases, and it definitely doesn't maintain binary compatibility. As I mentioned above, when you link against BFD you effectively pull in the linker. Reading a section from an object file is not hard. Linking against BFD to do it is massive overkill. If we were already linking against BFD, then sure. But introducing BFD for this will give us and the binutils developers some long-term maintenance pain for limited reward. At least, that is how I see it. Ian
Re: Discussion about merging Go frontend
On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor i...@google.com wrote: At least, that is how I see it. Why not require libelf just like for LTO? That seems like a time to reduce what we depend on. For an example if we compile with lto and go, GCC will use two different elf libraries. This seems dumb really. Thanks, Andrew Pinski
Re: Discussion about merging Go frontend
Andrew Pinski pins...@gmail.com writes: On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor i...@google.com wrote: At least, that is how I see it. Why not require libelf just like for LTO? That seems like a time to reduce what we depend on. For an example if we compile with lto and go, GCC will use two different elf libraries. This seems dumb really. libelf is rather awkward and has different implementations with different bugs and also usually needs to be installed explicitely on Linux. It would be better to make LTO use Ian's library (but then it's C++ I believe, not C) -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [wwwdocs] PATCH for Re: new mirror
On Thu, 7 Oct 2010, James Miller wrote: Our mirror address has been changed from http://gcc.parentinginformed.com/ to http://gcc.parentingamerica.com/ Please update your list to use the new URL. Also please use new e-mail to contact me when necessary: jmil...@parentingamerica.com. Thanks for the heads up, James. I have updated our web site per the patch below a week ago, just failed to send this earlier. (I also noticed you put an http redirect in place which is nice; too many webmasters don't.) Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.202 diff -u -3 -p -r1.202 mirrors.html --- mirrors.html22 Sep 2010 22:11:00 - 1.202 +++ mirrors.html17 Oct 2010 16:35:00 - @@ -34,7 +34,7 @@ Key fingerprint = 33C2 35A3 4C46 AA3F FB ul liAustria: a href=ftp://gd.tuwien.ac.at/gnu/gcc/;gd.tuwien.ac.at/a, thanks to Antonin dot Sprinzl at tuwien dot ac dot at/li liBulgaria: a href=http://gcc.igor.onlinedirect.bg/;gcc.igor.onlinedirect.bg/a, thanks to igor at onlinedirect dot bg/li -liCanada: a href=http://gcc.parentinginformed.com;http://gcc.parentinginformed.com/a, thanks to James Miller (jmiller at parentinginformed dot com)./li +liCanada: a href=http://gcc.parentingamerica.com;http://gcc.parentingamerica.com/a, thanks to James Miller (jmiller at parentingamerica dot com)./li liCanada: a href=http://gcc.skazkaforyou.com;http://gcc.skazkaforyou.com/a, thanks to Sergey Ivanov (mirrors at skazkaforyou dot com)/li liChina: a href=ftp://linuxforum.net/ftp.gcc.gnu.org/;ftp://linuxforum.net/ftp.gcc.gnu.org//a, thanks to David Deng (david99deng at yahoo dot com)/li liFrance (no snapshots): a href=ftp://ftp.lip6.fr/pub/gcc/;ftp.lip6.fr/a, thanks to ftpmaint at lip6 dot fr/li
Re: combiner
roy rosen roy.1ro...@gmail.com writes:
In my port I get to such a situation:
(insn 60 59 61 4 a.c:65 (set (subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0)
(zero_extract:SI (subreg:SI (reg/v:DI 138 [ v4hi1 ]) 4)
(const_int 16 [0x10])
(const_int 16 [0x10]))) 53 {extzv} (nil))
(insn 61 60 62 4 a.c:65 (set (reg:BI 159)
(gtu:BI (reg:HI 129 [ __prephitmp_4 ])
(reg/v:HI 143 [ usiThresh ]))) 94 {cmprr_hi_gtu} (nil))
The patterns for these are:
(define_insn extzv
[(set (match_operand:SI 0 register_operand =d)
(zero_extract:SI (match_operand:SI 1 register_operand d)
(match_operand:SI 2 immediate_operand U06)
(match_operand:SI 3 immediate_operand U06)))]
extractua\t %2, %3, %1, %0 %!
)
and
(define_insn cmprr_hi_code
[(set (match_operand:BI 0 register_operand =c)
(any_cond_rr:BI (match_operand:HI 1 register_operand d)
(match_operand:HI 2 register_operand d)))]
cmpcode %2.L, %1.L, %0:%I0 %!
)
I want the combiner to combine both insns since I have an intruction
which can compare from an HI partial register.
I am trying to write an insn pattern for that but the combiner does not use i.
I thought about something like:
(define_insn cmprr_hi_code_1
[(set (match_operand:BI 0 register_operand =c)
(any_cond_rr:BI (zero_extract:SI (match_operand:DI 1
register_operand d)
(const_int 16) (const_int 16))
(match_operand:HI 2 register_operand d)))]
cmpcode %2.L, %1.L, %0:%I0 %!
)
but it does not work.
That insn won't work because you don't have a DImode operand to your
zero_extract. You have an SImode operand. It's a subeg of a DImode
operand, but that doesn't matter.
I'm not sure how well combine will work with the paradoxical subreg
(subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0) though.
Ian
Re: Is it possbile to hack I386 backend to make all function calls to be indirect function calling?
redriver jiang jiang.redri...@gmail.com writes: I meet a requirement to make all function calls to be indirect function calling ( for I386 GCC compiler). I am not familiar with frontend, so my first idea is to hack it from backend, change the asm output for call and call_value insn patterns, generate a related varible in data section, and when output call insn, output indirect call. You could probably just change the call_insn_operand predicate to not accept constant_call_address_operand. Or something along those lines. Ian
Re: movmemm pattern
On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning paul_kon...@dell.com wrote:
Question on movmemm:
Given
extern int *i, *j;
void foo (void) { memcpy (i, j, 10); }
I would expect to see argument 4 (the shared alignment) to be sizeof(int)
since both argument are pointers to int. What I get instead is 1. Why is
that?
Because the int * could point to unaligned data and there is no access
that would prove otherwise (memcpy accepts any alignment).
Richard.
If I have
extern int i[10], j[10];
then I do get larger alignment as expected.
paul
Re: REGNO_OK_FOR_BASE_P
Paul Koning paul_kon...@dell.com writes: Working on the pdp11 target, I ran into something odd. It defines REGNO_OK_FOR_BASE_P in a way that seems to match what gccint says one should do in the strict case -- but does so all the time. Specifically, it says: #define REGNO_OK_FOR_BASE_P(REGNO) \ ((REGNO) 8 || (unsigned) reg_renumber[REGNO] 8) (8 because there are 8 general registers on the PDP11, all suitable as base.) It then defines another similarly named macro REG_OK_FOR_BASE_P which takes an rtx instead of a regno, for use in GO_IF_LEGITIMATE_ADDRESS. That second macro *does* come with a non-strict form which accepts all registers. Looking at gccint, that seemed wrong. As far as I can tell, REG_OK_FOR_BASE_P is not (or no longer) a standard macro so it's just a convenience macro inside the target. No problem there. But the strict REGNO_OK_FOR_BASE_P in non-strict settings seemed like an issue, so I changed it. The surprise it that it makes no difference. No change in code, no change in testsuite results. Why didn't it matter? Is the documentation wrong? Or is the existing definition somehow ok even for the non-strict case, in a way that isn't obvious? I think the documentation is wrong. REGNO_OK_FOR_BASE_P is only meaningful for hard registers. It doesn't make much sense to ask whether a pseudo-register is OK to use as a base. The pseudo-register can in principle be assigned to any hard register, so the answer is always true. In older releases GO_IF_LEGITIMATE_ADDRESS was often a macro written in terms of REGNO_OK_FOR_BASE_P. Since GO_IF_LEGITIMATE_ADDRESS had to change based on REG_OK_STRICT, it made sense to have REGNO_OK_FOR_BASE_P change based on REG_OK_STRICT. But the generic part of gcc will not check REGNO_OK_FOR_BASE_P for a pseudo register. And since current targets should be using TARGET_LEGITIMATE_ADDRESS_P instead of GO_IF_LEGITIMATE_ADDRESS, the issue of REGNO_OK_FOR_BASE_P is less important. Probably the docs should be changed. Ian
Re: Is it possbile to hack I386 backend to make all function calls to be indirect function calling?
redriver jiang jiang.redri...@gmail.com writes: I meet a requirement to make all function calls to be indirect function calling ( for I386 GCC compiler). I am not familiar with frontend, so my first idea is to hack it from backend, change the asm output for call and call_value insn patterns, generate a related varible in data section, and when output call insn, output indirect call. You could probably just change the call_insn_operand predicate to not accept constant_call_address_operand. Or something along those lines. -mcmodel=large already promote all calls to be indirect as far as I can remember (on x86-64) but you can just grab that code for x86 too. Honza Ian
Re: Discussion about merging Go frontend
On 25/10/2010 19:43, Andi Kleen wrote: Andrew Pinski pins...@gmail.com writes: On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor i...@google.com wrote: At least, that is how I see it. Why not require libelf just like for LTO? That seems like a time to reduce what we depend on. For an example if we compile with lto and go, GCC will use two different elf libraries. This seems dumb really. libelf is rather awkward and has different implementations with different bugs and also usually needs to be installed explicitely on Linux. It would be better to make LTO use Ian's library (but then it's C++ I believe, not C) -Andi What would be even nicer would be if we could share the same code-reader interface between lto and go (and the lto-plugin), thereby getting object format independence equally everywhere for no extra cost. That could be orthogonal to plugging elfcpp into the role currently occupied by libelf in that reader. (As to needing c++, that's just a matter of enabling c++ as a stage1 language and living with the minor limitation that go can't be a stage1 language unless you already have an installed c++ compiler, no?) cheers, DaveK
Re: Discussion about merging Go frontend
On 10/25/2010 7:01 PM, Dave Korn wrote: What would be even nicer would be if we could share the same code-reader interface between lto and go (and the lto-plugin), thereby getting object format independence equally everywhere for no extra cost. That could be orthogonal to plugging elfcpp into the role currently occupied by libelf in that reader. I think it's reasonable to argue that GCC should, going forward, be an ELF-only toolchain -- with postprocessing tools for generating PE/COFF, Symbian DLLs, Mach-O or what have you. But, we haven't made that decision. So, I don't think we should get there by half-measures. Either we should decide that's what we want to do, or we should try to keep the compiler independent of the object file format -- as we have up until now. I understand Ian's distaste for BFD, but it is the format-independent object file reader we have, so it seems a natural choice. And libelf, which we already rely on seems more natural than elfcpp, if we're willing to go ELF-only -- unless we're going to replace the use of libelf in LTO with elfcpp as well. In any case, I think we should avoid a single compiler build requiring multiple object-file reading libraries. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: movmemm pattern
On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote:
On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning paul_kon...@dell.com wrote:
Question on movmemm:
Given
extern int *i, *j;
void foo (void) { memcpy (i, j, 10); }
I would expect to see argument 4 (the shared alignment) to be sizeof(int)
since both argument are pointers to int. What I get instead is 1. Why is
that?
Because the int * could point to unaligned data and there is no access
that would prove otherwise (memcpy accepts any alignment).
Ok, but if I do a load on an int*, I get an aligned load, not an unaligned
load, so in all those other cases there *is* an assumption that an int*
contains a properly aligned address.
paul
Re: movmemm pattern
On 26/10/2010 01:53, Paul Koning wrote:
On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote:
On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning paul_kon...@dell.com
wrote:
Question on movmemm:
Given
extern int *i, *j; void foo (void) { memcpy (i, j, 10); }
I would expect to see argument 4 (the shared alignment) to be
sizeof(int) since both argument are pointers to int. What I get
instead is 1. Why is that?
Because the int * could point to unaligned data and there is no access
that would prove otherwise (memcpy accepts any alignment).
Ok, but if I do a load on an int*,
I think that is what Richard meant by an access that would prove otherwise.
I get an aligned load, not an unaligned
load, so in all those other cases there *is* an assumption that an int*
contains a properly aligned address.
This is a bit like GCC optimising away a null-pointer check if it knows
you've already dereferenced the pointer. Either you've already crashed by
then, or it doesn't matter.
What happens if you dereference i and j before the memcpy in foo? Do you
then get int-sized shared alignment in movmemM?
extern int *i, *j; void foo (void) { *i; *j; memcpy (i, j, 10); }
cheers,
DaveK
Re: Discussion about merging Go frontend
On 25/10/2010 23:49, Mark Mitchell wrote: On 10/25/2010 7:01 PM, Dave Korn wrote: What would be even nicer would be if we could share the same code-reader interface between lto and go (and the lto-plugin), thereby getting object format independence equally everywhere for no extra cost. That could be orthogonal to plugging elfcpp into the role currently occupied by libelf in that reader. I think it's reasonable to argue that GCC should, going forward, be an ELF-only toolchain -- with postprocessing tools for generating PE/COFF, Symbian DLLs, Mach-O or what have you. But, we haven't made that decision. So, I don't think we should get there by half-measures. I'll probably be on the other side of that argument, when it comes, for a combination of political and engineering reasons. But, like you say, let's not get side-tracked. Either we should decide that's what we want to do, or we should try to keep the compiler independent of the object file format -- as we have up until now. Ian could fairly point out that LTO was accepted into the compiler before it was format-agnostic. I would counter that, until such a decision as you contemplate is actually made, it would have been preferable if it was format-agnostic from the start. However, we are where we are, and don't want to let the perfect be the enemy of the good. I understand Ian's distaste for BFD, but it is the format-independent object file reader we have, so it seems a natural choice. And libelf, which we already rely on seems more natural than elfcpp, if we're willing to go ELF-only -- unless we're going to replace the use of libelf in LTO with elfcpp as well. Well, TBH, I suggested BFD as a devil's-advocate position. It does indeed work, but it is kind of clunky, and top-heavy for what the compiler's requirements actually amount to. From Ian's description, gccgo has the exact same requirements as LTO: be able to parse an object file, get a list of sections, and get raw binary access to the data contained within a named section. This is a problem which we already have solved. (And indeed LTO's solution also has object writing capabilities that gccgo doesn't need.) In any case, I think we should avoid a single compiler build requiring multiple object-file reading libraries. Code re-use FTW! As far as I can see, we're not going to need anything significantly more complex than what the LTO-FE already needs, until and unless we get to a point of integrating the (assembler and) linker into the compiler itself, which is a long way off for now. That being the case, I think a reasonable plan would be: - integrate gccgo, with elfcpp - then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all the FEs can share it - then convert it to use elfcpp (with a bit of file I/O added) and stop using libelf altogether - then switch gccgo over to using it ... of which I think all but the first step would even be stage3-friendly. cheers, DaveK
Re: Discussion about merging Go frontend
On 10/25/2010 10:07 PM, Dave Korn wrote: - integrate gccgo, with elfcpp - then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all the FEs can share it - then convert it to use elfcpp (with a bit of file I/O added) and stop using libelf altogether - then switch gccgo over to using it I think that's a reasonable plan. It makes things no less object-file netural than they are now, which is OK. (And, before someone else points it out, I believe it was I who started using libelf in the LTO prototype, so I know full well how we got here!) I certainly have no problem with using elfcpp over libelf. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
Dave Korn dave.korn.cyg...@gmail.com writes: [...] From Ian's description, gccgo has the exact same requirements as LTO: be able to parse an object file, get a list of sections, and get raw binary access to the data contained within a named section. This is a problem which we already have solved. (And indeed LTO's solution also has object writing capabilities that gccgo doesn't need.) [...] By the way, is there some necessity in accomplishing this by means of a linked library, as opposed to via a spawned objcopy process? - FChE
Re: Discussion about merging Go frontend
On 10/25/2010 10:34 PM, Frank Ch. Eigler wrote: By the way, is there some necessity in accomplishing this by means of a linked library, as opposed to via a spawned objcopy process? Probably none in theory, but it certainly seems messy and likely to be slow in practice. Is there a reason that this would be desirable? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
Hi - By the way, is there some necessity in accomplishing this by means of a linked library, as opposed to via a spawned objcopy process? Probably none in theory, but it certainly seems messy and likely to be slow in practice. Yes, maybe. Is there a reason that this would be desirable? It would seem to moot the present discussion about competing elf consumer libraries. none of the above is a possible answer. - FChE
Re: Discussion about merging Go frontend
On 10/25/2010 10:39 PM, Frank Ch. Eigler wrote: It would seem to moot the present discussion about competing elf consumer libraries. none of the above is a possible answer. True. It seems that LTO and Go need a very simple interface; presumably we can abstract that in the compiler and then we can implement that interface as we please. I agree that a fallback to an external objcopy is plausible, as is linking with BFD. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
inline assembly vs. intrinsic functions
Hi, I am trying to demonstrate my port capabilities. I am writing an application which needs to use instructions like max a,b,c,d,e,f where a,b,c are inputs and d,e,f are outputs. Is that possible to write an intrinsic function for that? I think not because that means that I need to pass d,e,f by reference which means that they would be in memory and not in a register as meant by the instruction. Is there any port with such an example? So, I thought of implementing that with inline assembly but here I encounter a different problem: The compiler does not understand the instruction given in inline assembly and therefore it does not parallelize it with other insns. Is there any other solution for that which I don't see? Thanks, Roy.
[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46115
--- Comment #3 from Rob Staudinger robert.staudinger at gmail dot com
2010-10-25 07:31:59 UTC ---
For the record, this is already possible using bracketed expressions, but the
syntactical sugar of not having to pick a function name would be great.
#include stdio.h
#include stdlib.h
int
main (int argc, char **argv)
{
void (*func_ptr)(int) = ({ void func(int i) { printf (%i\n, i); };
func;
});
func_ptr (3);
return EXIT_SUCCESS;
}
[Bug target/46163] GCC Produces Invalid Assembly Code from Anonymous Function Syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46163 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target|Linux x86_64|x86_64-linux-gnu Host|Linux x86_64| --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-25 08:09:15 UTC --- This is a target issue of how $ is handled in names.
[Bug target/46163] GCC Produces Invalid Assembly Code from Anonymous Function Syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46163 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.25 09:43:27 CC||hjl.tools at gmail dot com, ||ubizjak at gmail dot com Target Milestone|--- |4.4.6 Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-10-25 09:43:27 UTC --- I think it is a bad idea to use $.1590 as function label. .$1590 is a better one. But I don't see x86 backend can do it by itself.
[Bug middle-end/46164] New: Local variables in specified registers don't work correctly with inline asm operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164
Summary: Local variables in specified registers don't work
correctly with inline asm operands
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: siarhei.siamas...@gmail.com
When testing with gcc 4.5.1
ARM
$ cat test.c
int f(int a)
{
register int result asm(r0);
asm (
addr0, %[a], #123\n
: [result] =r (result)
: [a] r (a)
);
return result;
}
$ gcc -O2 -c test.c
$ objdump -d test.o
f:
0: e280007badd r0, r0, #123; 0x7b
4: e1a3mov r0, r3
8: e12fff1ebx lr
Here the local variable 'result' gets assigned to register r3 instead of r0
causing all kind of problems.
x86-64
$ cat test.c
int f(int a)
{
register int result asm(edi);
asm (
lea0x7b(%[a]), %%edi\n
: [result] =r (result)
: [a] r (a)
);
return result;
}
$ gcc -O2 -c test.c
$ objdump -d test.o
f:
0: 67 8d 7f 7b addr32 lea 0x7b(%edi),%edi
4: c3 retq
=
And some final bits.
http://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html#Local-Reg-Vars
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
The documantation is a bit confusing, but it gives at least one example of
assigining variables to specified registers:
Sometimes you need to make an asm operand be a specific register, but there's
no matching constraint letter for that register by itself. To force the operand
into that register, use a local variable for the operand and specify the
register in the variable declaration. See Explicit Reg Vars. Then for the asm
operand, use any register constraint letter that matches the register:
register int *p1 asm (r0) = ...;
register int *p2 asm (r1) = ...;
register int *result asm (r0);
asm (sysint : =r (result) : 0 (p1), r (p2));
Let's try to use something like that with x86-64:
//
void abort();
int __attribute__((noinline)) f(int a)
{
register int p1 asm (edi);
register int result asm (edi);
asm (
mov %2, %0\n
add %2, %0\n
add %2, %0\n
: =r (result) : 0 (p1), r (a));
return result;
}
int main()
{
if (f(1) != 3)
abort();
}
//
This testcase fails.
So is it a bug in gcc? Or the documentation is wrong? Or I'm missing something?
[Bug middle-end/32820] optimizer malfunction when mixed with asm statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32820 --- Comment #8 from Siarhei Siamashka siarhei.siamashka at gmail dot com 2010-10-25 10:17:47 UTC --- On the second thought, this bug was about global variables. But my problem is related to the use of local variables. So I have submitted a separate PR46164 about it.
[Bug middle-end/46164] Local variables in specified registers don't work correctly with inline asm operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 --- Comment #1 from Siarhei Siamashka siarhei.siamashka at gmail dot com 2010-10-25 10:37:13 UTC --- Created attachment 22144 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22144 proposed testcase for x86_64
[Bug middle-end/46164] Local variables in specified registers don't work correctly with inline asm operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 Siarhei Siamashka siarhei.siamashka at gmail dot com changed: What|Removed |Added Attachment #22144|0 |1 is obsolete|| --- Comment #2 from Siarhei Siamashka siarhei.siamashka at gmail dot com 2010-10-25 12:32:01 UTC --- Created attachment 22145 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22145 updated testcase (x86_64) Actually the previous testcase was not very good. It tried to simulate earlyclobber operand by specifying it both as input and output, but because p1 was actually not initialized, gcc may be allowed to optimize it and screw up everything (without any kind of warnings, but that's another story). So the problem is actually related to using specified registers for earlyclobber output operands in such a way that they try to use the same registers as function arguments.
[Bug fortran/46010] I/O: Namelist-reading bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46010 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-10-25 13:12:33 UTC --- The patch in comment #7 works for the original test case but fails for the one in comment #4. I have a revised patch that also works for comment #4 and passes regression testing. I will submit it later tonight.
[Bug rtl-optimization/45967] [4.5 Regression] gcc-4.5.x optimizes code with side-effects away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45967 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added CC||krebbel at gcc dot gnu.org --- Comment #5 from Andreas Krebbel krebbel at gcc dot gnu.org 2010-10-25 14:16:38 UTC --- (In reply to comment #4) Fixed for trunk sofar. Let's see if there is any fallout. This seems to have broken bootstrap on s390x. From a first glance it looks like collect2 has been miscompiled. I'll try to gather more infos.
[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128 --- Comment #2 from Siarhei Siamashka siarhei.siamashka at gmail dot com 2010-10-25 14:43:52 UTC --- (In reply to comment #1) Note that there may be problems clobbering D registers. See bug 43440. I don't think Richard Earnshaw's patch http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00978.html ever got reviewed or pinged - it probably needs pinging. (In general, unreviewed patches are best pinged about weekly.) Yes, that's a very well known bug. But there should be no problems with D registers, only Q registers are affected. They say codesourcery already has it fixed (so I assume the patch has been at least reviewed): http://www.beagleboard.org/irclogs/index.php?date=2010-06-27 # [11:19:58] ssvb raster: check gcc bugzilla - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440; # [11:19:59] mru the gcc design makes it very hard to do this conversion # [11:20:01] raster unliek a cpu - gcc can be fixed and updated easily :) # [11:20:14] raster mru: seems codesourcery managed it More generally, it would be beneficial to be able to optimize routines using specific VFPv3 instructions (such as VMOV's immediate-operand form), or to make use of VFPv4's fused-mulitply-accumulate instructions. For fused multiply-add, the best approach is to describe them in the ARM .md files using the new fma: RTL facility, so that calls to fma / fmaf / __builtin_fma / __builtin_fmaf use the instructions automatically as on other targets whose .md files have been updated like this. But still there are cases when performance is actually important and builtins/intrinsics are ruled out because of this. Inline assembly is convenient because it can be added directly to C sources, without any need to tweak makefiles or build scripts. This makes inline assembly a good choice for small non-intrusive performance patches. Another inconvenience is that in order to check whether for example ARMv6 instructions are supported, one has to use constructs like this (identifiers fished out from gcc sources): #if defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) || \ defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6Z__) || \ defined(__ARM_ARCH_6ZK__) || defined(__ARM_ARCH_6T2__) || \ defined(__ARM_ARCH_6M__) || defined(__ARM_ARCH_7__) || \ defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7R__) || \ defined(__ARM_ARCH_7M__) [...] #endif And this is not very maintainable because future gcc versions may introduce more predefined symbols for newer arm architecture variants. It would be much nicer if it was possible to just do something like: #if defined(__arm__) (__ARM_ARCH__ = 6) [...] #endif It's basically the same problem as VFP variant identification.
[Bug fortran/46140] [4.4/4.5/4.6 Regression] Include not found - but exit status code is zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46140 --- Comment #7 from kargl at gcc dot gnu.org 2010-10-25 16:07:37 UTC --- Author: kargl Date: Mon Oct 25 16:07:34 2010 New Revision: 165922 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165922 Log: 2010-10-25 Steven G. Kargl ka...@gcc.gnu.org PR fortran/46140 * fortran/scanner.c (include_line): Check return value of load_file. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c
[Bug fortran/46140] [4.4/4.5/4.6 Regression] Include not found - but exit status code is zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46140 --- Comment #8 from kargl at gcc dot gnu.org 2010-10-25 16:09:51 UTC --- Author: kargl Date: Mon Oct 25 16:09:47 2010 New Revision: 165923 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165923 Log: 2010-10-25 Steven G. Kargl ka...@gcc.gnu.org PR fortran/46140 * fortran/scanner.c (include_line): Check return value of load_file. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/scanner.c
[Bug fortran/46140] [4.4/4.5/4.6 Regression] Include not found - but exit status code is zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46140 --- Comment #9 from kargl at gcc dot gnu.org 2010-10-25 16:12:05 UTC --- Author: kargl Date: Mon Oct 25 16:11:54 2010 New Revision: 165924 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165924 Log: 2010-10-25 Steven G. Kargl ka...@gcc.gnu.org PR fortran/46140 * fortran/scanner.c (include_line): Check return value of load_file. Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/scanner.c
[Bug fortran/46140] [4.4/4.5/4.6 Regression] Include not found - but exit status code is zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46140 kargl at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.6 --- Comment #10 from kargl at gcc dot gnu.org 2010-10-25 16:15:52 UTC --- Fixed on 4.4, 4.5, and trunk. Closing.
[Bug fortran/42647] [F03] Missed initialization/dealloc of allocatable scalar DT with allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Summary|Missed |[F03] Missed |initialization/dealloc of |initialization/dealloc of |allocatable scalar DT with |allocatable scalar DT with |allocatable component |allocatable component
[Bug tree-optimization/46165] New: ICE: verify_flow_info failed when casting-out attribute noreturn with -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46165 Summary: ICE: verify_flow_info failed when casting-out attribute noreturn with -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22146 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22146 reduced testcase (from gcc.c-torture/compile/20050202-1.c) Compiler output: $ gcc -O -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce pr46165.c pr46165.c: In function 'g': pr46165.c:2:6: error: control flow in the middle of basic block 2 pr46165.c:2:6: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165915 - crash 4.5 r165781 - crash 4.4 r165754 - crash 4.4 r149995 - crash
[Bug fortran/46166] New: optimization and/or removing an if(.false.) statement leads to bad results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46166 Summary: optimization and/or removing an if(.false.) statement leads to bad results Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sjbe...@comcast.net Created attachment 22147 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22147 example program described in bug report On Mac OS X 10.6.4, with gfortran from recent sources on the 4.6 trunk: et:new.single.v2 sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -v Using built-in specs. COLLECT_GCC=/volumes/dev/gfortran-4.6-trunk/bin/gfortran COLLECT_LTO_WRAPPER=/Volumes/dev/gfortran-4.6-trunk/bin/../libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../gfortran-4.6-src/configure --prefix=/volumes/dev/gfortran-4.6-trunk --enable-languages=fortran --host=x86_64-apple-darwin10 --build=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 Thread model: posix gcc version 4.6.0 20101013 (experimental) (GCC) the following bug(s) have been observed: (1) if the attached file is compiled as follows sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -O0 driver.f90 sjbespa$ ./a.out and run, the program executes correctly. The output is shown in example 1. (2) if the optimization level is changed to -O1 or higher: sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -O1 driver.f90 sjbespa$ ./a.out the program doesn't run correctly as shown in example 2. It appears that the variables fcurr and flast have invalid values. (3) finally, if the if statement beginning at statement 251 is commented out, the example program fails in the same manner as in (2) independent of the optimization level. example 1 sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -O0 driver.f90 sjbespa$ ./a.out input data for constitutive model solver rhosat =40743665431535.492 !! rho100.00 plStrainInv0. plStrainInvLast0. plStrainInvRate0. dlamba 0. fcurr -999.02 flast -999.02 215.998498240953100. 6.95322298958717986E-310 !! rho100.00 plStrainInv0. plStrainInvLast0. plStrainInvRate0. dlamba 0. fcurr -999.02 flast -999.02 863.993992963812390. 6.95322298958717986E-310 example 2 * sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -O1 driver.f90 sjbespa$ ./a.out input data for constitutive model solver rhosat =40743665431535.492 !! rho100.00 plStrainInv0. plStrainInvLast0. plStrainInvRate0. dlamba 0. fcurr -999.02 flast -999.02 !! rho1005087.50 plStrainInv 9.99955E-007 plStrainInvLast0. plStrainInvRate 9.99955E-007 dlamba9.99955E-007 fcurr NaN flast NaN !! rhoNaN plStrainInvNaN plStrainInvLast0. plStrainInvRateNaN dlamba NaN fcurr NaN flast NaN !!
[Bug tree-optimization/46165] [4.3/4.4/4.5/4.6 Regression] ICE: verify_flow_info failed when casting-out attribute noreturn with -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46165 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.25 17:48:34 CC||hjl.tools at gmail dot com Summary|ICE: verify_flow_info |[4.3/4.4/4.5/4.6 |failed when casting-out |Regression] ICE: |attribute noreturn with |verify_flow_info failed |-fno-tree-ccp |when casting-out attribute |-fno-tree-copy-prop |noreturn with -fno-tree-ccp |-fno-tree-dce |-fno-tree-copy-prop ||-fno-tree-dce Ever Confirmed|0 |1
[Bug tree-optimization/46167] New: [4.5/4.6 Regression] ICE: SEIGSEGV in flow_bb_inside_loop_p (cfgloop.c:776) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46167 Summary: [4.5/4.6 Regression] ICE: SEIGSEGV in flow_bb_inside_loop_p (cfgloop.c:776) with -O -ftree-vectorize Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22148 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22148 reduced testcase valgrind output : $ gcc -O -ftree-vectorize pr46167.c ==21601== Invalid read of size 8 ==21601==at 0x5933E8: flow_bb_inside_loop_p (cfgloop.c:776) ==21601==by 0x100FA9F: vect_recog_dot_prod_pattern (tree-vect-patterns.c:260) ==21601==by 0x10104A5: vect_pattern_recog (tree-vect-patterns.c:683) ==21601==by 0x9DE777: vect_analyze_loop (tree-vect-loop.c:1406) ==21601==by 0x9EC288: vectorize_loops (tree-vectorizer.c:219) ==21601==by 0x797A5E: execute_one_pass (passes.c:1560) ==21601==by 0x797CF4: execute_pass_list (passes.c:1615) ==21601==by 0x797D06: execute_pass_list (passes.c:1616) ==21601==by 0x797D06: execute_pass_list (passes.c:1616) ==21601==by 0x8E4B65: tree_rest_of_compilation (tree-optimize.c:422) ==21601==by 0xAAF281: cgraph_expand_function (cgraphunit.c:1494) ==21601==by 0xAB1849: cgraph_optimize (cgraphunit.c:1553) ==21601== Address 0x18 is not stack'd, malloc'd or (recently) free'd ==21601== pr46167.c: In function 'foo': pr46167.c:1:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165915 - crash r163636 - crash r161659 - OK r159696 - OK 4.5 r165781 - crash 4.5.1 - OK 4.4 r165754 - OK
[Bug fortran/46166] optimization and/or removing an if(.false.) statement leads to bad results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46166 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-10-25 18:45:18 UTC --- 1) Remove the Tabs from your source. (2) Compile with -O2 -Wall -Wuninitialized -fcheck=all.
[Bug fortran/46166] optimization and/or removing an if(.false.) statement leads to bad results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46166 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2010-10-25 18:50:56 UTC --- Have you thought about using -Wall and fixing the issue with tauc?
[Bug tree-optimization/46168] New: ICE: verify_ssa failed: definition in block 6 does not dominate use in block 5 with -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46168 Summary: ICE: verify_ssa failed: definition in block 6 does not dominate use in block 5 with -ftree-loop-linear Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22149 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22149 reduced testcase Compiler output: $ gcc -O -ftree-loop-linear pr46168.c pr46168.c: In function 'foo': pr46168.c:2:1: error: definition in block 6 does not dominate use in block 5 for SSA_NAME: i16_8 in statement: i16_28 = PHI i16_16(7), i16_8(5) PHI argument i16_8 for PHI node i16_28 = PHI i16_16(7), i16_8(5) pr46168.c:2:1: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165915 - crash 4.5 r165781 - crash 4.4 r165754 - crash 4.4 r149995 - crash
[Bug target/46163] GCC Produces Invalid Assembly Code from Anonymous Function Syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46163 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.4.6 |---
[Bug c/46169] New: ICE: internal compiler error: in convert_move, at expr.c:371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46169 Summary: ICE: internal compiler error: in convert_move, at expr.c:371 Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: e...@anholt.net I ran into an ICE doing some code I was hacking on for Mesa to make a temporary shim for some upcoming interface changes. I managed to cut it down to this testcase, which is not minimal but hopefully small enough to reveal problems well. anh...@pollan:anholt/src/temp% gcc -o gcc-fail gcc-fail.c -Os -fno-strict-aliasing gcc-fail.c: In function ‘main’: gcc-fail.c:57: internal compiler error: in convert_move, at expr.c:371 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. anh...@pollan:anholt/src/temp% dpkg -l gcc Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii gcc 4:4.4.5-1The GNU C compiler
[Bug tree-optimization/46165] [4.3/4.4/4.5/4.6 Regression] ICE: verify_flow_info failed when casting-out attribute noreturn with -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46165 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC|hjl.tools at gmail dot com |amacleod at redhat dot com --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-25 20:19:53 UTC --- It was introduced by revision 119657: http://gcc.gnu.org/ml/gcc-cvs/2006-12/msg00276.html
[Bug c/46169] ICE: internal compiler error: in convert_move, at expr.c:371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46169 --- Comment #1 from Eric Anholt eric at anholt dot net 2010-10-25 20:20:19 UTC --- Created attachment 22150 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22150 gcc-fail.c
[Bug c++/46170] New: g++ wrongly rejects pointer-to-member in template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46170
Summary: g++ wrongly rejects pointer-to-member in template
arguments
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: f...@csl.cornell.edu
The following reduced test case is wrongly rejected by g++-4.4 and g++-4.5:
test case: reduce.ii =
namespace util {
struct option_value {
};
template class T struct options_map_impl {
typedef T options_struct_type;
typedef bool (*opt_func)(const option_value, options_struct_type);
template class V, V K static bool set_member_constant(const option_value,
options_struct_type, V options_struct_type::*);
template class V, V options_struct_type::*mem, V K static bool
set_member_constant(const option_value opt, options_struct_type t) {
return set_member_constantV,K(opt, t, mem);
}
};
}
struct cflat_options {
bool show_precharges;
};
typedef util::options_map_implcflat_options options_map_impl_type;
class register_options_modifier {
typedef options_map_impl_type::opt_func modifier_type;
public: register_options_modifier();
register_options_modifier(const char* Mode,const modifier_type COM,
const char* h);
};
static const register_options_modifier
cflat_opt_mod_show_precharges(precharges,
options_map_impl_type::set_member_constantbool,
cflat_options::show_precharges, true, show precharge expressions),
cflat_opt_mod_no_show_precharges(no- precharges,
options_map_impl_type::set_member_constantbool,
cflat_options::show_precharges, false, hide precharge expressions);
=== end test case ===
delta-reduced using:
#!/bin/sh -e
# reduce.sh
CXXFLAGS=-ansi -Woverloaded-virtual -W -Wextra -Wall -Wundef -Wshadow
-Wno-unused-parameter -Wpointer-arith -Wcast-qual -Wcast-align -Wconversion
-Werror -Wno-conversion -Wno-long-long
# must pass g++-4.2 first
g++ $CXXFLAGS -c -o reduce.o reduce.ii
g++-4 -pipe -g -O2 $CXXFLAGS -x c++ reduce.ii -o reduce.o 2 reduce.err || :
grep -q not a valid template argument reduce.err
# exactly 4 lines of errors
el=`wc -l reduce.err | awk '{print $1;}'`
test $el -eq 4
diagnostic:
reduce.ii: In static member function 'static bool
util::options_map_implT::set_member_constant(const util::option_value, T)
[with V = bool, V T::* mem = cflat_options::show_precharges, V K = true, T =
cflat_options]':
reduce.ii:22: instantiated from here
reduce.ii:9: error: 'true' is not a valid template argument for type 'bool
cflat_options::*'
reduce.ii:9: error: it must be a pointer-to-member of the form `X::Y'
it pass g++-4.2 and fails g++-4.4, g++-4.5:
f...@fangbook 163 g++ -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5664~105/src/configure --disable-checking
--enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10-
--host=x86_64-apple-darwin10 --target=i686-apple-darwin10
--with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)
f...@fangbook 164 g++-4 -v
Using built-in specs.
Target: i386-apple-darwin10.4.0
Configured with: ../gcc-4.4.4/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.4/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.4
Thread model: posix
gcc version 4.4.4 (GCC)
(for 4.5)
g++-4 -v
Using built-in specs.
COLLECT_GCC=g++-4
COLLECT_LTO_WRAPPER=/Volumes/MacSpare/sw/lib/gcc4.5/bin/../libexec/gcc/i386-apple-darwin10.4.0/4.5.0/lto-wrapper
Target: i386-apple-darwin10.4.0
Configured with: ../gcc-4.5.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.5
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.5/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.5
Thread model: posix
gcc version 4.5.0 (GCC)
===
keywords: rejects-valid, diagnostic
known-to-work: 4.2.1
known-to-fail: 4.4.4 4.5.0
This also used to work on 4.4.2, so it might be a branch regression.
[Bug tree-optimization/46168] ICE: verify_ssa failed: definition in block 6 does not dominate use in block 5 with -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46168 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-10-25 20:50:24 UTC --- 0n x86_64-apple-darwin10, 4.5 revision 154654 crashes, but gcc version 4.5.0 is OK (release checking). On powerpc-apple-darwin9, gcc version 4.3.0 20071218 (experimental) (GCC) crashes (at that time I did not recorded the revision).
[Bug rtl-optimization/46171] New: [4.6 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:774 with -fno-tree-dce -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46171 Summary: [4.6 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:774 with -fno-tree-dce -g Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22151 reduced testcase Compiler output: $ gcc -O -fno-tree-dce -g pr46171.c pr46171.c: In function 'foo': pr46171.c:8:1: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:774 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165915 - crash r165699 - crash r163636 - OK 4.5 r165781 - OK
[Bug target/46171] [4.6 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:774 with -fno-tree-dce -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46171 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|target Target Milestone|--- |4.6.0
[Bug c/46158] Spurious never executed warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46158 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-25 21:01:51 UTC --- -Wunreachable-code is broken and has been removed from GCC 4.5. Do not use it.
[Bug middle-end/46158] Spurious never executed warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46158 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end Target Milestone|--- |4.5.0
[Bug c++/46170] g++ wrongly rejects pointer-to-member in template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46170 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-25 21:09:02 UTC --- Looks related to PR46162. Jason, could you please have a look to both? Thanks in advance.
[Bug tree-optimization/46172] New: ICE: in expand_widen_pattern_expr, at optabs.c:522 with -ftree-vectorize -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46172 Summary: ICE: in expand_widen_pattern_expr, at optabs.c:522 with -ftree-vectorize -fno-tree-dce Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22152 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22152 reduced testcase Output - 4.6 (trunk): $ gcc -ftree-vectorize -O -fno-tree-dce pr46172.c pr46172.c: In function 'foo': pr46172.c:3:5: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Output - 4.5: $ gcc -ftree-vectorize -O -fno-tree-dce pr46172.c pr46172.c: In function 'foo': pr46172.c:3:5: internal compiler error: in expand_expr_real_2, at expr.c:8275 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Output - 4.4: $ gcc -ftree-vectorize -O -fno-tree-dce pr46172.c pr46172.c: In function 'foo': pr46172.c:3: internal compiler error: in c_expand_expr, at c-common.c:5015 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165915 - crash 4.5 r165781 - crash 4.4 r165781 - crash 4.4 r149995 - crash
[Bug middle-end/46169] ICE: internal compiler error: in convert_move, at expr.c:371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46169 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-10-25 21:21:37 UTC --- It was fixed in gcc 4.5 by revision 147731: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00708.html
[Bug lto/45736] [4.6 Regression] ICE: in cgraph_remove_unreachable_nodes, at ipa.c:245 with -flto and attribute((constructor))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45736 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2010-10-25 21:31:15 UTC --- Created attachment 22153 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22153 Patch I am testing.
[Bug bootstrap/46173] New: gcc/gencheck.c:30:24: error: all-tree.def: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46173 Summary: gcc/gencheck.c:30:24: error: all-tree.def: No such file or directory Product: gcc Version: 4.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: dirtye...@gentoo.org Rev 137006 included this change: * gencheck.c (tree_codes): Include all-tree.def, rather than tree.def, c-common.def, and gencheck.h. Undefined DEFTREECODE after it is used. However the change to the build/gencheck.o target in gcc/Makefile.in was: @@ -3239,7 +3245,7 @@ build/genattrtab.o : genattrtab.c $(RTL_BASE_H) $(OBSTACK_H) \ build/genautomata.o : genautomata.c $(RTL_BASE_H) $(OBSTACK_H) \ $(BCONFIG_H) $(SYSTEM_H) coretypes.h $(GTM_H) errors.h vec.h \ $(HASHTAB_H) gensupport.h -build/gencheck.o : gencheck.c gencheck.h tree.def $(BCONFIG_H) $(GTM_H) \ +build/gencheck.o : gencheck.c tree.def $(BCONFIG_H) $(GTM_H) \ $(SYSTEM_H) coretypes.h $(lang_tree_files) build/genchecksum.o : genchecksum.c $(BCONFIG_H) $(SYSTEM_H) $(MD5_H) build/gencodes.o : gencodes.c $(RTL_BASE_H) $(BCONFIG_H) $(SYSTEM_H) \ rather than depending on tree.def, it should be all-tree.def. This leads to a sporadic parallel build error we're seeing on our weekly builds. This was fixed with rev 147491 but never made it onto the 4.4 branch.
[Bug fortran/46174] New: [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 Summary: [OOP] ALLOCATE with SOURCE: Deep copy missing Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org The following is in a sense a follow up to PR 45451. Assuming that X and Y are both polymorphic (CLASS) and the following operation: ALLOCATE (x, SOURCE=y) or x = y ! Fortran 2008: (Re)alloc on assignment with polymorphic LHS In those cases, one might need to do a deep copy as the polymorphic item might have allocatable components. This currently does not work. Example: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 11 12 13 14 15 16 17 18 19 20 Aborted (core dumped) The third line should be the same as the first one - but in reality it still points to the allocatable components of the SOURCE=. implicit none type t end type t type, extends(t) :: t2 integer, allocatable :: a(:) end type t2 class(t), allocatable :: x, y integer :: i allocate(t2 :: x) select type(x) type is (t2) allocate(x%a(10)) x%a = [ (i, i = 1,10) ] print '(*(i3))', x%a class default call abort() end select allocate(y, source=x) select type(x) type is (t2) x%a = [ (i, i = 11,20) ] print '(*(i3))', x%a class default call abort() end select select type(y) type is (t2) print '(*(i3))', y%a if (any (y%a /= [ (i, i = 1,10) ])) call abort() class default call abort() end select end
[Bug middle-end/38942] possible integer codegen error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38942 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #3 from Ian Lance Taylor ian at airs dot com 2010-10-25 22:12:55 UTC --- I can't recreate this with mainline or gcc 4.4 branch. I tested with and without -m32. I also built mainline for 32-bit only, and could not recreate this. I think this is likely fixed.
[Bug middle-end/38942] possible integer codegen error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38942 John Regehr regehr at cs dot utah.edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #4 from John Regehr regehr at cs dot utah.edu 2010-10-25 22:16:10 UTC --- Works for me too.
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-25 22:22:49 UTC --- (In reply to comment #6) Note in Fortran 2008 (cf. PR 41719), polymorphic-variable = expr is allowed iff the variable is allocatable. And note further that this is nontrivial as it requires a deep copy, cf. PR 46174. * * * Newer draft patch for realloc on assignment (w/o the polymorphic assignment): http://gcc.gnu.org/ml/fortran/2010-10/msg00213.html
[Bug rtl-optimization/46175] New: ICE: in rtl_verify_flow_info_1, at cfgrtl.c:2037: flow control insn inside a basic block with -O -fgcse -fno-guess-branch-probability -freorder-blocks and asm goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46175 Summary: ICE: in rtl_verify_flow_info_1, at cfgrtl.c:2037: flow control insn inside a basic block with -O -fgcse -fno-guess-branch-probability -freorder-blocks and asm goto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22154 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22154 reduced testcase Compiler output: $ gcc -O -fgcse -fno-guess-branch-probability -freorder-blocks pr46175.c pr46175.c: In function 'foo': pr46175.c:27:1: error: in basic block 7: pr46175.c:27:1: error: flow control insn inside a basic block (jump_insn 14 46 61 7 (parallel [ (asm_operands/v () () 0 [] [] [ (label_ref:DI 16) ] pr46175.c:27) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ]) pr46175.c:19 -1 (expr_list:REG_UNUSED (reg:QI 18 fpsr) (expr_list:REG_UNUSED (reg:QI 17 flags) (nil))) - 16) pr46175.c:27:1: internal compiler error: in rtl_verify_flow_info_1, at cfgrtl.c:2037 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165915 - crash r153685 - crash 4.5 r165781 - crash 4.4 r165754 - doesn't know asm goto
[Bug middle-end/46176] New: profile feedback causes 20% linux kernel binary growth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176 Summary: profile feedback causes 20% linux kernel binary growth Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Recent gcc 4.6 snapshot on x86_64-linux. I did an experimental patch to use profile feedback with the Linux kernel With a very simple training run (covering only ~50% of the files partially) Unfortunately recompiling with the feedback data leads to a 20% larger binary. This is compiled using -O2. Trained: textdata bss dec hex filename 136150401202668 1357680 16175388 f6d11c vmlinux Untrained: 111364521200876 1357552 13694880 d0f7a0 vmlinux Comparing the symbols with the largest growth I get: add/remove: 674/2006 grow/shrink: 12172/4139 up/down: 3000900/-510189 (2490711) function old new delta r600_kms_blit_copy 2640 16394 +13754 static.do_con_write- 10681 +10681 r600_blit_copy 10605 21205 +10600 zlib_inflate5459 15261 +9802 static.rv770_startup -9541 +9541 e1000_setup_copper_link-9510 +9510 e1000_diag_test14064 22948 +8884 kmem_cache_create 1385 10227 +8842 I have not analyzed it in detail, but current suspicion is much more aggressive inlining? Note also that a lot of functions were using fallback profiling data because the training load wasn't very good.
[Bug middle-end/46176] profile feedback causes 20% linux kernel binary growth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-25 22:57:50 UTC --- I think this is unrolling. -fprofile-generate/-fprofile-use turns on unrolling.
[Bug tree-optimization/46177] New: [4.5/4.6 Regression] ICE: in prop_phis, at tree-loop-distribution.c:327 with -fno-tree-copy-prop -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46177 Summary: [4.5/4.6 Regression] ICE: in prop_phis, at tree-loop-distribution.c:327 with -fno-tree-copy-prop -ftree-loop-distribution Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22155 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22155 reduced testcase Compiler output: $ gcc -O -fno-tree-copy-prop -ftree-loop-distribution pr46177.c pr46177.c: In function 'foo': pr46177.c:5:1: internal compiler error: in prop_phis, at tree-loop-distribution.c:327 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Fails with -O3 -fno-tree-copy-prop as well as it implies -ftree-loop-distribute-patterns Tested revisions: r165915 - crash r153685 - crash 4.5 r165781 - crash 4.4 r165754 - OK
[Bug rtl-optimization/46178] New: gcc.target/i386/(u)divmod-[58].c FAIL: ICE: in dec_register_pressure, at ira-lives.c:215 with -fira-algorithm=priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46178 Summary: gcc.target/i386/(u)divmod-[58].c FAIL: ICE: in dec_register_pressure, at ira-lives.c:215 with -fira-algorithm=priority Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Compiler output: $ gcc gcc.target/i386/divmod-5.c -O -m8bit-idiv -fira-algorithm=priority gcc.target/i386/divmod-5.c: In function 'bar': gcc.target/i386/divmod-5.c:10:1: internal compiler error: in dec_register_pressure, at ira-lives.c:215 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ gcc gcc.target/i386/divmod-8.c -O -m8bit-idiv -fira-algorithm=priority gcc.target/i386/divmod-8.c: In function 'bar': gcc.target/i386/divmod-8.c:12:1: internal compiler error: in dec_register_pressure, at ira-lives.c:215 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I think I have seen this ICE often with -fira-algorithm=priority -fschedule-insns, but I didn't report it. This is the only case I found where -fira-algorithm=priority fails without -fschedule-insns. Tested revisions: r165915 - crash r165699 - crash
[Bug tree-optimization/46154] [4.6 Regression] ICE: failed to reclaim unneeded function with -fipa-cp -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46154 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug debug/46150] [4.6 Regression] -fcompare-debug failure (length) with -fPIC -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46150 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/46130] [4.6 Regression] ICE: SIGSEGV in walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2 -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46130 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46123 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/46120] [4.6 regression] g++.dg/ipa/ivinline-?.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46120 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug debug/46101] [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/46099] [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46099 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug target/46171] [4.6 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:774 with -fno-tree-dce -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46171 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.10.26 00:50:48 CC||aoliva at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26 00:50:48 UTC --- This crash is from dead_debug_insert_before, will look at it.
[Bug c++/46156] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11370 with -frounding-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46156 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug debug/46095] [4.6 Regression] ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:2341 with -fstack-protector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46095 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/46036] [4.6 Regression] verify_ssa failed: definition in block 3 follows the use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46036 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 01:03:32 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/45913] [4.6 Regression] ICE: in insn_default_length, at config/i386/i386.md:584 with -fselective-scheduling2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45913 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26 01:05:25 UTC --- Fixed.
[Bug middle-end/45876] [4.6 Regression] ICE: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45876 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26 01:07:45 UTC --- Fixed.
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org
[Bug fortran/46010] I/O: Namelist-reading bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46010 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-10-26 01:37:04 UTC --- Created attachment 22156 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22156 Patch to fix this. I think my email service is out. I attach the patch here for review. It may show up on the list. I tried sending it three times.
[Bug target/46179] New: Codegen/TLS: invalid assembler syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46179 Summary: Codegen/TLS: invalid assembler syntax Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: fth...@telegraphics.com.au Target: m68k-linux-gnu Created attachment 22157 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22157 pre-processed source from gen_uuid.c from util-linux gcc version 4.5.2 20101021 (prerelease) (GCC) $ m68k-linux-gnu-gcc -c gen_uuid.i -O2 /tmp/cceVtxzz.s: Assembler messages: /tmp/cceVtxzz.s:709: Error: syntax error -- statement `move.l %d1,last.5...@tlsle+4(%a0)' ignored /tmp/cceVtxzz.s:886: Error: syntax error -- statement `move.l %d1,last.5...@tlsle+4(%a0)' ignored Some background may be found here (relating to debian's gcc-4.4 package which has TLS backported): http://lists.debian.org/debian-68k/2010/10/msg00037.html (In that compiler, the code generated is an offset against TLSLDO, but shows the same bug.) The bug was initially filed for binutils (since closed as invalid): http://sourceware.org/bugzilla/show_bug.cgi?id=12157 Bug may be worked around with -O0.
[Bug tree-optimization/45875] [4.6 Regression] ice in gimple_fold_obj_type_ref_known_binfo with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45875 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26 03:51:52 UTC --- Fixed.
[Bug target/45870] [4.5/4.6 Regression] note: non-delegitimized UNSPEC 5 found (-O1 -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45870 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/45865] [4.6 Regression] ifcvt/crossjump failed to mark return jump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45865 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/46053] [4.6 Regression] g++.dg/torture/pr45699.C FAILs with -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46053 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/45991] [4.6 Regression] ICE: verify_stmts failed: Invalid address operand in in TARGET_MEM_REF. with -fstrict-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45991 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/45971] [4.6 Regression] ice in vect_update_ivs_after_vectorizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45971 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/45934] [4.6 Regression] g++.old-deja/g++.other/dtor5.C FAILs with -finline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45934 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
