Re: can we rename vec<>.safe_push() to vec<>.push()?

On Thu, Aug 31, 2017 at 1:41 PM, Aldy Hernandez wrote: > So ok to default to a lazy one, or are suggesting we leave things > as they are? Either leave as-is or default to the lazy one. Richard. > Aldy > > On Thu, Aug 31, 2017 at 7:38 AM, Richard Biener > wrote: >>

Re: Issues when emitting sjlj dispatch table

On Tue, Sep 5, 2017 at 12:20 PM, Claudiu Zissulescu wrote: > Hi guys, > > I found an ICE when emitting sjlj dispatch table for ARC. Namely, in > sjlj_emit_dispatch_table() function, we create a dispatch table where the > case elements are having the high value is set to NULL (except.c:1326). >

Re: RFC: Improving GCC8 default option settings

On Wed, Sep 13, 2017 at 3:21 AM, Michael Clark wrote: > >> On 13 Sep 2017, at 1:15 PM, Michael Clark wrote: >> >> - https://rv8.io/bench#optimisation >> - https://rv8.io/bench#executable-file-sizes >> >> -O2 is 98% perf of -O3 on x86-64 >> -Os is 81% perf of -O3 on x86-64 >> >> -O2 saves 5% space

Re: RFC: Improving GCC8 default option settings

On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek wrote: > On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote: >> On its own -O3 doesn't add much (some loop opts and slightly more >> aggressive inlining/unrolling), so whatever it does we >> should consid

Re: RFC: Improving GCC8 default option settings

On September 13, 2017 5:35:11 PM GMT+02:00, Jan Hubicka wrote: >> On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek >wrote: >> > On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote: >> >> On its own -O3 doesn't add much (some loop opts and slig

Re: RFC: Improving GCC8 default option settings

On September 13, 2017 6:24:21 PM GMT+02:00, Jan Hubicka wrote: >> >I don't see static profile prediction to be very useful here to find >> >"really >> >hot code" - neither in current implementation or future. The problem >of >> >-O2 is that we kind of know that only 10% of code somewhere matters >

Re: RFC: Improving GCC8 default option settings

On Wed, Sep 13, 2017 at 5:08 PM, Allan Sandfeld Jensen wrote: > On Mittwoch, 13. September 2017 15:46:09 CEST Jakub Jelinek wrote: >> On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote: >> > On its own -O3 doesn't add much (some loop opts and slightly more &

Re: RFC: Improving GCC8 default option settings

On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote: > On 12/09/17 16:57, Wilco Dijkstra wrote: >> >> [...] As a result users are >> required to enable several additional optimizations by hand to get good >> code. >> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM >>

Re: RFC: Improving GCC8 default option settings

On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote: > On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote: >> On 2017.09.14 at 11:57 +0200, Richard Biener wrote: >>> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras wrote: >>>> On 12/09/17 16:57, Wilco Dijkstra

Re: RFC: Improving GCC8 default option settings

On Thu, Sep 14, 2017 at 12:42 PM, Martin Liška wrote: > On 09/14/2017 12:37 PM, Bin.Cheng wrote: >> On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener >> wrote: >>> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška wrote: >>>> On 09/14/2017 12:07 PM, Markus Trippe

Re: RFC: Improving GCC8 default option settings

On Thu, Sep 14, 2017 at 3:08 PM, Markus Trippelsdorf wrote: > On 2017.09.14 at 14:48 +0200, Richard Biener wrote: >> On Thu, Sep 14, 2017 at 12:42 PM, Martin Liška wrote: >> > On 09/14/2017 12:37 PM, Bin.Cheng wrote: >> >> On Thu, Sep 14, 2017 at 11:24 AM, Richard

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

On Fri, Sep 15, 2017 at 12:07 AM, Jeff Law wrote: > 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 >> c

Re: [RFC] type promotion pass

On September 15, 2017 6:56:04 PM GMT+02:00, Jeff Law wrote: >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

Re: GCC aliasing extension for C

On September 18, 2017 4:12:07 PM GMT+02:00, Andrew Haley wrote: >On 18/09/17 10:48, Florian Weimer wrote: >> Is this a property of the char type, or would other types work as >well, >> for example, double or long double? > >It has to be a character type, I believe. It can be any type. All store

Re: [RFC] type promotion pass

On Mon, Sep 18, 2017 at 4:30 AM, Kugan Vivekanandarajah wrote: > Hi Richard, > > On 16 September 2017 at 06:12, Richard Biener > wrote: >> On September 15, 2017 6:56:04 PM GMT+02:00, Jeff Law wrote: >>>On 09/15/2017 10:19 AM, Segher Boessenkool wrote: >>>

Re: [RFC] type promotion pass

On Tue, Sep 19, 2017 at 4:58 PM, Jeff Law wrote: > 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 sy

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On September 21, 2017 7:38:29 PM GMT+02:00, Carlos O'Donell wrote: >On 09/21/2017 10:50 AM, Thomas Schwinge wrote: >> So my question is, if I've gotten a patch reviewed by someone who is >not >> yet ;-) familiar with that new process, and I nevertheless want to >> acknowledge their time invested

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On September 21, 2017 8:18:39 PM GMT+02:00, Carlos O'Donell wrote: >On 09/21/2017 11:56 AM, Richard Biener wrote: >>> Not yet. >> >> I think given an OK from an official reviewer entitles you to commit >> it indeed IS matching the formal statement. It bett

Re: How to force gcc to vectorize the loop with particular vectorization width

On Thu, Oct 19, 2017 at 9:22 AM, Denis Bakhvalov wrote: > Hello! > > I have a hot inner loop which was vectorized by gcc, but I also want > compiler to unroll this loop by some factor. > It can be controled in clang with this pragma: > #pragma clang loop vectorize(enable) vectorize_width(8) > Plea

Re: How to force gcc to vectorize the loop with particular vectorization width

ther than AVX vector sizes. Eventually this option is among the valid target attributes for #pragma GCC target > On 19/10/2017, Jakub Jelinek wrote: >> On Thu, Oct 19, 2017 at 10:38:28AM +0200, Richard Biener wrote: >>> On Thu, Oct 19, 2017 at 9:22 AM, Denis Bakhvalov >>&

Re: Have "gcc -v" print information about slow run-time checking?

On Fri, Oct 20, 2017 at 12:40 PM, Thomas Schwinge wrote: > Hi! > > In , we got a user wonder about released vs. > trunk GCC execution times, not knowing that the latter has more run-time > checking enabled. Once that got clarified, the discussion proceeded: > > (In re

Re: How to force gcc to vectorize the loop with particular vectorization width

vx-128 > >But now I have a question: Is it possible in gcc to have vectorization >with vf < 16? No, not at the moment. Richard. >On 20/10/2017, Richard Biener wrote: >> On Fri, Oct 20, 2017 at 12:13 PM, Denis Bakhvalov > >> wrote: >>> Thank you for the r

Re: Handling prefetcher tag collisions while allocating registers

On Tue, Oct 24, 2017 at 1:44 AM, Kugan Vivekanandarajah wrote: > Hi All, > > I am wondering if there is anyway we can prefer certain registers in > register allocations. That is, I want to have some way of recording > register allocation decisions (for loads in loop that are accessed in > steps) a

Re: do we ever thread computed gotos?

On Thu, Oct 26, 2017 at 1:05 PM, 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

Re: do we ever thread computed gotos?

On Thu, Oct 26, 2017 at 2:35 PM, Aldy Hernandez wrote: > > > On 10/26/2017 08:31 AM, Richard Biener wrote: >> >> On Thu, Oct 26, 2017 at 1:05 PM, Aldy Hernandez wrote: >>> >>> Howdy. >>> >>> In the backwards threader we attempt to threa

Re: Question about generated type for common block in fortran

On October 26, 2017 6:47:59 PM GMT+02:00, "Bin.Cheng" 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), t

Re: [std-discussion] Is this union aliasing code well-defined?

On Fri, Oct 27, 2017 at 3:00 PM, Yubin Ruan wrote: > +Cc gcc-list. > > Does any gcc developer have any comments? See PR82224. The code is valid. > On Mon, Sep 25, 2017 at 01:41:55PM -0700, Myriachan wrote: >> This question that "supercat" posted on Stack Overflow ran into an >> interesting prob

Re: Problems in IPA passes

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 that is not safe to do. Various paths through those routines >will access static objects within tree-vrp.c which

Re: [std-discussion] Is this union aliasing code well-defined?

On October 29, 2017 2:46:42 AM GMT+01:00, Yubin Ruan wrote: >On 10/27/2017 04:54 PM, Richard Biener wrote: >> On Fri, Oct 27, 2017 at 3:00 PM, Yubin Ruan >wrote: >>> +Cc gcc-list. >>> >>> Does any gcc developer have any comments? >> >> See

Re: Problems in IPA passes

On October 31, 2017 4:47:06 AM GMT+01:00, 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: >>> >>> Jan, >>> >>> What's the purpose behind calling vrp_meet and >>> extract_range_from_unary_expr from within the IP

Re: Problems in IPA passes

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: >>> Hi Jeff, >>> >>> On 28 October 2017 at 18:28, Jeff Law wrote: Jan, What's the purpo

Re: Problems in IPA passes

On October 31, 2017 4:49:20 PM GMT+01:00, Jeff Law wrote: >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

Re: Problems in IPA passes

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 at least w

Re: libmvec simd math functions in fortran

On Thu, Nov 2, 2017 at 1:49 PM, Szabolcs Nagy wrote: > On 01/11/17 16:47, Szabolcs Nagy wrote: >> On 01/11/17 16:26, Jakub Jelinek wrote: >>> On Wed, Nov 01, 2017 at 04:23:11PM +, Szabolcs Nagy wrote: is there a way to get vectorized math functions in fortran? in c code there is

Re: libmvec simd math functions in fortran

On Thu, Nov 2, 2017 at 2:07 PM, Richard Biener wrote: > On Thu, Nov 2, 2017 at 1:49 PM, Szabolcs Nagy wrote: >> On 01/11/17 16:47, Szabolcs Nagy wrote: >>> On 01/11/17 16:26, Jakub Jelinek wrote: >>>> On Wed, Nov 01, 2017 at 04:23:11PM +, Szabolcs Nagy wrot

Re: libmvec simd math functions in fortran

On Thu, Nov 2, 2017 at 7:42 PM, Toon Moene wrote: > On 11/01/2017 05:26 PM, Jakub Jelinek wrote: > >> On Wed, Nov 01, 2017 at 04:23:11PM +, Szabolcs Nagy wrote: >>> >>> is there a way to get vectorized math functions in fortran? >>> >>> in c code there is attribute simd declarations or openmp

GCC 8.0.0 Status Report (2017-11-03)

Status == The feature development phase of GCC 8, Stage 1, is coming to its ends at Friday, Nov. 17th (as usual you can use your local timezone to your own advantage). This means that from Saturday, Nov. 18th we will be in Stage 3 which allows for general bugfixing. All feature implementati

Re: Question about generated type for common block in fortran

On Tue, Nov 7, 2017 at 4:55 PM, Michael Matz wrote: > Hi, > > On Thu, 26 Oct 2017, Richard Biener wrote: > >> >Hi, >> >I am looking into DSE transformation of some fortran codes. Given >> >below fortran declarations: >> > >> > rea

Re: Question about generated type for common block in fortran

On Wed, Nov 8, 2017 at 3:45 PM, Michael Matz wrote: > 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

Re: getting the right boolean type

On Thu, Nov 9, 2017 at 3:44 PM, Andrew MacLeod wrote: > I'm a little confused. In gimple I need to do a comparison between 2 > values, and I create a boolean_type_node result. > I then combine it with an existing condition, but fortran is crapping out on > me because the boolean_type I created is

Re: getting the right boolean type

On Thu, Nov 9, 2017 at 4:24 PM, Andrew MacLeod wrote: > On 11/09/2017 10:16 AM, Richard Biener wrote: >> >> On Thu, Nov 9, 2017 at 3:44 PM, Andrew MacLeod >> wrote: >>> >>> I'm a little confused. In gimple I need to do a comparison between 2 >>

Re: Types of operands in a gimple equality operation

On Fri, Nov 10, 2017 at 2:49 PM, Andrew MacLeod wrote: > Before I open a PR, I want to confirm my beliefs. > > > Is it not true that both operations of a gimple operation such as == or != > must satisfy types_compatible_p (op1_type, op2_type) ? Even when one is a > constant? > > given : > > _1

Re: Types of operands in a gimple equality operation

On Fri, Nov 10, 2017 at 3:54 PM, Andrew MacLeod wrote: > On 11/10/2017 09:03 AM, Richard Biener wrote: >> >> On Fri, Nov 10, 2017 at 2:49 PM, Andrew MacLeod >> wrote: >>> >>> Before I open a PR, I want to confirm my beliefs. >>> >>> >

Re: Question about generated type for common block in fortran

On Mon, Nov 13, 2017 at 11:01 AM, Michael Matz wrote: > 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 pu

Re: potential bug in libstc++ ?

On Tue, Nov 14, 2017 at 3:35 PM, Sergey Nenakhov wrote: > Hello. > > Excuse me if I'm posting to the wrong mailing list. I've grabbed gcc-7.2.0 > sources and noticed strange statement in the file > gcc-7.2.0\libstdc++-v3\include\bits\locale_conv.h which seems like a bug > to me: > Line 434 and 43

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

On November 17, 2017 11:20:45 PM GMT+01:00, 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: Finding all CALL_EXPR tree nodes during GENERIC

On November 18, 2017 5:38:35 PM GMT+01:00, Katsunori Kumatani wrote: >Hello, I'm doing some testing with a gcc plugin (also helped me >understand a lot of how GCC works) but I've hit a roadblock. > >I want to find all of a function body's CALL_EXPR nodes (i.e. what >calls it has) early during GEN

Re: Possible suboptimal code generated in 32-bit ABI mode

On Sun, Nov 19, 2017 at 5:35 PM, Richard Bradfield wrote: > On Sun, Nov 19, 2017 at 04:19:45PM +, bradf...@fstab.me wrote: >> >> For reference, I am compiling everything using gcc trunk, at commit >> 254929 from Sun Nov 19, and I am benchmarking on a Skylake i7-6700K >> at 4.0GHz. > > > And so

Re: Finding all CALL_EXPR tree nodes during GENERIC

change things. Richard. > On Sat, Nov 18, 2017 at 6:49 PM, Richard Biener > wrote: >> On November 18, 2017 5:38:35 PM GMT+01:00, Katsunori Kumatani >> wrote: >>>Hello, I'm doing some testing with a gcc plugin (also helped me >>>understand a lot of how GC

GCC 8.0.0 Status Report (2017-11-20)

Status == GCC 8 is now in Stage 3 which means open for general bugfixing. As usual we're now in a short period where posted but not yet reviewed feature patches can be accepted. As time goes by even those will be no longer appropriate. As usual in this time not all regressions have been pr

Re: loading of zeros into {x,y,z}mm registers

On Fri, Dec 1, 2017 at 6:45 AM, Kirill Yukhin wrote: > Hello Jan, > On 29 Nov 08:59, Jan Beulich wrote: >> Kirill, >> >> in an unrelated context I've stumbled across a change of yours >> from Aug 2014 (revision 213847) where you "extend" the ways >> of loading zeros into registers. I don't underst

Re: GCC 7.3 timeline?

On December 6, 2017 3:29:28 PM GMT+01:00, Paul Smith wrote: >Hi all; are we on track to have a GCC 7.3 sometime in the next few >weeks, as per usual for the last few years? Not looking for a date, >just a feeling. > >I'm not sure why my toolchain rollouts always seem to fall right around >the ti

Re: question about inlining

On December 6, 2017 6:38:11 PM GMT+01:00, Martin Sebor wrote: >While testing a libstdc++ patch that relies on inlining to >expose a GCC limitation I noticed that the same member function >of a class template is inlined into one function in the test but >not into the other, even though it is inline

Re: question about inlining

On December 7, 2017 2:15:53 AM GMT+01:00, Martin Sebor wrote: >On 12/06/2017 12:11 PM, Richard Biener wrote: >> On December 6, 2017 6:38:11 PM GMT+01:00, Martin Sebor > wrote: >>> While testing a libstdc++ patch that relies on inlining to >>> expose a GCC limitation

Re: question about inlining

On December 8, 2017 4:26:05 AM GMT+01:00, Martin Sebor wrote: >On 12/06/2017 11:45 PM, Richard Biener wrote: >> On December 7, 2017 2:15:53 AM GMT+01:00, Martin Sebor > wrote: >>> On 12/06/2017 12:11 PM, Richard Biener wrote: >>>> On December 6, 2017 6:38:11 PM G

Re: question about inlining

On December 8, 2017 6:50:17 PM GMT+01:00, Martin Sebor wrote: >On 12/08/2017 12:00 AM, Richard Biener wrote: >> On December 8, 2017 4:26:05 AM GMT+01:00, Martin Sebor > wrote: >>> On 12/06/2017 11:45 PM, Richard Biener wrote: >>>> On December 7, 2017 2:15:53 AM G

Re: nexttoward/nextafter attribute question

On Mon, Dec 11, 2017 at 11:34 PM, Joseph Myers wrote: > On Mon, 11 Dec 2017, Steve Ellcey wrote: > >> the attribute. The other is why the function would be pure with >> -fno-math-errno but const otherwise. I would think that the -fno-math-errno >> version would be const (stricter than pure) sinc

Re: nexttoward/nextafter attribute question

On Tue, Dec 12, 2017 at 2:43 PM, Joseph Myers wrote: > On Tue, 12 Dec 2017, Jakub Jelinek wrote: > >> Any other functions that are using ATTR_MATHFN_FPROUNDING_ERRNO or >> ATTR_MATHFN_FPROUNDING and aren't affected by fesetround? > > drem, fmod, frexp, ilogb, modf, remainder, remquo, significand s

GCC 7.3 Status report (2017-12-18)

Status == GCC 7 is in regression and documentation fixes mode and it is time to think about backports you want/need to do for GCC 7.3. The plan is to do a release candidate for GCC 7.3 in the second week of January following by a release a week after that. As usual the branch is in good sha

Re: [question] replacing called function by gimple_call_set_fndecl doesn't actually take effect

On Fri, Jan 5, 2018 at 5:57 AM, Tong Zhou wrote: > Hi, > > I am new to gcc and was trying to implement a gimple pass today. One thing > I tried to do was to make a call_stat that originally calls malloc call > another function like new_malloc. I used gimple_call_set_fndecl and also > did update_st

GCC 8.0.0 Status Report (2018-01-08), Stage 3 ends Jan 14th

Status == GCC 8 is in development stage 3 currently but that is going to end at the end of Sunday, Jan 14th after which we go into regression and documentation fixes mode similar as if trunk was a release branch. We're still in pretty bad shape regression-wise but I hope things will get bett

GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

Status == GCC 8 is in regression and documentation fixes stage now similar as if trunk was a release branch. We're still in pretty bad shape regression-wise. Please also take the opportunity to check the state of your favorite host/target combination to make sure building and testing works

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

On Tue, Jan 16, 2018 at 8:20 PM, Andrew Roberts wrote: > Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0 > snapshot, it still is working fine with 7.2.0. > I've added bug: 83903 > > x86_64, armv6, armv7, aarch64 all seem fine on linux. I've been building > with latest gmp (

GCC 7 branch now frozen for the release of GCC 7.3

The GCC 7 branch is now frozen in preparation for GCC 7.3 RC1. All changes from this point to the final release of GCC 7.3 now require release manager approval. As said I'm happily taking adjustments/enhancements to the spectre mitigation patches (as well as rs6000 backports). Richard.

GCC 7.3 Release Candidate available from gcc.gnu.org

A release candidate for GCC 7.3 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-7.3.0-RC-20180117/ and shortly its mirrors. It has been generated from SVN revision 256792. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and r

Re: Google Summer of Code 2018: Call for mentors and ideas

On January 19, 2018 5:34:35 PM GMT+01:00, Joseph Myers wrote: >On Fri, 19 Jan 2018, Martin Jambor wrote: > >> Hi Joseph, >> >> On Wed, Jan 17 2018, Joseph Myers wrote: >> > On Wed, 17 Jan 2018, Martin Jambor wrote: >> > >> >> 3?) Joseph Myers brought up idea to do "built-in functions for TS >186

Second GCC 7.2 Release Candidate available from gcc.gnu.org

A second release candidate for GCC 7.3 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/7.3.0-RC-20180122/ and shortly its mirrors. It has been generated from SVN revision 256937. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and

Re: Bugzilla timing out

On Mon, Jan 22, 2018 at 7:08 PM, Frank Ch. Eigler wrote: > Hi - > >> Problems are still occurring for me; Bugzilla gives me 504 Gateway >> Time-outs when I try to access it tonight... > > OK, we reworked some of the database routine maintenance workload, > e.g., a nightly cleanup pass that was qui

GCC 7.3 Released

The GNU Compiler Collection version 7.3 has been released. GCC 7.3 is a bug-fix release from the GCC 7 branch containing important fixes for regressions and serious bugs in GCC 7.2 with more than 99 bugs fixed since the previous release. This release includes code generation options to mitigate

GCC 7.4 Status report (2018-01-25)

Status == The GCC 7 branch is again open for regression and documentation fixes. Quality Data Priority # Change from last report --- --- P1 P2 164 + 2 P3 22 + 9 P4 1

Re: Resolving LTO symbols for static library boundary

On February 5, 2018 12:26:58 PM GMT+01:00, Allan Sandfeld Jensen wrote: >Hello GCC > >In trying to make it possible to use LTO for distro-builds of Qt, I >have again >hit the problem of static libraries. In Qt in general we for LTO rely >on a >library boundary, where LTO gets resolved when gene

Re: finding bugs deferred from previous releases

On Wed, Feb 7, 2018 at 5:37 AM, Alexandre Oliva wrote: > Hi, > > In this round of GCC stabilization, I've noticed a larger than usual > number of bugs that carried over from earlier cycles, with notes > indicating it was too late to fix them during stabilization. > > I wish we had some means to ma

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

On Mon, Feb 5, 2018 at 6:06 AM, Simon Marchi wrote: > Hi Martin, > > Thanks for the reply. > > On 2018-02-04 02:17 PM, Martin Sebor wrote: >> Printing the suffix is unhelpful because it leads to unnecessary >> differences in diagnostics (even in non-template contexts). For >> templates with non-t

Re: Willing to apply for GSoC 2018

On Thu, Feb 15, 2018 at 6:20 PM, 김규래 wrote: > Hi, my name is Ray Kim. > > I am a Junior EE student in Sogang Univ. Korea. > > I wish applying to gcc for GSoC 2018. > > > > I'm have a little experience on C, C++, Parallelism/Concurrency and CUDA, > > however mostly very new to compiler technology.

Re: determining aggregate member from MEM_REF

On Thu, Feb 15, 2018 at 6:28 PM, Martin Sebor wrote: > There are APIs to determine the base object and an offset > into it from all sorts of expressions, including ARRAY_REF, > COMPONENT_REF, and MEM_REF, but none of those I know about > makes it also possible to discover the member being referred

Re: determining aggregate member from MEM_REF

On Fri, Feb 16, 2018 at 8:07 PM, Martin Sebor wrote: > On 02/16/2018 04:22 AM, Richard Biener wrote: >> >> On Thu, Feb 15, 2018 at 6:28 PM, Martin Sebor wrote: >>> >>> There are APIs to determine the base object and an offset >>> into it from all

Re: GSoC

On Mon, Feb 26, 2018 at 5:35 PM, Dushyant Pratap Singh wrote: > Hello GCC community, > My name is Dushyant and I am interested in Gsoc at GCC .I am pursuing > Integrated B.Tech (Computer Science) and M.Tech (software engineering) from > Gautam Buddha University, India. Currently I am in 4th year o

Re: determining aggregate member from MEM_REF

On Mon, Feb 26, 2018 at 9:04 PM, Jeff Law wrote: > 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 >>

Re: GSOC 2018 - Textual LTO dump tool project

On Sun, Feb 25, 2018 at 10:46 AM, Martin Jambor wrote: > Hello Hrishikesh, > > I apologize for replying to you this late, this has been a busy week > and now I am traveling. > > On Mon, Feb 19 2018, Hrishikesh Kulkarni wrote: >> Hi, >> >> I am Hrishikesh Kulkarni currently studying as an undergrad

Re: GSOC 2018 - Textual LTO dump tool project

On Fri, Mar 2, 2018 at 10:24 AM, Hrishikesh Kulkarni wrote: > Hello everyone, > > > Thanks for your suggestions and engaging response. > > Based on the feedback I think that the scope of this project comprises of > following three indicative actions: > > > 1. Creating separate driver i.e. separate

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

On March 4, 2018 1:30:39 AM GMT+01:00, Peter Bergner wrote: >On 3/3/18 5:47 PM, Peter Bergner wrote: >> On 3/3/18 10:29 AM, Jeff Law wrote: >>> Here's the comment from regstat.c: >>> >>> /* We have a problem with any pseudoreg that lives >>> across the setjmp. ANSI

Re: Interested to contribute in gsoc project

On Sun, Mar 4, 2018 at 8:28 PM, shreya pohekar wrote: > > Hello , > I am Shreya Pohekar, 2nd year student of University Institute of Technology > ,RGPV ,Bhopal, India. I am interested in applying in GSoC 2018, and would > like to contribute to the project : Parallelize the compilation using thre

Re: How big (and fast) is going to be GCC 8?

On Tue, Mar 6, 2018 at 11:12 AM, Martin Liška wrote: > Hello. > > Many significant changes has landed in mainline and will be released as GCC > 8.1. > I decided to use various GCC configs we have and test how there configuration > differ > in size and also binary size. > > This is first part whe

Re: eliminate dead stores across functions

On Tue, Mar 6, 2018 at 1:00 PM, Prathamesh Kulkarni wrote: > Hi, > For the following test-case, > > int a; > > __attribute__((noinline)) > static void foo() > { > a = 3; > } > > int main() > { > a = 4; > foo (); > return a; > } > > I assume it's safe to remove "a = 4" since 'a' would be o

Re: GSOC 2018 - Textual LTO dump tool project

On Tue, Mar 6, 2018 at 2:30 PM, Hrishikesh Kulkarni wrote: > Hi, > > Thank you Richard and Honza for the suggestions. If I understand correctly, > the issue is that LTO file format keeps changing per compiler versions, so > we need a more “stable” representation and the first step for that would b

Re: GSOC 2018 - Textual LTO dump tool project

On Tue, Mar 6, 2018 at 4:02 PM, Jan Hubicka wrote: >> On Tue, Mar 6, 2018 at 2:30 PM, Hrishikesh Kulkarni >> wrote: >> > Hi, >> > >> > Thank you Richard and Honza for the suggestions. If I understand correctly, >> > the issue is that LTO file format keeps changing per compiler versions, so >> > w

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

On Tue, Mar 6, 2018 at 4:21 PM, 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

Re: eliminate dead stores across functions

On Tue, Mar 6, 2018 at 4:50 PM, Bin.Cheng wrote: > On Tue, Mar 6, 2018 at 2:28 PM, Richard Biener > wrote: >> On Tue, Mar 6, 2018 at 1:00 PM, Prathamesh Kulkarni >> wrote: >>> Hi, >>> For the following test-case, >>> >>> int a;

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

On Tue, Mar 6, 2018 at 9:02 PM, Renlin Li wrote: > Hi Richard, > > > On 06/03/18 16:04, Richard Biener wrote: >> >> On Tue, Mar 6, 2018 at 4:21 PM, Renlin Li wrote: >>> >>> Hi all, >>> >>> The problem described here probably onl

Re: Compiling c++ template is very slow.

On Fri, Mar 9, 2018 at 3:33 AM, Fis Trivial wrote: > > I tried to use c++ template to generate code for a personal project, but > found that the compilation time needed with g++ is much > slower(exponentially) than with clang++. > > This is a code snippet for testing purpose: > > #include > > tem

Re: Compiling c++ template is very slow.

On Fri, Mar 9, 2018 at 11:32 AM, Richard Biener wrote: > On Fri, Mar 9, 2018 at 3:33 AM, Fis Trivial wrote: >> >> I tried to use c++ template to generate code for a personal project, but >> found that the compilation time needed with g++ is much >> slower(exp

Re: Compiling c++ template is very slow.

On Fri, Mar 9, 2018 at 2:08 PM, Nathan Sidwell wrote: > On 03/09/2018 06:51 AM, Richard Biener wrote: >> >> On Fri, Mar 9, 2018 at 11:32 AM, Richard Biener >> wrote: > > >> callgrind shows that propagate_binfo_offsets recursing >> to self very many tim

Re: GSOC 2018 - Textual LTO dump tool project

On Sun, Mar 11, 2018 at 8:23 PM, Hrishikesh Kulkarni wrote: > Hi, > > Greetings! Please find my draft proposal for GSOC attached herewith. I am > very grateful to all of you for your inputs, suggestions and directions. I > have tried to assimilate these inputs received from you to convert it into

Re: cross compiled output differs

On Sat, Mar 10, 2018 at 12:58 PM, Milan Ton wrote: > Hi: > > I built two versions -- linux/mingw -- of a 32-bit gcc cross compiler > of codebase 7.3.0 on fedora 20 (gcc 4.8). Then I compiled an embedded > project using the both cross compilers in the same build > environment. An assemble code insp

Re: [ Plugins ] Read-only, or...?

On Mon, Mar 12, 2018 at 3:47 PM, Deruupu Sutoomo wrote: > Hello! I have a question regarding Plugins... > > I implemented a small one as a test to get used to working with GIMPLE and > basic blocks. I read the Plugin API page, the wiki, and followed a tutorial > to get started. However, I seem to

Re: cross compiled output differs

On Mon, Mar 12, 2018 at 5:11 PM, Milan Ton wrote: > > Nathan, Richard: > > sorry if it wasn't clear: my target was a 32-bit embedded system for that I > built two cross compilers to be run on two hosts -- linux32 and mingw32, my > build system was Fedora x86_64 (with gcc -m32 and i686-w64-mingw32-

Re: GSOC 2018 - Textual LTO dump tool project

Drive link to Draft Proposal: > > https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7ljTDLS1xMwvK5w/edit > > > Regards, > > Hrishikesh > > > > > On Mon, Mar 12, 2018 at 4:45 PM, Richard Biener > wrote: >> >> On Sun, Mar 11, 2018 at 8:23

Re: GSOC

On Wed, Mar 14, 2018 at 5:34 PM, Martin Jambor wrote: > Hello Prashant, > > On Thu, Mar 08 2018, prashant kumar wrote: >> Hello sir my self *Prashant kumar *second year B.TECH student and i am >> interesting in *"GCC plugin Api" *project .i have a good hand in c,c++ >> languages .Can u tell me wha

Re: GSOC 2018 - Textual LTO dump tool project

let's ask the Mentor for the project, Martin, for his opinion first. Martin? Thanks, Richard. > Drive link to Proposal: > https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7ljTDLS1xMwvK5w/edit > > Regards, > > Hrishikesh > > On Wed, Mar 14, 2018 at 8:28

Re: GSOC Question about the parallelization project

On Fri, Mar 16, 2018 at 5:25 PM, Sebastiaan Peters wrote: > Hello, > > My name is Sebastiaan Peters, currently an undergrad compsci student from The > Netherlands. > > I'm interested in the project about parallelizing the compilation with > threads project. Thanks for your interest in this proj

<    8   9   10   11   12   13   14   15   16   17   >