[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

[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&action=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/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases

[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&root=gcc&view=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 te

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

[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/92767] [m68k]: Random ICE: verify_flow_info failed

[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 bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686



--- Comment #39 from Bernd Schmidt  2013-04-11 
11:35:33 UTC ---

Created attachment 29857

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29857

Candidate fix



Ok, the --enable-checking made it reproducible. The lesson here is that a good

bug report includes information on how the build was configured.



Try this patch.

[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003



Bernd Schmidt  changed:



   What|Removed |Added



 CC||bernds at gcc dot gnu.org



--- Comment #13 from Bernd Schmidt  2013-04-24 
09:25:47 UTC ---

We need at least preprocessed source of the failing code, produced with gcc -E.

[Bug rtl-optimization/57003] [4.8/4.9 Regression] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003



--- Comment #20 from Bernd Schmidt  2013-04-25 
10:12:12 UTC ---

Patch is OK, thanks Jakub - you were too fast for me on this one.

[Bug middle-end/53411] [4.8 Regression] ICE in move_unallocated_pseudos

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411

--- Comment #6 from Bernd Schmidt  2012-08-13 
11:07:27 UTC ---
If the call to delete_trivially_dead_insns is supposed to eliminate only
pre-existing dead insns, then just moving it to the beginning of IRA fixes this
bug.

[Bug rtl-optimization/54645] [4.8 Regression] Many testsuite failures

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645



--- Comment #1 from Bernd Schmidt  2012-09-20 
19:19:05 UTC ---

gcc.dg/pch and g++.dg/pch just completed here without problems. I don't see how

a scheduler patch could cause primarily PCH failures. Can you check your

bisection, and can you run tests with stage1 to see if you have a later

miscompilation of the compiler?



It would help to include sample excess error messages in a bug report if there

are failures of that type.

[Bug bootstrap/54643] Build hangs compiling unwind-arm.c

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54643



--- Comment #2 from Bernd Schmidt  2012-09-20 
22:01:57 UTC ---

Author: bernds

Date: Thu Sep 20 22:01:47 2012

New Revision: 191595



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191595

Log:

PR bootstrap/54643

* haifa-sched.c (schedule_block): Skip find_modifiable_mems if using

SCHED_PRESSURE_MODEL.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/haifa-sched.c

[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688



--- Comment #5 from Bernd Schmidt  2012-09-26 
13:18:41 UTC ---

(In reply to comment #3)

> It's r191493, the transformation is applied to a %sp-based load, which is

> invalid since the frame is destroyed, and the resulting offset is bogus:

> 

> In .split4:

> 

> (insn 52 41 43 4 (set (reg:SI 1 %g1 [orig:137 D.6097+8 ] [137])

> (mem/c:SI (plus:SI (reg/f:SI 14 %sp)

> (const_int 80 [0x50])) [23 D.6097+8 S4 A64]))

> /home/eric/svn/gcc/gcc/ada/restrict.adb:1067 61 {*movsi_insn}

>  (expr_list:REG_EQUIV (mem/c:SI (plus:SI (reg/f:SI 14 %sp)

> (const_int 80 [0x50])) [23 D.6097+8 S4 A64])

> (nil)))

> 

> [...]

> (note 60 43 61 4 NOTE_INSN_EPILOGUE_BEG)

> 

> (insn 61 60 62 4 (set (reg/f:SI 14 %sp)

> (minus:SI (reg/f:SI 14 %sp)

> (const_int -88 [0xffa8])))

> /home/eric/svn/gcc/gcc/ada/restrict.adb:1068 183 {subsi3}

> 

> In .sched2:

> 

> (insn 61 64 52 4 (set (reg/f:SI 14 %sp)

> (minus:SI (reg/f:SI 14 %sp)

> (const_int -88 [0xffa8])))

> /home/eric/svn/gcc/gcc/ada/restrict.adb:1068 183 {subsi3}

>  (nil))

> 

> (insn 52 61 43 4 (set (reg:SI 1 %g1 [orig:137 D.6097+8 ] [137])

> (mem/c:SI (plus:SI (reg/f:SI 14 %sp)

> (const_int 168 [0xa8])) [23 D.6097+8 S4 A64]))

> /home/eric/svn/gcc/gcc/ada/restrict.adb:1067 61 {*movsi_insn}

>  (expr_list:REG_EQUIV (mem/c:SI (plus:SI (reg/f:SI 14 %sp)

> (const_int 80 [0x50])) [23 D.6097+8 S4 A64])

> (nil)))



I admit I don't quite see yet why this would be invalid (assuming that the

stack grows from high address to low ones). What do you mean by "the frame is

destroyed", is there something special about sparc?

[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688



--- Comment #7 from Bernd Schmidt  2012-09-26 
13:50:06 UTC ---

Oh, I missed that it was a MINUS rtx. This is noncanonical RTL, it should be

(plus (sp) (negated constant)).



Does the bug persist if you fix the sparc port in this way?

[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688



--- Comment #9 from Bernd Schmidt  2012-09-26 
14:13:31 UTC ---

Created attachment 28283

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28283

Candidate patch.



The offset range should not be an issue with the right constraints etc.; the

port really ought to be changed.



In the meantime, please try this patch.

[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688



--- Comment #11 from Bernd Schmidt  2012-09-27 
13:28:12 UTC ---

Hmm, strange. What if you just make a change like this:



@@ -4600,8 +4600,7 @@ parse_add_or_inc (struct mem_inc_info *m

   if (!REG_P (SET_DEST (pat)))

 return false;



-  if (GET_CODE (SET_SRC (pat)) != PLUS

-  && GET_CODE (SET_SRC (pat)) != MINUS)

+  if (GET_CODE (SET_SRC (pat)) != PLUS)

 return false;



   mii->inc_insn = insn;

[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction "No_Elaboration_Code" on a-ioexce.ads

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688



--- Comment #14 from Bernd Schmidt  2012-09-28 
20:33:00 UTC ---

Author: bernds

Date: Fri Sep 28 20:32:55 2012

New Revision: 191838



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191838

Log:

PR bootstrap/54688

* sched-deps.c (parse_add_or_inc): Remove MINUS handling.  Take

STACK_GROWS_DOWNWARD into account.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/sched-deps.c

[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850



--- Comment #2 from Bernd Schmidt  2012-10-08 
14:18:58 UTC ---

Could you attach both dumps? (and use -fsched-verbose=5)

Did your test include r191838?

[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850



--- Comment #9 from Bernd Schmidt  2012-10-18 
11:54:34 UTC ---

Created attachment 28482

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28482

Candidate patch.



Could you both please test this patch?

[Bug target/54747] config/bfin/bfin.c:2721: possible missing break ?

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54747



Bernd Schmidt  changed:



   What|Removed |Added



 CC||bernds at gcc dot gnu.org



--- Comment #2 from Bernd Schmidt  2012-11-05 
11:29:37 UTC ---

Looks like the code works correctly either way. You could add a break if you

feel like it.

[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850



--- Comment #13 from Bernd Schmidt  2012-11-08 
17:10:34 UTC ---

Author: bernds

Date: Thu Nov  8 17:10:26 2012

New Revision: 193332



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193332

Log:

PR rtl-optimization/54850

* sched-deps.c (find_inc): Add all dependencies from the inc_insn

to the mem_insn.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/sched-deps.c

[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt  2011-01-04 
12:03:09 UTC ---
Please post a preprocessed source file and the exact compiler options that must
be passed to cc1 to produce incorrect assembly. If possible, also include the
two dump files from before/after things go wrong.

[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166

--- Comment #8 from Bernd Schmidt  2011-01-11 
15:45:34 UTC ---
I think the real problem here is that when reloading autoincs, we somehow end
up with 

(gdb) p spill_reg_store[3]
$42 = (rtx) 0xf7a1118c
(gdb) pr
(insn 3163 3161 3164 99 rectmm.c:1041 (set (reg:SI 1 r1)
(plus:SI (reg:SI 1 r1)
(const_int 280 [0x118]))) 4 {*arm_addsi3} (nil))

which doesn't set R3 at all - insn 3164 does.

[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166

--- Comment #9 from Bernd Schmidt  2011-01-11 
17:02:40 UTC ---
Created attachment 22945
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22945
Test patch

Could you try the following? It's a variant of a patch Richard Sandiford
recently posted.

[Bug rtl-optimization/47166] [4.5.2/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166

--- Comment #14 from Bernd Schmidt  2011-01-19 
19:31:20 UTC ---
(In reply to comment #13)
> Please consider reverting the reload change on the branch.  I don't think we
> want to keep fiddling with reload there.

I don't see how this makes any sense. We've identified two bugs in reload, both
leading to incorrect code, and you'd rather revert the fix for one than fix
both?

[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166

--- Comment #20 from Bernd Schmidt  2011-01-23 
21:11:27 UTC ---
Author: bernds
Date: Sun Jan 23 21:11:24 2011
New Revision: 169144

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169144
Log:
PR rtl-optimization/47166
* reload1.c (emit_reload_insns): Disable the spill_reg_store
mechanism for PRE_MODIFY and POST_MODIFY.
(inc_for_reload): For PRE_MODIFY, return the insn that sets the
reloadreg.

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

[Bug rtl-optimization/42835] Missed merging common code sequence at the end of two basic blocks

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42835

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #6 from Bernd Schmidt  2011-02-01 
01:10:36 UTC ---
Fixed.

[Bug rtl-optimization/47166] [4.5 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166

--- Comment #26 from Bernd Schmidt  2011-02-01 
01:34:59 UTC ---
I'll be testing the backport and committing the patch.

[Bug rtl-optimization/47166] [4.5 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166

--- Comment #28 from Bernd Schmidt  2011-02-11 
16:01:24 UTC ---
Author: bernds
Date: Fri Feb 11 16:01:19 2011
New Revision: 170053

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170053
Log:
PR rtl-optimization/47166
* reload1.c (emit_reload_insns): Disable the spill_reg_store
mechanism for PRE_MODIFY and POST_MODIFY.
(inc_for_reload): For PRE_MODIFY, return the insn that sets the
reloadreg.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/reload1.c

[Bug rtl-optimization/47166] [4.5 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #29 from Bernd Schmidt  2011-02-11 
16:02:23 UTC ---
I've had some problems with timeouts in my test setup, but I now have runs that
differ only in that pthread1.cc times out for one multilib and no longer times
out for another. I took that as good enough to commit the patch.

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893

--- Comment #6 from Bernd Schmidt  2011-02-25 
16:10:55 UTC ---
(In reply to comment #5)
> Similarly not queuing anything into frame_space lists
> when assign_stack_local is called from within assign_stack_temp_for_type would
> kill most of the savings Bernds' original patch had.

I think that's worth trying though. I can't think of any other good solution at
the moment short of reverting the whole thing.

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893

--- Comment #8 from Bernd Schmidt  2011-02-25 
17:24:15 UTC ---
(In reply to comment #7)
> My temptation would be to revert until someone can get in there and design
> things so that we either have a single list or there's clear rules for
> manipulating objects in each list and reflecting the necessary information 
> back
> and forth.
> 
> Even with Jakub's suggestions my worry is other similar, subtle bugs are in
> there and will bite us later.

We're not actually calling assign_stack_temp after the assign phase, are we?
IMO we can set a flag once we expect to only call assign_stack_local, and start
using the frame_space list after that point. There'll be no worries about
inconsistent lists.

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893

--- Comment #9 from Bernd Schmidt  2011-02-25 
17:25:13 UTC ---
Created attachment 23468
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23468
Test patch

Does this fix it?

[Bug c/50198] New: New test gcc.c-torture/execute/scal-to-vec1.c fails on many targets

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50198

 Bug #: 50198
   Summary: New test gcc.c-torture/execute/scal-to-vec1.c fails on
many targets
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ber...@gcc.gnu.org


FAIL: gcc.c-torture/execute/scal-to-vec1.c execution, -O0 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O1 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O2 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O3 -fomit-frame-pointer
-funroll-loops 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -Os 

I've seen this with mips64-elf, arm-eabi, and c6x-elf toolchains.

[Bug debug/50215] [4.7 Regression] FAIL: gcc.dg/guality/pr45882.c

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50215

--- Comment #2 from Bernd Schmidt  2011-08-28 
11:44:05 UTC ---
How was this caused by my patch then? I can't even reproduce this here.

[Bug middle-end/50232] [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232

--- Comment #2 from Bernd Schmidt  2011-08-30 
11:31:34 UTC ---
Ugh, code prettyfication gone wrong. Will fix.

However, you'll probably also want to add "return" patterns to PA for
optimization.

[Bug middle-end/50232] [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232

--- Comment #4 from Bernd Schmidt  2011-08-30 
15:06:05 UTC ---
Surely the PA has some kind of return instruction?
Most ports define a "return" pattern with an insn condition that requires that
the epilogue is empty. In that case, jumps to the end of the function will be
replaced by return instructions. Also, the "return" pattern can in this case
emit either a "return" or a "simple_return" rtx; they are equivalent if there
is no epilogue.

You can define a "simple_return" pattern, but it will only gain anything once
the final shrink-wrapping bits are in.

[Bug rtl-optimization/49972] Invalid .gcc_except_table with -freorder-blocks-and-partition

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972

--- Comment #8 from Bernd Schmidt  2011-09-02 
14:49:51 UTC ---
I'm guessing it was this:

http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02175.html

[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50099

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-09-06
 AssignedTo|unassigned at gcc dot   |bernds at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #8 from Bernd Schmidt  2011-09-06 
13:11:24 UTC ---
Created attachment 25202
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25202
Candidate patch

[Bug rtl-optimization/50326] [4.7 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50326

--- Comment #2 from Bernd Schmidt  2011-09-09 
11:22:00 UTC ---
Hmm, are you sure you bisected that correctly? I did a build on gcc60 with the
patch reverted, and it failed with the same error.

[Bug target/50350] [4.6 Regression] ICE (segfault) in canonicalize_float_value

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50350

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt  2011-09-21 
12:44:09 UTC ---
Almost certainly a dup of 50326.

[Bug rtl-optimization/50249] ira marks wrong value for inheriting

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50249

--- Comment #7 from Bernd Schmidt  2011-09-27 
14:55:16 UTC ---
Author: bernds
Date: Tue Sep 27 14:55:11 2011
New Revision: 179272

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179272
Log:
PR rtl-optimization/50249
* reload1.c (reload_reg_reaches_end_p): Accept a reloadnum argument
instead of opnum and type.  All callers changed.  Remove useless
declaration.
Search forward for other reloads of the same type for the same operand
using the same register; if any are found, return false.
(reload_regs_reach_end_p): Same argument changes; all callers changed.

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

[Bug bootstrap/50621] [4.7 Regression] Bootstrap failure

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621

--- Comment #7 from Bernd Schmidt  2011-10-05 
17:17:17 UTC ---
Author: bernds
Date: Wed Oct  5 17:17:12 2011
New Revision: 179560

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179560
Log:
PR bootstrap/50621
* config/i386/i386.c (ix86_add_cfa_restore_note): Omit notes only
if the function was not shrink-wrapped.
(ix86_expand_epilogue): Ensure queued cfa_adjust notes are attached
to an insn.
* function.c (thread_prologue_and_epilogue_insns): Make sure the
shrink_wrapped flag is set even if there is no dump file.

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

[Bug bootstrap/50621] [4.7 Regression] Bootstrap failure

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Bernd Schmidt  2011-10-05 
17:20:08 UTC ---
Fixed.

[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049

--- Comment #8 from Bernd Schmidt  2011-10-06 
13:13:00 UTC ---
Author: bernds
Date: Thu Oct  6 13:12:50 2011
New Revision: 179607

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179607
Log:
PR target/49049
* config/arm/arm.md (arm_subsi3_insn): Lose the last alternative.

* gcc.c-torture/compile/pr49049.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr49049.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588

--- Comment #14 from Bernd Schmidt  2011-10-06 
13:30:31 UTC ---
It looks like ifcvt (or rather, can_move_insns_across_p) is doing the right
thing. The problem is that may_trap_or_fault_p returns false for the memory
reference with an out-of-range address based on the frame pointer.

I'll keep thinking about it; no good idea yet about how to fix it without
losing too many optimization opportunities.

[Bug middle-end/50633] [4.7 Regression] New test failures

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633

--- Comment #6 from Bernd Schmidt  2011-10-06 
18:43:21 UTC ---
How do you build this? What's the target triplet?

[Bug middle-end/50633] [4.7 Regression] New test failures

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633

--- Comment #9 from Bernd Schmidt  2011-10-06 
19:59:18 UTC ---
Created attachment 25434
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25434
Test patch

Can you give this a try? Seems to fix the testcase.

[Bug middle-end/50633] [4.7 Regression] New test failures

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633

--- Comment #11 from Bernd Schmidt  2011-10-07 
12:10:11 UTC ---
I see none of these failures in the x86_64 test run with my last patch applied.
Can you confirm that it's fixed?

[Bug middle-end/50633] [4.7 Regression] New test failures

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633

--- Comment #12 from Bernd Schmidt  2011-10-07 
12:20:57 UTC ---
Sorry, commit didn't go through earlier - it's in now.

[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049

--- Comment #9 from Bernd Schmidt  2011-10-07 
12:56:55 UTC ---
Author: bernds
Date: Fri Oct  7 12:56:52 2011
New Revision: 179657

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179657
Log:
 PR target/49049
 * config/arm/arm.md (arm_subsi3_insn): Lose the last alternative.

* gcc.c-torture/compile/pr49049.c: New test.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr49049.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/arm/arm.md
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Bernd Schmidt  2011-10-07 
13:07:02 UTC ---
Fixed.

[Bug libstdc++/50661] std::equal should use more efficient version for arrays of pointers

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #18 from Bernd Schmidt  2011-10-11 
12:03:09 UTC ---
I think there are better people to answer ARM questions, but to the best of my
knowledge, there is no problem on that target.

I've tried to grep for something that might have an issue, and only found a

(define_expand "canonicalize_funcptr_for_compare"

and

/* We need a libcall to canonicalize function pointers on TARGET_ELF32.  */
#define CANONICALIZE_FUNCPTR_FOR_COMPARE_LIBCALL \
  "__canonicalize_funcptr_for_compare"

in config/pa.

[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686

--- Comment #4 from Bernd Schmidt  2011-10-12 
16:46:23 UTC ---
This doesn't seem to happen with a cross compiler :(

When you say "in stage 2", do you mean the stage 1 compiler is crashing, or the
stage 2 compiler is crashing?

[Bug target/50721] [4.6/4.7 Regression] Segfault of -O0 compiled program on x86_64 related to register allocator

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50721

--- Comment #8 from Bernd Schmidt  2011-10-14 
13:23:58 UTC ---
It looks like gsl_poly_dd_taylor overwrites part of the caller's stack frame.
Specifically, this statement

w[size - 1] = 1.0;

appears to go out of bounds. Can someone who understands Fortran check the
source whether it's actually valid?

[Bug target/50721] [4.6/4.7 Regression] Segfault of -O0 compiled program on x86_64 related to register allocator

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50721

--- Comment #9 from Bernd Schmidt  2011-10-14 
13:29:35 UTC ---
Hmm, even without understanding Fortran it looks like 

  real(fgsl_double) :: ra, xa(10), ya(10), da(10), di(10), d(2)

declares d as a 2 element array, but

#0  gsl_poly_dd_taylor (c=0x7fffd930, xp=0, dd=0x7fffd980,
xa=0x7fffd8d0, size=3, w=0x7fffd9d0)
(gdb) p size
$16 = 3

For the moment I'll assume user error.

[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686

--- Comment #7 from Bernd Schmidt  2011-10-17 
11:40:25 UTC ---
AFAIK there's no IRIX6.5 machine in the compile farm. Can you debug a bit at
the point of the crash to see what's going on?

Configure won't let me build the target without "--neable-obsolete" anyway, so
is it a serious issue?

[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686

--- Comment #9 from Bernd Schmidt  2011-10-17 
15:04:17 UTC ---
Well, shooting in the dark, let's get a few preliminaries out of the way - what
are the return values of dwarf2out_do_cfi_asm() and targetm.debug_unwind_info
()?

Also, a few of the last RTL dumps (there ought to be a "dwarf2" one) would be
helpful.

[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686

--- Comment #14 from Bernd Schmidt  2011-10-17 
16:34:42 UTC ---
Ok, so there are two restore_state notes following each other; note 374 and
note 375. We'll want a breakpoint in add_cfi to catch the two calls where these
notes are added. I'd expect it's from connect_traces, and at

  cfi->dw_cfi_opc = DW_CFA_restore_state;
  add_cfi (cfi);

in that function I'd like to see some state:
p debug_rtx (prev_ti->head)
p debug_rtx (ti->head)
p debug_cfi_row (ti->beg_row)

for each time we reach this code.

[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686

--- Comment #16 from Bernd Schmidt  2011-10-17 
17:37:11 UTC ---
Sorry, I was being imprecise - only the instances where we generate notes 374
and 375 are interesting. Can you identify these two?

[Bug bootstrap/50825] [4.7 regression] bootstrap fails at stage1 libgcc from r180302

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50825

--- Comment #1 from Bernd Schmidt  2011-10-21 
18:38:48 UTC ---
Author: bernds
Date: Fri Oct 21 18:38:44 2011
New Revision: 180310

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180310
Log:
PR bootstrap/50825
* sched-deps.c (add_dependence): If not doing predication, promote
REG_DEP_CONTROL to REG_DEP_ANTI.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c

[Bug bootstrap/50836] [4.7 regression] bootstrap fails due to error: no previous prototype for 'find_all_hard_reg_sets'

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50836

--- Comment #2 from Bernd Schmidt  2011-10-24 
11:03:16 UTC ---
Author: bernds
Date: Mon Oct 24 11:03:12 2011
New Revision: 180376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180376
Log:
PR bootstrap/50836
* rtlanal.c: Swap includes of "hard-reg-set.h" and "rtl.h".

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

[Bug rtl-optimization/50833] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -fshrink-wrap

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50833

--- Comment #1 from Bernd Schmidt  2011-10-24 
11:46:09 UTC ---
Author: bernds
Date: Mon Oct 24 11:46:04 2011
New Revision: 180377

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180377
Log:
PR rtl-optimization/50833
* function.c (thread_prologue_and_epilogue_insns): Expect the
return insn optimization only if optimize.

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

[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686

--- Comment #19 from Bernd Schmidt  2011-10-24 
12:10:21 UTC ---
It's really hard to run a gdb session this way. You're not a gcc newbie, and
you're the only one with an IRIX machine - can you not debug a bit further from
where we are now? You'll have to figure out why we get to that point twice with
the same data - this is making no sense to me. Check whether it's the same
loop, or (unlikely) two calls to connect_traces. If it's the same loop, what
are the indices? What's the contentes of the VEC? etc.

[Bug rtl-optimization/50762] ICE: in extract_insn, at recog.c:2137 (unrecognizable insn)

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762

--- Comment #14 from Bernd Schmidt  2011-11-10 
13:34:02 UTC ---
Is this with your patch from comment 6? You really can't have a CONST_INT
inside a zero_extend; the abort is justified.

[Bug rtl-optimization/53180] [4.8 Regression] Revision 186378 generates incorrect code for cpu2006 416.gamess

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53180

--- Comment #1 from Bernd Schmidt  2012-05-08 
10:35:21 UTC ---
Created attachment 27344
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27344
Candidate patch

I think I have a theory of what's going wrong. Can you test this patch?

[Bug tree-optimization/41718] internal compiler error: in add_stack_var_conflict, at cfgexpand.c:359

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41718

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #4 from Bernd Schmidt  2012-05-10 
16:36:34 UTC ---
I think this got fixed in r154689.

[Bug rtl-optimization/53180] [4.8 Regression] Revision 186378 generates incorrect code for cpu2006 416.gamess

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53180

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Bernd Schmidt  2012-05-16 
01:38:55 UTC ---
Fixed (r187495)

[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381

--- Comment #2 from Bernd Schmidt  2012-05-16 
22:30:53 UTC ---
What's it actually trying to access, and failing? Is dest NULL or something?

[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381

--- Comment #4 from Bernd Schmidt  2012-05-16 
23:14:32 UTC ---
Created attachment 27427
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27427
Candidate patch

Ok, seriously weird call insns. If you can fix that in the port, it'll benefit
from the optimization. Otherwise, try the following which disables it for
targets with strange call insns.

I won't be able to check this in until Monday; I think if it passes testing on
your machine you can either check it in as obvious or wait a few days.

[Bug middle-end/53411] [4.8 Regression] ICE in move_unallocated_pseudos

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411

--- Comment #3 from Bernd Schmidt  2012-05-21 
16:52:06 UTC ---
Odd. The following is in 190r.asmcons:

(insn 39 51 141 3 (set (reg:DI 135 [ D.1745 ])
(sign_extend:DI (reg:SI 132 [ j ]))) regehr.c:22 122
{*extendsidi2_rex64}
 (expr_list:REG_DEAD (reg:SI 132 [ j ])
(expr_list:REG_UNUSED (reg:DI 135 [ D.1745 ])
(nil

That insn has no purpose. We then run delete_trivially_dead_insns in IRA... but
it happens after find_moveable_pseudos, and probably needs to happen before as
well.

[Bug rtl-optimization/53373] [4.8 regression] ICE on valid code with -mavx

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373

--- Comment #11 from Bernd Schmidt  2012-05-21 
21:37:05 UTC ---
Author: bernds
Date: Mon May 21 21:37:01 2012
New Revision: 187745

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187745
Log:
PR rtl-optimization/53373
* caller-save.c (save_call_clobbered_regs): Look into a possible
PARALLEL manually rather than using single_set on a call insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/caller-save.c

[Bug rtl-optimization/53373] [4.8 regression] ICE on valid code with -mavx

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Bernd Schmidt  2012-05-25 
18:23:37 UTC ---
Fixed.

[Bug middle-end/53411] [4.8 Regression] ICE in move_unallocated_pseudos

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411

--- Comment #4 from Bernd Schmidt  2012-05-25 
18:32:40 UTC ---
Looks like an earlier dce pass (during .ce2) leaves a dead insn lying around.
Bug in DCE?

[Bug target/40657] allocate local variables with fewer instructions

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #13 from Bernd Schmidt  2012-06-20 
18:30:54 UTC ---
Yeah.

[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287

--- Comment #1 from Bernd Schmidt  2012-02-16 
19:47:29 UTC ---
Please attach the reginfo.ii file.

[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287

--- Comment #3 from Bernd Schmidt  2012-02-16 
20:43:03 UTC ---
Not reproducible with a cross compiler.

[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287

--- Comment #9 from Bernd Schmidt  2012-02-23 
15:41:49 UTC ---
(In reply to comment #8)
> This reproduces only on Solaris 8 because the sort of the ready list isn't
> stable in the presence of debug insns, given that rank_for_schedule isn't
> anti-symmetrical:

Thanks for investigating this.

> Index: haifa-sched.c
> ===
> --- haifa-sched.c   (revision 184352)
> +++ haifa-sched.c   (working copy)
> @@ -1647,7 +1647,7 @@ rank_for_schedule (const void *x, const
>/* Schedule debug insns as early as possible.  */
>if (DEBUG_INSN_P (tmp) && !DEBUG_INSN_P (tmp2))
> return -1;
> -  else if (DEBUG_INSN_P (tmp2))
> +  else if (DEBUG_INSN_P (tmp2) && !DEBUG_INSN_P (tmp))
> return 1;
>  }
> 
> as it makes the sort stable and equivalent to the non-Solaris 8 case.

Almost OK, but in the case of two debug insns, can you make it return the
difference of the INSN_UIDs here? I'd rather not fall through into the other
code for DEBUG_INSNs.

Such a patch is preapproved.

[Bug target/52425] [4.6 Regression] ICE when compiling file from audacious on debian sparc

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52425

--- Comment #4 from Bernd Schmidt  2012-03-02 
14:22:54 UTC ---
For some reason I can never reproduce sparc bugs with cross compilers. The
original testcase doesn't fail here; the reduced one fails but with a different
error message, and it fails in instantiate_virtual_regs which is before any
head-merging ever runs:

sparcbug.i: In function ‘action_button_cb’:
sparcbug.i:57:1: error: unrecognizable insn:
(insn 7 6 8 3 (set (reg:SI 130)
(lo_sum:SI (reg:SI 130)
(unspec:SI [
(symbol_ref/f:DI ("*.LC0") [flags 0x2] )
] 0))) sparcbug.i:49 -1
 (nil))

Breakpoint 2, internal_error (gmsgid=0xd6093d "in %s, at %s:%d") at
../../trunk/gcc/diagnostic.c:839
839{
(gdb) bt
#0  internal_error (gmsgid=0xd6093d "in %s, at %s:%d") at
../../trunk/gcc/diagnostic.c:839
#1  0x00bcf7cc in fancy_abort (file=, line=2123,
function=0xc99260 "extract_insn")
at ../../trunk/gcc/diagnostic.c:899
#2  0x0081e8d3 in _fatal_insn (msgid=,
insn=0x76bc5990, 
file=0xc9885b "../../trunk/gcc/recog.c", line=2123, function=0xc99260
"extract_insn")
at ../../trunk/gcc/rtl-error.c:110
#3  0x0081e912 in _fatal_insn_not_found (insn=0xc99260, file=0xc9886b
"recog.c", line=2123, 
function=0xa ) at
../../trunk/gcc/rtl-error.c:118
#4  0x007ea2b4 in extract_insn (insn=0x76bc5990) at
../../trunk/gcc/recog.c:2123
#5  0x006cfe1c in instantiate_virtual_regs_in_insn
(insn=0x76bc5990) at ../../trunk/gcc/function.c:1555
#6  instantiate_virtual_regs () at ../../trunk/gcc/function.c:1911

Please post the actual command line that gets passed to cc1. Also, it would be
helpful if you could load cc1 into a debugger and do the following at the crash
site in output_addr_const:

(gdb) p debug_rtx (x)

and at some higher level, also use debug_rtx to print out the insn it's trying
to print.

[Bug rtl-optimization/45813] [4.5 Regression] alias analysis problem with -mthumb

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813

Bernd Schmidt  changed:

   What|Removed |Added

 CC|bernds at gcc dot gnu.org   |

--- Comment #14 from Bernd Schmidt  2012-03-13 
14:47:02 UTC ---
This really just needs -fno-strict-aliasing, doesn't it? Removing myself from
Cc.

[Bug rtl-optimization/52573] [4.5/4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573

--- Comment #2 from Bernd Schmidt  2012-04-13 
13:02:03 UTC ---
 (expr_list:REG_DEAD (reg:SI 3 %d3 [236])
(expr_list:REG_UNUSED (reg:SI 3 %d3 [236])

The REG_DEAD note is bogus and confuses the renamer. Only REG_UNUSED should be
on this insn.

[Bug middle-end/52997] [4.8 Regression] FAIL: gcc.dg/c99-intconst-1.c (internal compiler error)

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52997

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #1 from Bernd Schmidt  2012-04-19 
14:21:06 UTC ---
Created attachment 27190
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27190
Candidate patch

Does this fix it?

[Bug middle-end/52997] [4.8 Regression] FAIL: gcc.dg/c99-intconst-1.c (internal compiler error)

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52997

--- Comment #3 from Bernd Schmidt  2012-04-26 
13:25:48 UTC ---
Author: bernds
Date: Thu Apr 26 13:25:41 2012
New Revision: 186875

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186875
Log:
* PR middle-end/52997
* ira.c (find_moveable_pseudos): Call resize_reg_info.

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

[Bug middle-end/52940] conversion from MODE_PARTIAL_INT uses sign extension for unsigned types

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52940

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Bernd Schmidt  2012-04-26 
13:54:03 UTC ---
Committed now.

[Bug middle-end/52940] conversion from MODE_PARTIAL_INT uses sign extension for unsigned types

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52940

--- Comment #2 from Bernd Schmidt  2012-04-26 
14:20:50 UTC ---
Author: bernds
Date: Thu Apr 26 14:20:39 2012
New Revision: 186877

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186877
Log:
PR middle-end/52940
* machmode.h (CLASS_HAS_WIDER_MODES_P): True for MODE_PARTIAL_INT.
* expr.c (convert_move): Honor unsignedp when extending partial int
modes.
* genmodes.c (complete_mode): Don't clear component field of partial
int modes.
(emit_mode_inner): Don't emit it however.
(calc_wider_mode): Partial int modes widen to their component.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/genmodes.c
trunk/gcc/machmode.h

[Bug middle-end/52997] [4.8 Regression] FAIL: gcc.dg/c99-intconst-1.c (internal compiler error)

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52997

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Bernd Schmidt  2012-04-26 
15:02:14 UTC ---
Fixed.

[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791

--- Comment #10 from Bernd Schmidt  ---
(In reply to John David Anglin from comment #9)
> Any chance the candidate patch can be submitted?

I guess this means you've tested it and it works?

[Bug target/51003] bfin ICE compiling libgcc in gen_const_vector, at emit-rtl.c:5476

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51003

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Bernd Schmidt  2011-12-19 
12:41:00 UTC ---
Fixed.

[Bug middle-end/51200] Wrong code sequence to store restrict volatile bitfield

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51200

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bernd Schmidt  2011-12-21 
01:22:08 UTC ---
Fixed, I think?

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

[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 rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850



Bernd Schmidt  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #15 from Bernd Schmidt  2012-11-23 
12:06:37 UTC ---

Fixed.

[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158



--- Comment #20 from Bernd Schmidt  2012-12-04 
11:06:07 UTC ---

Created attachment 28873

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28873

Another patch



Here's another attempt, given that it seems to be the speculation code that

causes the problem.

[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814



--- Comment #9 from Bernd Schmidt  2012-12-08 
14:08:52 UTC ---

Created attachment 28900

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28900

Candidate patch



Try this.

[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'

[bernds at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814



Bernd Schmidt  changed:



   What|Removed |Added



  Attachment #28900|0   |1

is obsolete||



--- Comment #12 from Bernd Schmidt  2012-12-18 
04:50:04 UTC ---

Created attachment 28990

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28990

Better patch



Sorry for doing this, but here's a slightly improved version of the patch. Does

this also fix the issue?



This one was bootstrapped and tested on x86_64-linux, so it could go in if it

works; not sure I want to do that before I stop reading email for the next two

weeks though.

[Bug rtl-optimization/68730] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68730

--- Comment #14 from Bernd Schmidt  ---
It does look like an issue with lra-remat...

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #12 from Bernd Schmidt  ---
(In reply to Jeffrey A. Law from comment #10)
> /* Advance to an even register if the argument is doubleword-aligned.  */
>   if (doubleword_aligned_p)
> info->reg_offset += info->reg_offset & 1;
> 
> Which can be tracked back to this commit:
> commit 26bcab5a0015a5304899649081fd676996b8
> Author: rsandifo 
> Date:   Sat Sep 25 07:42:43 2004 +
> 
> * config/mips/mips.h (struct mips_args): Clarify comments.
> * config/mips/mips.c (struct mips_arg_info): Likewise.
> (mips_arg_info): Don't allow fpr_p to affect the register or
> stack alignment.  Remove o64 silliness.
> (function_arg): Deal with the o32 float,float case specially.
> 

Cc'ing Richard in case he has input.

[Bug c/69522] [4.9/5/6 Regression] gcc hangs on valid code on x86_64-linux-gnu

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #5 from Bernd Schmidt  ---
The hang seems to be due to some sort of corrupted AVL tree in the C frontend
(e->left == e). Marek, do you want it or should I have a look?

[Bug c/69522] [4.9/5/6 Regression] gcc hangs on valid code on x86_64-linux-gnu

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #7 from Bernd Schmidt  ---
So far: looks like we're creating multiple init elts with the same address and
trying to put them into the same tree. Looks like we're discarding an obstack
while we still have something pointing to it, and I suspect it's related to the
warning message.

[Bug c/69522] [4.9/5/6 Regression] gcc hangs on valid code on x86_64-linux-gnu

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522

--- Comment #8 from Bernd Schmidt  ---
Ok so the warning is irrelevant. Slightly improved testcase that doesn't have
it:

struct str {};
struct {
  struct str b;
  float c[1];
  int d[1];
  float e[2];
  int f[1];
} a = {{}, 0, {0.5}, 0, 0, {0}};

The problem seems to be the initialization of an array without explicit braces
(let's say the initialization of c), followed by a starting brace
(initialization of d) which triggers the "implicit != 1" code in
push_init_level. It looks like that puts the initializers of c onto the obstack
that was initialized for parsing the initializer of d, which gets discarded too
soon.

Hmmm.

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #5 from Bernd Schmidt  ---
Jakub, do you want to look at it or should I assign myself?

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #7 from Bernd Schmidt  ---
Taking it and also hoping it's not in reg-stack.

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570

--- Comment #8 from Bernd Schmidt  ---
Looks like it can be slightly reduced, removing not executed paths.

template  constexpr inline const T &
min (const T &a, const T &b)
{
  if (b < a)
return b;
  return a;
}

template < typename T > constexpr inline const T &
max (const T &a, const T &b)
{
  if (a < b)
return b;
  return a;
}

static inline void
foo (unsigned x, unsigned y, unsigned z, double &h, double &s, double &l)
{
  double r = x / 255.0;
  double g = y / 255.0;
  double b = z / 255.0;
  double m = max (r, max (g, b));
  double n = min (r, min (g, b));
  double d = m - n;
  double e = m + n;
  h = 0.0, s = 0.0, l = e / 2.0;
  if (d > 0.0)
{
  s = l > 0.5 ? d / (2.0 - e) : d / e;
  if (m == g)
h = (b - r) / d + 2.0;
  h /= 6.0;
}
}

__attribute__ ((noinline, noclone))
void bar (unsigned x[3], double y[3])
{
  double h, s, l;
  foo (x[0], x[1], x[2], h, s, l);
  y[0] = h;
  y[1] = s;
  y[2] = l;
}

int
main ()
{
  unsigned x[3] = { 0, 128, 0 };
  double y[3];

  bar (x, y);
  if (__builtin_fabs (y[0] - 0.3) > 0.001)
__builtin_abort ();

  return 0;
}