Re: comparing parallel test runs

On 05/17/2017 07:28 AM, Jonathan Wakely wrote: > On 17 May 2017 at 11:23, Aldy Hernandez wrote: >> Has anyone seen this behavior? Is it my test box? Are there known problems >> with parallel checks? > > Smells like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77684 > Yup. Note that I ack'd a p

Re: comparing parallel test runs

On 05/17/2017 04:23 AM, Aldy Hernandez wrote: > Hi folks. > > I've been having troubles comparing the results of different test runs > for quite some time, and have finally decided to whine about it. Perhaps > someone can point out to whatever I may be doing wrong. > > I generally do "make check

Re: Basic Block Statistics

On 05/17/2017 10:36 AM, Will Hawkins wrote: > As I started looking into this, it seems like PLUGIN_FINISH is where > my plugin will go. Everything is great so far. However, when plugins > at that event are invoked, they get no data. That means I will have to > look into global structures for inform

Re: git-svn error due to out-of-sync changes?

On 05/18/2017 11:41 AM, Martin Sebor wrote: > I just tried to push a change and got the error below. git > pull says my tree is up to date. I wonder if it's caused by > my commit conflicting with another commit (in this case > r248244) that git-svn doesn't see because it lags behind SVN. > I brus

Re: git-svn error due to out-of-sync changes?

On 05/18/2017 01:42 PM, Martin Sebor wrote: > On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote: >> On 2017.05.18 at 12:41 -0600, Martin Sebor wrote: >>> On 05/18/2017 11:59 AM, Jeff Law wrote: >>>> On 05/18/2017 11:41 AM, Martin Sebor wrote: >>>>> I

Re: git-svn error due to out-of-sync changes?

On 05/18/2017 02:06 PM, Markus Trippelsdorf wrote: > On 2017.05.18 at 13:42 -0600, Martin Sebor wrote: >> On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote: >>> On 2017.05.18 at 12:41 -0600, Martin Sebor wrote: >>>> On 05/18/2017 11:59 AM, Jeff Law wrote: >>>

Re: Basic Block Statistics

On 05/17/2017 08:22 PM, Will Hawkins wrote: > On Wed, May 17, 2017 at 2:59 PM, Will Hawkins wrote: >> On Wed, May 17, 2017 at 2:41 PM, Will Hawkins wrote: >>> On Wed, May 17, 2017 at 1:04 PM, Will Hawkins wrote: >>>> On Wed, May 17, 2017 at 1:02 PM, Jeff Law wrote

Re: Steering committee, please, consider using lzip instead of xz

On 06/07/2017 02:25 PM, Antonio Diaz Diaz wrote: > Dear GCC steering committee, > > This has been recently asked in this list[1], but in case you have > missed it because of a subject line not explicit enough, I would like to > appeal to you directly. > > [1] http://gcc.gnu.org/ml/gcc/2017-06/msg

Re: Steering committee, please, consider using lzip instead of xz

On 06/08/2017 03:27 AM, Antonio Diaz Diaz wrote: > Jeff Law wrote: >> We've got far more important items to tackle than this. But if you >> want me to bring it up formally with the SC I can. >> >> ps. And just to be clear, I actually don't like xz and

Re: Getting spurious FAILS in testsuite?

On 06/08/2017 04:24 AM, Christophe Lyon wrote: > On 8 June 2017 at 11:57, Georg-Johann Lay wrote: >> On 05.06.2017 18:25, Jim Wilson wrote: >>> >>> On 06/01/2017 05:59 AM, Georg-Johann Lay wrote: Hi, when I am running the gcc testsuite in $builddir/gcc then $ make check-gcc RUNTESTF

Re: Killing old dead bugs

On 07/02/2017 11:08 AM, Yuri Gribov wrote: > Hi all, > > What do I need to do to close an old bug which does not repro with > modern GCC and reporter does not care anymore (e.g. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528)? Also, is there > some general policy about closing old bugs? Idea

Re: x86 branches vs conditional moves

On 07/08/2017 01:31 AM, Yuri Gribov wrote: > On Sat, Jul 8, 2017 at 12:30 AM, Michael Clark wrote: >> Hi, >> >> Curious about this codegen: >> >> - https://godbolt.org/g/5XxP5S >> >> Why does gcc branch on _Bool, but emits a conditional move for an integer? >> can it emit cmovne instead of branch

Re: Add support to trace comparison instructions and switch statements

On 07/10/2017 06:07 AM, 吴潍浠(此彼) wrote: > Hi > > I write some codes to make gcc support comparison-guided fuzzing. > It is very like > http://clang.llvm.org/docs/SanitizerCoverage.html#tracing-data-flow . > With -fsanitize-coverage=trace-cmp the compiler will insert extra > instrumentation around

Re: Killing old dead bugs

On 07/17/2017 10:33 PM, NightStrike wrote: > On Mon, Jul 17, 2017 at 11:23 AM, Martin Sebor wrote: >> you did for the bugs below is ideal. Adding a test case if one >> doesn't exist in the test suite is also very useful, though quite >> a bit more work. > > Isn't a testcase always required? Requ

Re: Register allocation trouble

On 07/21/2017 05:50 AM, Andrew Stubbs wrote: > Hi all, > > I have an architecture that has two register files. Let's call them > class A and class B. There are some differences between their > capabilities, but for the purposes of this problem, they can be > considered to be identical, both holdin

Re: Register allocation trouble

On 07/21/2017 12:40 PM, Nathan Sidwell wrote: > On 07/21/2017 07:50 AM, Andrew Stubbs wrote: > >> (set (match_operand:SI "register_operand" "=a,b") >> (match_operand:SI "memory_operand" "Ra,Rb")) > > > How horrible would it be to split expose the entire mem: > > (set (match_operand:SI "

Re: Register allocation trouble

On 07/24/2017 11:37 AM, Georg-Johann Lay wrote: > Andrew Stubbs schrieb: >> On 24/07/17 14:58, Georg-Johann Lay wrote: >>> Dunno if that works in all situation. For example, when the register >>> allocator is facing high register pressure and decides to spill the >>> target register, it uses the c

Re: Volatile Memory accesses in Branch Delay Slots

On 07/25/2017 06:32 AM, Oleg Endo wrote: > On Tue, 2017-07-25 at 10:47 +0200, Jakob Wenzel wrote: >> >> jr's delay slot is not filled. However, if the declaration of a is >> changed to `extern int a`, the delay slot is filled with the sw. >> >> The function responsible for this behavior seems to

Re: [patch] RFC: Hook for insn costs?

On 07/17/2017 02:35 PM, Richard Henderson wrote: > On 07/17/2017 12:20 AM, Richard Biener wrote: >> On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool >>> Now what should it take as input? An rtx_insn, or just the pattern >>> (as insn_rtx_cost does)? >> >> Is there any useful info on the other o

Re: Overwhelmed by GCC frustration

On 07/31/2017 10:49 AM, Joel Sherrill wrote: > > > On 7/31/2017 11:12 AM, Oleg Endo wrote: >> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote: >>> Around 2010, someone who used a code snipped that I published in >>> a wiki, reported that the code didn't work and hang in an >>> endless l

Re: Overwhelmed by GCC frustration

On 07/31/2017 11:23 AM, Segher Boessenkool wrote: > On Tue, Aug 01, 2017 at 01:12:41AM +0900, Oleg Endo wrote: >> I could probably write a similar rant. This is the life of a "minority >> target programmer". Most development efforts are being done with >> primary targets in mind. And as a result

Re: GCC Runtime Library Exception in gcc/config/* files?

On 07/21/2017 12:14 PM, Georg-Johann Lay wrote: > Sebastian Huber schrieb: >> Hello, >> >> there are some files in gcc/config/* that contain the GCC Runtime >> Library Exception >> >> grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l >> gcc/config | wc >> 186 1865361 >> >> a

Re: [patch] RFC: Hook for insn costs?

On 08/02/2017 01:34 PM, Richard Earnshaw wrote: > On 26/07/17 18:54, Jeff Law wrote: >> On 07/17/2017 02:35 PM, Richard Henderson wrote: >>> On 07/17/2017 12:20 AM, Richard Biener wrote: >>>> On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool >>>>> N

Re: RFC [testsuite] Obey --load-average

On 08/02/2017 11:34 PM, Daniel Santos wrote: > I'm working on a patch to modify the testsuite to obey the > --load-average value if one is passed to make. It seems to work pretty > well, except for libstdc++ which doesn't load gcc/libs/gcc-defs.exp > since it defines it's own ${tool}_functions. I

Re: Upstreaming very old changes

On 08/04/2017 11:20 AM, co...@sdf.org wrote: > Hi, GCC! > > I believe netbsd is the primary user of the vax target. its status is: > > good: netbsd uses gcc 5.4.0, and cross compiles its userland+kernel with > this. it runs and is also able to natively build useful programs like perl. > > bad: -

Re: What to do about all the gcc.dg/guality test failures?

On 08/08/2017 01:38 PM, Steve Ellcey wrote: > I was wondering if something needs to be done about the gcc.dg/guality tests. > > There are two main issues I see with these tests, one is that they are often > not run during testing and so failures do not show up. I looked into this > and found that

Re: [PATCH] Write dependency information (-M*) even if there are errors

On 08/06/2017 01:59 AM, Boris Kolpackov wrote: > Hi, > > Currently GCC does not write extracted header dependency information > if there are errors. However, this can be useful when dealing with > outdated generated headers that trigger errors which would have been > resolved if we could update it

Re: Overwhelmed by GCC frustration

On 08/16/2017 08:14 AM, Eric Botcazou wrote: >> Just the fact that the backends that get most attention and attract >> most developers don't use cc0 doesn't mean cc0 is a useless device. > > Everything that can be done with cc0 can be done with the new representation, > at least theoritically, al

Re: Optimizing away deletion of null pointers with g++

On 08/16/2017 08:44 AM, Jonathan Wakely wrote: > On 16 August 2017 at 15:40, Jonathan Wakely wrote: >> On 16 August 2017 at 15:27, Oleg Endo wrote: >>> On Wed, 2017-08-16 at 13:30 +0200, Paolo Carlini wrote: I didn't understand why we don't already handle the easy case: constexp

Re: Building on gcc112 is stuck in msgfmt

On 08/28/2017 01:16 AM, Martin Liška wrote: > Hello. > > I've just repeatedly seen stuck in build process: > > make[5]: Entering directory > `/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/libstdc++-v3/po' > msgfmt -o de.mo ../../../../libstdc++-v3/po/de.po > > 49__as

Re: gcc torture test pr52286.c

On 08/27/2017 09:33 PM, 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)); I wouldn't use a matching constraint here. Something like this is probably c

Re: gcc torture test pr52286.c

On 08/28/2017 11:33 AM, Michael Matz wrote: > 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

Re: gcc torture test pr52286.c

On 08/28/2017 11:56 AM, Michael Matz wrote: > 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

Re: operand_equal_p() and SSA_NAME

On 08/28/2017 08:46 PM, Martin Sebor wrote: > operand_equal_p() doesn't handle SSA_NAMEs and returns false for > operands in that form even when they have equal values (when both > are ADDR_EXPR of the same decl). Yet the function is extensively > relied on in the middle end where I would expect i

Re: operand_equal_p() and SSA_NAME

On 08/28/2017 09:46 PM, Andrew Pinski wrote: > On Mon, Aug 28, 2017 at 7:46 PM, Martin Sebor wrote: >> operand_equal_p() doesn't handle SSA_NAMEs and returns false for >> operands in that form even when they have equal values (when both >> are ADDR_EXPR of the same decl). Yet the function is exte

Re: Redundant sign-extension instructions on RISC-V

On 08/30/2017 06:52 AM, Richard Biener wrote: > On Wed, Aug 30, 2017 at 11:53 AM, Michael Clark wrote: >> >>> On 30 Aug 2017, at 9:43 PM, Michael Clark wrote: >>> > diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c > index ce632ae..25dd70f 100644 > --- a/gcc/simplify-rtx.c > ++

Re: Redundant sign-extension instructions on RISC-V

On 08/30/2017 12:34 AM, Michael Clark wrote: > >> On 30 Aug 2017, at 12:36 PM, Michael Clark wrote: >> >> Dear GCC folk, >> >> >> # Issue Background >> >> We’re investigating an issue with redundant sign-extension instructions >> being emitted with the riscv backend. Firstly I would like to stat

Re: Can we replace uses of vec with vec in the backwards threader?

On 08/30/2017 04:41 AM, Aldy Hernandez wrote: > Hi! > > I'm looking at tree-ssa-threadbackward.c, where we pass around a lot > of "vec" pointers representing a path through a > flow graph. > > I'm wondering why we use va_gc, when AFAICT, the paths are local to > the pass, and we can easily free t

Re: RFC [testsuite] Obey --load-average

On 08/06/2017 05:05 PM, Daniel Santos wrote: > On 08/03/2017 11:45 AM, Jeff Law wrote: >> On 08/02/2017 11:34 PM, Daniel Santos wrote: >> So does this perform better than make -j X -l X? I use that with good >> success. >> >> jeff > > Sorry for my slow re

Re: Can we replace uses of vec with vec in the backwards threader?

On 09/05/2017 06:32 AM, Aldy Hernandez wrote: > On Wed, Aug 30, 2017 at 10:32 AM, Jeff Law wrote: >> On 08/30/2017 04:41 AM, Aldy Hernandez wrote: > >> If you're looking for further cleanups, pulling the rest of the FSM bits >> out of tree-ssa-threadupdate.c is r

Re: Redundant sign-extension instructions on RISC-V

On 09/06/2017 10:43 AM, Richard Henderson wrote: > On 08/29/2017 05:36 PM, Michael Clark wrote: >> We’re investigating an issue with redundant sign-extension instructions >> being emitted with the riscv backend. Firstly I would like to state that >> riscv is possibly a unique backend with respect

Re: Redundant sign-extension instructions on RISC-V

On 09/06/2017 11:17 AM, Richard Henderson wrote: > On 09/06/2017 09:53 AM, Jeff Law wrote: >>> I think the easiest solution to this is for combine to notice when IOR has >>> operands with non-zero-bits that do not overlap, convert the operation to >>> ADD. >>

Re: Infering that the condition of a for loop is initially true?

On 09/14/2017 01:28 PM, Niels Möller wrote: > This is more of a question than a bug report, so I'm trying to send it > to the list rather than filing a bugzilla issue. > > I think it's quite common to write for- and while-loops where the > condition is always initially true. A simple example might

Re: [RFC] type promotion pass

On 09/15/2017 07:47 AM, Wilco Dijkstra wrote: > David Edelsohn wrote: > >> Why does AArch64 define PROMOTE_MODE as SImode? GCC ports for other >> RISC targets mostly seem to use a 64-bit mode. Maybe SImode is the >> correct definition based on the current GCC optimization >> infrastructure, but

Re: [RFC] type promotion pass

On 09/15/2017 10:19 AM, Segher Boessenkool wrote: > On Fri, Sep 15, 2017 at 09:18:23AM -0600, Jeff Law wrote: >> WORD_REGISTER_OPERATIONS works with PROMOTE_MODE. The reason you can't >> define WORD_REGISTER_OPERATIONS on aarch64 is because that the implicit >> promoti

Re: [RFC] type promotion pass

On 09/19/2017 05:40 AM, Richard Biener wrote: >> We might also need some way of having gimple statements that can >> convert (or promote to the type without extensions) just to keep the >> gimple type system happy. > > Yes, one of the "issues" is GIMPLE doesn't have subregs (I think that's > a go

Re: GCC Buildbot

On 09/20/2017 09:01 AM, Paulo Matos wrote: > Hi all, > > I am internally running buildbot for a few projects, including one for a > simple gcc setup for a private port. After some discussions with David > Edelsohn at the last couple of Cauldrons, who told me this might be > interesting for the com

Re: Weird warning when building gcc

On 09/22/2017 08:25 PM, nick wrote: > Greetings All, > > I am wondering if this is a warning worth looking into or is it just another > false postive: > > /home/nick/gcc/gcc/combine.c:1316:8: warning: ‘prev’ may be used > uninitialized in this function [-Wmaybe-uninitialized] > if ((ne

Re: Weird warning when building gcc

On 09/23/2017 04:57 PM, Eric Gallager wrote: > On Sat, Sep 23, 2017 at 12:34 PM, nick wrote: >> >> >> On 2017-09-23 12:05 PM, Jeff Law wrote: >>> On 09/22/2017 08:25 PM, nick wrote: >>>> Greetings All, >>>> >>>> I am wondering i

Re: pass manager question

On 10/03/2017 05:36 AM, Martin Jambor wrote: > Hi, > > On Mon, Oct 02, 2017 at 01:27:05PM -0600, Sandra Loosemore wrote: >> Is there an idiom for target-specific back end code to ask the pass manager >> if a particular pass (e.g., "split1") has already run? > > (I might be wrong but) I don't thin

Re: -ffunction-sections and -fdata-sections documentation

On 10/13/2017 01:06 AM, Sebastian Huber wrote: > Hello, > > I would like to update the documentation of these compiler flags and > have some questions.  The -ffunction-sections and -fdata-sections > documentation is currently: > > "Place each function or data item into its own section in the outp

Re: Global analysis of RTL

On 10/13/2017 12:18 PM, Geoff Wozniak wrote: > My team and I are working on a procedural abstraction (PA) optimization > for GCC based on the ARM Embedded Toolchain distribution that uses GCC > 6.2.1. Our initial attempt to get something functional has been > successful, but it is a very messy solu

Re: -ffunction-sections and -fdata-sections documentation

On 10/13/2017 12:45 PM, Sebastian Huber wrote: > > > - Am 13. Okt 2017 um 20:39 schrieb David Edelsohn dje@gmail.com: > >> On Fri, Oct 13, 2017 at 2:34 PM, Sebastian Huber >> wrote: >> > Do these options affect the code generation? They can affect code generation. By placing

Re: do we ever thread computed gotos?

On 10/26/2017 05:05 AM, Aldy Hernandez wrote: > Howdy. > > In the backwards threader we attempt to thread paths that lead to a > basic block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a > GIMPLE_GOTO.  The latter doesn't make much sense, since we only handle > constants.  What does a goto t

Problems in IPA passes

Jan, What's the purpose behind calling vrp_meet and extract_range_from_unary_expr from within the IPA passes? AFAICT that is not safe to do. Various paths through those routines will access static objects within tree-vrp.c which may not be initialized when IPA runs (vrp_equiv_obstack, vr_value)

Re: Problems in IPA passes

On 10/28/2017 11:18 AM, Richard Biener wrote: > On October 28, 2017 9:28:38 AM GMT+02:00, Jeff Law wrote: >> >> Jan, >> >> What's the purpose behind calling vrp_meet and >> extract_range_from_unary_expr from within the IPA passes? >> >> AFAICT th

Re: Problems in IPA passes

On 10/29/2017 03:54 PM, Kugan Vivekanandarajah wrote: > Hi Jeff, > > On 28 October 2017 at 18:28, Jeff Law wrote: >> >> Jan, >> >> What's the purpose behind calling vrp_meet and >> extract_range_from_unary_expr from within the IPA passes? > > Th

Re: Problems in IPA passes

On 10/31/2017 03:49 AM, Kugan Vivekanandarajah wrote: > Hi Jeff, > > On 31 October 2017 at 14:47, Jeff Law wrote: >> On 10/29/2017 03:54 PM, Kugan Vivekanandarajah wrote: >>> Hi Jeff, >>> >>> On 28 October 2017 at 18:28, Jeff Law wrote: >>>>

Re: Problems in IPA passes

On 10/31/2017 04:36 AM, Richard Biener wrote: > On October 31, 2017 10:49:51 AM GMT+01:00, Kugan Vivekanandarajah > wrote: >> Hi Jeff, >> >> On 31 October 2017 at 14:47, Jeff Law wrote: >>> On 10/29/2017 03:54 PM, Kugan Vivekanandarajah wrote: >>>>

Re: Problems in IPA passes

On 10/31/2017 04:31 AM, Richard Biener wrote: > > Equivalence shouldn't be used from the extract_range_from_* routines. > Vrp_meet probably uses them though. Factoring this function would be nice. You'd think it shouldn't be needed :-) If we look at extract_range_from_binary_expr_1, you'll see

Re: Problems in IPA passes

On 11/01/2017 12:31 AM, Richard Biener wrote: In my local tree I'm just passing around the vrp_bitmap_obstack right now. Nobody's accessing it via a global anymore. So at least we know what routines directly or indirectly want to touch vrp_bitmap_obstack. Maybe that's not necessary in most p

Re: Problems in IPA passes

On 11/01/2017 08:24 AM, Richard Biener wrote: On November 1, 2017 3:12:05 PM GMT+01:00, Jeff Law wrote: On 11/01/2017 12:31 AM, Richard Biener wrote: In my local tree I'm just passing around the vrp_bitmap_obstack right now. Nobody's accessing it via a global anymore. So a

Re: Where should I report security related issues?

On 11/01/2017 03:22 AM, Florian Weimer wrote: * Charo: Is there any private list or something like that to report it or should I use the GCC bug tracker? You could pick one of the distributions and let them handle this: * Debian * Red Hat * SUSE Just contacting one distribution is suffic

Re: testsuite question

On 11/03/2017 12:34 PM, Steve Kargl wrote: One of the tests for gfortran has been XPASSing on newer versions of FreeBSD. The testcase has the line ! { dg-xfail-if "" { "*-*-freebsd*" } { "*" } { "" } } I know the tests passes on *-*-freebsd12.0. I should pass on *-*-freebsd11.* and perhaps *

Re: Types of operands in a gimple equality operation

On 11/13/2017 01:30 AM, Richard Biener wrote: >> Huh, that bites. Im surprised we don't just make those places produce a >> cast, or just introduce an explicit cast of the (void *)0 during the >> expression building process. > > I'm quite sure we could relax the above now given we have gimple_ca

Re: RTL for stackmachines

On 11/15/2017 08:33 AM, Ábrahám Endre wrote: > Hi, > I'm trying to make a gcc backend for a stack machine, is there a way to > disable register specific behaviour required by target.h, target.c? also > all preserved names in the RTL language assume usages of operands (addm3 > mulm3 etc) which is no

Re: Backporting ARC patch to gcc7.x

On 11/15/2017 06:49 AM, Claudiu Zissulescu wrote: > Hi, > > I would like to backport patch r250097 to gcc7.x branch. It does changes > libgcc/config.host and gcc/config.gcc for ARC. Do I need to get extra > approvals for it or I just fallow the wiki on this page > (https://gcc.gnu.org/wiki/SvnM

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/03/2017 08:59 AM, Qing Zhao wrote: > Hi, > > This is the first time I am asking for a design review for fixing a GCC > enhancement request, Let me know if I need to send this email to other > mailing list as well. > > I have been studying PR 78809 for some time > https://gcc.gnu.org/bugz

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/16/2017 03:39 PM, Qing Zhao wrote: > Hi, Jeff,  > thanks a lot for your comments. please see my reply in below: > > >> On Nov 16, 2017, at 12:47 PM, Jeff Law > <mailto:l...@redhat.com>> wrote: >> >>> >>>   B. for strncmp (s1, s2, n) (

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 03:45 PM, Qing Zhao wrote: >>> do you think using this routine is good? or do you have other >>> suggestions (since I am still not very familiar with the internals of >>> GCC, might not find the best available one now…) >> The range information attached to an SSA_NAME is global data.

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 03:50 PM, Qing Zhao wrote: >> >> The difficulty is tracking when exposure leads to these secondary >> opportunities. I often end up looking for this kind of stuff by first >> identifying many source files where the transformation applies. Then I >> generate dumps & assembly code fo

Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

On 11/17/2017 03:20 PM, Qing Zhao wrote: > >> On Nov 16, 2017, at 6:24 PM, Martin Sebor > > wrote: >>> >>> In my current local implementation, I used the following routine to >>> get the range info:  (and use the MINMAXLEN[1]+1 for the length of >>> the non-constant string

Re: How far should we trust ChangeLog attribution dates?

On 12/21/2017 03:55 PM, Eric S. Raymond wrote: > Jason Merrill : >> YMD in the ChangeLog is typically commit date rather than authorship >> date anyway, so (i) and (iii) shouldn't differ much at all, and (i) >> seems simpler. > > I have not generally observed this to be true. Maybe it's a GCC-loca

Re: How far should we trust ChangeLog attribution dates?

On 12/21/2017 04:13 PM, Eric S. Raymond wrote: > Jeff Law : >> I think we've routinely made the ChangeLog date the commit date. > > Ah, so you modify patches as they come in? Yes we routinely twiddle the ChangeLog dates. In fact we tried to discourage folks from including the

Re: Possbile patch for compilation errors re possibly uninitialized variables at -Og

On 12/30/2017 03:58 AM, Louis Krupp wrote: > Thank you for making me stop and think about this. I was basically full of > crap; like the test case in 78394, the tree compiles just fine at -O0. I > don't know where I got the idea that it didn't. > > Initializing dozens of variables just to make t

Re: Status of m32c target?

On 01/12/2018 07:24 AM, Segher Boessenkool wrote: > On Fri, Jan 12, 2018 at 08:02:40AM +0100, Sebastian Huber wrote: >> what is the status of the m32c target? There are some open bugs that >> prevent the C/C++ compiler build: >> >> https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bu

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

On 01/12/2018 11:26 AM, Cory Fields wrote: > Quick disclaimer: I'm 100% new to GCC code and the dev process, so > there are bound to be some faulty assumptions below. > > I recently worked on a build of gcc, x86_64-pc-linux-gnu -> > x86_64-pc-linux-musl. In order to boost my confidence in musl, I

Re: Status of m32c target?

On 01/12/2018 04:07 PM, Joseph Myers wrote: > On Fri, 12 Jan 2018, Jeff Law wrote: > >> I was going to suggest deprecation for gcc-8 given how badly it was >> broken in gcc-7 and the lack of maintenance on the target. > > While we're considering deprecations, what ha

Re: Status of m32c target?

On 01/15/2018 11:11 AM, Joel Sherrill wrote: > > > On 1/15/2018 11:31 AM, Segher Boessenkool wrote: >> On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote: >>> On 13/01/18 00:16, Jeff Law wrote: >>>> On 01/12/2018 04:07 PM, Joseph Myers wrote:

Re: Status of m32c target?

On 01/19/2018 06:33 AM, Georg-Johann Lay wrote: > On 13.01.2018 00:07, Joseph Myers wrote: >> On Fri, 12 Jan 2018, Jeff Law wrote: >> >>> I was going to suggest deprecation for gcc-8 given how badly it was >>> broken in gcc-7 and the lack of maintenance on the targ

Re: Retpolines and CFI

On 01/25/2018 06:38 AM, H.J. Lu wrote: > On Mon, Jan 22, 2018 at 4:21 AM, Florian Weimer wrote: >> I tried this: >> >> struct C { >> virtual ~C(); >> virtual void f(); >> }; >> >> void >> f (C *p) >> { >> p->f(); >> p->f(); >> } >> >> with r256939 and -mindirect-branch=thunk -O2 on x86-64

Re: GCC compiler -Warray-bounds option

On 02/26/2018 02:41 AM, Mustafa i. wrote: > Hello, > > What exactly is the -Warray-bounds option to the GCC compiler supposed > to warn about? It's meant to warn for out of bounds array access. For example, if you have a 10 element array, but try to access the 11th element you should get a warnin

Re: determining aggregate member from MEM_REF

On 02/26/2018 05:08 AM, Richard Biener wrote: > On Fri, Feb 16, 2018 at 8:07 PM, Martin Sebor wrote: >> Say I have a struct like this: >> >> struct A { >> char a[4], b[5]; >> }; >> >> then in >> >> extern struct A *a; >> >> memset (&a[0].a[0] + 14, 0, 3); // invalid >> >> memset (

Re: determining aggregate member from MEM_REF

On 02/26/2018 08:44 AM, Martin Sebor wrote: > > Folding things to MEM_REF (or rather, folding them too early) > makes all kinds of analysis harder: not just warnings but even > optimization.  I've raised a whole slew of bugs for the strlen > pass alone where folding string functions to MEM_REF def

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

On 03/02/2018 12:45 PM, Peter Bergner wrote: > While debugging the PR84264 ICE caused by the following test case: > > void _setjmp (); > void a (unsigned long *); > void > b () > { > for (;;) > { > _setjmp (); > unsigned long args[9]{}; > a (args); > } >

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

On 03/02/2018 08:28 PM, Peter Bergner wrote: > On 3/2/18 3:26 PM, Jeff Law wrote: >> On 03/02/2018 12:45 PM, Peter Bergner wrote: >>> ...which forces us to spill everything live across the setjmp by forcing >>> the pseudos to interfere all hardregs. That can't be g

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

On 03/04/2018 01:57 AM, Richard Biener wrote: > > I think posix says you have to mark such variables volatile. So I > fully agree with your analysis of why setjmp isn't special for RA. It > would be only making non-conforming code work by accident. Note the code we're carrying around has its origi

Re: BLKmode parameters are stored in unaligned stack slot when passed via registers.

On 03/06/2018 08:21 AM, Renlin Li wrote: > Hi all, > > The problem described here probably only affects targets whose ABI allow > to pass structured > arguments of certain size via registers. > > If the mode of the parameter type is BLKmode, in the callee, during RTL > expanding, > a stack slot w

Re: Internal compiler error building libstdc++ for vax

On 03/19/2018 03:46 PM, co...@sdf.org wrote: > (updating) > krister found a better hack patch which explains what the problem is, > adding a useless move at the end of the instruction, so the label is > not the last instruction. > > (And, in the problem code, the last instruction in the function.)

Re: GCC contribution

On 03/29/2018 12:56 AM, Andre Groenewald wrote: > The heart of GCC should remain pure C as far as possible, for the very > same reason the Linux kernel is only in C. Deviate from this, and in a > few years we will end up with Java as the programming language of GCC. > > It is the duty of the steer

Re: Selective scheduling and its usage

On 03/29/2018 04:15 AM, Eric Botcazou wrote: >> I noticed there are quite many selective scheduling PRs: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872 >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842 >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659 >> >> and many others. > > Righ

Re: Internal compiler error building libstdc++ for vax

On 04/02/2018 10:15 AM, co...@sdf.org wrote: > It turns out (all from krister, I am still totally lost) that it is not > failing for this specific reason in this case. > > Rather, the attached patch from krister fixes it, saying that gcc > wants to change the label and then doesn't recognise the n

Re: GCC changes for Fedora + riscv64

On 03/31/2018 12:27 PM, Richard W.M. Jones wrote: > Hi GCC maintainers! > > I'd like to talk about what changes we (may) need to GCC in > Fedora to get it working on 64-bit RISC-V, and also (more > importantly) to ask your advice on things we don't fully > understand yet. However, I don't know ev

Re: GCC changes for Fedora + riscv64

On 04/09/2018 12:04 PM, Jim Wilson wrote: > On 04/08/2018 08:22 AM, Jeff Law wrote: >> On 03/31/2018 12:27 PM, Richard W.M. Jones wrote: >>> I'd like to talk about what changes we (may) need to GCC in >>> Fedora to get it working on 64-bit RISC-V, and also (more >

Re: GCC changes for Fedora + riscv64

On 04/09/2018 04:47 PM, Stef O'Rear wrote: > On Mon, Apr 9, 2018 at 6:37 PM, Jeff Law wrote: >> On 04/09/2018 12:04 PM, Jim Wilson wrote: >>> On 04/08/2018 08:22 AM, Jeff Law wrote: >>>> On 03/31/2018 12:27 PM, Richard W.M. Jones wrote: >>>>> I&

Re: GCC changes for Fedora + riscv64

On 04/10/2018 01:55 AM, Andreas Schwab wrote: > On Apr 10 2018, Kito Cheng wrote: > >> You can use -r option (e.g. ./qemu-riscv64 -r 4.15) or set QEMU_UNAME >> environment variable to change the uname for qemu. > > But be aware that the emulated environment still assumes that all system > calls

Re: GCC changes for Fedora + riscv64

On 04/10/2018 12:27 AM, Richard W.M. Jones wrote: > On Mon, Apr 09, 2018 at 04:37:30PM -0600, Jeff Law wrote: >> Are you guys using qemu user mode emulation for testing purposes? When >> I've set up a suitable riscv64 rootfs and try to do anything nontrivial >> in it wit

Re: Internal compiler error building libstdc++ for vax

On 04/10/2018 01:27 PM, Maciej W. Rozycki wrote: > On Sun, 8 Apr 2018, Jeff Law wrote: > >> I think you need to go back to my earlier reply and read it carefully. >> In particular, you need an insn where the label_ref and pc are swapped. > > Ouch, there are no rev

Re: GCC changes for Fedora + riscv64

On 04/09/2018 11:01 PM, Kito Cheng wrote: > Hi Jeff: > > You can use -r option (e.g. ./qemu-riscv64 -r 4.15) or set QEMU_UNAME > environment variable to change the uname for qemu. That did the trick. Exactly what I needed. Thanks! jeff

Re: GCC-8 branching

On 04/19/2018 04:07 PM, Peryt, Sebastian wrote: > Hi, > > I'd like to ask what is the expected date for GCC branching to GCC-8 release > version? > I'm mostly interested because I'd like to know when it'll be ok again to add > new features? > Or are we still able to add them? No exact date for b

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