Re: Dead code at gcc/tree-ssa-loop.c:772?

On 6/6/19 7:02 AM, Andrew MacLeod wrote: > On 6/6/19 6:20 AM, Martin Liška wrote: >> Hi. >> >> The code is dead: >> >>     757    char * >>     758    get_lsm_tmp_name (tree ref, unsigned n, const char *suffix) >>     759    { >>     760  char ns[2]; >>     761    >>     762  lsm_tmp_name_l

Re: Dead code at gcc/tree-ssa-loop.c:772?

On 6/6/19 1:42 PM, Andrew MacLeod wrote: > On 6/6/19 1:20 PM, Jeff Law wrote: >> On 6/6/19 7:02 AM, Andrew MacLeod wrote: >>> On 6/6/19 6:20 AM, Martin Liška wrote: >>>> Hi. >>>> >>>> The code is dead: >>>> >>>> 757

Re: alloca (0) in include/libiberty.h

On 6/10/19 5:54 AM, Andrew Haley wrote: > On 6/10/19 8:24 AM, Martin Liška wrote: > >> I've just noticed that we have couple of alloca (0) in libiberty: >> >> #ifndef REGEX_MALLOC >> # ifdef C_ALLOCA >> alloca (0); >> # endif >> #endif >> >> If I'm correct the value 0 has a special meaning t

Re: [PATCH] Deprecate ia64*-*-*

On 6/13/19 5:13 AM, Richard Biener wrote: > > ia64 has no maintainer anymore so the following deprecates it > with the goal of eliminating the port for GCC 11 if no maintainer > steps up. > > OK? > > Thanks, > Richard. > > 2019-06-13 Richard Biener > > * config.gcc: Mark ia64*-*-* tar

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

On 6/12/19 9:25 AM, Michael Matz wrote: > Hi, > > On Wed, 12 Jun 2019, Martin Sebor wrote: > >>> Otherwise LGTM as the patch, but I'd like to hear from others whether >>> it is kosher to add such a special case to the warn_unused_result >>> attribute warning. And if the agreement is yes, I thi

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

On 6/12/19 10:40 AM, Jakub Jelinek wrote: > On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote: >> But GCC doesn't support such an implementation, does it? > > Why would that be relevant? The warning would cause people to make portable > code less portable (by removing the alloca (0) ca

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

On 6/13/19 10:46 AM, Tom Tromey wrote: >>>>>> "Jeff" == Jeff Law writes: > > Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm > Jeff> not sure we can realistically do that. > > Are there still platform

Re: [PATCH] Deprecate ia64*-*-*

On 6/14/19 1:14 AM, Richard Biener wrote: > On Thu, 13 Jun 2019, Jim Wilson wrote: > >> On Thu, Jun 13, 2019 at 10:39 AM Joel Sherrill >> wrote: >>> Ok with me if no one steps up and the downstream projects like Debian gets >>> notice. This is just a reflection of this architecture's status in t

Re: ARM peephole2 from 2003 never merged, still valid

On 6/6/19 10:06 AM, Richard Earnshaw (lists) wrote: > On 06/06/2019 15:55, Fredrik Hederstierna wrote: >>> From: Segher Boessenkool >>> Sent: Thursday, June 6, 2019 4:02 PM >>> To: Richard Earnshaw (lists) >>> Cc: Jeff Law; Fredrik Hederstierna; gcc@gcc.gnu.

Re: [PATCH] Deprecate ia64*-*-*

On 6/14/19 6:26 PM, Jason Duerstock wrote: > I volunteer to be maintainer for ia64. So the first step would be to start your assignment paperwork with the FSF. Without it we can't accept non-trivial contributions/fixes from you. Contact ass...@gnu.org to get a past and future copyright assignment

Re: Avoid stack references in inline assembly

On 6/17/19 2:28 PM, Vincent Rivière wrote: > Hi, > > My goal is to create optimal C bindings for Atari ST system calls, using > m68k-elf-gcc (tested with version 7.1.0). Basically, system calls are > similar to function calls: parameters are stacked in the reverse order, > last one being a functio

Re: Confusion with labels as values

On 6/19/19 7:04 AM, Florian Rommel wrote: > Hi, > > Recently I wanted to take and print the address of a label. When > compiling with -O2, I noticed that the address equals the function body > start address if the label is not used as a goto target. > > Here is an example: > > #include > int m

Re: [RFC] zstd as a compression algorithm for LTO

On 6/19/19 3:21 AM, Martin Liška wrote: > Hi. > > I've written a patch draft that replaces zlib with the zstd compression > algorithm ([1]) > in LTO. I'm also sending statistics that are collected for couple of quite > big C++ source > files. Observation I did: > > - LTO stream compression take

Re: Confusion with labels as values

On 6/19/19 11:09 AM, Segher Boessenkool wrote: > On Wed, Jun 19, 2019 at 09:39:01AM -0600, Jeff Law wrote: >> A label used as a value, but which is not a jump target will have an >> indeterminate value -- it'll end up somewhere in its containing >> function, that'

Re: if (x > ((2^x)-1)) optimization

On 6/22/19 7:55 AM, Jason Duerstock wrote: > I was starting at the assembly from some of the Python source, and > came across this (simplified) comparison: > > if (x > 2305843009213693951) {...} > > This is the same as: > > if (x > 0x1fff) {...} > > This is equivalent to: > > if (x

Re: if (x > ((2^x)-1)) optimization

On 6/22/19 12:44 PM, Segher Boessenkool wrote: > On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote: >> On 6/22/19 7:55 AM, Jason Duerstock wrote: >>> More generally, we can rewrite >>> >>> if ( x > ((1 << z) -1)) { ...} >>> >>>

Re: if (x > ((2^x)-1)) optimization

On 6/23/19 5:50 AM, Segher Boessenkool wrote: > On Sat, Jun 22, 2019 at 03:30:15PM -0600, Jeff Law wrote: >> On 6/22/19 12:44 PM, Segher Boessenkool wrote: >>> On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote: >>>> On 6/22/19 7:55 AM, Jason Duerstock wrote

Re: Threadsafe Garbage Collection allocation

On 6/28/19 2:48 PM, Giuliano Belinassi wrote: > Hi, > > *** > Question: What are all the possible ways to allocate and deallocate memory > through the Garbage Collector? > *** > > Context: I am parallelizing GCC internals and I am facing problems with the > GCC > Garbage Collector, and therefore

Re: RFC on a new optimization

On 7/1/19 3:58 PM, Gary Oblock wrote: > I've been looking at trying to optimize the performance of code for > programs that use functions like qsort where a function is passed the > name of a function and some constant parameter(s). > > The function qsort itself is an excellent example of what I'm

Re: [EXT] Re: RFC on a new optimization

On 7/1/19 5:01 PM, Gary Oblock wrote: > On 7/1/19 3:08 PM, Jeff Law wrote: >> External Email >> >> -- >> On 7/1/19 3:58 PM, Gary Oblock wrote: >>> I've been looking at trying to optimize

Re: [PATCH] Add .gnu.lto_.lto section.

On 7/1/19 4:59 AM, Martin Liška wrote: > Hi. > > Ok, so there's a version with added ChangeLog that survives regression tests. > > Ready to be installed? > Thanks, > Martin > > > 0001-Add-.gnu.lto_.lto-section.patch > > From e6745583dc4b7f5543878c0a25498e818531f73e Mon Sep 17 00:00:00 2001 > F

Re: [PATCH 2/2] Add zstd support for LTO bytecode compression.

On 7/1/19 5:00 AM, Martin Liška wrote: > Hi. > > This is updated version of the zstd patch that should handle all what Joseph > pointed out. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin > > > 0002-Add-zstd-support-for-

Re: ARM peephole2 from 2003 never merged, still valid

On 7/8/19 12:41 AM, Fredrik Hederstierna wrote: >> From: Segher Boessenkool Sent: >> Thursday, June 6, 2019 6:49 PM To: Richard Earnshaw (lists) Cc: >> Fredrik Hederstierna; Jeff Law; gcc@gcc.gnu.org Subject: Re: ARM >> peephole2 from 2003 never merged, still valid >>

Re: Can LTO minor version be updated in backward compatible way ?

On 7/17/19 11:29 AM, Andi Kleen wrote: > Romain Geissler writes: >> >> I have no idea of the LTO format and if indeed it can easily be updated >> in a backward compatible way. But I would say it would be nice if it >> could, and would allow adoption for projects spread on many teams >> depending o

Re: Can LTO minor version be updated in backward compatible way ?

On 7/22/19 8:25 AM, Martin Liška wrote: > On 7/17/19 8:10 PM, Jeff Law wrote: >> On 7/17/19 11:29 AM, Andi Kleen wrote: >>> Romain Geissler writes: >>>> >>>> I have no idea of the LTO format and if indeed it can easily be updated >>>> in a bac

Re: Can LTO minor version be updated in backward compatible way ?

On 7/23/19 2:49 AM, Martin Liška wrote: > On 7/22/19 4:31 PM, Jeff Law wrote: >> On 7/22/19 8:25 AM, Martin Liška wrote: >>> On 7/17/19 8:10 PM, Jeff Law wrote: >>>> On 7/17/19 11:29 AM, Andi Kleen wrote: >>>>> Romain Geissler writes: >>>>

Re: Use predicates for RTL objects

On 8/7/19 12:05 PM, Segher Boessenkool wrote: > On Wed, Aug 07, 2019 at 01:39:53PM -0400, Arvind Sankar wrote: >> On Wed, Aug 07, 2019 at 12:33:53PM -0500, Segher Boessenkool wrote: >>> On Wed, Aug 07, 2019 at 12:15:29PM -0400, Arvind Sankar wrote: I would also like to get some comments on the

Re: Indirect memory addresses vs. lra

On 8/8/19 1:19 PM, Segher Boessenkool wrote: > On Thu, Aug 08, 2019 at 01:30:41PM -0400, Paul Koning wrote: >> >> >>> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool >>> wrote: >>> >>> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: > On Aug 8, 2019, at 12:25 PM, Vladimir Makarov

Re: Use predicates for RTL objects

On 8/8/19 11:06 AM, Arvind Sankar wrote: > On Thu, Aug 08, 2019 at 08:31:28AM -0600, Jeff Law wrote: >> True, but they could be. When David was working in this space a few >> years ago I concluded that the main value in sub-classing the various >> RTL operators just wan

Re: Use predicates for RTL objects

On 8/8/19 11:42 AM, Arvind Sankar wrote: > On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote: >> On Wed, Aug 07, 2019 at 02:58:12PM -0400, Arvind Sankar wrote: >> code does is cheap. With "x->is_a (PLUS)", who knows what is happening That's not my point -- my point was th

Re: Use predicates for RTL objects

On 8/8/19 12:46 PM, Jakub Jelinek wrote: > On Thu, Aug 08, 2019 at 02:35:27PM -0400, Arvind Sankar wrote: >> Surely there's general agreement on using REG_P etc? I don't see anyone > > No objections from me for using REG_P and other *_P macros more. Right. These are convenience macros and I think

Re: Indirect memory addresses vs. lra

On 8/9/19 2:14 AM, John Darrington wrote: > On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: > > Yea, it's certainly designed with the more mainstream architectures in > mind. THe double-indirect case that's being talked about here is well > out

Re: Help with bug in GCC garbage collector

On 8/19/19 4:59 PM, Steve Ellcey wrote: > I was wondering if anyone could help me investigate a bug I am > seeing in the GCC garbage collector. This bug (which may or may not > be PR 89179) is causing a segfault in GCC, but when I try to create > a preprocessed source file, the bug doesn't trigger

Re: Proposal for the transition timetable for the move to GIT

On 9/17/19 6:02 AM, Richard Earnshaw (lists) wrote: > At the Cauldron this weekend the overwhelming view for the move to GIT > soon was finally expressed. [ ... proposal itself ... ] So there's nothing in the proposal I would object to, nor do I object to being slightly flexible. If we need to mov

Re: taking OpenCL C as a built-in lang of GCC?

On 9/12/19 8:48 AM, Jianbin Fang wrote: > Hello Guys, > > > > I am working on OpenCL for a couple of years, and would like to ask, > as for GCC, why not taking OpenCL C as a built-in language in its > front-end? There's no inherent reason why we don't support OpenCL C. Someone would just need t

Re: syncing the GCC vax port, atomic issue

On 9/20/19 3:04 PM, co...@sdf.org wrote: > On Fri, Sep 20, 2019 at 11:15:32AM +, co...@sdf.org wrote: >> Removed from the diff. Unfortunately this introduces an ICE during the >> build of GCC... > > I took another look at the VAX atomic pattern issue. > (http://gnats.netbsd.org/53039) > It is

Re: peephole or expand optimization for fixing poor code generated in conversion from QImode to PSImode pointer?

On 9/23/19 5:56 AM, Jozef Lawrynowicz wrote: > For msp430-elf in the large memory model there are PSImode (20-bit) pointers. > POINTERS_EXTEND_UNSIGNED == 1 and "char" is unsigned by default. > > We get poor code generated for the following code snippet: > > const int table[2] = {1, 2}; > > int

Re: RTL alternative selection question

On 9/23/19 9:26 AM, Andrew Stubbs wrote: > On 23/09/2019 16:21, Segher Boessenkool wrote: >> Pass the register class or constraint or something like that to the hook, >> then based on what the hook returns, either or not do the reject?  So >> your >> hook would special-case SCC_CONDITIONAL_REG, may

Re: Reposurgeon status

On 9/25/19 2:32 PM, Eric S. Raymond wrote: > Since the subject of repository conversions has come up, a situation report... > > I am in the very last stages of qualifying the Go port of reposurgeon. > Most importantly to your project, the Go code passed all of the > existing regression tests for r

Re: syncing the GCC vax port, atomic issue

On 9/20/19 7:18 PM, co...@sdf.org wrote: > On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote: >> Introducing the reversed jbb* patterns doesn't seem to help with the >> original issue. It crashes building libatomic. > > My loose understanding of what is going on: > - GCC emits this ato

Re: syncing the GCC vax port, atomic issue

On 9/21/19 12:27 PM, Paul Koning wrote: > > >> On Sep 20, 2019, at 9:18 PM, co...@sdf.org wrote: >> >> On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote: >>> Introducing the reversed jbb* patterns doesn't seem to help with the >>> original issue. It crashes building libatomic. >> >> M

Re: gcc-10 Bug report

On 10/3/19 2:01 PM, Thomas Koenig wrote: > Hi, > >> I am using gcc version 10.0.0 20190825 (experimental) . During the >> Lapack compilation I got the following errors: >> >> >> >> sbdsvdx.f:777:39: >> >>    777 |  CALL SCOPY( N*

Fwd: Joint statement on the GNU Project

Some of you may be aware of the recently released joint statement on the GNU project. Like Carlos, I have signed that joint statement as an individual. I would encourage all contributors to read the statement and, if you want to sign the statement or have questions, please contact Carlos off-li

Re: Proposal for the transition timetable for the move to GIT

On 10/25/19 8:10 AM, Richard Earnshaw (lists) wrote: > On 19/09/2019 15:42, Damian Rouson wrote: >> On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist >> >> wrote: >> >>> >>> One thing that's unclear to me is how should I actually make my stuff >>> appear in the public repo? Say I want to work on som

Re: GCC selftest improvements

On 10/25/19 6:01 PM, Gabriel Dos Reis wrote: > [Andrew] > > | > GCC has some rather unique requirements, in that we support a great many > | > build configurations, some of which are rather primitive - for example, > | > requiring just C++98 with exceptions disabled, in that we want to be able >

Re: GCC selftest improvements

On 10/28/19 1:42 PM, Richard Biener wrote: >> >> I'd really like to see us move to C++11 or beyond. Sadly, I don't >> think >> we have any good mechanism for making this kind of technical decision >> when there isn't consensus. > > Well, we just do it? For some reason I thought you were against s

Re: GCC selftest improvements

On 10/28/19 2:27 PM, Segher Boessenkool wrote: > On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote: >> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote: >>> Jason, Jonathan - is the situation on the terrain really that dire that >>> C++11 (or C++14) isn't at all

Re: GCC selftest improvements

On 10/28/19 3:52 PM, Andrew Pinski wrote: > On Mon, Oct 28, 2019 at 2:47 PM Jakub Jelinek wrote: >> >> On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote: >>> On 10/28/19 2:27 PM, Segher Boessenkool wrote: >>>> On Mon, Oct 28, 2019 at 01:40:03PM -0600, Je

Re: svn unavailable since more than an hour

On 10/30/19 1:49 PM, Bill Seurer wrote: > On 10/30/19 1:29 PM, Rainer Emrich wrote: >> svn: E170013: Unable to connect to a repository at URL >> 'svn://gcc.gnu.org/svn/gcc/trunk' >> svn: E210002: Network connection closed unexpectedly >> > > I can ping gcc.gnu.org but if I tracert/traceroute to it

Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th

On 11/1/19 9:08 AM, Marek Polacek wrote: > On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote: >> Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit : >>> >>> Please make sure to get features intended for GCC 10 finished >>> and reviewed before the end of stage 1. >>> >> >> Hi, >> >

Re: cc0 -> CCmode questions

On 11/2/19 9:51 AM, Georg-Johann Lay wrote: > Segher Boessenkool schrieb: >>> Btw, does GCC support clobbering registers in branches (or >>> cbranch4 for that matter)?  This requirement would come up when >>> transitioning avr to cc_mode because cbranches would live post reload. >> >> Of course.  Y

Re: Commit messages and the move to git

On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote: > With the move to git fairly imminent now it would be nice if we could > agree on a more git-friendly style of commit messages; and, ideally, > start using them now so that the converted repository can benefit from > this. > > Some tools, partic

Re: Comparison operations in machine description (-1 vs +1)

On 11/12/19 11:29 AM, m wrote: > Hello gcc developers! > > I am working on a new back end for my MRISC32 ISA [1], and I'm still very > new to gcc internals. I suspect that I will have more questions further > down the road, but let's start with this topic... > > The MRISC32 ISA has instructions f

Re: GCC selftest improvements

On 11/22/19 4:41 PM, Segher Boessenkool wrote: > On Fri, Nov 22, 2019 at 11:36:18PM +0100, Jakub Jelinek wrote: >> On Fri, Nov 22, 2019 at 04:01:43PM -0600, Segher Boessenkool wrote: >>> On Fri, Nov 22, 2019 at 09:02:05PM +, Andrew Dean wrote: >> Many systems do not have a system compiler n

Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

On 11/25/19 2:43 PM, Andrew Dean via gcc wrote: >> I get errors like this: >> >> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file >> 'rdimon.specs': No such file or directory >> >> I can see that the rdimon.specs flag is added based on this line >> in aarc

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

On 12/5/19 9:24 AM, Paul Koning wrote: > > >> On Dec 5, 2019, at 11:17 AM, Joseph Myers >> wrote: >> >> On Thu, 5 Dec 2019, Thomas Schwinge wrote: >> >>> In the relevant session at the GNU Tools Cauldron 2019, Michael >>> Meissner stated that even he is not using a 80 x 24 terminal >>> anymore

Re: GCC static analysis branch now available on Compiler Explorer

On Tue, 2019-12-10 at 12:51 -0700, Martin Sebor wrote: > On 12/10/19 10:56 AM, David Malcolm wrote: > > On Tue, 2019-12-10 at 09:36 -0700, Martin Sebor wrote: > > > On 12/10/19 8:46 AM, David Malcolm wrote: > > > > For the adventurous/curious, my static analyzer branch of GCC > > > > [1] > > > > is

Re: Questions about IPA/clones and new LTO pass

On Mon, 2019-12-09 at 17:59 -0500, Erick Ochoa wrote: > Hello, > > this is an update on the LTO pass we've been working on. The > optimization is called ipa-initcall-cp because it propagates constant > values written to variables with static lifetimes (such as ones > initialized in initialization

Re: Proposal for the transition timetable for the move to GIT

On Mon, 2019-12-16 at 08:54 -0500, Eric S. Raymond wrote: > Segher Boessenkool : > > > Do people really want to keep tweaking the conversions and postpone the > > > git switchover? > > > > No. > > It may not be my place to say, but...I think the stakes are pretty > high here. If I were a GCC dev

Re: Proposal for the transition timetable for the move to GIT

On Mon, 2019-12-16 at 13:53 +, Joseph Myers wrote: > > > > However, we should also note that stage 3 is intended to last two months, > > > ending with the move to git > > > > > > ;, and give

Re: Proposal for the transition timetable for the move to GIT

On Mon, 2019-12-16 at 11:37 -0500, Eric S. Raymond wrote: > Jeff Law : > > > It may not be my place to say, but...I think the stakes are pretty > > > high here. If I were a GCC developer, I think I'd want the best > > > possible conversion even if that takes

Re: Proposal for the transition timetable for the move to GIT

On Mon, 2019-12-16 at 11:29 +, Joseph Myers wrote: > On Mon, 16 Dec 2019, Mark Wielaard wrote: > > > Should we go with the gcc-reparent.git repo now? > > I think we should go with the reposurgeon conversion, with all Richard's > improvements to commit messages. gcc-reparent.git has issues o

Re: Proposal for the transition timetable for the move to GIT

On Mon, 2019-12-16 at 09:36 -0600, Segher Boessenkool wrote: > On Mon, Dec 16, 2019 at 02:13:06PM +, Joseph Myers wrote: > > On Mon, 16 Dec 2019, Segher Boessenkool wrote: > > > > > Most of us are perfectly happy even with the current git mirror, for > > > old commits. We want "real" git to m

Re: Proposal for the transition timetable for the move to GIT

On Mon, 2019-12-16 at 15:59 -0600, Segher Boessenkool wrote: > In particular, we should look carefully at the commit > > attributions in both conversions and Maxim's may well give ideas for > > improving the reposurgeon changelogs command (Richard came up with three > > ideas recently, which I'v

Re: Proposal for the transition timetable for the move to GIT

On Mon, 2019-12-16 at 16:42 -0600, Segher Boessenkool wrote: > Hi! > > On Mon, Dec 16, 2019 at 03:13:49PM -0700, Jeff Law wrote: > > On Mon, 2019-12-16 at 15:59 -0600, Segher Boessenkool wrote: > > > In particular, we should look carefully at the commit > > > &

Re: Proposal for the transition timetable for the move to GIT

On Wed, 2019-12-18 at 13:50 -0600, Segher Boessenkool wrote: > On Wed, Dec 18, 2019 at 11:07:11AM -0700, Jeff Law wrote: > > > That isn't what I said. I said that freshly constructed complex software > > > will have more and deeper errors than stupid simple scripts do (

Re: Does gcc automatically lower optimization level for very large routines?

On Thu, 2019-12-19 at 17:06 -0600, Qing Zhao wrote: > Hi, Dmitry, > > Thanks for the responds. > > Yes, routine size only cannot determine the complexity of the routine. > Different compiler analysis might have different formula with multiple > parameters to compute its complexity. > > Howev

Need sanity check on DSE vs expander issue

I need a sanity check here. Given this code: > typedef union { long double value; unsigned int word[4]; } memory_long_double; > static unsigned int ored_words[4]; > static void add_to_ored_words (long double x) > { > memory_long_double m; > size_t i; > memset (&m, 0, sizeof (m)); > m.valu

Re: Need sanity check on DSE vs expander issue

On Fri, 2019-12-20 at 08:09 +0100, Richard Biener wrote: > On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law wrote: > > I need a sanity check here. > > > > Given this code: > > > > > typedef union { long double value; unsigned int word[4]; } > > mem

Re: The far past of GCC

On Sat, 2019-12-28 at 03:53 -0500, Eric S. Raymond wrote: > In moving the history of a project old enough to have used > more than one version-control system, I think it's good practice > to mark the strata. I'm even interested in pinning down the > RCS-to-CVS cutover, if there's enough evidence

Re: Git conversion: fixing email addresses from ChangeLog files

On Sun, 2019-12-29 at 07:32 -0500, Eric S. Raymond wrote: > Richard Earnshaw (lists) : > > I've just commented that one out for now; if anybody knows the correct > > addresses, please let me know. Also, there's one joint list that I've > > not attempted to fix at this time. > > # "28488": "Jim Ki

Re: Proposal for the transition timetable for the move to GIT

On Sun, 2019-12-29 at 22:30 +0100, Thomas Koenig wrote: > Am 29.12.19 um 14:26 schrieb Segher Boessenkool: > > We cannot waste a year on a social experiment. We can slowly and carefully > > adopt new procedures, certainly. But anything drastic isn't advisable imo. > > > > Also, many GCC develope

Re: Proposal for the transition timetable for the move to GIT

On Wed, 2020-01-08 at 23:34 +, Joseph Myers wrote: > > As noted on overseers, once Saturday's DATESTAMP update has run at 00:16 > UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk > and change the SVN hooks to make SVN readonly, then disable gccadmin's > cron jobs tha

Re: Proposal for the transition timetable for the move to GIT

On Thu, 2020-01-09 at 12:30 +, Joseph Myers wrote: > On Wed, 8 Jan 2020, Jeff Law wrote: > > > Is there any chance we could get one more trunk snapshot before the > > conversion starts -- even if that means firing up the snapshot process > > Friday? It'd be

Re: input address reload issue

On 01/09/2017 07:02 AM, Aurelien Buhrig wrote: On 06/01/2017 17:06, Jeff Law wrote: On 01/06/2017 03:20 AM, Aurelien Buhrig wrote: So the insn: (set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1)) is transformed into: (set (reg:SI 8 a0) (reg:SI 2 r2)) (set (reg:SI 8 a0

Re: Bootstrap failure on aarch64-linux-gnu with trunk

On 01/13/2017 04:54 PM, Andrew Pinski wrote: Between revision 244386 and 28, aarch64-linux-gnu started to miscompare bootstrap. These are the options I used: --prefix=`pwd`/../tools \ --enable-languages=c,c++,fortran,go \ --with-cpu=thunderx \ --disable-werr

Re: Bootstrap failure on aarch64-linux-gnu with trunk

On 01/13/2017 07:35 PM, David Edelsohn wrote: On Fri, Jan 13, 2017 at 6:56 PM, Jeff Law wrote: On 01/13/2017 04:54 PM, Andrew Pinski wrote: Between revision 244386 and 28, aarch64-linux-gnu started to miscompare bootstrap. These are the options I used: --prefix=`pwd`/../tools \ --enable

Re: Bootstrap failure on aarch64-linux-gnu with trunk

On 01/13/2017 05:57 PM, Andrew Pinski wrote: On Fri, Jan 13, 2017 at 3:56 PM, Jeff Law wrote: On 01/13/2017 04:54 PM, Andrew Pinski wrote: Between revision 244386 and 28, aarch64-linux-gnu started to miscompare bootstrap. These are the options I used: --prefix=`pwd`/../tools \ --enable

Re: make[1]: *** wait: No child processes during make -j8 check

On 01/16/2017 05:37 PM, Martin Sebor wrote: I've run into this failure during make check in the past with a very large make -j value (such as -j128), but today I've had two consecutive make check runs fail with -j12 and -j8 on my 8 core laptop with no much else going on. The last thing running w

Re: make[1]: *** wait: No child processes during make -j8 check

On 01/17/2017 09:59 AM, Martin Sebor wrote: On 01/17/2017 08:30 AM, Jeff Law wrote: On 01/16/2017 05:37 PM, Martin Sebor wrote: I've run into this failure during make check in the past with a very large make -j value (such as -j128), but today I've had two consecutive make check runs

Re: Obsolete powerpc*-*-*spe*

On 02/13/2017 08:07 PM, Segher Boessenkool wrote: Hi all, I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes the spe.h installed header file, all the __builtin_spe* intrinsics, the -mfloat-gprs= command-line option, and the support for the SPE ABIs. No one has properly test

Re: RFC: Treat plugins as first class citizens

On 03/14/2017 07:44 AM, Richard Biener wrote: On Tue, Mar 14, 2017 at 2:38 PM, Nick Clifton wrote: Hi Richard, I was thinking that it would be nice to make plugins a "first-class citizen" in the gcc world by having a proper directory structure and integration into the rest of gcc. I bel

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 12:47 PM, Bernd Schmidt wrote: On 03/17/2017 07:38 PM, Pinski, Andrew wrote: One of the following revision caused a bootstrap comparison failure on aarch64-linux-gnu: r246225 r246226 r246227 Can you help narrow that down? I'm provisioning an aarch64 system now. jeff

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 03:31 PM, Andrew Pinski wrote: On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt wrote: On 03/17/2017 07:38 PM, Pinski, Andrew wrote: One of the following revision caused a bootstrap comparison failure on aarch64-linux-gnu: r246225 r246226 r246227 Can you help narrow that down?

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

On 03/17/2017 05:51 PM, Jim Wilson wrote: On 03/17/2017 04:12 PM, Jim Wilson wrote: I have access to a fast box that isn't otherwise in use at the moment so I'm taking a look. r246225 builds OK. r246226 does not. So it is Bernd's combine patch. A little experimenting shows that the compare d

Re: [BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

On 02/12/2017 03:57 PM, Jan-Benedict Glaw wrote: Hi! When building a cross-gcc using config_list.mk using r245361 (as both, a freshly built `build' compiler and as sources for the cross-compiler), my build robot fails (see http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565). S

Re: Historic gcc 0.9 tapes

On 03/25/2017 12:26 AM, Marshall Lee Whittaker wrote: Hi, I was looking through the historic archives of gcc at ftp.vim.org and found a very old version of gcc dating back to 1987. I was wondering if the below thread still applies? As in, does anybody happen to have any very old original tapes

Re: About global var reg optimization

On 04/03/2017 09:42 AM, Aurelien Buhrig wrote: Hello ! I would like to use a fixed global register (here, as an applicative stack pointer) and would like gcc (6.3 / private backend) to actually optimize the following code using postinc/predec addressing mode on this global fixed reg itself (a4 h

Re: suggestion: c compiler warning for failure to test result

On 04/25/2017 05:02 PM, Martin Sebor wrote: On 04/25/2017 02:35 PM, Joe Perches wrote: A possibly useful addition similar to: __attribute__((warn_unused_result)) might be __attribute__((warn_untested_result)) for things like allocation failures that are not verified before use. I agree tha

Re: LCOV of current GCC

On 04/28/2017 03:38 AM, Richard Biener wrote: On Fri, Apr 28, 2017 at 11:07 AM, Martin Liška wrote: Hello. I've been working on some patches for GCOV and lcov was of my test scenarios. I'm sending link to static HTML pages made by the tool which are recorded for GCC (w/o bootstrap) build + run

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

On 04/28/2017 05:15 PM, Segher Boessenkool wrote: Hi Andrew, On Wed, Apr 26, 2017 at 10:18:55AM +0100, Andrew Jenner wrote: On 13/03/2017 18:01, Andrew Jenner wrote: I volunteer to be the point of contact for the SPE port. Over here at CodeSourcery/Mentor Embedded, we have a strong interest i

Re: .bad_compare in bootstrap of head

On 05/04/2017 12:59 AM, Andreas Schwab wrote: On Mai 03 2017, Daniel Santos wrote: Anybody else getting bootstrap failures from the head? gcc/tree-outof-ssa.o differs gcc/insn-output.o differs gcc/tree-chrec.o differs gcc/cp/semantics.o differs gcc/lto-cgraph.o differs gcc/builtins.o differs

Re: .bad_compare in bootstrap of head

On 05/04/2017 07:26 AM, Дмитрий Дьяченко wrote: Fedora 26 x86_64 r247595 ~/src/gcc_current/configure --prefix=/usr/local/gcc_current --enable-static --enable-checking=no --enable-languages=c,c++,lto --enable-plugin --disable-multilib And that may be the key, I've been able to get a similar failu

Re: .bad_compare in bootstrap of head

On 05/04/2017 08:31 AM, Jeff Law wrote: On 05/04/2017 07:26 AM, Дмитрий Дьяченко wrote: Fedora 26 x86_64 r247595 ~/src/gcc_current/configure --prefix=/usr/local/gcc_current --enable-static --enable-checking=no --enable-languages=c,c++,lto --enable-plugin --disable-multilib And that may be the

Re: GCC target_clone support

On 05/05/2017 12:18 PM, Michael Meissner wrote: I'm in the middle of adding support for the target_clone attribute to the PowerPC. At the moment, the x86_64/i386 port is the only port that supports target_clone. I added the arm/s390 port maintainers to this query, because those ports might also

Re: Question about dump_printf/dump_printf_loc

On 05/05/2017 04:37 PM, Steve Ellcey wrote: I have a simple question about dump_printf and dump_printf_loc. I notice that most (all?) of the uses of these function are of the form: if (dump_enabled_p ()) dump_printf_loc (MSG_*, ..); Since dump_enabled_p() is just ch

Re: GCC target_clone support (functionality question)

On 05/06/2017 12:44 AM, Richard Sandiford wrote: Michael Meissner writes: This message is separated from the question about moving code, as it is a questions about the functionality of target_clone support. Right now it looks like target_clone only generates the ifunc handler if there is a cal

Re: dejagnu version update?

On 05/13/2017 04:38 AM, Jakub Jelinek wrote: On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote: I guess neither redhat (https://access.redhat.com/downloads/content/dejagnu/ redirects to a login page but there seem to be 1.5.1 packages) nor SuSE did update dejagnu in the m

Re: Basic Block Statistics

On 05/16/2017 12:24 PM, Will Hawkins wrote: > Hello everyone! > > I apologize if this is not the right venue to ask this question and/or > this is a waste of your time. > > I was just wondering if there are statistics that gcc can emit that > includes either a) the average number of instructions

Re: Basic Block Statistics

On 05/16/2017 12:37 PM, Will Hawkins wrote: > On Tue, May 16, 2017 at 2:33 PM, Jeff Law wrote: >> On 05/16/2017 12:24 PM, Will Hawkins wrote: >>> Hello everyone! >>> >>> I apologize if this is not the right venue to ask this question and/or >>> thi

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