[Bug target/92767] [m68k]: Random ICE: verify_flow_info failed

2019-12-03 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92767

--- Comment #1 from Bernd Schmidt  ---
People will be more likely to look at it if there's a preprocessed .i file that
reproduces the issue, ideally with a cross compiler rather than a native
bootstrap.
If it only occurs when bootstrapping, narrowing down the offending commit would
be helpful.

[Bug target/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases

2019-11-25 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Bernd Schmidt  ---
Fixed.

[Bug target/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases

2019-11-25 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851

--- Comment #8 from Bernd Schmidt  ---
Author: bernds
Date: Mon Nov 25 12:31:16 2019
New Revision: 278681

URL: https://gcc.gnu.org/viewcvs?rev=278681=gcc=rev
Log:
Convert m68k to not use cc0

* config/m68k/m68k.c (output_move_himode, output_move_qimode):
Replace code for non-CONST_INT constants with gcc_unreachable.
* config/m68k/m68k.md (cbranchdi): Don't generate individual
compare and test.
(CMPMODE): New mode_iterator.
(cbranchsi4, cbranchqi4, cbranchhi4): Replace expanders with
cbranch4.
(cstoresi4, cstoreqi4, cstorehi4): Replace expanders with
cstore4.
(cmp_68881): Remove 'F' constraint from first comparison
operand.
(bit test insns patterns): Use nonimmediate_operand, not
register_operand, for source operands that allow memory in
their constraints.
(divmodsi4, udivmodsi4, divmodhi4 and related unnamed patterns):
Use register_operand, not nonimmediate_operand, for the
destinations.
(DBCC): New mode_iterator.
(dbcc peepholes): Use it to reduce duplication.
(trap): Use const_true_rtx, not const1_rtx.
* config/m68k/predicates.md (m68k_comparison_operand): Renamed
from m68k_subword_comparison_operand and changed to handle
SImode.

PR target/91851
* config/m68k/m68k-protos.h (output-dbcc_and_branch): Adjust
declaration.
(m68k_init_cc): New declaration.
(m68k_output_compare_di, m68k_output_compare_si)
(m68k_output_compare_hi, m68k_output_compare_qi)
(m68k_output_compare_fp, m68k_output_btst, m68k_output_bftst)
(m68k_find_flags_value, m68k_output_scc, m68k_output_scc_float)
(m68k_output_branch_integer, m68k_output_branch_integer_rev.
m68k_output_branch_float, m68k_output_branch_float_rev):
Likewise.
(valid_dbcc_comparison_p_2, flags_in_68881)
(output_btst): Remove declaration.
* config/m68k/m68k.c (INCLDUE_STRING): Define.
(TARGET_ASM_FINAL_POSTSCAN_INSN): Define.
(valid_dbcc_comparison_p_2, flags_in_68881): Delete functions.
(flags_compare_op0, flags_compare_op1, flags_operand1,
flags_operand2, flags_valid): New static variables.
(m68k_find_flags_value, m68k_init_cc): New functions.
(handle_flags_for_move, m68k_asm_final_postscan_insn,
remember_compare_flags): New static functions.
(output_dbcc_and_branch): New argument CODE.  Use it, and add
PLUS and MINUS to the possible codes.  All callers changed.
(m68k_output_btst): Renamed from output_btst.  Remove OPERANDS
and INSN arguments, add CODE arg.  Return the comparison code
to use.  All callers changed.  Use CODE instead of
next_insn_tests_no_inequality, and replace cc_status management
with changing the return code.
(m68k_rtx_costs): Instead of testing for COMPARE, test for
RTX_COMPARE or RTX_COMM_COMPARE.
(output_move_simode, output_move_qimode): Call
handle_flags_for_move.
(notice_update_cc): Delete function.
(m68k_output_bftst, m68k_output_compare_di, m68k_output_compare_si,
m68k_output_compare_hi, m68k_output_compare_qi,
m68k_output_compare_fp, m68k_output_branch_integer,
m68k_output_branch_integer_rev, m68k_output_scc,
m68k_output_branch_float, m68k_output_branch_float_rev,
m68k_output_scc_float): New functions.
(output_andsi3, output_iorsi3, output_xorsi3): Call CC_STATUS_INIT
once at the start, and set flags_valid and flags_operand1 if the
flags are usable.
* config/m68k/m68k.h (CC_IN_68881, NOTICE_UPDATE_CC,
CC_OVERFLOW_UNUSABLE, CC_NO_CARRY, OUTPUT_JUMP): Remove
definitions.
(CC_STATUS_INIT): Define.
* config/m68k/m68k.md (flags_valid): New define_attr.
(tstdi, tstsi_internal_68020_cf, tstsi_internal, tsthi_internal,
tstqi_internal, tst_68881, tst_cf, cmpdi_internal,
cmpdi, unnamed cmpsi/cmphi/cmpqi patterns, cmpsi_cf,
cmp_68881, cmp_cf, unnamed btst patterns,
tst_bftst_reg, tst_bftst_reg, unnamed scc patterns, scc,
sls, sordered_1, sunordered_1, suneq_1, sunge_1, sungt_1,
sunle_1, sunlt_1, sltgt_1, fsogt_1, fsoge_1, fsolt_1, fsole_1,
bge0_di, blt0_di, beq, bne, bgt, bgtu, blt, bltu, bge, bgeu,
ble, bleu, bordered, bunordered, buneq, bunge, bungt, bunle,
bunlt, bltgt, beq_rev, bne_rev, bgt_rev, bgtu_rev,
blt_rev, bltu_rev, bge_rev, bgeu_rev, ble_rev, bleu_rev,
bordered_rev, bunordered_rev, buneq_rev, bunge_rv, bungt_rev,
bunle_rev, bunlt_rev, bltgt_rev, ctrapdi4, ctrapsi4, ctraphi4,
ctrapqi4, conditional_trap): Delete patterns.
(cbranchdi4_insn): New pattern.
(cbranchdi4): Don't generate cc0 patterns.  When testing LT 

[Bug c/90677] [9/10 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type

2019-11-22 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #9 from Bernd Schmidt  ---
Created attachment 47333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47333=edit
Candidate patch

I was actually using the following during testing recently. I can't see a
reason to emit an error in that function.
This was bootstrapped and tested on the gcc135 machine.

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

2019-03-28 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865

--- Comment #2 from Bernd Schmidt  ---
Jakub seems to be the author of gcc.target/i386/pr49095.c.

[Bug tree-optimization/78972] [5/6/7/8 Regression] poor x86 simd instruction scheduling

2017-08-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972

--- Comment #11 from Bernd Schmidt  ---
For reference: patch and discussion here.
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01058.html

[Bug middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation

2017-08-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

--- Comment #15 from Bernd Schmidt  ---
For reference: patch and discussion here.
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01058.html

[Bug middle-end/80283] [5/6/7 Regression] bad SIMD register allocation

2017-04-04 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

--- Comment #9 from Bernd Schmidt  ---
Cou(In reply to Michael_S from comment #8)
> Here is a variant that makes an issue to show on x64 with -fno-tree-ter.
> https://godbolt.org/g/mSLiRZ

Could you attach this here as well? I've been trying to get the testcase out of
godbolt, but there seems not to be a save option and copy & paste doesn't work
either.

In general, the problem is that ter makes pessimal scheduling decisions,
increasing register pressure. The patch I have adds a little mini-scheduler
into the expand stage to try to prevent this. In theory that should also work
for testcases where the bad scheduling was done manually, but I'd like to
check.

[Bug middle-end/80283] [5/6/7 Regression] bad SIMD register allocation

2017-04-03 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

--- Comment #7 from Bernd Schmidt  ---
Well, I've made a small tweak to the patch I have for PR78972, and I've got
what at a glance looks like optimal code (no spills).

[Bug target/80160] [7 regression] operand has impossible constraints

2017-03-24 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80160

--- Comment #7 from Bernd Schmidt  ---
Author: bernds
Date: Sat Mar 25 01:12:04 2017
New Revision: 246473

URL: https://gcc.gnu.org/viewcvs?rev=246473=gcc=rev
Log:
PR rtl-optimization/80160
PR rtl-optimization/80159
* lra-assigns.c (must_not_spill_p): Tighten new test to also take
reg_alternate_class into account.

* gcc.target/i386/pr80160.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr80160.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/80159] [7 regression] gcc takes very long time with -Os

2017-03-24 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80159

--- Comment #4 from Bernd Schmidt  ---
Author: bernds
Date: Sat Mar 25 01:12:04 2017
New Revision: 246473

URL: https://gcc.gnu.org/viewcvs?rev=246473=gcc=rev
Log:
PR rtl-optimization/80160
PR rtl-optimization/80159
* lra-assigns.c (must_not_spill_p): Tighten new test to also take
reg_alternate_class into account.

* gcc.target/i386/pr80160.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr80160.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80160] [7 regression] operand has impossible constraints

2017-03-23 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80160

--- Comment #4 from Bernd Schmidt  ---
Perhaps this.

Index: lra-assigns.c
===
--- lra-assigns.c   (revision 246226)
+++ lra-assigns.c   (working copy)
@@ -908,7 +908,8 @@ must_not_spill_p (unsigned spill_regno)
  does not solve the general case where existing reloads fully
  cover a limited register class.  */
   if (!bitmap_bit_p (_reload_pseudos, spill_regno)
-  && reg_class_size [reg_preferred_class (spill_regno)] == 1)
+  && reg_class_size [reg_preferred_class (spill_regno)] == 1
+  && reg_alternate_class (spill_regno) == NO_REGS)
 return true;
   return false;
 }

[Bug debug/80025] [5/6/7 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

2017-03-23 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80025

--- Comment #12 from Bernd Schmidt  ---
That still doesn't seem to address the root cause though? Isn't the problem
that this reversible mappings code can create cycles and we should avoid
creating these in the first place?

[Bug target/79185] [5/6/7 Regression] register allocation in the addition of two 128 bit ints

2017-03-17 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|bernds at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #9 from Bernd Schmidt  ---
Won't spend any more time on this in the near future, probably.

[Bug target/79185] [5/6/7 Regression] register allocation in the addition of two 128 bit ints

2017-03-17 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185

--- Comment #8 from Bernd Schmidt  ---
Created attachment 40997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40997=edit
Some steps towards solving it

There are some relatively obvious issues in ira-lives:
a) We briefly mark a register as live for a plain CLOBBER pattern
b) For a subword SET, DF gives us an extra use of the whole register, which
messes up our conflict graph as well if we handle it like any other use. It
seems safe to ignore it.

Unfortunately, this doesn't solve the issue - the conflicts are reduced, but it
seems that r88 isn't involved in copies from hard regs, and so when we pop it
first, we choose a random unused register. Maybe that's something Vlad could
figure out more quickly. What's worse, I've seen cases where the additional
freedom (fewer conflicts, more copies detected) leads to worse results.

Also, limiting lifetimes can have the effect of sometimes detecting that an
object does not really live at any point. I've tweaked things somewhat, but a
few testsuite failures still remain.

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

2017-03-15 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71294

--- Comment #14 from Bernd Schmidt  ---
I can't reproduce this, but that's probably because of
  cc1plus: warning: will not generate power8 instructions because assembler
lacks power8 support

Binutils was just configured for ppc64le-linux - do I need any special options
on the configure command line there?

[Bug rtl-optimization/80025] [5/6/7 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

2017-03-14 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80025

Bernd Schmidt  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||bernds at gcc dot gnu.org

--- Comment #7 from Bernd Schmidt  ---
CC'ing Alex. I've poked around this a bit and it seems to be in code he's
written and which I don't fully understand.

[Bug rtl-optimization/78911] [5/6 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

2017-03-10 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

Bernd Schmidt  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] Infinite |[5/6 Regression] Infinite
   |loop at -O2/O3 optimization |loop at -O2/O3 optimization
   |levels while trying to  |levels while trying to
   |compile server.c from   |compile server.c from
   |Wine-2.0-rc2|Wine-2.0-rc2

--- Comment #14 from Bernd Schmidt  ---
Fixed on trunk.

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

2017-03-10 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

--- Comment #13 from Bernd Schmidt  ---
Author: bernds
Date: Fri Mar 10 21:17:13 2017
New Revision: 246059

URL: https://gcc.gnu.org/viewcvs?rev=246059=gcc=rev
Log:
PR rtl-optimization/78911
* lra-assigns.c (must_not_spill_p): New function.
(spill_for): Use it.

PR rtl-optimization/78911
* gcc.target/i386/pr78911-1.c: New test.
* gcc.target/i386/pr78911-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr78911-1.c
trunk/gcc/testsuite/gcc.target/i386/pr78911-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79185] [5/6/7 Regression] register allocation in the addition of two 128 bit ints

2017-03-10 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #7 from Bernd Schmidt  ---
Will investigate at least a little. I have a feeling this should be working...

[Bug tree-optimization/78972] [5/6/7 Regression] poor x86 simd instruction scheduling

2017-03-10 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #10 from Bernd Schmidt  ---
I have a patch I'll submit for gcc-8.

[Bug rtl-optimization/79806] [5/6/7 Regression] ICE error: unable to find a register to spill (in assign_by_spills, at lra-assigns.c:1457)

2017-03-08 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79806

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt  ---
I'm tempted to classify this as unsupported. The testcase reserves edx, and the
alloca call includes a division operation which requires edx. Without
optimization, it remains until register allocation.

Global registers are somewhat fragile, and I think it's not worth it trying to
fix this. I'd put this at P4 at most.

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

2017-03-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916

--- Comment #4 from Bernd Schmidt  ---
I also have trouble reproducing this. Rather than the g++ commandline, please
post what is passed to cc1plus.

[Bug rtl-optimization/79910] [7 Regression] wrong code with -O -fweb

2017-03-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79910

--- Comment #4 from Bernd Schmidt  ---
(In reply to Zdenek Sojka from comment #0)
> Trying 27, 28 -> 33:
> ...
> Successfully matched this instruction:
> (set (reg:QI 128 [ _6 ])
> (plus:QI (subreg:QI (reg:DI 111 [ p1D.1798 ]) 0)
> (subreg:QI (reg/v:DI 100 [ bD.1802 ]) 0)))
> Successfully matched this instruction:
> (set (reg:QI 123 [ p1D.1798 ])
> (plus:QI (reg:QI 128 [ _6 ])
> (subreg:QI (reg:DI 92 [ _6 ]) 0)))
> allowing combination of insns 27, 28 and 33

It looks like this combination introduces a new use of reg 100 into insn 28 (it
was previously used in insn 33). Thus, it becomes the first use of reg 100, but
the other use in insn 32 still has the LOG_LINKS pointer, allowing the second
combination which makes the code incorrect.

This looks like a pretty serious hole in the combiner. Not sure yet how best to
fix it.

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

2017-03-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571

--- Comment #13 from Bernd Schmidt  ---
(In reply to Martin Liška from comment #11)
> I see a similar test-case on ppc64le-linux-gnu (w/ cross-compiler):
> 
> $ ppc64le-linux-gnu-g++
> /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return-6_x.
> C -mno-popcntd -Og

> 
> Should I create a separate issue, or is it the same as this one?

Most likely something else, please create a new one and Cc me and Vlad.

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

2017-03-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571

--- Comment #12 from Bernd Schmidt  ---
(In reply to Jakub Jelinek from comment #10)
> Wouldn't it penalize other code?  E.g. if you have a TImode MEM and store
> from something in XMM register, then it doesn't have to be offsetable and
> can use even zero_extend in the address.

Well, the testcase seems to come with -mno-sse, so maybe we check for that as
well and assume things can be reloaded into an SSE reg otherwise. Guess I'll
fire up a test.

[Bug rtl-optimization/79405] [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

2017-03-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|bernds at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #6 from Bernd Schmidt  ---
Unassigning myself.

[Bug rtl-optimization/79405] [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

2017-03-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405

--- Comment #5 from Bernd Schmidt  ---
Patch and discussion here:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01063.html

[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912

2017-03-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728

--- Comment #4 from Bernd Schmidt  ---
Actually here's mine from last week:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00176.html

[Bug rtl-optimization/79910] [7 Regression] wrong code with -O -fweb

2017-03-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79910

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #3 from Bernd Schmidt  ---
Investigating.

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

2017-03-03 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571

--- Comment #9 from Bernd Schmidt  ---
Maybe we just need to declare this address to be invalid for TImode. The
following seems to cure the testcase; untested otherwise.

Index: i386.c
===
--- i386.c  (revision 245685)
+++ i386.c  (working copy)
@@ -15877,7 +15877,7 @@ ix86_validate_address_register (rtx op)
be recognized.  */

 static bool
-ix86_legitimate_address_p (machine_mode, rtx addr, bool strict)
+ix86_legitimate_address_p (machine_mode mem_mode, rtx addr, bool strict)
 {
   struct ix86_address parts;
   rtx base, index, disp;
@@ -15899,7 +15899,8 @@ ix86_legitimate_address_p (machine_mode,
 {
   rtx reg = ix86_validate_address_register (base);

-  if (reg == NULL_RTX)
+  if (reg == NULL_RTX
+ || (GET_MODE (reg) != Pmode && mem_mode == TImode))
return false;

   if ((strict && ! REG_OK_FOR_BASE_STRICT_P (reg))

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

2017-03-03 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #8 from Bernd Schmidt  ---
I was also playing with this before I noticed Jakub was investigating. As an
experiment, I came up with the following, trying to recognize situations where
picking one alternative would cause an infinite cycle:

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 245685)
+++ lra-constraints.c   (working copy)
@@ -1899,6 +1899,7 @@ process_alt_operands (int only_alternati
   int reload_nregs, reload_sum;
   bool costly_p;
   enum reg_class cl;
+  bool must_not_reload_op1 = false;

   /* Calculate some data common for all alternatives to speed up the
  function. */
@@ -1932,6 +1933,15 @@ process_alt_operands (int only_alternati
  = regno_reg_rtx[hard_regno[nop]];
 }

+  /* See if we have an insn of the form
+   (set (pseudo) (something)
+ If yes, then we should not try to reload operand 1 into a pseudo,
+ because this would cause an infinite cycle.  */
+  if (curr_insn_set != NULL_RTX
+  && operand_reg[0] != NULL_RTX
+  && hard_regno[0] < 0)
+must_not_reload_op1 = true;
+
   /* The constraints are made of several alternatives. Each operand's
  constraint looks like foo,bar,... with commas separating the
  alternatives.  The first alternatives for all operands go
@@ -2193,7 +2203,10 @@ process_alt_operands (int only_alternati
  switch (get_constraint_type (cn))
{
case CT_REGISTER:
- cl = reg_class_for_constraint (cn);
+ if (nop == 1 && must_not_reload_op1)
+   cl = NO_REGS;
+ else
+   cl = reg_class_for_constraint (cn);
  if (cl != NO_REGS)
goto reg;
  break;

Sadly, it seems to be ineffective (or at least incomplete), it goes into a
different infinite cycle.

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

2017-03-01 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #11 from Bernd Schmidt  ---
Investigating (but not entirely sure yet I'm getting somewhere).

[Bug rtl-optimization/79780] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

2017-03-01 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79780

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #2 from Bernd Schmidt  ---
So the verification triggers before the dead blocks get removed?

I think I'd keep the seen_uncond_trap and just delete_insn inside the if
statement if it's already true.

[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912

2017-02-28 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #2 from Bernd Schmidt  ---
Taking a look.

[Bug rtl-optimization/79541] New: lra reads uninitialized memory (with invalid input)

2017-02-15 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79541

Bug ID: 79541
   Summary: lra reads uninitialized memory (with invalid input)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernds at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40753=edit
Reproducer

Disclaimer: I'm uncertain how severe this is: the test program contains an
invalid assembly statement that LRA converts into a nop. If that asm is
corrected, the problem no longer reproduces, and I don't know if the issue
could show up on a legitimate input. I noticed this because an unrelated patch
that should have had no effect on this program caused differences in assembly
output.

Compile the test program as follows, for ppc-linux (I use an x86_64-linux x
ppc-linux cross):

valgrind ./cc1 -O2 sl4.i   -I include 

The following should show up in the output:

==7398== Conditional jump or move depends on uninitialised value(s)
==7398==at 0xCB3791: lra_eliminate_regs_1(rtx_insn*, rtx_def*,
machine_mode, bool, bool, long, bool) (lra-eliminations.c:403)
==7398==by 0xCB4133: lra_eliminate_regs_1(rtx_insn*, rtx_def*,
machine_mode, bool, bool, long, bool) (lra-eliminations.c:642)
==7398==by 0xCC1D71: remove_pseudos(rtx_def**, rtx_insn*)
(lra-spills.c:421)
==7398==by 0xCC1E1F: remove_pseudos(rtx_def**, rtx_insn*)
(lra-spills.c:431)
==7398==by 0xCC2089: spill_pseudos() (lra-spills.c:475)
==7398==by 0xCC27A9: lra_spill() (lra-spills.c:604)
==7398==by 0xC93355: lra(_IO_FILE*) (lra.c:2486)
==7398==by 0xC38FC0: do_reload() (ira.c:5400)
==7398==by 0xC39476: (anonymous namespace)::pass_reload::execute(function*)
(ira.c:5584)
==7398==by 0xD83360: execute_one_pass(opt_pass*) (passes.c:2465)
==7398==by 0xD836C4: execute_pass_list_1(opt_pass*) (passes.c:2554)
==7398==by 0xD836F5: execute_pass_list_1(opt_pass*) (passes.c:2555)

The unitialized memory seems to be the sp_offset field of an insn created by
LRA. The .reload dump should contain a line as follows, with random numbers for
sp_off:

 Choosing alt 5 in insn 266:  (0) m  (1) r {*movsi_internal1}
(sp_off=139971034200304)

[Bug rtl-optimization/79405] [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

2017-02-14 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #4 from Bernd Schmidt  ---
Oscillating, replacing two registers with each other in a single location.
Probably related to one of them being uninitialized.

[Bug rtl-optimization/79386] [7 Regression] ICE: segmentation fault in cprop w/ -O2 on 32-bit BE powerpc

2017-02-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79386

--- Comment #3 from Bernd Schmidt  ---
Gah. If we clean up the CFG after bypass_conditional_jumps, it can crash if it
finds an unconditional trap in the middle of a block. If we do it beforehand,
we're referencing data by the wrong bb number.

Maybe we just skip bypass_conditional_jumps if we had to modify the CFG for
unconditional traps?

[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.

2017-02-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634

--- Comment #5 from Bernd Schmidt  ---
I don't know the machine, but with a branch cost of 1 this seems like it might
be expected. Do you think this is a testcase problem or something else?

[Bug target/67288] [5/6/7 regression] non optimal simple function (useless additional shift/remove/shift/add)

2017-01-30 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #5 from Bernd Schmidt  ---
(In reply to Christophe Leroy from comment #0)

> The following section is just useless: (shift left 4 bits, remove 16, shift
> right 4 bits, add 1)
> c000d984:   55 24 20 36 rlwinm  r4,r9,4,0,27
> c000d988:   39 24 ff f0 addir9,r4,-16
> c000d98c:   55 29 e1 3e rlwinm  r9,r9,28,4,31
> c000d990:   39 29 00 01 addir9,r9,1

Are you suggesting just removing these? That would not produce the same value
in all cases - consider zero as an input:

((0 << 4) - 16) >> 4 = 0xfff, add one and you get 0x1000.

[Bug tree-optimization/78972] [5/6/7 Regression] poor x86 simd instruction scheduling

2017-01-30 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-30
 CC||bernds at gcc dot gnu.org
  Component|target  |tree-optimization
 Ever confirmed|0   |1

--- Comment #9 from Bernd Schmidt  ---
Confirmed, and it does seem to be ter doing something stupid.

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

2017-01-25 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559

--- Comment #12 from Bernd Schmidt  ---
Sorry, long pause while editing that comment made me leave out part of what I
was trying to say - I meant only discard notes that reference the CC reg. But
it seems an unnecessary complication.

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

2017-01-25 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559

--- Comment #11 from Bernd Schmidt  ---
Looks like other_insn is only used for cases where we rewrite cc sets in this
way, so Bin's patch does look reasonably narrow. We could maybe record the CC
reg being changed and only discard reg notes, but in my testing I've not been
able to produce code generation differences except for the testcase. Let's wait
for Segher's testing, but I think the patch is OK.

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

2017-01-24 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #9 from Bernd Schmidt  ---
Ok, I'll look.

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

2017-01-23 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724

--- Comment #7 from Bernd Schmidt  ---
Author: bernds
Date: Mon Jan 23 16:30:55 2017
New Revision: 244817

URL: https://gcc.gnu.org/viewcvs?rev=244817=gcc=rev
Log:
PR rtl-optimization/71724
* combine.c (if_then_else_cond): Look for situations where it is
beneficial to undo the work of one of the recursive calls.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.

2017-01-23 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Bernd Schmidt  ---
Fixed.

[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.

2017-01-23 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634

--- Comment #2 from Bernd Schmidt  ---
Author: bernds
Date: Mon Jan 23 16:17:33 2017
New Revision: 244816

URL: https://gcc.gnu.org/viewcvs?rev=244816=gcc=rev
Log:
PR rtl-optimization/78634
* config/i386/i386.c (ix86_max_noce_ifcvt_seq_cost): New function.
(TARGET_MAX_NOCE_IFCVT_SEQ_COST): Define.
* ifcvt.c (noce_try_cmove): Add missing cost check.

testsuite/
PR rtl-optimization/78634
* gcc.target/i386/funcspec-11.c: Also pass -mtune=i686.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/funcspec-11.c

[Bug rtl-optimization/79194] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

2017-01-23 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79194

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #2 from Bernd Schmidt  ---
Oh well, guess I know how to fix those by now.


[Bug rtl-optimization/56069] [5/6/7 Regression] RA pessimization

2017-01-23 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069

--- Comment #16 from Bernd Schmidt  ---
I retested again with a few different combinations of things. With an older
gdb, I can still reproduce the issue that sra-1 becomes UNSUPPORTED (presumably
through a gdb crash). With gdb-7.12 installed the patch now causes sra-1.c to
fail (apparently a value becomes optimized out). If we consider the guality
testsuite in some way meaningful we still can't apply this patch.
Also, Vlad's reasoning for waiting until gcc-7 last time now holds for waiting
until gcc-8.

[Bug rtl-optimization/79125] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

2017-01-19 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79125

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #4 from Bernd Schmidt  ---
Actually just the same approach we used for the global pass ought to just work.
Watch for conditional traps turning into unconditional ones, put those in a
vec, split basic blocks later for every element in the vec.

[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.

2017-01-18 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634

--- Comment #1 from Bernd Schmidt  ---
Patch and discussion here.

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00212.html

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

2016-12-21 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724

--- Comment #4 from Bernd Schmidt  ---
Maybe we just need to test for that condition, even though it's ugly. However,
I think there are some other improvements we could make here.

Part of the problem seems to be what if_then_else_cond does on this rtx:

(plus:SI (if_then_else:SI (eq (reg:CC 185)
(const_int 0 [0]))
(reg:SI 165)
(reg:SI 174 [ t9.0_1+4 ]))
(reg:SI 165))

Reg 165 is known to be zero or one, so it gets turned into a condition, and we
have two different conditions on the operands. That causes us to fail to make
the fairly obvious transformation to 
 cond = reg:CC 185
 true_rtx = (plus r165 r165)
 false_rtx = (plus r174 r165)

I'm testing the following, which tries to undo such transformation of plain REG
if that seems it'll enable other transformations which are more likely to be
beneficial. It makes the crash go away.

Index: combine.c
===
--- combine.c   (revision 242958)
+++ combine.c   (working copy)
@@ -9031,11 +9031,31 @@ if_then_else_cond (rtx x, rtx *ptrue, rt
  the same value, compute the new true and false values.  */
   else if (BINARY_P (x))
 {
-  cond0 = if_then_else_cond (XEXP (x, 0), , );
-  cond1 = if_then_else_cond (XEXP (x, 1), , );
+  rtx op0 = XEXP (x, 0);
+  rtx op1 = XEXP (x, 1);
+  cond0 = if_then_else_cond (op0, , );
+  cond1 = if_then_else_cond (op1, , );
+
+  if ((cond0 != 0 && cond1 != 0 && !rtx_equal_p (cond0, cond1))
+ && (REG_P (op0) || REG_P (op1)))
+   {
+ /* Try to enable a simplification by undoing work done by
+if_then_else_cond if it converted a REG into something more
+complex.  */
+ if (REG_P (op0))
+   {
+ cond0 = 0;
+ true0 = false0 = op0;
+   }
+ else
+   {
+ cond1 = 0;
+ true1 = false1 = op1;
+   }
+   }

   if ((cond0 != 0 || cond1 != 0)
- && ! (cond0 != 0 && cond1 != 0 && ! rtx_equal_p (cond0, cond1)))
+ && ! (cond0 != 0 && cond1 != 0 && !rtx_equal_p (cond0, cond1)))
{
  /* If if_then_else_cond returned zero, then true/false are the
 same rtl.  We must copy one of them to prevent invalid rtl

[Bug target/77345] [7 Regression] Segmentation fault w/ -misel -O1 (and above)

2016-12-21 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77345

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #4 from Bernd Schmidt  ---
Seems very likely.

[Bug target/71321] [6/7 Regression] x86: worse code for uint8_t % 10 and / 10

2016-12-21 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71321

--- Comment #6 from Bernd Schmidt  ---
Author: bernds
Date: Wed Dec 21 16:45:33 2016
New Revision: 243861

URL: https://gcc.gnu.org/viewcvs?rev=243861=gcc=rev
Log:

PR target/71321
* config/i386/i386.md (lea_general_2b, lea_general_3b): New
patterns.
* config/i386/predicates.md (const123_operand): New.

PR target/71321
* gcc.target/i386/pr71321.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr71321.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

2016-12-20 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #3 from Bernd Schmidt  ---
Looks like if_then_else_cond manages to return a false_rtx identical to the
original one, and we try to simplify it again.

[Bug c/32643] [5/6/7 Regression] Wrong error message with unsigned char a = uchar&512

2016-12-19 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #22 from Bernd Schmidt  ---
Ok, so I have a patch that makes the original testcase pass, by allowing
folding in get_unwidened depening on a new arg. That was:

unsigned char p;
unsigned char p1 = p & 512;

But, how about

char p2 = p & 512;

Are we supposed to still warn about this (we do, with the patch I have)?
Probably not, right?

[Bug target/71321] [6/7 Regression] x86: worse code for uint8_t % 10 and / 10

2016-12-15 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71321

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #4 from Bernd Schmidt  ---
I have some ideas. Investigating...

[Bug rtl-optimization/78727] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

2016-12-14 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78727

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #5 from Bernd Schmidt  ---
Patch posted.

[Bug tree-optimization/77309] [5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

2016-12-12 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309

Bernd Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Bernd Schmidt  ---
Fixed.

[Bug rtl-optimization/78669] [7 Regression]: ICE: in combine_and_move_insns, at ira.c:3665 with -Os -fno-tree-ter -mavx512bw

2016-12-12 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78669

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Bernd Schmidt  ---
Fixed.

[Bug rtl-optimization/78669] [7 Regression]: ICE: in combine_and_move_insns, at ira.c:3665 with -Os -fno-tree-ter -mavx512bw

2016-12-12 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78669

--- Comment #5 from Bernd Schmidt  ---
Author: bernds
Date: Mon Dec 12 13:29:48 2016
New Revision: 243551

URL: https://gcc.gnu.org/viewcvs?rev=243551=gcc=rev
Log:

PR rtl-optimization/78669
* ira.c (combine_and_move_insns): When deleting an insn, clear the
replace flag for all used regs in that insn.

PR rtl-optimization/78669
* gcc.target/i386/pr78669.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78669.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77309] [5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

2016-12-12 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309

--- Comment #6 from Bernd Schmidt  ---
Author: bernds
Date: Mon Dec 12 13:01:28 2016
New Revision: 243550

URL: https://gcc.gnu.org/viewcvs?rev=243550=gcc=rev
Log:
Backport from mainline
2016-11-07  Bernd Schmidt  

PR rtl-optimization/77309
* combine.c (make_compound_operation): Allow EQ for IN_CODE, and
don't assume an equality comparison for plain COMPARE.
(simplify_comparison): Pass a more accurate code to
make_compound_operation.

PR rtl-optimization/77309
* gcc.dg/torture/pr77309.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr77309.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/combine.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/77309] [5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

2016-12-12 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309

--- Comment #5 from Bernd Schmidt  ---
Author: bernds
Date: Mon Dec 12 13:00:53 2016
New Revision: 243549

URL: https://gcc.gnu.org/viewcvs?rev=243549=gcc=rev
Log:
Backport from mainline
2016-11-07  Bernd Schmidt  

PR rtl-optimization/77309
* combine.c (make_compound_operation): Allow EQ for IN_CODE, and
don't assume an equality comparison for plain COMPARE.
(simplify_comparison): Pass a more accurate code to
make_compound_operation.

PR rtl-optimization/77309
* gcc.dg/torture/pr77309.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77309.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/combine.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

2016-12-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626

--- Comment #9 from Bernd Schmidt  ---
I can't read that assembly language, but I'll take your word for it. I'm
testing the patch on x86.

[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

2016-12-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626

--- Comment #4 from Bernd Schmidt  ---
Created attachment 40269
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40269=edit
Candidate patch

[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

2016-12-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626

--- Comment #3 from Bernd Schmidt  ---
Not sure it's that bad really. An unconditional trap is pretty much by
definition not performance-critical. Then again, there's a possible alternate
fix, which I'll attach.

[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

2016-12-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt  ---
This appears to happen in cprop. Would anyone like to test this on ppc?

Index: cprop.c
===
--- cprop.c (revision 242958)
+++ cprop.c (working copy)
@@ -1047,6 +1047,10 @@
   int changed = 0, changed_this_round;
   rtx note;

+  /* We can't convert these to unconditional traps because it would invalidate
the CFG.  */
+  if (GET_CODE (PATTERN (insn)) == TRAP_IF)
+return 0;
+
   do
 {
   changed_this_round = 0;

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

2016-12-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #27 from Bernd Schmidt  ---
Thread with discussion is here. The patch got stalled because we don't
understand the bootstrap failure.

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00421.html

[Bug bootstrap/78338] [7 Regression] bootstrap broken on mips-linux-gnu

2016-12-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78338

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Bernd Schmidt  ---
Closing then.

[Bug bootstrap/78338] [7 Regression] bootstrap broken on mips-linux-gnu

2016-12-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78338

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #2 from Bernd Schmidt  ---
Matthias, can you confirm it's fixed?

[Bug rtl-optimization/78669] [7 Regression]: ICE: in combine_and_move_insns, at ira.c:3665 with -Os -fno-tree-ter -mavx512bw

2016-12-05 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78669

--- Comment #4 from Bernd Schmidt  ---
Something like this perhaps.

Index: ira.c
===
--- ira.c   (revision 242958)
+++ ira.c   (working copy)
@@ -3705,6 +3705,14 @@ combine_and_move_insns (void)
  remove_death (regno, use_insn);
  SET_REG_N_REFS (regno, 0);
  REG_FREQ (regno) = 0;
+ df_ref use;
+ FOR_EACH_INSN_USE (use, def_insn)
+   {
+ unsigned int use_regno = DF_REF_REGNO (use);
+ if (!HARD_REGISTER_NUM_P (use_regno))
+   reg_equiv[use_regno].replace = 0;
+   }
+
  delete_insn (def_insn);

  reg_equiv[regno].init_insns = NULL;

[Bug middle-end/71443] [7 regression] test case gcc.dg/plugin/must-tail-call-2.c reports error

2016-11-30 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71443

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bernds at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Bernd Schmidt  ---
Tried this with an aarch64-linux cross, and it seems to work now:

PASS: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 17)
PASS: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 32)
PASS: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 39)
PASS: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 48)
PASS: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 57)
PASS: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so
(test for excess errors)

The other PR also mentions that it started to work again.

[Bug target/71293] [7 regression] test case gcc.dg/plugin/must-tail-call-2.c fails starting with r236514

2016-11-30 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71293

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bernds at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Bernd Schmidt  ---
PR71443 was a similar issue for aarch64 which also seems to have gotten solved.
Closing.

[Bug target/27855] [5/6/7 regression] reassociation causes the RA to be confused

2016-11-30 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #52 from Bernd Schmidt  ---
Still seems to be an issue, although I do not see code generation like in
comment #6.

-O2 -ffast-math -msse4.1 -DTYPE=double  -fno-tree-reassoc

atlasmm   60   1000   0.077 5634.83

-O2 -ffast-math -msse4.1 -DTYPE=double

atlasmm   60   1000   0.097 4469.00

[Bug target/71436] [7 Regression] Segmentation fault in arm_output_multireg_pop

2016-11-30 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436

--- Comment #14 from Bernd Schmidt  ---
Maybe the match_parallel predicate ought to also check that you have more than
4 loads, so that it doesn't match anything that could also be handled by
ldmstm.md.

[Bug target/70905] [7 regression] FAIL: gcc.c-torture/compile/20011219-2.c -Os (unrecognizable insn)

2016-11-29 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70905

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bernds at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Bernd Schmidt  ---
No longer seems to happen with a powerpc-linux cross and -frename-registers.

[Bug target/71436] [7 Regression] Segmentation fault in arm_output_multireg_pop

2016-11-29 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436

--- Comment #7 from Bernd Schmidt  ---
Ooh, ouch. Maybe load_multiple needs a "&& reload_completed" predicate?

[Bug testsuite/70826] [7 regression] many test cases fail starting with r235442

2016-11-29 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826

Bernd Schmidt  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #12 from Bernd Schmidt  ---
*** Bug 70907 has been marked as a duplicate of this bug. ***

[Bug target/70907] [7 regression] FAIL: gcc.target/powerpc/savres.c -Os execution test

2016-11-29 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70907

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bernds at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Bernd Schmidt  ---
Seems already fixed.

*** This bug has been marked as a duplicate of bug 70826 ***

[Bug target/71436] [7 Regression] Segmentation fault in arm_output_multireg_pop

2016-11-29 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
  Component|rtl-optimization|target

--- Comment #5 from Bernd Schmidt  ---
That just means reload will never get to see it - it can't look into a
match_parallel predicate to decide what to do about it.

I seem to recall these patterns weren't generated before reload in the past.
Has something changed there? Or maybe the load_multiple pattern is new, unlike
the ones in ldmstm.md?

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-28 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

Bernd Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Bernd Schmidt  ---
Still fixed.

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-28 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

--- Comment #13 from Bernd Schmidt  ---
Author: bernds
Date: Mon Nov 28 08:59:01 2016
New Revision: 242908

URL: https://gcc.gnu.org/viewcvs?rev=242908=gcc=rev
Log:
PR rtl-optimization/78120
* rtlanal.c (insn_rtx_cost): Revert previous change.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-24 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

--- Comment #12 from Bernd Schmidt  ---
Author: bernds
Date: Thu Nov 24 12:22:16 2016
New Revision: 242834

URL: https://gcc.gnu.org/viewcvs?rev=242834=gcc=rev
Log:
PR rtl-optimization/78120
* ifcvt.c (noce_conversion_profitable_p): Check original cost in all
cases, and additionally test against max_seq_cost for speed
optimization.
(noce_process_if_block): Compute an estimate for the original cost when
optimizing for speed, using the minimum of then and else block costs.

testsuite/
PR rtl-optimization/78120
* gcc.target/i386/pr78120.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78120.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-24 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

--- Comment #11 from Bernd Schmidt  ---
Author: bernds
Date: Thu Nov 24 12:17:52 2016
New Revision: 242833

URL: https://gcc.gnu.org/viewcvs?rev=242833=gcc=rev
Log:
PR rtl-optimization/78120
* rtlanal.c (insn_rtx_cost): Use set_rtx_cost.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-24 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

--- Comment #10 from Bernd Schmidt  ---
Author: bernds
Date: Thu Nov 24 12:16:47 2016
New Revision: 242832

URL: https://gcc.gnu.org/viewcvs?rev=242832=gcc=rev
Log:
PR rtl-optimization/78120
* config/i386/i386.c (ix86_rtx_costs): Fully handle SETs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-11 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

--- Comment #7 from Bernd Schmidt  ---
Sorry James, I think these two got mixed up in my memory.

I've attached a candidate patch I'm testing. This tries to make a better effort
to calculate before/after costs for the speed case so we don't rely entirely on
max_seq_cost. I'd be interested in whether it produces good results on ARM (or
even on x86) if someone is set up to run benchmarks.

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-11 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

--- Comment #6 from Bernd Schmidt  ---
Created attachment 40028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40028=edit
Candidate patch

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-11 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

--- Comment #4 from Bernd Schmidt  ---
The other issue here seems to be simply that BRANCH_COST is 0 for predictable
branches on x86. Which makes the default implementation of the hook used here

  if_info.max_seq_cost
= targetm.max_noce_ifcvt_seq_cost (then_edge);

come out as zero, and we fail the conversion because of this.

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-11 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

--- Comment #3 from Bernd Schmidt  ---
Gah, that's obviously bogus and fails elsewhere. Still looking...

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

2016-11-11 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||bernds at gcc dot gnu.org,
   ||jgreenhalgh at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #2 from Bernd Schmidt  ---
Looks like a mismatch where we use different cost calculations to compare
before/after sequences. The following seems to make it come out right, but it
probably needs a lot of testing to make sure it behaves as intended. (James?)

Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c   (revision 242038)
+++ gcc/rtlanal.c   (working copy)
@@ -5224,13 +5224,8 @@ seq_cost (const rtx_insn *seq, bool spee
   rtx set;

   for (; seq; seq = NEXT_INSN (seq))
-{
-  set = single_set (seq);
-  if (set)
-cost += set_rtx_cost (set, speed);
-  else
-cost++;
-}
+if (NONDEBUG_INSN_P (seq))
+  cost += insn_rtx_cost (set, speed);

   return cost;
 }

[Bug tree-optimization/77309] [5/6/7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

2016-11-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309

--- Comment #3 from Bernd Schmidt  ---
Author: bernds
Date: Mon Nov  7 16:59:11 2016
New Revision: 241912

URL: https://gcc.gnu.org/viewcvs?rev=241912=gcc=rev
Log:
PR rtl-optimization/77309
* combine.c (make_compound_operation): Allow EQ for IN_CODE, and
don't assume an equality comparison for plain COMPARE.
(simplify_comparison): Pass a more accurate code to
make_compound_operation.

testsuite/
PR rtl-optimization/77309
* gcc.dg/torture/pr77309.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77309.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77309] [5/6/7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

2016-10-25 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #2 from Bernd Schmidt  ---
Investigating.

[Bug c++/69733] -Wignored-qualifiers points to wrong const

2016-10-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69733

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Bernd Schmidt  ---
Fixed.

[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3

2016-10-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Bernd Schmidt  ---
Fixed.

[Bug c++/69733] -Wignored-qualifiers points to wrong const

2016-10-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69733

--- Comment #2 from Bernd Schmidt  ---
Author: bernds
Date: Fri Oct  7 12:21:55 2016
New Revision: 240863

URL: https://gcc.gnu.org/viewcvs?rev=240863=gcc=rev
Log:
c/
PR c++/69733
* c-decl.c (smallest_type_quals_location): New static function.
(grokdeclarator): Try to find the correct location for an ignored
qualifier.
cp/
PR c++/69733
* decl.c (grokdeclarator): Try to find the correct location for an
ignored qualifier.
testsuite/
PR c++/69733
* c-c++-common/pr69733.c: New test.
* gcc.dg/pr69733.c: New test.
* gcc.target/i386/pr69733.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/pr69733.c
trunk/gcc/testsuite/gcc.dg/pr69733.c
trunk/gcc/testsuite/gcc.target/i386/pr69733.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3

2016-10-07 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880

--- Comment #4 from Bernd Schmidt  ---
Author: bernds
Date: Fri Oct  7 12:16:55 2016
New Revision: 240862

URL: https://gcc.gnu.org/viewcvs?rev=240862=gcc=rev
Log:
PR tree-optimization/77880
* expr.c (by_pieces_ninsns): Use unsigned HOST_WIDE_INT where
necessary.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c

[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3

2016-10-06 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880

--- Comment #2 from Bernd Schmidt  ---
Hmm, a memcmp with ULONG_MAX as the size. Try this?

Index: expr.c
===
--- expr.c  (revision 240429)
+++ expr.c  (working copy)
@@ -785,7 +785,7 @@ by_pieces_ninsns (unsigned HOST_WIDE_INT
case COMPARE_BY_PIECES:
  int batch = targetm.compare_by_pieces_branch_ratio (mode);
  int batch_ops = 4 * batch - 1;
- int full = n_pieces / batch;
+ unsigned HOST_WIDE_INT full = n_pieces / batch;
  n_insns += full * batch_ops;
  if (n_pieces % batch != 0)
n_insns++;

[Bug middle-end/77718] [7 Regression] expand_builtin_memcmp swaps args

2016-09-27 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77718

--- Comment #4 from Bernd Schmidt  ---
So something like this maybe?

Index: builtins.c
===
--- builtins.c  (revision 240511)
+++ builtins.c  (working copy)
@@ -3707,11 +3707,13 @@ expand_builtin_memcmp (tree exp, rtx tar

   by_pieces_constfn constfn = NULL;

-  const char *src_str = c_getstr (arg1);
-  if (src_str == NULL)
-src_str = c_getstr (arg2);
-  else
-std::swap (arg1_rtx, arg2_rtx);
+  const char *src_str = c_getstr (arg2);
+  if (result_eq && src_str == NULL)
+{
+  src_str = c_getstr (arg1);
+  if (src_str != NULL)
+   std::swap (arg1_rtx, arg2_rtx);
+}

   /* If SRC is a string constant and block move would be done
  by pieces, we can avoid loading the string from memory

[Bug middle-end/77718] [7 Regression] expand_builtin_memcmp swaps args

2016-09-26 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77718

--- Comment #2 from Bernd Schmidt  ---
Over here the testcase seems not to arrive in this function, and it prints the
same value (-5) twice, which I think is supposed to be expected?

Please clarify.

[Bug c++/72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-loo

2016-09-21 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72774

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #2 from Bernd Schmidt  ---
I had multidelta reduce a testcase to something that produces the same error -
most likely the same bug.

namespace __gnu_cxx __attribute__ ((__visibility__ ("default")))
{
  template < typename _Tp > struct __add_unsigned
  {
  };
  class locale;

template < typename _CharT, typename _InIter > class num_get:public
locale::facet
  {
typedef _InIter iter_type;
template < typename _ValueT >
  __attribute ((__abi_tag__ ("cxx11"))) iter_type
  _M_extract_int (iter_type, iter_type, int &, ios_base::iostate &,
  _ValueT &) const;
  }
  template < typename _CharT,
typename _InIter > template < typename _ValueT >
__attribute ((__abi_tag__ ("cxx11"))) _InIter num_get < _CharT,
_InIter >::_M_extract_int (_InIter __beg, _InIter __end, ios_base & __io,
   ios_base::iostate & __err,
   _ValueT & __v) const const
  {
using __gnu_cxx::__add_unsigned;
typedef __numpunct_cache < _CharT > __cache_type;

  1   2   3   4   5   >