[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #7 from Paulo J. Matos 2012-08-02 10:05:40 UTC --- (In reply to comment #6) > With send it to gcc-patches. 's/With/Will/'
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #6 from Paulo J. Matos 2012-08-02 09:58:55 UTC --- Created attachment 27926 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27926 regcprop patch to remove redundant moves This patch seems to fix 54154. I am not sure its generic enough to make it straight into GCC but it works with our port and I ran all the tests I have access to without any regressions. With send it to gcc-patches.
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #5 from Paulo J. Matos 2012-08-02 09:34:03 UTC --- I have now a patch for this which I will submit shortly.
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #4 from Paulo J. Matos 2012-08-01 15:01:29 UTC --- Due to my last comment I marked this as a request for enhancement.
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154
Paulo J. Matos changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #3 from Paulo J. Matos 2012-08-01
15:00:34 UTC ---
OK, so I just noted this is not really a bug but a missed optimization:
/* Assert that SRC has been copied to DEST. Adjust the data structures to
reflect that SRC contains an older copy of the shared value. */
static void
copy_value (rtx dest, rtx src, struct value_data *vd)
{
unsigned int dr = REGNO (dest);
unsigned int sr = REGNO (src);
unsigned int dn, sn;
unsigned int i;
/* ??? At present, it's possible to see noop sets. It'd be nice if this were
cleaned up beforehand... */
if (sr == dr)
return;
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #2 from Paulo J. Matos 2012-08-01 14:37:53 UTC --- Created attachment 27924 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27924 Add debug info when redundant insn is going to be generated Looking at the gcc log header after running cprop_hardreg shows: rescanning insn with uid = 14. deleting insn with uid = 14. insn 14: replaced reg 0 with 1 insn 48: replaced reg 0 with 1 rescanning insn with uid = 48. deleting insn with uid = 48. rescanning insn with uid = 5. deleting insn with uid = 5. oops, substitution makes dest same as src insn 5: replaced reg 0 with 1
[Bug middle-end/54154] cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154 --- Comment #1 from Paulo J. Matos 2012-08-01 14:34:48 UTC --- Created attachment 27923 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27923 After cprop_hardreg
[Bug middle-end/54154] New: cprop_hardreg generates redundant instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54154
Bug #: 54154
Summary: cprop_hardreg generates redundant instructions
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com
Created attachment 27922
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27922
Before cprop_hardreg
Hello,
I have touched this subject before:
* http://gcc.gnu.org/ml/gcc/2010-08/msg00347.html
* http://gcc.gnu.org/ml/gcc/2011-03/msg00214.html
and it looks like a long standing issue so I am wary of reporting a bug but I
think I did find the culprit code. So, unless you consider this a feature
somehow I reckon it's a bug.
cprop_hardreg grabs an insn chain and through forward propagation of registers
ends up generating redundant passes where the src and dest are the same (same
regnumber, same mode).
Consider the program (obtained using creduce):
int a;
int fn1 ();
void fn2 ();
int fn3 ();
int
fn4 ()
{
if (fn1 ())
return 0;
a = fn3 ();
if (a != (1 << (32 - (9 + 9))) - 1)
fn2 (0, a);
return (1 << (32 - (9 + 9))) - 1;
}
Now, after compiling for my backend with -Os I get before cprop_hardreg (after
ce3) [real logs attached]:
#8 reg AL <- call fn1
#50/51 if_then_else AL != 0
goto label 34
#12AL <- call fn3
#13AH <- AL
#14mem sym a <- AH
#48/49 if_then_else AH == 16383
goto label 38
#17AL <- 0
#19call fn2
#4 AL <- 16383
#43jump label 20
label 34:
#3 AL <- 0
#45jump label 20
label 38:
#5 AL <- AH
label 20:
return
the number after '#' is the insn number.
cprop_hardreg decided to replace AH with AL so the top of cprop_hardreg shows:
rescanning insn with uid = 14.
deleting insn with uid = 14.
insn 14: replaced reg 0 with 1
insn 48: replaced reg 0 with 1
rescanning insn with uid = 48.
deleting insn with uid = 48.
rescanning insn with uid = 5.
deleting insn with uid = 5.
insn 5: replaced reg 0 with 1
reg 0 is AH and reg 1 is AL.
When you replace in insn 5, AH by AL you get the insn AL <- AL and that's #5
after cprop_hardreg.
I find it strange that there's no code checking if set dest is equal to
replacement and if it is, simply remove insn.
I think this is a bug and should be fixed.
[Bug middle-end/53917] Warning message line about variable points to place where variable doesn't occur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917 --- Comment #2 from Paulo J. Matos 2012-07-10 16:38:22 UTC --- Created attachment 27772 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27772 Another testcase (inlining issue)
[Bug middle-end/53917] Warning message line about variable points to place where variable doesn't occur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917
--- Comment #1 from Paulo J. Matos 2012-07-10
16:37:20 UTC ---
Here's another example:
void fn1 ();
typedef struct
{
int hdr[0];
} foo;
typedef enum
{
READ_WRITE
} bar;
typedef struct
{
struct
{
foo t1;
} mp;
} foobar;
bar fn2 ();
typedef struct
{
foobar tag_mem_config;
} tag;
static int
fn3 (foobar * p1)
{
int valid;
if (p1->mp.t1.hdr[0])
valid = 0;
else
switch (fn2 ())
case 0:
valid = 1;
return valid;
}
void
fn4 ()
{
tag p_t1_rw_fsm_data;
if (fn3 (&p_t1_rw_fsm_data.tag_mem_config))
fn1 ();
}
GCC says:
test.c: In function 'fn4':
test.c:38:8: warning: 'valid' may be used uninitialized in this function
[-Wuninitialized]
Again, line 38 is: if (fn3 (&p_t1_rw_fsm_data.tag_mem_config))
In this case this looks like it's related to inlining.
[Bug middle-end/53917] New: Warning message line about variable points to place where variable doesn't occur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917
Bug #: 53917
Summary: Warning message line about variable points to place
where variable doesn't occur
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com
Created attachment 27771
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27771
Testcase
Hi,
I have noticed that when compiling the following test case (will attach to the
bug):
test1.c:
int a, b;
void fn1 ();
typedef enum
{
READ_WRITE
} TAG_STATE;
TAG_STATE fn2 ();
void
fn3 ()
{
int c;
if (a)
c = 0;
else
switch (fn2 ())
case 0:
c = 1;
b = c;
if (b)
fn1 ();
}
gcc says:
$ gcc -Os -S -Wall test1.c
test1.c: In function 'fn3':
test1.c:19:8: warning: 'c' may be used uninitialized in this function
[-Wuninitialized]
However line 19 is 'if (b)'.
Used gcc46 but also reproducible with gcc47.
[Bug c/16351] NULL dereference warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 Paulo J. Matos changed: What|Removed |Added CC||Paulo.Matos at csr dot com --- Comment #10 from Paulo J. Matos 2012-07-02 14:36:40 UTC --- I wonder if this is ever going to be fixed and if not, if there's any point in being open.
[Bug middle-end/53454] New: [RX backend]: redundant insn being expanded for long long trivial arithmetic comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53454
Bug #: 53454
Summary: [RX backend]: redundant insn being expanded for long
long trivial arithmetic comparison
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com
I was comparing my port double word arithmetic comparison with the one from rx
and I noticed some strange code being expanded.
In GCC4.6.3 for the code compiled with -Os:
int le(long long x) { return x <= 0; }
I get after expand:
;; Generating RTL for gimple basic block 2
;; return D.1216_2;
(insn 9 8 10 (set (reg:SI 27)
(const_int 1 [0x1])) test.c:1 -1
(nil))
(jump_insn 10 9 11 (set (pc)
(if_then_else (gt (subreg:SI (reg/v:DI 26 [ x ]) 4)
(const_int 0 [0]))
(label_ref 16)
(pc))) test.c:1 -1
(nil))
(jump_insn 11 10 12 (set (pc)
(if_then_else (ne (subreg:SI (reg/v:DI 26 [ x ]) 4)
(const_int 0 [0]))
(label_ref 18)
(pc))) test.c:1 -1
(nil))
(jump_insn 12 11 13 (set (pc)
(if_then_else (ne (subreg:SI (reg/v:DI 26 [ x ]) 0)
(const_int 0 [0]))
(label_ref 16)
(pc))) test.c:1 -1
(nil))
(jump_insn 13 12 14 (set (pc)
(if_then_else (ne (subreg:SI (reg/v:DI 26 [ x ]) 0)
(const_int 0 [0]))
(label_ref 18)
(pc))) test.c:1 -1
(nil))
(jump_insn 14 13 15 (set (pc)
(label_ref 18)) test.c:1 -1
(nil))
(barrier 15 14 16)
(code_label 16 15 17 3 "" [0 uses])
(insn 17 16 18 (set (reg:SI 27)
(const_int 0 [0])) test.c:1 -1
(nil))
(code_label 18 17 19 2 "" [0 uses])
(insn 19 18 20 (set (reg:SI 24 [ ])
(reg:SI 27)) test.c:1 -1
(nil))
(jump_insn 20 19 21 (set (pc)
(label_ref 0)) test.c:1 -1
(nil))
(barrier 21 20 0)
What's strange in here are insn 12/13, insn 13 is redundant. Marked this as
minor since it seems to me that GCC notices this and the assembly generation is
ok.
[Bug middle-end/53347] New: Duplicated redundant condition in compare-elim.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53347 Bug #: 53347 Summary: Duplicated redundant condition in compare-elim.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com There's a duplicated redundant condition in compare-elim.c, line 148: if (REG_P (XEXP (src, 0)) && REG_P (XEXP (src, 0)) && (REG_P (XEXP (src, 1)) || CONSTANT_P (XEXP (src, 1 return src; This can be simplified: if (REG_P (XEXP (src, 0)) && (REG_P (XEXP (src, 1)) || CONSTANT_P (XEXP (src, 1 return src; I think care must be taken to ensure that this is indeed duplicated and that the developer didn't intend to write something else instead.
[Bug rtl-optimization/52235] rtlanal: commutative_operand_precedence should prioritize regs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52235 --- Comment #3 from Paulo J. Matos 2012-02-14 07:27:50 UTC --- Thanks for the reminder Steven. Now submitted.
[Bug rtl-optimization/52235] rtlanal: commutative_operand_precedence should prioritize regs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52235 --- Comment #1 from Paulo J. Matos 2012-02-13 16:58:17 UTC --- Created attachment 26651 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26651 Patch to increase regs priority in commutative_operand_precedence
[Bug rtl-optimization/52235] New: rtlanal: commutative_operand_precedence should prioritize regs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52235 Bug #: 52235 Summary: rtlanal: commutative_operand_precedence should prioritize regs Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com I noticed the combine receives insns of the form: (set (reg ...) (ior (mem (reg ...)) (reg ...))) (in my specific case the reg inside mem was an argument pointer that later would be eliminated in terms of a function pointer. After an initial discussion in the mailing list: http://www.mail-archive.com/gcc@gcc.gnu.org/msg62132.html Richard pointed me to commutative_operand_precedence. Both him and I expected to see the register come first. Having the register come first is more intuitive and under my backend it performs much better. The whole reason to look into this stemmed from the fact that commutative operations like ior were not being correctly combined since the backend rule looked like: (define_insn "iorqi3" [(set (match_operand:QI 0 "register_operand" "=c") (ior:QI (match_operand:QI 1 "register_operand" "%0") (match_operand:QI 2 "general_operand" "cwmi"))) (clobber (reg:CC RCC))] "" "or\\t%0,%f2") Makes sense for operand1 to be a register_operand because it will be forced to be the same as operand0. However, if we can't assume registers come first a lot of rule duplication has to occur in order to achieve the same effect. I would guess in this case I would need to have instead of the above: (define_insn "iorqi3" [(set (match_operand:QI 0 "register_operand" "=c") (ior:QI (match_operand:QI 1 "register_operand" "0") (match_operand:QI 2 "general_operand" "cwmi"))) (clobber (reg:CC RCC))] "" "or\\t%0,%f2") (define_insn "iorqi3" [(set (match_operand:QI 0 "register_operand" "=c") (ior:QI (match_operand:QI 1 "general_operand" "cwmi") (match_operand:QI 2 "register_operand" "0"))) (clobber (reg:CC RCC))] "" "or\\t%0,%f1") The simple fix of making registers have priority over everything else works like a charm. Patch follows.
[Bug target/50794] New: [picochip] incorrect implementation of ashrsi3 for negative numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50794 Bug #: 50794 Summary: [picochip] incorrect implementation of ashrsi3 for negative numbers Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com I was looking at the ashrsi3 implementation in picochip and I find something odd. I think it would generate incorrect results for negative numbers. Note, however that I have not tested the code, so this is through inspection only. Picochip ashrsi3.c contains the following piece of code: /* Given a word of sign bits, shift back left to create the destination sign bits. */ wordOfSignBits = __builtin_asri(value.s.high, 15); signWord = wordOfSignBits << reverseCount; result.s.high |= signWord; Note however that wordOfSignBits should be 0x for negative value.s.high and 0x for positive value.s.high. However, this will either be 0x for positive value.s.high or 0x0001 for negative value.s.high. This is because value.s.high is unsigned, so arithmetic shift will be performed as if on an unsigned value and the word will never contain the expected value. Replacing the above by: /* Given a word of sign bits, shift back left to create the destination sign bits. */ + HItype topword = value.s.high; + wordOfSignBits = __builtin_asri(topword, 15); - wordOfSignBits = __builtin_asri(value.s.high, 15); signWord = wordOfSignBits << reverseCount; result.s.high |= signWord;
[Bug middle-end/50706] Fold check failed (expected tree that contains 'typed' structure, have 'block' in fold_checksum_tree, at fold-const.c:13921)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50706 --- Comment #4 from Paulo J. Matos 2011-10-18 07:51:28 UTC --- Created attachment 25537 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25537 Another testcase.
[Bug middle-end/50706] Fold check failed (expected tree that contains 'typed' structure, have 'block' in fold_checksum_tree, at fold-const.c:13921)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50706 Paulo J. Matos changed: What|Removed |Added CC||Paulo.Matos at csr dot com --- Comment #3 from Paulo J. Matos 2011-10-18 07:50:36 UTC --- I also stumbled upon this. Reproduced with 4.6 and 4.7. I attach yet another testcase.
[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801 --- Comment #12 from Paulo J. Matos 2011-10-17 15:26:51 UTC --- Sorry for the time taken to reply. I have tested snapshots of 4.6 and 4.7 and both seem happy now. Looks like it's sorted. Thanks.
[Bug debug/40713] Overlapping .debug_ranges (C++)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40713 --- Comment #6 from Paulo J. Matos 2011-10-11 11:48:08 UTC --- (In reply to comment #5) > As the home page says, 4.4.x is the oldest maintained branch.. Right! Sorry for the noise.
[Bug debug/40713] Overlapping .debug_ranges (C++)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40713 Paulo J. Matos changed: What|Removed |Added CC||Paulo.Matos at csr dot com --- Comment #4 from Paulo J. Matos 2011-10-11 10:34:52 UTC --- This also seems to occur on gcc 4.3.6, is the patch ever going to be backported there?
[Bug target/50630] New: rx: sbb_flags doesn't call rx_match_ccmode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50630 Bug #: 50630 Summary: rx: sbb_flags doesn't call rx_match_ccmode Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com Hi, I am not sure but I think *sbb_flags should be predicated by "reload_completed && rx_match_ccmode(insn, CC_ZSCmode)" as is the case for *adc_flags. I don't think this is a major problem. In the worst case, GCC is just not generating code as good as it could.
[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
--- Comment #3 from Paulo J. Matos 2011-10-05
11:08:36 UTC ---
(In reply to comment #2)
> Is this bug still reproducible for you ?
>
> I tried building an rx-elf toolchain from the current 4.6 branch sources and
> I could not reproduce the problem...
Hi Nick,
Yes, this is still reproducible.
Here's what I did.
$ wget
ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/snapshots/4.6-20110930/gcc-4.6-20110930.tar.bz2
$ mkdir gcc-build && cd gcc-build
$ ../gcc-4.6-20110930/configure --enable-languages=c --target=rx-linux-elf
--disable-libssp --disable-shared --disable-libquadmath --enable-checking=all
--prefix=$HOME/local/rx-gcc-461-head && make -j5
$
$ gcc/cc1 -Os -da -fdump-tree-all-all shift.c
{GC 953k -> 896k} foo {GC 900k -> 899k}
Analyzing compilation unit
{GC 1092k -> 959k} {GC 959k -> 959k}Performing interprocedural optimizations
<*free_lang_data> {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC
959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k ->
959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k}
{GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k}
{GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k} {GC 964k -> 963k} {GC 963k -> 963k} {GC 965k ->
963k} {GC 964k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k
-> 963k} {GC 964k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k}
{GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k}
{GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k}Assembling functions:
foo {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k}
{GC 965k -> 965k} {GC 966k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC
968k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k ->
965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k}
{GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC
967k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 966k ->
966k} {GC 966k -> 966k} {GC 966k -> 966k} {GC 966k -> 966k} {GC 966k -> 965k}
{GC 972k -> 969k} {GC 969k -> 969k} {GC 970k -> 969k} {GC 969k -> 969k} {GC
969k -> 969k} {GC 969k -> 969k} {GC 974k -> 973k} {GC 973k -> 973k} {GC 973k ->
973k} {GC 973k -> 971k} {GC 971k -> 971k} {GC 972k -> 971k} {GC 972k -> 972k}
{GC 973k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC
972k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 972k ->
972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 974k -> 972k} {GC 972k -> 972k}
shift.c: In function ‘foo’:
shift.c:7:1: internal compiler error: in df_live_verify_transfer_functions, at
df-problems.c:1816
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug other/50582] Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50582 --- Comment #3 from Paulo J. Matos 2011-10-05 10:53:06 UTC --- Created attachment 25420 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25420 Allows reload to remove trivial insn I noticed that reload was failing to remove insn of the form: (parallel [(set rX rX) (clobber RCC)]) Attached is a patch that does this. Removes move instructions whose clobber, clobbers registers defined in NOT_REALLY_HARD_REG.
[Bug other/50582] Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50582 --- Comment #2 from Paulo J. Matos 2011-09-30 15:57:21 UTC --- Created attachment 25389 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25389 Patch for GCC 4.6.1 implementing suggested enhancement
[Bug other/50582] Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50582
--- Comment #1 from Paulo J. Matos 2011-09-30
15:54:25 UTC ---
I have implemented a fix to this using a new macro: NOT_REALLY_HARD_REGS which
is an array of FIRST_PSEUDO_REGISTER length, with a 1 in position x if register
x should not be considered a hard register for the purposes of
added_clobbers_hard_reg_p.
So for my backend where FIRST_PSEUDO_REGISTER = 14, CC_REGNUM = 13,
NOT_REALLY_HARD_REGS looks as follows:
#define NOT_REALLY_HARD_REG \
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 }
I attach a patch to genemit.c implementing this enhancement.
[Bug other/50582] New: Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50582 Bug #: 50582 Summary: Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com As noted in : http://gcc.gnu.org/ml/gcc/2011-09/msg00313.html `insn_invalid_p' calls `added_clobbers_hard_reg_p' with the comment: /* If we have to add CLOBBERs, fail if we have to add ones that reference hard registers since our callers can't know if they are live or not. Otherwise, add them. */ Backends like rx and mn10300 implement CC_REGNUM as a register containing flags, however, none of their move instructions clobbers CC_REGNUM. If a backend move clobbers CC_REGNUM a move instruction (set r0 r1) is deemed as invalid because the pattern for it is: (parallel [(set r0 r1) (clobber CC_REGNUM)]) However, this shouldn't be the case. The backend should be able to inform genemit.c which registers shouldn't be considered hard registers for the purpose of `added_clobbers_hard_reg_p'.
[Bug tree-optimization/49601] [4.7 Regression] ICE at ipa-inline-analysis.c:1188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49601 --- Comment #4 from Paulo J. Matos 2011-09-23 13:22:15 UTC --- (In reply to comment #3) > Richard raised concerns about this PR being an old bug and already fixed. > Initially I only confirmed it in 4.6.1 but I can reproduce it in git head > 36181f98f (that's from 30mins ago). Ignore previous comment. Wrong bug.
[Bug regression/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472 Paulo J. Matos changed: What|Removed |Added CC||Paulo.Matos at csr dot com --- Comment #3 from Paulo J. Matos 2011-09-23 13:20:57 UTC --- Richard raised concerns about this PR being an old bug and already fixed. Initially I only confirmed it in 4.6.1 but I can reproduce it in git head 36181f98f (that's from 30mins ago).
[Bug tree-optimization/49601] [4.7 Regression] ICE at ipa-inline-analysis.c:1188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49601 Paulo J. Matos changed: What|Removed |Added CC||Paulo.Matos at csr dot com --- Comment #3 from Paulo J. Matos 2011-09-23 13:19:33 UTC --- Richard raised concerns about this PR being an old bug and already fixed. Initially I only confirmed it in 4.6.1 but I can reproduce it in git head 36181f98f (that's from 30mins ago).
[Bug regression/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472 --- Comment #2 from Paulo J. Matos 2011-09-23 13:18:10 UTC --- (In reply to comment #1) > Duplicate of PR50078? Might be but I can't confirm. Surely we will know once Mat fixes PR50078.
[Bug regression/50472] New: Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472
Bug #: 50472
Summary: Volatile qualification in data is not enough to avoid
optimization over pointer to data
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com
Given the following code:
static const unsigned int foo = 1;
unsigned int test( void )
{
const volatile unsigned int *bar = &foo;
return ( *bar );
}
GCC46 is generating:
$ local/gcc-4.6.1/bin/gcc -Os -S vol.c
$ cat vol.s
...
test:
.LFB0:
.cfi_startproc
movl$1, %eax
ret
.cfi_endproc
...
This is optimizing away bar even though the data bar points to is being
qualified as volatile. The way to ensure this doesn't happen requires
qualifying the pointer as a volatile too:
static const unsigned int foo = 1;
unsigned int test( void )
{
const volatile unsigned int * volatile bar = &foo;
return ( *bar );
}
$ local/gcc-4.6.1/bin/gcc -Os -S vol.c
$ cat vol.s
...
test:
.LFB0:
.cfi_startproc
movq$foo, -8(%rsp)
movq-8(%rsp), %rax
movl(%rax), %eax
ret
.cfi_endproc
...
This is a regression to what GCC45 used to do. Qualification of the data as
volatile used to be enough to block the optimization.
Posting this to the mailing list revealed Ian agrees this is a regression:
http://gcc.gnu.org/ml/gcc/2011-09/msg00197.html
[Bug other/50434] New: genmodes.c hardcodes size of CCmode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50434 Bug #: 50434 Summary: genmodes.c hardcodes size of CCmode Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com The size of CCmode is harcoded in genmodes.c as 4 bytes: case MODE_CC: /* Again, nothing more need be said. For historical reasons, the size of a CC mode is four units. */ validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET); m->bytesize = 4; m->ncomponents = 1; m->component = 0; break; However, this seems to work when the size of a byte is 8 bits, however, if this changes then things start to break. I have a backend where a byte is 16 bits (size of a word and unit and also size of int) and m->bytesize = 1; is the correct value. Paul Koning suggested making it equal to word size. Thread is : http://www.mail-archive.com/gcc@gcc.gnu.org/msg59864.html
[Bug other/50345] New: Incomplete GCC Internals sentence on LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345 Bug #: 50345 Summary: Incomplete GCC Internals sentence on LTO Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com In the GCC Internals manual, LTO chapter (http://gcc.gnu.org/onlinedocs/gccint/LTO.html) there's the sentence (2nd paragraph): "A, perhaps surprising, side effect of this feature is that any mistake in the toolchain that leads to LTO information not being used (e.g. an older libtool calling ld directly)." I have a feeling that the mentioned 'surprising side effect' is never actually explained.
[Bug c/50264] New: -Wdisabled-optimizations without -O generates strange errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50264 Bug #: 50264 Summary: -Wdisabled-optimizations without -O generates strange errors Classification: Unclassified Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com Try: echo 'char id[] = "x";' > id_test.c Then: $ gcc-4.3.4 -Wdisabled-optimization -c id_test.c cc1: warning: -funit-at-a-time is required for inlining of functions that are only called once That warning looks like a bug to me and Ian.
[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801 Paulo J. Matos changed: What|Removed |Added Severity|normal |major
[Bug rtl-optimization/49884] get_last_value in combine ignores register mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49884 --- Comment #1 from Paulo J. Matos 2011-07-28 09:46:36 UTC --- Created attachment 24854 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24854 Fixes PR49884 Sent to gcc-patches.
[Bug rtl-optimization/49884] New: get_last_value in combine ignores register mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49884
Summary: get_last_value in combine ignores register mode
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com
Created attachment 24853
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24853
Insn list right before combine when compiling test with gcc-4.6.1 and -Os
I have noticed this with GCC 4.3.4, GCC 4.4.4, GCC 4.5.2 and GCC 4.6.1.
The problem was triggered by a change in our backend and none of our testsuites
have ever caught it. Only by analysing the generated code we noticed something
was wrong when compiling:
unsigned long val;
int swap_magic(void)
{
unsigned int low = val;
unsigned int high = (val >> 16);
unsigned long swapped = ((unsigned long)low << 16) | (unsigned long)high;
if(swapped == 0x12345678)
return 1;
else
return 0;
}
This happens in our port with that has the following types:
int : QImode (1 word, 16 bits)
unsigned long : HImode (2 words, 32 bits)
and the following constraints:
- a shift can only be done in HImode over registers AH and AL (AH holds the 16
most significant bits and AL holds the 16 least significant bits).
So, our backend expand a shift over an unsigned long like:
(define_expand "ashlhi3"
[
(use (match_operand:HI 0 "nonimmediate_operand" ""))
(use (match_operand:HI 1 "general_operand" ""))
(use (match_operand:QI 2 "general_operand" ""))
]
""
{ xap_expand_HIoperation(ASHIFT, operands); DONE; })
(define_insn "*ashlhi3"
[
(set (reg:HI RAH)
(ashift:HI (reg:HI RAH)
(match_operand:QI 0 "general_operand" "cwmi")))
]
""
"asl\\t%f0"
[(set_attr "cc" "set_c")]
)
and xap_expand_HIoperation for ASHIFT does:
rtx regAH_HI = gen_rtx_REG(HImode, RAH);
emit_insn(gen_movhi(regAH_HI, operands[1]));
emit_insn(gen_rtx_SET(VOIDmode,
regAH_HI,
gen_rtx_ASHIFT(HImode, regAH_HI, operands[2])));
emit_insn(gen_movhi(operands[0], regAH_HI));
The ior in HImode, which also uses AH:HImode, splits into two QImode iors.
So, we arrive at combine (after dce pass) with the following (simplified) insn
list:
regQI 37 <- memQI val
regQI 38 <- memQI val + 1
regQI AH <- const_int 0
regQI AL <- regQI 38
regHI AH <- ashift regHI AH, 16
regQI 45 <- regQI AH
...
cc0 <- compare regQI 45, const_int 0x1234
if_then_else cc0 != const_int 0, jump to label 27, pc
[the full insn list is attached]
The problem is that combine assumes the jump is always true because it thinks
that regQI 45 is zero!
The problem stems from get_last_value when applied to regHI AH in the shift
insn. get_last_value when applied to regHI AH during the ashift instruction
returns const_int 0. Should return 0. We don't know the value! We know that
regQI AH was set to zero but the value of regHI AH needs to take AL into
consideration so we really don't know it.
get_last_value should take the mode of the register into consideration when
returning the value it was last set to. If the last set value was set in a
different mode, then we can say nothing about the value in the register.
[Bug c/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801 --- Comment #1 from Paulo J. Matos 2011-07-21 09:03:06 UTC --- I pinpointed this issue to the bitmaps computed in df_live_verify_transfer_functions (df-problems.c). bitmap saved_gen has no bit set while bb_info->gen has bit 16 set (corresponding to the CC reg). Something seems to be confusing function computing these values but I haven't been able yet to pinpoint the problem.
[Bug c/49801] New: df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
Summary: df_live_verify_transfer_functions fails with to use of
CC_REGNUM and checking enabled in rx backend
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com
Created attachment 24802
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24802
files resulting from -da -fdump-tree-all-all
Compiled the rx backend enough to get a cc1:
$ ../gcc-4.6.1/configure --enable-languages=c --target=rx-linux-elf
--disable-libssp --disable-shared --disable-libquadmath --enable-checking=all
--prefix=$HOME/local/rx-gcc-461 && make -j5
...
$ cat shift.c
unsigned long foo(unsigned int a, unsigned int b)
{
if(a < b)
return a << b;
else
return a >> b;
}
$ ~/tmp/rx-gcc461-build/gcc/cc1 -Os -da -fdump-tree-all-all shift.c
{GC 953k -> 896k} foo {GC 900k -> 899k}
Analyzing compilation unit
{GC 1092k -> 959k} {GC 959k -> 959k}Performing interprocedural optimizations
<*free_lang_data> {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC
959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k ->
959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k}
{GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k}
{GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k} {GC 964k -> 963k} {GC 963k -> 963k} {GC 965k ->
963k} {GC 964k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k
-> 963k} {GC 964k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k}
{GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k}
{GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k}Assembling functions:
foo {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k}
{GC 965k -> 965k} {GC 966k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC
968k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k ->
965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k}
{GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC
967k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 966k ->
966k} {GC 966k -> 966k} {GC 966k -> 966k} {GC 966k -> 966k} {GC 966k -> 965k}
{GC 972k -> 969k} {GC 969k -> 969k} {GC 970k -> 969k} {GC 969k -> 969k} {GC
969k -> 969k} {GC 969k -> 969k} {GC 974k -> 973k} {GC 973k -> 973k} {GC 973k ->
973k} {GC 973k -> 971k} {GC 971k -> 971k} {GC 972k -> 972k} {GC 972k -> 972k}
{GC 973k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC
972k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 973k -> 972k} {GC 972k ->
972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 974k -> 972k} {GC 972k -> 972k}
shift.c: In function ‘foo’:
shift.c:7:1: internal compiler error: in df_live_verify_transfer_functions, at
df-problems.c:1816
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 --- Comment #6 from Paulo J. Matos 2011-02-17 16:23:47 UTC --- Thanks Paolo, I will take a look at those patches.
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 --- Comment #4 from Paulo J. Matos 2011-02-17 16:04:36 UTC --- Thanks Andy, was that documented anywhere? It would be interesting for me to know which other stuff became compulsory to implement in the backend.
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 --- Comment #2 from Paulo J. Matos 2011-02-17 14:56:45 UTC --- Just a note to this... this bug assumes that cbranch4 is _not_ implemented. If cbranch4 is not an optional standard name to implement then this bug is invalid, but we should document this requirement somewhere. I just noticed that optabs.h has the comment before can_compare_p: /* Nonzero if a compare of mode MODE can be done straightforwardly (without splitting it into pieces). */ extern int can_compare_p (enum rtx_code, enum machine_mode, enum can_compare_purpose); By this I assume that cbranch should be implemented if there is an instruction that performs a compare and branch in one go without ''splitting it into pieces''. However, by looking at the vax case (which I think it does not have such an intruction) cbranch is implemented as: (define_expand "cbranch4" [(set (cc0) (compare (match_operand:VAXint 1 "nonimmediate_operand" "") (match_operand:VAXint 2 "general_operand" ""))) (set (pc) (if_then_else (match_operator 0 "ordered_comparison_operator" [(cc0) (const_int 0)]) (label_ref (match_operand 3 "" "")) (pc)))] "") which ends up expanding it into multiple insns... I can do the same on my side. However, that makes cbranch non-optional which is not-documented and breaks backward compatibility (in the sense that in previous gcc versions the lack of a cbranch implementation didn't seem to trigger any strange bug).
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 --- Comment #1 from Paulo J. Matos 2011-02-17 11:55:32 UTC --- Created attachment 23379 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23379 source code to reproduce bug
[Bug middle-end/47782] New: Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 Summary: Infinite cycle generates segmentation fault in targets without cbranch support Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com Created attachment 23378 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23378 patch to assert !can_compare_p I have tested this with gcc 4.5.2. It doesn't happen in 4.4.4. There's a possibility for an infinite loop between two dojump.c functions: do_jump_by_parts_greater_rtx and do_compare_rtx_and_jump One condition needs to be met: !can_compare_p(code, mode, ccp_jump). As far as I understand from the code this is when the target doesn't implement cbranch. Unfortunately you can't reproduce it straightforwardly with i386 since it implements cbranch but by patching gcc with the no-cbranch.patch you can make gcc think there's no cbranch. The minimized and modified testcase is _mulhi3.i. You'll be able to reproduce this on a 64bit. If you have a 32bit you might reproduce it without any changes but you can also try (but it is untested) the substitutions s/DI/SI and s/TI/DI. Run the line: /cc1 -O2 _muldi3.i I have seen two behaviours... either you get a segmentation fault or an infinite loop that will eat all your memory if you don't limit it. In the meantime I am trying to sort out what the problem is.
