Re: [PING][PATCH] doc: Correct `--enable-version-specific-runtime-libs' support information

On Fri, 29 Nov 2019, Joseph Myers wrote: > > > The `--enable-version-specific-runtime-libs' configuration option is now > > > supported throughout all of our target library subdirectories, so update > > > installation documentation accordingly and also mention that the default > > > for the opt

Re: [PATCH v2 1/2] driver: Do not warn about ineffective `-x' option if no inputs were given

On Fri, 29 Nov 2019, Joseph Myers wrote: > > * gcc.c (process_command): Only warn about an ineffective `-x' > > option if any input files have actually been supplied. > > OK. Applied, thanks for your review. Maciej

Re: Symver attribute

> On 11/15/19 10:05 AM, Jan Hubicka wrote: > > I am by no means expert in the area so feedback is welcome. I would > > like to get the patch to trunk early next week if it works well. > > Thank you Honza for the patch. The idea looks nice to me and I have just > few comments: > > 1) we should al

Re: Symver attribute

> On Fri, 15 Nov 2019, Jan Hubicka wrote: > > > I was originaly supporting multiple symvers like: > > __attribute__ ((__symver__ ("foo@VERS_1"))) int > > __attribute__ ((__symver__ ("foo@VERS_2"))) int > > foo_v1 (void) > > { > > } > > > > but then noticed it is rejected by gas. > > That's

Re: Symver attribute

Hi, > > +static tree > > +handle_symver_attribute (tree *node, tree ARG_UNUSED (name), tree args, > > +int ARG_UNUSED (flags), bool *no_add_attrs) > > +{ > > + tree symver; > > + const char *symver_str; > > + > > + if (TREE_CODE (*node) != FUNCTION_DECL && TREE_CODE (*node) !

Re: Symver attribute

On Sat, 30 Nov 2019, Jan Hubicka wrote: > > I'd rather GCC created those aliases automatically (with names that can't > > be used as C symbols, e.g. containing '.', if possible, or failing that > > implementation-namespace names that are unlikely to conflict with C > > symbols), so that the API

Re: Symver attribute

> On Sat, 30 Nov 2019, Jan Hubicka wrote: > > > > I'd rather GCC created those aliases automatically (with names that can't > > > be used as C symbols, e.g. containing '.', if possible, or failing that > > > implementation-namespace names that are unlikely to conflict with C > > > symbols), so

Re: [patch, fortran] Fix PR 91783

Hi Thomas, This is OK for trunk. Thanks for the patch Paul On Sun, 24 Nov 2019 at 17:10, Thomas Koenig wrote: > > Hello world, > > this patch fixes a 10 regression in dependency checking. The > approach is simple - if gfc_dep_resolver is handed references > with _data, remove that. > > Regress

Re: [PATCH] track dynamic allocation in strlen (PR 91582)

On Tue, 12 Nov 2019 at 02:28, Martin Sebor wrote: > > The attached patch extends the strlen pass to detect out-of-bounds > accesses to memory allocated by calls to other allocation functions > besides calloc and malloc, as well as VLAs, and user-defined > functions declared with attribute alloc_si

Fix crossmodule ipa-inline hint

Hi, while looking into Firefox perofmrance I noticed that inline hint marking crossmodule calls is off most of time. It is based on comparing lto_file_data which is often released because ipa-icf or profile merging has read the function body before inlining. Moreover this logic is broken for incr

Re: [Patch, build] Unbreak objc build

On 11/26/19, Tobias Burnus wrote: > When I tried to bootstrap with --enable-languages=default, which > includes objc, it failed to build libobj. > > As Rhy0lite on IRC correctly guessed, the issue is that the cet.m4 file > is at a different location. I wonder why no one had the problem before > in

Re: [PATCH] PR85678: Change default to -fno-common (porting_to for GCC 10)

On 11/29/19, Wilco Dijkstra wrote: > Hi Martin, > >> I've noticed quite significant package failures caused by the revision. > > How significant? Is it mostly the common mistake of forgetting extern? > >> Would you please consider documenting this change in porting_to.html >> (and in changes.html)

Re: Symver attribute

Hi, this is patch incorporating (I hope) all the suggestions and corrections which I applied. I will work incremnetaly on supporting the name@@@node semantics which is bit different from @ and @@ one by actually removing the original symbol. Here I need to change assembler name of the symbol itse