Re: Type inheritance graph analysis & speculative devirtualization, part 4a/6 simple anonymous namespace devirtualization during cgraph construction
Jan, This has broken all builds because method_type_class() is defined. Graham
Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS
Hi Richard, There is some minor testsuite fallout with these patches on MIPS a couple of tests (see below)ICE ingen_int_mode () in both these ICE the mode is CCmode. Here we arrive at gen_int_mode () via a use of plus_constant () is cse.c with a register with CCmode called from find_reg_offset_for_const (). The plus_constant () ends up trying to create the reg+const rtx via if (c != 0) x = gen_rtx_PLUS (mode, x, gen_int_mode (c, mode)); with the gen_int_mode 90 triggering the ICE. It obviously doesn't make sensegenerating a reg + const where the reg has CCMode. I've only got results from check-gcc-c testsuite so far. Graham testsuite/c-c++-common/cilk-plus/AN/builtin_func_double.c testsuite/gcc.c-torture/execute/921013-1.c
Re: Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS
Hi Richard, Thanks I'll give a go tomorrow. Not sure why it has only been seen/reported for MIPS so far I can't see why it can't happen in other backends. Cheers Graham
Re: Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS
Hi Richard,
After applying just the cse.c part of the patch the two testcases no longer ICE
and pass
with regressions in C or C++ testsuites.
Not sure if we really need the other part of the patch to gen_int_mode ().
Graham
- Original Message -
From: Richard Sandiford
To: Graham Stott
Cc: James Greenhalgh ; "gcc-patches@gcc.gnu.org"
Sent: Wednesday, 11 September 2013, 19:39
Subject: Re: Using gen_int_mode instead of GEN_INT minot testsuite fallout on
MIPS
Graham Stott writes:
> Hi Richard,
>
> There is some minor testsuite fallout with these patches on MIPS a
> couple of tests (see below)ICE ingen_int_mode () in both these ICE the
> mode is CCmode.
Hmm, interesting. I suppose gen_int_mode should handle CC modes,
since there's no other constant rtx that can be used instead. OTOH,
like you say, it doesn't really make sense to apply try_const_anchor
to CCmode.
How does the following patch look?
Thanks,
Richard
gcc/
* emit-rtl.c (gen_int_mode): Handle CC modes.
* cse.c (try_const_anchors): ...but punt on them here.
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c 2013-09-08 11:52:15.0 +0100
+++ gcc/emit-rtl.c 2013-09-11 19:32:35.702377902 +0100
@@ -417,6 +417,11 @@ gen_rtx_CONST_INT (enum machine_mode mod
rtx
gen_int_mode (HOST_WIDE_INT c, enum machine_mode mode)
{
+ /* CONST_INT is used for CC modes too. We can't make any assumptions
+ about the precision or bitsize in that case, so just pass the value
+ through unchanged. */
+ if (GET_MODE_CLASS (mode) == MODE_CC)
+ return GEN_INT (c);
return GEN_INT (trunc_int_for_mode (c, mode));
}
Index: gcc/cse.c
===
--- gcc/cse.c 2013-09-08 11:52:15.0 +0100
+++ gcc/cse.c 2013-09-11 19:38:17.664399826 +0100
@@ -1354,6 +1354,11 @@ try_const_anchors (rtx src_const, enum m
rtx lower_exp = NULL_RTX, upper_exp = NULL_RTX;
unsigned lower_old, upper_old;
+ /* CONST_INT is used for CC modes, but we should leave those alone. */
+ if (GET_MODE_CLASS (mode) == MODE_CC)
+ return NULL_RTX;
+
+ gcc_assert (SCALAR_INT_MODE_P (mode));
if (!compute_const_anchors (src_const, &lower_base, &lower_offs,
&upper_base, &upper_offs))
return NULL_RTX;
Re: Profile housekeeping 6/n (-fprofile-consistency-report)
Jan. This patch also breaks bootstrap due compilation errors reported for pases.c and toplev.c Graham
A recent change has broken bootstrap on trunk and gcc8-branch
Hi A heads up a change too tree_switch_conversion.c has broken bootstraps Graham
Re: A recent change has broken bootstrap on trunk and gcc8-branch
Internal compile error mpn_base_power_of_two_p Original message From: graham stott Date: 03/09/2018 11:58 (GMT+00:00) To: gcc-patches Cc: gmail Subject: A recent change has broken bootstrap on trunk and gcc8-branch Hi A heads up a change too tree_switch_conversion.c has broken bootstraps Graham
WM
finished
washing
jj you going to do more washing?
build failure x86_64
A recent patch has broken RTL checking builds on x86_64 fails during combine RTL check: expected code 'reg' have 'lshirtrt' in rhs_regno at rtl.h:1891 builfing libgçc2.c in function __mulsc3
food
if you do go can you please get some chicken fillets for papa thanks
RE: [PATCH RFC] MIPS add support for MIPS SIMD ARCHITECTURE V1.07
Hi Joseph, Thanks for the comments I will address these issues and send an updated patch. Graham
Re: r273969 - in /trunk/gcc/lto: ChangeLog Make-lan...
There's no ChangeLog entry fof this Original message From: edlin...@gcc.gnu.org Date: 01/08/2019 09:45 (GMT+00:00) To: gcc-...@gcc.gnu.org Subject: r273969 - in /trunk/gcc/lto: ChangeLog Make-lan... Author: edlingerDate: Thu Aug 1 08:45:29 2019New Revision: 273969URL: https://gcc.gnu.org/viewcvs?rev=273969&root=gcc&view=revLog:2019-08-01 Bernd Edlinger * Make-lang.in (lto.install-common): Remove unnecessary slash between $(DESTDIR) and $(bindir).Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/Make-lang.in
remove unused fiields in init_expmed_rtl expmed.c
All,
The struture init_expmed_rtl defined in expmed.c has many fields which are
totally unused
this patch removes them.
Bootstraped x86_64 all langauges
Graham
gcc/ChangeLog
* expmed.c: (init_expmed_rtl) Remove unused fields reg_fld, plus_fld,
mult_fld, sdiv_fld1, udiv_fld1,
sdiv_32_fld1, smod_32_fld1, wide_mult_fld1, wide_lshr_fld1, shift_fld1,
shift_mult_fld1 shift_add_fld1,
shift_sub0_fld1, shift_sub1_fld1.
Index: gcc/expmed.c
===
--- gcc/expmed.c (revision 198200)
+++ gcc/expmed.c (working copy)
@@ -69,22 +69,22 @@
struct init_expmed_rtl
{
- struct rtx_def reg; rtunion reg_fld[2];
- struct rtx_def plus; rtunion plus_fld1;
+ struct rtx_def reg;
+ struct rtx_def plus;
struct rtx_def neg;
- struct rtx_def mult; rtunion mult_fld1;
- struct rtx_def sdiv; rtunion sdiv_fld1;
- struct rtx_def udiv; rtunion udiv_fld1;
- struct rtx_def sdiv_32; rtunion sdiv_32_fld1;
- struct rtx_def smod_32; rtunion smod_32_fld1;
- struct rtx_def wide_mult; rtunion wide_mult_fld1;
- struct rtx_def wide_lshr; rtunion wide_lshr_fld1;
+ struct rtx_def mult;
+ struct rtx_def sdiv;
+ struct rtx_def udiv;
+ struct rtx_def sdiv_32;
+ struct rtx_def smod_32;
+ struct rtx_def wide_mult;
+ struct rtx_def wide_lshr;
struct rtx_def wide_trunc;
- struct rtx_def shift; rtunion shift_fld1;
- struct rtx_def shift_mult; rtunion shift_mult_fld1;
- struct rtx_def shift_add; rtunion shift_add_fld1;
- struct rtx_def shift_sub0; rtunion shift_sub0_fld1;
- struct rtx_def shift_sub1; rtunion shift_sub1_fld1;
+ struct rtx_def shift;
+ struct rtx_def shift_mult;
+ struct rtx_def shift_add;
+ struct rtx_def shift_sub0;
+ struct rtx_def shift_sub1;
struct rtx_def zext;
struct rtx_def trunc;
Re: [patch][mips] split mips_reorg in pre- and post-dbr_schedule parts
Steven, The new execute mips_machine_reorrg2 part of the patch doesn't have a return value! Graham
Testsuite MIPS libs/scanasm.exe allow mathing against (no)micromips/
All,
When micromips was added scanasm.exe wasn't updated this was causing a few tests
which scanned the assembler output to start failing such as
dg.c++/debiug/dwarf2/lineno-simple1.C.
Fixed with the ollowing patch
Graham
testuite/ChangeLog:
21-05-2013 * graham stott graham.st...@btinternet.com
* lib/scanasm.exp (dg-function-on-line) target mips-*-*-* allow matching
aginst micromips
directive
Index: scanasm.exp
===
--- scanasm.exp (revision 199093)
+++ scanasm.exp (working copy)
@@ -493,7 +493,7 @@
set pattern [format {\t;[^:]+:%d\n(\t[^\t]+\n)+%s:\n\t.PROC} \
$line $symbol]
} elseif { [istarget mips*-*-*] } {
- set pattern [format {\t\.loc [0-9]+ %d 0(
[^\n]*)?\n(\t.cfi_startproc[^\t]*\n)*\t\.set\t(no)?mips16\n\t\.ent\t%s\n\t\.type\t%s,
@function\n%s:\n} \
+ set pattern [format {\t\.loc [0-9]+ %d 0(
[^\n]*)?\n(\t.cfi_startproc[^\t]*\n)*\t\.set\t(no)?mips16\n\t\.set\t(no)?micromips\n\t\.ent\t%s\n\t\.type\t%s,
@function\n%s:\n} \
$line $symbol $symbol $symbol]
} else {
set pattern [format
{%s:[^\t]*(\t.(fnstart|frame|mask|file)[^\t]*)*\t[^:]+:%d\n} \
MIPS elimate trap-if-zero instruction if possible for divisions
Hi Richard, This patch attemps to elimate the TEQ instruction div DIV/MOD instructions if possible (i.e the numerator is known to be non-zero) I have introduced and seperated UNSPEC UNSPEC_SET_HILO_NOTRAP which is generation by a peephole2 when the trap is known not to be required. The peephole's work by checking for a REG_EQUAL or/REG_EQUIV on the instruction which sets the numerator for the DIV/MOD this doesn't catch all possible cases but does catch the common cases where ths numerator is set set in a insn immediately preceeding the DIV/MOD. ChangeLog 2013-07-03 Graham Stottgrah...@btinternet.com * config/mips/mips.c: (mips_output_division) : Make static add new traps enables/disables the geration if a trap insn is TRAPS for divison are enabled. (mips_output_division_with_trap): New enables geration of trap on division by zero instruction. (mips_output_division_without_trap) New disables generation of trap.on division by zero instruction. * config/mips/mips-protos.h (mips_output_divison): Delete. (mips_output_division_with_trap): Add outputs a division sequence with a trap-if-zero if required. (mips_output_division_without_trap): Add outputs the division sequence without and trap-if-zero instruction. * config/mips/mips.md (UNSPEC_SET_HILO_NOTRAP): Add unspec and two peephole2 defines (divmod4_hilo_: Rename divmod4_hilo__with_trap. (divmod4_hilo__without_trap): New * config/mips/predicates.md (binary_operator): Define. (unary_operator): Define. mips.md.diff Description: Binary data mips-protoes.h.diff Description: Binary data mips.c.diff Description: Binary data predicates.md.diff Description: Binary data
RFC DIVMOD expansion in expand_divmod:expmed.c
All, The DIV/MOD expansion performed in expmed is basically driven by RTX costs/-Os that are provided by the backend.In a few instances these costs and or _os appear to be ignored. One senerio is divsion by a constant in a mode whose size <= HOST_BITS_PER_WIDE_INT it will always expand the DIV/MOD using multiplation (Montgomery) when optimizing for size. Shouldn't this expansion be be guarded by !speed and the expansion skipped allowing the backend open coding an DIV/MOD sequence or libcall. Is guarding this with a !speed guard the best thing to do for most backends or should this be controlled with a new target hook with the default hook returning true for yes expand maintaining the status quo giving the backends to override. Another senerio is signed divison of a power-of-2 if the backend dosn't have optabs for sdiv and sdivmod then expand_sdiv_pow2 will be choosen even if otimizing for size and sdiv_pow2_cheap() retuns true! if (sdiv_pow2_cheap (speed, compute_mode) && ((optab_handler (sdiv_optab, compute_mode) != CODE_FOR_nothing) || (optab_handler (sdivmod_optab, compute_mode) != CODE_FOR_nothing))) quotient = expand_divmod (0, TRUNC_DIV_EXPR, compute_mode, op0, gen_int_mode (abs_d, compute_mode), NULL_RTX, 0); else quotient = expand_sdiv_pow2 (compute_mode, op0, abs_d); When optimizing for size (!speed) and sdiv_pow2_cheap() is true we ideally don't want to use expand_sdiv_pow2 but instead let the back end opend code the DIV. Question how can one determine if a backend can open code a DIV/MOD Graham
MIPS don't gererate MUL when muliplying by constant of for 2^N +/- 1 optimizing for size
Hi Richard, When -Os is used and the multiplier is of the for 2^N +- 1 we generate a MUL instruction rather that a shift-left N and add-sub 1. The problem is that rtx cost for the MUL is too cheap causing the shift-left and add-sub sequence to be more expensive. This patch makes the MUL slightly more expension so the alternate sequence and better sequence used. The shift + add/sub is faster and can probaly be scheduled better. This change is code size neutral because the MUL requires a load-immediate. ChangeLog: * config/mips/mips.c: (mips_rtx_costs): Slightly increase cost of MUL when optimizing for size. This allows a better sequence to be choosen when multiply by a constant of the form 2^N +- 1. Graham mips.c.diff Description: Binary data
Fix missing use of -Werror when compiling files in c-familty directory
All, Files in the c-family directory are being compiled during stage3 without -Werror and other warningb flags that are part of WARN_STRICT flags. Fixing this shows that array_notation_common.c generates unused variable warnings and will break the build after the apcth is applied. ChangeLog 03-07-2013Graham Stott * gcc/Makegfvile.in: Define c-family-warn. to WARN_STRICT. Makefile.in.diff Description: Binary data
Fix ununsed variables before my patch adding missing -Werror
This patch fixes the warnings from array-notation_common.c so that I can then apply my Makefile missing -Werror patch. Graham ChangeLog 03-07-2013 graham.stott graham.st...@btinternet.com * c-familly/array_notation_comon.c (length_mismatch_expr_p): Delete unused varables l_length and l_node Graham array-notation-common.c.diff Description: Binary data
Re: MIPS elimate trap-if-zero instruction if possible for divisions
Hi Jeff, Richard We could possibly also use VRP to change signed division to unsigned division when dividing a non-negative signed operand by a power of 2 because then the sign bit will be 0 and we could do the division using logical shift right. Graham
PING Fix ununsed variables before my patch adding missing -Werror
- Original Message - From: Graham Stott To: "gcc-patches@gcc.gnu.org" Cc: Sent: Wednesday, 3 July 2013, 16:25 Subject: Fix ununsed variables before my patch adding missing -Werror This patch fixes the warnings from array-notation_common.c so that I can then apply my Makefile missing -Werror patch. Graham ChangeLog 03-07-2013 graham.stott graham.st...@btinternet.com * c-familly/array_notation_comon.c (length_mismatch_expr_p): Delete unused varables l_length and l_node Graham
Re: Fix missing use of -Werror when compiling files in c-familty directory
I've fixed the issue with the warnings and have now comitted the patch with a corrected ChangeLog entry as revision 200783 Graham
Re: MIPS don't gererate MUL when muliplying by constant of for 2^N +/- 1 optimizing for size
Hi Richard,
The problem was with adjusting to be more expansive the load imm + mul sequence
and
the shift + add sequence were the smake cost when optimizing for size so the
code in expmed.c
choose the MUL.
I also considered this version also I couldn't decide which was better just
went with the other
version on a toss of a coin.
I submit again with mips target testcase which use scan assember technique to
check that
we use the shift+add/sub sequence.
A simple testcase compiled with -Os
int foo(int x)
{
return x * 17;
}
will demonstrate that we currently use "LI + MUL" and after the patch we will
use "SLL + ADDU".
Gtraham
Re: MIPS don't gererate MUL when muliplying by constant of for 2^N +/- 1 optimizing for size
hi Richard,
I've Updated patch and added testcases basically they are the same testcase just
using different constants
I tried combining them into one testcase couldn'tget the scan-assembler stuff
working when multiple functions were in the assembler output I couldn't
couldn't work
out how to restrict the scans to only part of the assembler file. Maybe its not
possible
without some new dejagnu/expect fragments.
Graham
gcc/ChangeLog
* config/mips/mips.c (): Very slightly increase code of MUL.whren
optimizing for size.
gcc/testsuite/ChangeLog
* gcc.target/mips/mulsize-7.c: New.
* gcc.target/mips/mulsize-9.c New.
* gcc/target/mips/mulsize-15.c: New.
* gcc.target/mips/mulsize-17.c: New.
diffs
Description: Binary data
/* { dg-final { scan-assembler "\t.globl\tf17" } } */
/* { dg-final { scan-assembler "\tsll\t" } } */
/* { dg-final { scan-assembler "\taddu\t" } } */
/* { dg-final { scan-assembler-not "\tli\t" } } */
/* { dg-final { scan-assembler-not "\tmul\t" } } */
int
f17(int x)
{
return x * 17;
}
/* { dg-final { scan-assembler "\t.globl\tf15" } } */
/* { dg-final { scan-assembler "\tsll\t" } } */
/* { dg-final { scan-assembler "\tsubu\t" } } */
/* { dg-final { scan-assembler-not "\tli\t" } } */
/* { dg-final { scan-assembler-not "\tmul\t" } } */
int
f15(int x)
{
return x * 15;
}
/* { dg-final { scan-assembler "\t.globl\tf9" } } */
/* { dg-final { scan-assembler "\tsubu\t" } } */
/* { dg-final { scan-assembler-not "\tli\t" } } */
/* { dg-final { scan-assembler-not "\tmul\t" } } */
int
f9(int x)
{
return x * 9;
}
/* { dg-final { scan-assembler "\t.globl\tf7" } } */
/* { dg-final { scan-assembler "\tsubu\t" } } */
/* { dg-final { scan-assembler-not "\tli\t" } } */
/* { dg-final { scan-assembler-not "\tmul\t" } } */
int
f7(int x)
{
return x * 7;
}
Re: MIPS elimate trap-if-zero instruction if possible for divisions
Hi Richard, Jeff. Richard what's your idea for exposing things early enough so that VRP can eliminate the need for a trao-if-zero insn iif possible. Graham
Re: MIPS elimate trap-if-zero instruction if possible for divisions
Richard, Isn't that to late for VRP its run twice before expand pass. Graham
Re: MIPS don't gererate MUL when muliplying by constant of for 2^N +/- 1 optimizing for size
Richard, I'll renumber then consecutively and fix the typo and change log entry before I commit Thanks Graham - Original Message - From: Richard Sandiford To: Graham Stott Cc: "gcc-patches@gcc.gnu.org" Sent: Tuesday, 9 July 2013, 18:31 Subject: Re: MIPS don't gererate MUL when muliplying by constant of for 2^N +/- 1 optimizing for size Graham Stott writes: > gcc/ChangeLog > > * config/mips/mips.c (): Very slightly increase code of MUL.whren > optimizing for size. * config/mips/mips.c (mips_rtx_costs): Very slightly increase the cost of MULT when optimizing for size. > gcc/testsuite/ChangeLog > * gcc.target/mips/mulsize-7.c: New. > * gcc.target/mips/mulsize-9.c New. > * gcc/target/mips/mulsize-15.c: New. > * gcc.target/mips/mulsize-17.c: New. Let's number these consecutively (1-4). Typo "gcc/target/mips" -> "gcc.target/mips". OK with those changes, thanks. Richard
Re: MIPS elimate trap-if-zero instruction if possible for divisions
Hi Jeff, Richard,
Not sure if that working.
I created some rtl using TRAP_IF to represent the TEQ and emiited via an
expander
The TRAP_IF rtl make ait all the way though the rtl optimizers which are run
after expand
even though it should be possible to determine is false.
(insn 7 3 20 2 (set (reg:SI 2 $2 [201])
(const_int 27 [0x1b])) bug.c:67 289 {*movsi_internal}
(expr_list:REG_EQUIV (const_int 27 [0x1b])
(nil)))
(insn 20 7 21 2 (trap_if (eq:SI (reg:SI 2 $2 [201])
(const_int 0 [0]))
(const_int 7 [0x7])) bug.c:68 8 {*conditional_trapNsi_if_zero}
(nil))
I grepped the RTL code for any code handling TRAP_IF that looked like it might
remove the TRAP_IF but
only found some code is final_scan which only applied to CC0 backends.
Is using a conditional trap (TRAP_IF) the right way to go?
Graham
Re: PING Fix ununsed variables before my patch adding missing -Werror
Erric, Thanks I'll these errors Graham - Original Message - From: Eric Botcazou To: Graham Stott Cc: gcc-patches@gcc.gnu.org Sent: Wednesday, 10 July 2013, 17:26 Subject: Re: PING Fix ununsed variables before my patch adding missing -Werror > ChangeLog > 03-07-2013 graham.stott graham.st...@btinternet.com > * c-familly/array_notation_comon.c (length_mismatch_expr_p): Delete > unused varables l_length and l_node Missing blank line in all your ChangeLog entries, and the above one is in the wrong ChangeLog file, it should be moved to c-family/ChangeLog as: 2013-07-08 Graham Stott * array-notation-common.c (length_mismatch_in_expr_p): Delete unused variables l_length and l_node. -- Eric Botcazou
Re: MIPS elimate trap-if-zero instruction if possible for divisions
Hi Jeff, Richard. None of the RTL optimzers look at TRAP_IF w.r.t optimiizations. I've decided to add some code to cprop.c and simplification primetives to simply_rtx () this do work once I fixed cprop to run on my testcase whicg only had functiions which 3 blocks currently it think theses nothing to do. I'jj submit a patchseparately for that. I'm currently tracking done a latent bug the cfg cleanup code which triggers a control inside basic block abort due to a (trap_if ((condtion) (const N)) being correctly optimized to ((trap_if (const_int 1)(conts_int N)). I ensure that when the condition is optimized to (const_int 1) that the block gets split after the unconditional trap satisfies control_flow_insn_p () predicate. The splt wroks so that the unconditional trap_if is the last instruction n its block but when cfg cleanup is run later it undoes this split and merges the blocks again thus triggering the verify_flow abort. Anyone know the rational (if any) for treating unconditional traps as control flow but not conditional traps. I would have expected them to be treated the same w.r.t flow control unless the condition is (const_int 0). Graham
RTL gensupport - fix warning when using a match_scratch predicate
All Currently using the match_scratch predicate on a destination operand will trigger the warning "warning: destination operand 0 allows non-lvalue", This happends because add_predicate_code() will set the pred->allows_non_lvalue when it encounters a SCRATCH rtx code which subsequently triggers the above genrecog warning/ Graham gcc/ChangeLog * gensupport.c:: (add_predicate_code) Also exclude SCRATCH from rtx codes which allow non-lvalues. Index: gcc/gensupport.c = --- gcc/gensupport.c (revision 198200) +++ gcc/gensupport.c (working copy) @@ -2732,7 +2732,8 @@ && code != MEM && code != CONCAT && code != PARALLEL - && code != STRICT_LOW_PART) + && code != STRICT_LOW_PART + && code != SCRATCH) pred->allows_non_lvalue = true; if (pred->num_codes == 1)
RE: [PATCH RFC] MIPS add support for MIPS SIMD ARCHITECTURE V1.07
Hi Richard, Attached is an updated patch for feedback so MSA support to MIPS backend can be added when open again for next stage1. It is unfinished in that some comments from your review of the initial patch have yet to be addressed. The diff is against svn 207500 Graham msa.svn.207500.diffs.gz Description: msa.svn.207500.diffs.gz
Re: [PATCH] Prevent out of bound access for multilib_options
All, It happens with all mulitilib configurations not just arm-elf if we have reached the end of the multilib_options string there are no more options to process so break from the loop. This patch is an alternative fix. = Index: gcc.c --- gcc.c (revision 209248) +++ gcc.c (working copy) @@ -7531,6 +7531,9 @@ } break; } + + if (*q == '\0') + break; } } } Graham
Re: Prevent inliner from removing aliases of used comdats
Jan, Any testcase do can add? Graham
Re: __sync_swap* [ rename sync builtins ]
All --- On Tue, 21/6/11, Richard Henderson wrote: > From: Richard Henderson > Subject: Re: __sync_swap* [ rename sync builtins ] > To: "Andrew MacLeod" > Cc: "Aldy Hernandez" , "Jakub Jelinek" , > "Joseph S. Myers" , "gcc-patches" > > Date: Tuesday, 21 June, 2011, 19:50 > On 06/21/2011 11:46 AM, Andrew > MacLeod wrote: > > * c-family/c-common.c: Add sync_ or > SYNC__ to builtin names. > > * c-family/c-omp.c: Add sync_ or > SYNC__ to builtin names. > > * java/builtins.c: Add sync_ or > SYNC__ to builtin names. > > * java/expr.c: Add sync_ or SYNC__ > to builtin names. > > * builtins.c: Add sync_ or SYNC__ > to builtin names. > > * sync-builtins.def: Add sync_ or > SYNC__ to builtin names. > > * omp-low.c: Add sync_ or SYNC__ to > builtin names. > > * cp/semantics.c: Add sync_ or > SYNC__ to builtin names. > > * fortran/trans-openmp.c: Add sync_ > or SYNC__ to builtin names. > > * fortran/trans-stmt.c: Add sync_ > or SYNC__ to builtin names. > > * fortran/trans-decl.c: Add sync_ > or SYNC__ to builtin names. > > Ok. > > > r~ > This looks to have broken the go frontend gcc/gcc/go/gofrontend/gogo-tree.cc: In member function ‘void Gogo::define_builtin_function_trees()’: /usr/local/src/gcc4.7/gcc/gcc/go/gofrontend/gogo-tree.cc:94:18: error: ‘BUILT_IN_ADD_AND_FETCH_1’ was not declared in this scope /usr/local/src/gcc4.7/gcc/gcc/go/gofrontend/gogo-tree.cc:99:19: error: ‘BUILT_IN_ADD_AND_FETCH_2’ was not declared in this scope /usr/local/src/gcc4.7/gcc/gcc/go/gofrontend/gogo-tree.cc:104:18: error: ‘BUILT_IN_ADD_AND_FETCH_4’ was not declared in this scope /usr/local/src/gcc4.7/gcc/gcc/go/gofrontend/gogo-tree.cc:109:18: error: ‘BUILT_IN_ADD_AND_FETCH_8’ was not declared in this scope Graham
Re: patch to fix PR 48435
Vladimir, The wrong PR 4435 was in referrenced the commit --- On Fri, 8/4/11, Jeff Law wrote: > From: Jeff Law > Subject: Re: patch to fix PR 48435 > To: "Vladimir Makarov" > Cc: "gcc-patches" > Date: Friday, 8 April, 2011, 16:18 > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/07/11 13:41, Vladimir Makarov wrote: > > The following patch should solve problem > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48435. > It might solve other > > latest IRA problems too including performance related > ones. The patch > > is for targets which require some values to be placed > in hard registers > > starting with an even (odd) hard registers. > > > > I already addressed an analogous problem recently and > the patch I sent > > that time although solved some problems it created > even more new > > problems. I should acknowledge this. > > > > The problem was in that profitable hard regs were used > for colorability > > criterion and finding hard registers where allocno > values can be resided > > but *also* as starting allocno hard registers. > It resulted in spilling > > allocnos which should be placed in multi-registers > starting on a > > specific border because profitable hard registers were > only starting > > registers and when we calculated number of available > hard registers > > multi-register allocnos can not fit only in their > starting hard registers. > > > > The following patch was successfully bootstrapped on > x86/x86-64 and on > > i686 with H.J.'s autotester options. > > > > OK to commit? > > > > 2011-04-07 Vladimir Makarov > > > > PR 4435 > > * ira-color.c > (setup_profitable_hard_regs): Add comments. > > Don't take prohibited hard > regs into account. > > > (setup_conflict_profitable_regs): Rename > to > > get_conflict_profitable_regs. > > (check_hard_reg_p): Check > prohibited hard regs. > OK. > jeff > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNnycrAAoJEBRtltQi2kC70DsH/A7fnYlawxDvYPeULGb1ctQD > 6LYWBWhJY4UDTiUNjLEzwALpq2XccVzubz1KEMI3wOndIHHYM2ykbsgTqCKmXqhf > ZthBjzNUtE/i7jSxK8JK3SEShqs2j7vaAvlkUKbdF7O61rhQap8MRnD2umHfrbet > PFea7MedpaC96mazzoyUWlzwWCt2CQhOlMFGlC44bxB1FrKy0nUjeIM7kWqjqG5W > Y9lV8RlC4O2cLST5qHpqtssLSO4omPlKsEUBEKW4E/87UCoFAxP0n8NOZ1EFgMsc > 3SlhSv+Dpinfh79gjHXt5+CH33bXTecf8Jfyd89Rn6huzL9OhAXJy+MjMi6cBm0= > =KSaH > -END PGP SIGNATURE- >
Re: [patch, fortran] Handling of .and. and .or. expressions
if i read this correctly it appears that IMPURE/PURE are not the normal pure attribute used by gcc but some entirely diff attribute specific to FORTANso people are taking about different things Original message From: Steve Kargl Date: 16/06/2018 17:38 (GMT+00:00) To: Janus Weil Cc: Janne Blomqvist , Thomas Koenig , fort...@gcc.gnu.org, gcc-patches Subject: Re: [patch, fortran] Handling of .and. and .or. expressions On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote: > > > Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl > : > >> But at least for pure functions, this optimization looks Ok. > >> > > > >Why is everyone fixated on PURE vs IMPURE functions? > > Simply because it makes a difference in this context! It does not! A function marked as PURE by a programmer must meet certain requirement of the Fortran standard. An unmarked function or a function marked as IMPURE can still meet those same requirements. Marking something as IMPURE has only a single requirement in the standard. An impure elemental procedure processes array arguments in array element order. That's it. Marking a function as IMPURE does not mean the function has side effects. It does not mean that a function must be evaluated for each reference. Are you advocating that gfortran must evaluate ping() twice for impure real function ping() end function ping x = ping() + 0 * ping() end -- Steve
bootstrap with --werror=yes fails
Heads Due too -Wabi empty class std::intergal_constant warning compiling libstdc++/c++/cxx11-shim_facets.cc Graham
bootstrap -O3 failure libgo on x64_86
Hi Fails due to undefind symbols runtime.* O2 works
Re: bootstrap -O3 failure libgo on x64_86
Ian A simple bootstrap using gcc 8 as host compiler works with default configuration all langs+ada. Now trying using gcc 9 host from a week ago Will tty elimate which configue opts cause problem Graham Original message From: Ian Lance Taylor via gcc-patches Date: 15/09/2018 16:01 (GMT+00:00) To: graham stott Cc: gcc-patches Subject: Re: bootstrap -O3 failure libgo on x64_86 On Sat, Sep 15, 2018 at 7:12 AM, graham stott via gcc-patches wrote: > Hi > Fails due to undefind symbols runtime.* > O2 works I tried my best guess at recreating the problem, and everything worked fine. Please tell us exactly what you did and exactly what happened. Thanks. Ian
Re: bootstrap -O3 failure libgo on x64_86
Ian I've bootstrapped gcc 9 with gcc 8 again and I'm unable to recreate failure boostrapping with gcc 9 so ignore I'll report if happens again Graham Original message From: Ian Lance Taylor via gcc-patches Date: 15/09/2018 16:01 (GMT+00:00) To: graham stott Cc: gcc-patches Subject: Re: bootstrap -O3 failure libgo on x64_86 On Sat, Sep 15, 2018 at 7:12 AM, graham stott via gcc-patches wrote: > Hi > Fails due to undefind symbols runtime.* > O2 works I tried my best guess at recreating the problem, and everything worked fine. Please tell us exactly what you did and exactly what happened. Thanks. Ian
Re: Fold more boolean expressions
Original message From: MCC CS Date: 02/10/2018 14:38 (GMT+00:00) To: gcc-patches@gcc.gnu.org Subject: Re: Fold more boolean expressions Thanks a lot!
gcc 8 trunk broken O3 on x86_64
All Just a heads the trunk has been broken since about Weds most files fail compare during bootstrap at O3 but pass at O2 My last succesful boostrap at O3 was Tuesday I no idea which commit caused it Graham
O3 bootstraps fail on x86-64
O3 bootstraps have started to fail to build since about Thursday. Due to an internal compiler error when building asan.c in function asan_emit_stack_protectìon tree-ssa--sccan.c:3396 Graham
Re: O3 bootstraps fail on x86-64
Disabling asan the build works Original message From: graham stott via gcc-patches Date: 19/05/2018 10:30 (GMT+00:00) To: gcc-patches Subject: O3 bootstraps fail on x86-64 O3 bootstraps have started to fail to build since about Thursday. Due to an internal compiler error when building asan.c in function asan_emit_stack_protectìon tree-ssa--sccan.c:3396 Graham
Re: O3 bootstraps fail on x86-64
It's --disable-libsanitizer that works not --disable-asan I got that wrong Original message From: graham stott via gcc-patches Date: 19/05/2018 10:30 (GMT+00:00) To: gcc-patches Subject: O3 bootstraps fail on x86-64 O3 bootstraps have started to fail to build since about Thursday. Due to an internal compiler error when building asan.c in function asan_emit_stack_protectìon tree-ssa--sccan.c:3396 Graham
Re: [
Looks like it fixed an GO Libs failure as well I was having Original message From: Jeff Law Date: 29/10/2018 15:56 (GMT+00:00) To: Segher Boessenkool , Andrew Pinski Cc: GCC Patches Subject: Re: [ On 10/29/18 1:49 AM, Segher Boessenkool wrote: > On Mon, Oct 29, 2018 at 12:31:28AM -0700, Andrew Pinski wrote: >>> PR rtl-optimization/87701 >>> PR rtl-optimization/87780 >>> * combine.c (make_more_copies): Rewrite. >> >> I think a better changelog would be :): >> * combine.c (make_more_copies): Rewrite to be simplier. > > But it is not simpler at all now: *not* removing old notes while changing > RTL instructions is a very bad idea often; and modifying instructions > while not being very careful upsets DF. It may *look* simple now ;-) FWIW, it looks like cr16 ran to completion this morning :-) Jeff
Re: [PATCH 29/43] i386: Emulate MMX ssse3_pmaddubsw with SSE
what about testcases? for these
Original message
From: Uros Bizjak
Date: 10/02/2019 12:26 (GMT+00:00)
To: "H.J. Lu"
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 29/43] i386: Emulate MMX ssse3_pmaddubsw with SSE
On 2/10/19, H.J. Lu wrote:
> Emulate MMX ssse3_pmaddubsw with SSE. Only SSE register source operand
> is allowed.
>
> PR target/89021
> * config/i386/sse.md (ssse3_pmaddubsw): Add SSE emulation.
OK.
Uros.
> ---
> gcc/config/i386/sse.md | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 4bcfd3fc272..8b13a76da72 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -15666,17 +15666,17 @@
> (set_attr "mode" "TI")])
>
> (define_insn "ssse3_pmaddubsw"
> - [(set (match_operand:V4HI 0 "register_operand" "=y")
> + [(set (match_operand:V4HI 0 "register_operand" "=y,x,Yv")
> (ss_plus:V4HI
> (mult:V4HI
> (zero_extend:V4HI
> (vec_select:V4QI
> - (match_operand:V8QI 1 "register_operand" "0")
> + (match_operand:V8QI 1 "register_operand" "0,0,Yv")
> (parallel [(const_int 0) (const_int 2)
> (const_int 4) (const_int 6)])))
> (sign_extend:V4HI
> (vec_select:V4QI
> - (match_operand:V8QI 2 "nonimmediate_operand" "ym")
> + (match_operand:V8QI 2 "nonimmediate_operand" "ym,x,Yv")
> (parallel [(const_int 0) (const_int 2)
> (const_int 4) (const_int 6)]
> (mult:V4HI
> @@ -15688,13 +15688,17 @@
> (vec_select:V4QI (match_dup 2)
> (parallel [(const_int 1) (const_int 3)
> (const_int 5) (const_int 7)]))]
> - "TARGET_SSSE3"
> - "pmaddubsw\t{%2, %0|%0, %2}"
> - [(set_attr "type" "sseiadd")
> + "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
> + "@
> + pmaddubsw\t{%2, %0|%0, %2}
> + pmaddubsw\t{%2, %0|%0, %2}
> + vpmaddubsw\t{%2, %1, %0|%0, %1, %2}"
> + [(set_attr "mmx_isa" "native,x64_noavx,x64_avx")
> + (set_attr "type" "sseiadd")
> (set_attr "atom_unit" "simul")
> (set_attr "prefix_extra" "1")
> (set (attr "prefix_rex") (symbol_ref "x86_extended_reg_mentioned_p
> (insn)"))
> - (set_attr "mode" "DI")])
> + (set_attr "mode" "DI,TI,TI")])
>
> (define_mode_iterator PMULHRSW
> [V4HI V8HI (V16HI "TARGET_AVX2")])
> --
> 2.20.1
>
>
Re: [PATCH 12/43] i386: Emulate MMX vec_dupv2si with SSE
All these patches from HJL have no testcases. Are they even sutable for gcc 9
at this stage
Original message
From: Uros Bizjak
Date: 11/02/2019 12:51 (GMT+00:00)
To: "H.J. Lu"
Cc: GCC Patches
Subject: Re: [PATCH 12/43] i386: Emulate MMX vec_dupv2si with SSE
On Mon, Feb 11, 2019 at 1:26 PM H.J. Lu wrote:
>
> On Sun, Feb 10, 2019 at 11:25 PM Uros Bizjak wrote:
> >
> > On Mon, Feb 11, 2019 at 2:04 AM H.J. Lu wrote:
> > >
> > > On Sun, Feb 10, 2019 at 1:49 PM Uros Bizjak wrote:
> > > >
> > > > On Sun, Feb 10, 2019 at 10:45 PM Uros Bizjak wrote:
> > > >
> > > > > > > > + [(const_int 0)]
> > > > > > > > +{
> > > > > > > > + /* Emulate MMX vec_dupv2si with SSE vec_dupv4si. */
> > > > > > > > + rtx op0 = gen_rtx_REG (V4SImode, REGNO (operands[0]));
> > > > > > > > + rtx insn = gen_vec_dupv4si (op0, operands[1]);
> > > > > > > > + emit_insn (insn);
> > > > > > > > + DONE;
> > > > > > >
> > > > > > > Please write this simple RTX explicitly in the place of
> > > > > > > (const_int 0) above.
> > > > > >
> > > > > > rtx insn = gen_vec_dupv4si (op0, operands[1]);
> > > > > >
> > > > > > is easy. How do I write
> > > > > >
> > > > > > rtx op0 = gen_rtx_REG (V4SImode, REGNO (operands[0]));
> > > > > >
> > > > > > in place of (const_int 0)?
> > > > >
> > > > > [(set (match_dup 2)
> > > > > (vec_duplicate:V4SI (match_dup 1)))]
> > > > >
> > > > > with
> > > > >
> > > > > "operands[2] = gen_rtx_REG (V4SImode, REGNO (operands[0]));"
> > > > >
> > > > > or even better:
> > > > >
> > > > > "operands[2] = gen_lowpart (V4SImode, operands[0]);"
> > > > >
> > > > > in the preparation statement.
> > > >
> > > > Even shorter is
> > > >
> > > > "operands[0] = gen_lowpart (V4SImode, operands[0]);"
> > > >
> > > > and use (match_dup 0) instead of (match_dup 2) in the RTX.
> > > >
> > > > There is plenty of examples throughout sse.md.
> > > >
> > >
> > > This works:
> > >
> > > (define_insn_and_split "*vec_dupv2si"
> > > [(set (match_operand:V2SI 0 "register_operand" "=y,x,Yv")
> > > (vec_duplicate:V2SI
> > > (match_operand:SI 1 "register_operand" "0,0,Yv")))]
> > > "TARGET_MMX || TARGET_MMX_WITH_SSE"
> > > "@
> > > punpckldq\t%0, %0
> > > #
> > > #"
> > > "TARGET_MMX_WITH_SSE && reload_completed"
> > > [(set (match_dup 0)
> > > (vec_duplicate:V4SI (match_dup 1)))]
> > > "operands[0] = gen_rtx_REG (V4SImode, REGNO (operands[0]));"
> > > [(set_attr "mmx_isa" "native,x64_noavx,x64_avx")
> > > (set_attr "type" "mmxcvt,ssemov,ssemov")
> > > (set_attr "mode" "DI,TI,TI")])
> >
> > If it works, then gen_lowpart is preferred due to extra checks.
> > However, it would result in a paradoxical subreg, so I wonder if these
> > extra checks allow this transformation.
>
> gen_lowpart dosn't work:
Ah, we need lowpart_subreg after reload.
Uros.
