Re: [PATCH 4/4] bb-reorder: convert to gcc_stablesort

Hi, On Tue, 28 Aug 2018, Alexander Monakov wrote: > > I think your proposed one > > warrants some comments. Maybe trade speed for some clearer code? > > I think it's not too complicated, but how about adding this comment: > > profile_count m = c1.max (c2); > /* Return 0 if counts are

Re: Questions related to creation of libgcov.so

Hi, On Fri, 24 Aug 2018, Martin Liška wrote: > If I see correctly, for libgcc has following files: > > /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc_eh.a > /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a > /home/marxin/bin/gcc/lib64/libgcc_s.so.1 >

Re: Questions related to creation of libgcov.so

Hi, On Fri, 24 Aug 2018, Martin Liška wrote: > >> Where > >> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so > >> points to /home/marxin/bin/gcc/lib64/libgcov.so.1 ? > > > > Any symlinks need to be *relative*, not absolute, so the install tree > > is relocatable. There's

Re: [PATCH] print full STRING_CST in Gimple dumps (PR 87052)

Hi, On Thu, 23 Aug 2018, Richard Biener wrote: > > > Can you write a not \0 terminated string literal in C? > > > > Yes: char a[2] = "12"; > > I thought they are fully defined in translation phase #1 ... No, you can't write a string literal which is not zero terminated, because in translation

Re: Questions related to creation of libgcov.so

Hi, On Thu, 16 Aug 2018, Joseph Myers wrote: > On Thu, 16 Aug 2018, Michael Matz wrote: > > > > About the location of libgcov.{a,so}, I believe right place would be now: > > > > > > /home/marxin/bin/gcc/lib64/libgcov.so.1 > > > /home/marxin/bin/gcc/l

Re: Questions related to creation of libgcov.so

Hi, On Thu, 16 Aug 2018, Martin Liška wrote: > SHLIB_SOVERSION = 1 > SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) > > which would require a substitution for soversion, show I generalize even > so much? I wouldn't bother. libgcov.so.1 sounds just fine, and due to symbol versioning

Re: Questions related to creation of libgcov.so

Hi, On Tue, 14 Aug 2018, Martin Liška wrote: > I'm sending second version of the patch candidate. I was able to create > a mapfile and generate versioned symbols for libgcov.so file. > > Unresolved issues: > 1) I still see linking with static library: > > $ find /home/marxin/bin/gcc -name

Re: dejagnu version update?

Hi, On Wed, 8 Aug 2018, Bernhard Reutner-Fischer wrote: > How come? > > If one wants to develop on a distro that is notoriously outdated then > you have to obtain the missing pieces yourself. It's not about developing on an "notoriously outdated" distro, but about _testing_ on it. There are

Re: dejagnu version update?

Hi, On Wed, 8 Aug 2018, Bernhard Reutner-Fischer wrote: > How come? > > If one wants to develop on a distro that is notoriously outdated then > you have to obtain the missing pieces yourself. It's not about developing on an "notoriously outdated" distro, but about _testing_ on it. There are

Re: [RFC] Adding Python as a possible language and it's usage

Hi, On Fri, 27 Jul 2018, Joseph Myers wrote: > I would have expected most concerns to be about builds on non-GNU hosts - > not about builds on GNU/Linux where Python is generally already available > (and differences in Python versions should definitely *not* affect the > generated output, so

Re: [RFC] Adding Python as a possible language and it's usage

Hi, On Fri, 27 Jul 2018, Michael Matz wrote: > Using any python scripts as part of generally building GCC (i.e. where > the generated files aren't prepackaged) will introduce a python > dependency for distro packages. And for those distros that bootstrap a > core cycle of p

Re: [RFC] Adding Python as a possible language and it's usage

Hi, On Tue, 17 Jul 2018, Martin Liška wrote: > 1) gcc/optc-save-gen.awk is full of copy code, due to lack of flags > type classes multiple > global variables are created (var_opt_char, var_opt_string, ...) > > 2) similar happens in gcc/opth-gen.awk > > 3) we do very many regex matches (mainly

Re: Invalid program counters and unwinding

Hi, On Mon, 2 Jul 2018, Jakub Jelinek wrote: > > I disagree. ASM code often lacks unwind descriptors (now less than in > > the past, but still). My rule of thumb is always: no descriptor -> > > has to be a framepointer-using routine with standard calling sequence. > > (I.e. declare the

Re: Invalid program counters and unwinding

Hi, On Thu, 28 Jun 2018, Jeff Law wrote: > I believe "dumb" is referring to the fact that we're already in a bit of > a weird state as evidenced by the NULL FDE. Blindly trying to read the > contents of the PC that we couldn't map to an FDE is, IMHO, dumb. > > One might even be able to argue

Re: [PATCH][RFC] Add dynamic edge/bb flag allocation

Hi, On Wed, 23 May 2018, Richard Biener wrote: > > alloc_flags (>cfg->bb_flag_pool); > > alloc_flags (>cfg->edge_flag_pool); > > You'll end up with sth like > >alloc_flags flag (BB_FLAG_POOL_FOR_FN (cfun)); > > then, mixing C++ RAII and macros! (eh) First: I don't see the

Re: [PATCH][RFC] Add dynamic edge/bb flag allocation

Hi, On Wed, 23 May 2018, Eric Botcazou wrote: > > Maybe you should convert the thing to a template when the need arises > > instead of before? You have now added 54 lines of code for wrapping an > > int! > > Yeah, it took me 5 minutes to understand what all this fluff is about! So, what I

Re: Auto-generated .rodata contents and __attribute__((section))

Hi, On Fri, 18 May 2018, Richard Biener wrote: > Interesting. Do they allow merging across such sections? Consider a 8 > byte entity 0x12345678 and 4 byte entities 0x1234 0x5678, will the 4 > byte entities share the rodata with the 8 byte one? There's no language to forbid this (as long as

Re: [PATCH][RFC] Add dynamic edge/bb flag allocation

Hi, On Wed, 23 May 2018, Richard Biener wrote: > > I messed up the conversion to a template. The bitnum should be > > subtracted from HOST_BITS_PER_WIDE_INT and yes, 1 in unsigned hwi > > should be shifted. Maybe you should convert the thing to a template when the need arises instead of

Re: Auto-generated .rodata contents and __attribute__((section))

Hi, On Wed, 16 May 2018, Richard Biener wrote: > > Are constant pool entries merged at compile time or at link time? I > > would presume it should be done at link time because otherwise you're > > only merging entries within a single compilation unit (which doesn't > > sound that useful in a

Re: [PATCH 0/2] Require that constraints are used to reference global regs

Hi, On Tue, 1 May 2018, Jeff Law wrote: > The very nature of a traditional asm implies that it can read or write > anything visible to compiler. We can't realistically peek inside to see > what's happening and the user hasn't provided appropriate dataflow > information. One could make the

Re: [PATCH 0/2] Require that constraints are used to reference global regs

Hi, On Tue, 24 Apr 2018, Alexander Monakov wrote: > On Tue, 24 Apr 2018, Michael Matz wrote: > > What is lost here (it wasn't explicit before, but is the case and must > > continue to work) is that function calls and returns count as needing the > > observable value in t

Re: [PATCH 0/2] Require that constraints are used to reference global regs

Hi, On Tue, 24 Apr 2018, Alexander Monakov wrote: > On Tue, 24 Apr 2018, Michael Matz wrote: > > Well, documentation is both: a description and specification. If we > > change the documentation now we might not be in the position anymore to > > change behaviour and doc

Re: [PATCH 0/2] Require that constraints are used to reference global regs

Hi, On Tue, 24 Apr 2018, Alexander Monakov wrote: > > Sure but even for that we need to decide if we want to go that or the > > opposite way, and that's not easy when a deadline is lurking behind > > you. > > I am surprised there is any question. Even gcc-3.4 optimizes reg vars > over asms,

Re: [PATCH 0/2] Require that constraints are used to reference global regs

Hi, On Tue, 24 Apr 2018, Alexander Monakov wrote: > On Mon, 23 Apr 2018, Michael Matz wrote: > > Sooo, hmm, I don't know ;-) We could try doing a roll backwards and > > demand explicit dependencies from asms with unknown effects on the few > > unknown users, though the t

Re: [PATCH 0/2] Require that constraints are used to reference global regs

Hi, On Mon, 23 Apr 2018, Alexander Monakov wrote: > I don't see how a user reading the documentation could infer that asms > and global reg vars interact like you say. That was always my interpretation of this clause (old docu, the current bullet list seems to have removed some clarity) and

Re: [PATCH 0/2] Require that constraints are used to reference global regs

Hi, On Mon, 23 Apr 2018, Alexander Monakov wrote: > In discussion of proposed fix for PR 44281 Michael said: > [ https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01963.html ] > > [...] What I mean to say is, the following is currently proper use of > > global reg vars: > > > > > > register

Re: Dealing with default recursive procedures in Fortran

Hi, On Thu, 12 Apr 2018, Thomas König wrote: > with Fortran 2018, recursive is becoming the default. This will likely > have a serious impact on many user codes, which often declare large > arrays which could then overflow stacks, leading to segfaults without > further explanation. -fopenmp

Re: Fix -Wstringop-overflow regression

Hi, On Wed, 4 Apr 2018, Richard Biener wrote: > Bootstrapped and tested ...? Err, yes, on x86-64, with all languages and without regressions. > OK. r259083. Ciao, Michael.

Fix -Wstringop-overflow regression

Hi, we shouldn't claim string overflows for character arrays at end of structures; the code that tries to avoid these accidentally passed the address of the accessed member to array_at_struct_end_p(), but that one wants the component_ref or array_ref itself. Needs updating of one testcase that

Re: [PATCH] S/390: Set ABI default based on uname

Hi, On Tue, 20 Mar 2018, Andreas Krebbel wrote: > On 03/13/2018 04:53 PM, Michael Matz wrote: > > Hi, > > > > On Tue, 13 Mar 2018, Andreas Krebbel wrote: > > > >> Leaving history aside don't you agree that it would have been more > >> sensible to

Re: [PATCH] Fix ICE in match_asm_constraints_1 (PR inline-asm/84941)

Hi, On Tue, 20 Mar 2018, Jakub Jelinek wrote: > It is very common that input is one of the above cases, during x86_64-linux > and i686-linux bootstraps+regtests I got: > 13201x CONST_INT, 1959x MEM, 114x SUBREG, 110x SYMBOL_REF, > 2x PLUS (the new testcase only) > and most of those were actually

Re: [PATCH] Fix ICE in match_asm_constraints_1 (PR inline-asm/84941)

Hi, On Mon, 19 Mar 2018, Jakub Jelinek wrote: > > Blaeh. Note that "1p" is actually invalid: > > > > -- > > `0', `1', `2', ... `9' > > An operand that matches the specified operand number is allowed. > > If a digit is used together with letters within the same > >

Re: [PATCH] Fix ICE in match_asm_constraints_1 (PR inline-asm/84941)

Hi, On Mon, 19 Mar 2018, Jakub Jelinek wrote: > The inline-asm here has "1p" constraint and we end up with > (plus (frame) (const_int ...)) Blaeh. Note that "1p" is actually invalid: -- `0', `1', `2', ... `9' An operand that matches the specified operand number is allowed.

Re: [PATCH] S/390: Set ABI default based on uname

Hi, On Tue, 13 Mar 2018, Andreas Krebbel wrote: > Leaving history aside don't you agree that it would have been more > sensible to require a -m option only if you want to build for an ABI > different from what is currently mandated by the personality setting? I agree with you. But we can't

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

Hi, On Thu, 8 Mar 2018, Richard Biener wrote: > Or re-do the warning? Since in the other thread about setjmp side-effects > we concluded that setjmp has to preserve all call-saved regs? Even worse. On SPARC setjmp clobbers even more than just call-clobbered regs (!). Ciao, Michael.

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

Hi, On Wed, 7 Mar 2018, Peter Bergner wrote: > On 3/7/18 12:01 AM, Jeff Law wrote: > > I believe so by nature that the setjmp dominates the longjmp sites and > > thus also dominates the dispatcher. But it's something I want to > > explicitly check before resubmitting. > > Are we sure a setjmp

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

Hi, On Tue, 6 Mar 2018, Richard Biener wrote: > > bb1 > > ret = setjmp(buf) > >| \ bb-recv > >|\ > >|ret = setjmp_receiver > >|/ > > normal /---/ > > path/ > >| /

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

Hi, On Mon, 5 Mar 2018, Jeff Law wrote: > >>> Actually, without further conditions I don't see how it would be safe > >>> for the successor to have multiple preds. We might have this > >>> situation: > >>> > >>> bb1: ret = setjmp > >>> bb2: x0 = phi > >> No. Can't happen -- we're still

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

Hi, On Mon, 5 Mar 2018, Jeff Law wrote: > >> The single successor test was strictly my paranoia WRT abnormal/EH > >> edges. > >> > >> I don't immediately see why the CFG would be incorrect if the > >> successor of the setjmp block has multiple preds. > > > > Actually, without further

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

Hi, On Wed, 28 Feb 2018, Jeff Law wrote: > The single successor test was strictly my paranoia WRT abnormal/EH edges. > > I don't immediately see why the CFG would be incorrect if the successor > of the setjmp block has multiple preds. Actually, without further conditions I don't see how it

Re: [RFC] Tree loop unroller pass

Hi, On Fri, 16 Feb 2018, Wilco Dijkstra wrote: > > How so? > > I thought it is well-known for many years that the rtl unroller doesn't > work properly. In practically all cases where LLVM beats GCC, it is due > to unrolling small loops. I thought it was because of vectorizing at -O2, not due

Re: how to make GCC option hook aware

Hi, On Sat, 17 Feb 2018, Andre Groenewald wrote: > Hi GCC folks, > > I have implemented a function for LANG_HOOKS_HANDLE_OPTION for my toy > language front end to handle options. > > The specific option is populated in lang.opt as fdemo-debug > > My lang-specs file has the following:

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

Hi, On Mon, 12 Feb 2018, Martin Sebor wrote: > >> Removing noreturn from the whitelist means having to prevent > >> the attribute from causing conflicts with the attributes on > >> the blacklist. E.g., in this: > >> > >> template [[malloc]] void* allocate (int); > >> > >> template <>

Re: gdb 8.x - g++ 7.x compatibility

Hi, On Wed, 7 Feb 2018, Simon Marchi wrote: > On 2018-02-07 12:30, Jonathan Wakely wrote: > >> Ah ok, the class name appears mangled in other entities' mangled name. But > >> from what I understand there's no mangled name for the class such that > >> > >> echo | c++filt > >> > >> outputs

Re: gdb 8.x - g++ 7.x compatibility

Hi, On Wed, 7 Feb 2018, Simon Marchi wrote: > This addresses the issue of how to do good software design in GDB to > support different producers cleanly, but I think we have some issues > even before that, like how to support g++ 7.3 and up. I'll try to > summarize the issue quickly. It's

Re: Unstable build/host qsorts causing differing generated target code

Hi, On Fri, 12 Jan 2018, Joseph Myers wrote: > On Fri, 12 Jan 2018, Alexander Monakov wrote: > > > No. The qsort_chk effort was limited to catching instances where comparators > > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or > > transitivity property (may indicate A < B

Re: [PATCH 1/5] x86: Add -mindirect-branch=

Hi, On Mon, 8 Jan 2018, Woodhouse, David wrote: > > > That can be done via asm aliases or direct assembler use; the kernel > > > doesn't absolutely have to access them via C compatible symbol names. > > > > > Hi David, > > > > Can you comment on this? > > It ends up being a real pain for the

Re: [PATCH 1/5] x86: Add -mindirect-branch=

Hi, On Mon, 8 Jan 2018, H.J. Lu wrote: > On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek wrote: > > On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote: > >> > I'm wondering whether thunk creation can be a good target-independent > >> > generalization? I guess > >> > we can

Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre

Hi, On Mon, 8 Jan 2018, Jakub Jelinek wrote: > On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote: > > See: > > > > https://sourceware.org/ml/binutils/2017-11/msg00369.html > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD

Re: Who generate .rela.debug_info?

Hi, On Mon, 18 Dec 2017, Nancy wrote: > tls.c: > __thread int i=10; > > $gcc -g -c -save-temps tls.c > $readelf -r tls.o > Relocation section '.rela.debug_info' at offset 0x2d0 contains 6 entries: > Offset Info Type Sym. ValueSym. Name + > Addend >

Re: [PATCH PR81740]Enforce dependence check for outer loop vectorization

Hi, On Mon, 18 Dec 2017, Richard Biener wrote: > where *unroll is similar to *max_vf I think. dist_v[0] is the innermost loop. [0] is always outermost loop. > The vectorizer does way more complicated things and only looks at the > distance with respect to the outer loop as far as I can see

Re: [PATCH] vrp_prop: Use dom_walker for -Warray-bounds (PR tree-optimization/83312)

Hi, On Tue, 12 Dec 2017, David Malcolm wrote: > There didn't seem to be a pre-existing way to determine the unique > out-edge after a GIMPLE_COND (if it has a constant cond), so I added > a new gimple_cond_get_unique_successor_edge function. Similarly, > something similar may apply for

Re: Fix PR83323 (crafty miscompile by unroll-and-jam)

Hi, On Fri, 8 Dec 2017, Richard Biener wrote: > OK. > Don't you need to adjust existing unroll and jam testcases? Ahem... that's at least what the regression testing told me as well :) Fixed in what I checked in (the only testcase we had was the one I added yesterday) Ciao, Michael.

Fix PR83323 (crafty miscompile by unroll-and-jam)

Hi, the predicate for feasiblity of unroll-and-jam was a bit nonsensical. Properly check for non-head-controlled loops, and also check all BBs of the outer loop for any instructions that would inhibit fusion (before we never checked header or latch). Richi also asked me to reuse the

Re: Add unroll-and-jam pass v2

d that). So if the input sibling list is in program order (e.g. if there's only one inner loop) then the output after unrolling will be as well. So I can now get rid of reverse_list. Regstrapped on trunk on x86_64-linux, okay? Ciao, Michael. commit 9445396f7af85017a70403471d82e9cb0c674f08 Auth

Re: [GCC 9][RFC][PATCH] Optimize PHIs with constant arguments better

Hi, On Thu, 30 Nov 2017, Jeff Law wrote: > And after PHI propagation we have: > # m_5 = PHI <10(5), 12(6), 14(7)> > # _2 = PHI <10(5), 12(6), 14(7)> > # _3 = PHI <320(5), 384(6), 448(7)> > : > goto ; [100.00%] > > DCE will come along and wipe out m_5 and _2 if they are unused. When I

Re: [PATCH] final: Improve output for -dp and -fverbose-asm

Hi, On Thu, 30 Nov 2017, David Malcolm wrote: > -fverbose-asm is on the border of compiler-debugging vs end-user usage. I have yet to see a relevant percentage of end-users who even know what assembler is. On the gcc.*@ and kernel.* mailing lists, sure. But Joe Randomapp? > FWIW an

Re: [PATCH] final: Improve output for -dp and -fverbose-asm

Hi, On Thu, 30 Nov 2017, Martin Sebor wrote: > adddi3_imm_carry_m1 seems (mostly) self-explanatory since it's built up > of common assembly mnemonics. I confess I don't know what the number > after # means, either on powerpc64 or on any other target. insn uid. > > Or, for that matter, what

Re: [PATCH] final: Improve output for -dp and -fverbose-asm

Hi, On Thu, 30 Nov 2017, Martin Sebor wrote: > > addic 4,9,-1 # 70 [c=4 l=4] *adddi3_imm_carry_m1 > > subfe 4,4,9 # 71 [c=4 l=4] *subfdi3_carry_in_internal > > b .L5# 81 [c=4 l=4] jump > > Not everyone who reads the verbose assembly is

Re: [PATCH] final: Improve output for -dp and -fverbose-asm

Hi, On Thu, 30 Nov 2017, Kyrill Tkachov wrote: > I don't know what rldicl means without looking it up on the Internet ;) :) (zero_extendsidi2/1 it seems, from Seghers dump, not that I would have known without) > Given how frequently I have to look at these dumps, I could get used to > any

Re: [PATCH] final: Improve output for -dp and -fverbose-asm

Hi, On Thu, 30 Nov 2017, Kyrill Tkachov wrote: > > This improves the assembler output (for -dp and -fverbose-asm) in > > several ways. It always prints the insn_cost. It does not print > > "[length = NN]" but "[c=NN l=NN]", to save space. It does not add one > > to the instruction

Re: [PATCH] final: Improve output for -dp and -fverbose-asm

Hi, On Thu, 30 Nov 2017, Segher Boessenkool wrote: > > [c=NN l=NN] will be meaningless to those without some deeper insight > > into/experience with what's actually being printed. It might as well > > say [NN NN]. But such extreme terseness would > > Length isn't printed on all targets,

Re: Add optabs for common types of permutation

Hi, On Thu, 23 Nov 2017, Richard Sandiford wrote: > > I don't want variable-size vector special-casing everywhere. I want > > it to be somehow naturally integrating with existing stuff. > > It's going to be a special case whatever happens though. It wouldn't have to be this way. It's like

Re: [RFC][PATCH] Change default to -fcommon

Hi, On Tue, 21 Nov 2017, Richard Biener wrote: > > That would be a simple oversight then. That's one of the nice things > > with common symbols, they contain their own alignment which you can > > freely adjust, you don't have to care for something like section > > alignment. > > You can't

Re: [RFC][PATCH] Change default to -fcommon

Hi, On Mon, 20 Nov 2017, Richard Biener wrote: > Also we cannot raise alignment of commons and thus vectorization is > pessimized (all vectorizer testcases use - fno-common). That would be a simple oversight then. That's one of the nice things with common symbols, they contain their own

Re: [RFC][PATCH] Change default to -fcommon

Hi, On Mon, 20 Nov 2017, Sandra Loosemore wrote: > > I have a hard time imaging that, so can you give details? FWIW I've > > personally always considered using common symbols nicer. > > The optimization case I'm familiar with is for targets that support -G > and GP-relative addressing modes

Re: [RFC][PATCH] Change default to -fcommon

Hi, On Mon, 20 Nov 2017, Wilco Dijkstra wrote: > > Note you have to make sure GFortran still works! So I think the patch > > should be changed to make the default behavior be frontend dependent > > or have a fortran/ adjustment that fixes things up for the fortran > > dialects that need it.

Add unroll-and-jam pass v2

x86-64-linux with all languages+Ada (on a two weeks old trunk, retesting in progress). Okay for trunk? Ciao, Michael. commit 7bc718fa3476f7f6f72c2220cba288458fd1406e Author: Michael Matz <m...@suse.de> Date: Fri Nov 17 13:49:39 2017 +0100 Add unroll and jam pass * gimple-lo

Re: [RFC, PR 80689] Copy small aggregates element-wise

Hi, On Mon, 13 Nov 2017, Richard Biener wrote: > The chance here is, of course (find the PR, it exists...), that SRA then > decomposes the char[] copy bytewise... > > That said, memcpy folding is easy to fix. The question is of course > what the semantic of VIEW_CONVERTs is (SRA _does_

Re: [RFC, PR 80689] Copy small aggregates element-wise

Hi, On Mon, 13 Nov 2017, Richard Biener wrote: > The main concern here is that GIMPLE is not very well defined for > aggregate copies and that gimple-fold.c happily optimizes > memcpy (, , sizeof (a)) into a = b; What you missed to mention is that we then discussed about rectifying this

Re: Question about generated type for common block in fortran

Hi, On Thu, 9 Nov 2017, Bin.Cheng wrote: > So I have two questions here. > A) Is this special kind union type only generated by fortran FE for > equivalence+common? It's not special in that it isn't marked in any way. For all purposes it's a normal union type with surprising field(offset)s.

Re: Question about generated type for common block in fortran

Hi, On Wed, 8 Nov 2017, Richard Biener wrote: > Not sure how - the issue is the FIELD_DECLs overlap which rules out a > RECORD_TYPE and leaves us with a UNION_TYPE. No, as the initial mail already mentioned, for the example in question the overlapping fields can be put into a union which

Re: Question about generated type for common block in fortran

Hi, On Thu, 26 Oct 2017, Richard Biener wrote: > >Hi, > >I am looking into DSE transformation of some fortran codes. Given > >below fortran declarations: > > > > real*8 a(len) , b(len) , c(len) , d(len) > > common /area/ a, b, c, d > > real*8 src1(len), temp1(len),

Re: [RFC] [Patch X86_64]: Pass to split FMA to MUL and ADD

Hi, On Tue, 7 Nov 2017, Richard Biener wrote: > > With FMA however the situation is different becuase there are rounding > > differences. Why we can convert multiplicatoin+add into FMA without > > -ffast-math at first place? > > We do with -ffp-contract=fast which is the default for C. But

Re: [RFC, PR 80689] Copy small aggregates element-wise

Hi, On Thu, 26 Oct 2017, Martin Jambor wrote: > > 35 bytes seems to be much - what is the code-size impact? > > I will find out and report on that. I need at least 32 bytes (four > long ints) to fix imagemagick, where the problematic structure is: Surely the final heuristic should look at the

Re: [PATCH GCC]A simple implementation of loop interchange

Hello, On Fri, 22 Sep 2017, Bin.Cheng wrote: > This is updated patch for loop interchange with review suggestions > resolved. Changes are: > 1) It does more light weight checks like rectangle loop nest check > earlier than before. > 2) It checks profitability of interchange before data

Re: [PATCH] Include from system.h (PR bootstrap/82610)

Hi, On Mon, 23 Oct 2017, David Malcolm wrote: > FWIW, this one isn't from #pragma poison, it's from: > #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__) > > (I messed up the --in-reply-to when posting the patch, but Gerald noted > the issue was due to: >

Re: [PATCH] Include from system.h (PR bootstrap/82610)

Hi, On Mon, 23 Oct 2017, Richard Biener wrote: > I guess so. But we have to make gdb happy as well. It really depends how > much each TU grows with the extra (unneeded) include grows in C++11 and > C++04 mode. The c++ headers unconditionally included from system.h, with: % echo '#include

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

Hi, On Wed, 18 Oct 2017, Segher Boessenkool wrote: > Certainly. And to work around the bug, it should work to mention some > hard register as asm input. Ideally something that is live anyway; > perhaps the stack pointer :-) Like so: > > __asm volatile ("mrs %0,PRIMASK" : "=r" (status) ::

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Jeff Law wrote: > > asm ("" : "=r" (x) : "r" (y+z)); > > asm ("" : "=r" (x) : "r" (z)); > > asm ("" : "=r" (x) : "r" (42)); > > > > > (are we still agreeing on this? I'm having a problem understanding why > > you think the above wouldn't work) > > How do we

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Michael Matz wrote: > On Mon, 28 Aug 2017, Jeff Law wrote: > > > I can't remember matching constraints ever working that way. > > They do work exactly so. FWIW, I was momentarily worried that there once was a world where you were right. If so (a

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Paul S wrote: > I've ported gcc to a 16 bit CPU and have all torture tests passing bar one, > pr52286.c > > The offending lines of code are > > long a, b = 0; > asm ("" : "=r" (a) : "0" (0)); > > > which should cause zero to be assigned to the "a" SI sized

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Jeff Law wrote: > I can't remember matching constraints ever working that way. They do work exactly so. These uses are all correct, though they place some random value into x: int x, y, z; y = z = init(); asm ("" : "=r" (x) : "r" (y+z)); asm ("" : "=r" (x) :

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Jeff Law wrote: > > long a, b = 0; > > asm ("" : "=r" (a) : "0" (0)); > I wouldn't use a matching constraint here. Something like this is > probably closer to what you want: > > asm ("" : "=r" (a) : "n" (0)); > > The "n" says accept any immediate integer constant

Re: [C++ PATCH] Kill CLASSTYPE_SORTED_FIELDS

Hi, On Mon, 28 Aug 2017, Nathan Sidwell wrote: > This patch replaces the sorted field vector with a hash map. Lookup for > non-function members of a complete class is now O(1), not O(log(n)). > We still do linear lookup when the class is incomplete. Fixing that is > still on the todo list.

Re: Optimization breaks inline asm code w/ptrs

Hi, On Mon, 14 Aug 2017, Alan Modra wrote: > I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to track > the lack of documentation. You mean like in this paragraph discussing memory clobbers and uses in extended asms that we have since 2004? : If your

Re: [PATCH] i386: Don't use frame pointer without stack access

Hi, On Wed, 9 Aug 2017, H.J. Lu wrote: > > OK, but then both -f[no-]omit-frame-pointer do not have clearly defined > > semantics and thus shouldn't be exposed to the user? > > -f[no-]omit-frame-pointer apply to cases where a new stack frame > is needed. -fno-omit-frame-pointer allows you to

Re: [PATCH] i386: Don't use frame pointer without stack access

Hi, On Mon, 7 Aug 2017, Arjan van de Ven wrote: > I'm not surprised to see one. > I'm surprised to see a useless one. > > The "perf" benefit is real, and that's why I asked for one... but the reorder > made it an expensive 3 instruction nop for all intents and purposes. > If the pop was just

Re: [PATCH] i386: Don't use frame pointer without stack access

Hi, On Mon, 7 Aug 2017, Arjan van de Ven wrote: > wanting a framepointer is very nice and desired... > ... but if the optimizer/ins scheduler moves instructions outside of the > frame'd portion, > (it does it for cases like below as well), the value is already negative for > these > functions

Re: [PATCH] i386: Don't use frame pointer without stack access

Hi, On Mon, 7 Aug 2017, H.J. Lu wrote: > >> [hjl@gnu-tools-1 pr81736]$ > >> > >> Does it mean clang is broken? > > > > In my book, yes. > > Does GCC do this for all targets or just x86? No idea. If so I'd say those other targets are broken as well (as long as the concept of frame pointer

Re: [PATCH] i386: Don't use frame pointer without stack access

Hi, On Mon, 7 Aug 2017, H.J. Lu wrote: > >> This will break unwinders relying on frame pointers to exist on all > >> functions, for which projects conciously forced a frame pointer with this > >> option. I don't think we can simply override user specified explicit > >> wishes in this way,

Re: [PATCH] i386: Don't use frame pointer without stack access

Hi, On Mon, 7 Aug 2017, Uros Bizjak wrote: > On Sun, Aug 6, 2017 at 9:40 PM, H.J. Lu wrote: > > When there is no stack access, there is no need to use frame pointer > > even if -fno-omit-frame-pointer is used. > > > > Tested on i686 and x86-64. OK for trunk? > > LGTM.

Re: [PATCH] Move static chain and non-local goto init after NOTE_INSN_FUNCTION_BEG (PR sanitize/81186).

Hello, On Mon, 17 Jul 2017, Martin Liška wrote: > which does all the stack preparation (including the problematic call to > __asan_stack_malloc_N). > > Note that this code still should be placed before parm_birth_note as we > cant's say that params are ready before a fake stack is prepared.

Re: [PATCH] Move static chain and non-local goto init after NOTE_INSN_FUNCTION_BEG (PR sanitize/81186).

Hi, On Thu, 13 Jul 2017, Martin Liška wrote: > Hopefully following patch will fix that. I returned to the first version > and saved/restored static_chain register before/after > __asan_stack_malloc. It should also work if you emit the parm_birth_note after the static chain is set up (not

Re: [PATCH][RFA/RFC] Stack clash mitigation 0/9

Hello, On Tue, 11 Jul 2017, Jeff Law wrote: > This patch series is designed to mitigate the problems exposed by the > stack-clash exploits. As I've noted before, the way to address this > class of problems is via a good stack probing strategy. > > This has taken much longer than expected to

Re: [PATCH][AArch64] Fix ILP32 memory access

Hi, On Tue, 4 Jul 2017, Wilco Dijkstra wrote: > > You'll probably also have to set GNATBIND and GNATMAKE to the > > appropriately suffixed variants.  Just saying, because that's what I'm > > usually forgetting and end up with strange errors :) > > Configure seems to be able to find

Re: [PATCH][AArch64] Fix ILP32 memory access

Hi, On Tue, 4 Jul 2017, Ramana Radhakrishnan wrote: > Yeah it turns out that on the machine Wilco was using, we are running > 14.04 which has a gcc 4.8 base compiler that didn't have Ada on for > AArch64. > > I think we can work around by installing a gcc-5 package and then > setting CC to

Re: [PATCH v9] add -fpatchable-function-entry=N,M option

Hi, On Tue, 4 Jul 2017, Michael Matz wrote: > I don't think so: get_insn_template() should always return strings in > .rodata, even for output statements, and should never point into GC > memory. Bah, ignore that. I should refetch mail before answering mid-thread ;) Ciao, Michael.

Re: [PATCH v9] add -fpatchable-function-entry=N,M option

Hello Richard, On Tue, 4 Jul 2017, Richard Earnshaw (lists) wrote: > > +void > > +default_print_patchable_function_entry (FILE *file, > > + unsigned HOST_WIDE_INT patch_area_size, > > + bool record_p) > > +{ > > + static const

Re: [PATCH] Move static chain and non-local goto init after NOTE_INSN_FUNCTION_BEG (PR sanitize/81186).

Hi, On Wed, 28 Jun 2017, Martin Liška wrote: > Thanks for the review. I'm not so familiar with RTL, but hopefully new > version of the patch should do it properly. Idea is to come up with a > new asan_stack_birth_insn that points after place where stack is ready > to use (when one uses

<    1   2   3   4   5   6   7   8   9   10   >