Re: [PATCH] fortran: C++ support for generating C prototypes

Am 12.05.19 um 00:02 schrieb Jakub Jelinek: Is it correct to use macros in user namespace? Shouldn't they be say __ prefixed, or even have __GFC_ or __GFORTRAN_ in them? I think Jakub has a point there -- something like __GFC_DOUBLE_COMPLEX would probably be better. So, OK with that change.

Re: [PATCH] fortran: C++ support for generating C prototypes

On Sun, May 12, 2019 at 11:06 AM Thomas Koenig wrote: > > Am 12.05.19 um 00:02 schrieb Jakub Jelinek: > > Is it correct to use macros in user namespace? Shouldn't they be say __ > > prefixed, or even have __GFC_ or __GFORTRAN_ in them? > > I think Jakub has a point there -- something like __GFC_D

Re: [PATCH] fortran: C++ support for generating C prototypes

Am 12.05.19 um 10:29 schrieb Janne Blomqvist: Thanks, committed as r271106. I prefixed the macros with __GFORTRAN_, as that seems clearer to users where those come from as gfc seems used mostly in the compiler internals. Sounds good. Any opinions whether it should be committed to 9 as well?

[committed] Accept code attributes as rtx codes in .md files

The recent AArch64 absolute difference patterns had to go through some hoops to pair max/min rtx codes with the same signedness. I also need to pair signed/unsigned codes with sign/zero extension for some SVE ACLE patterns. This patch therefore supports <...> as rtx codes, like we already do for m

Re: malloc cannot alias preexisting pointers

Marc Glisse writes: > Hello, > > this patch lets gcc know that if a pointer existed before the call to > malloc, the result of malloc cannot alias it. This is a bit ad hoc and > fragile. A small improvement would be, when the 2 statements are in the > same bb but in the wrong order, to check if

Re: malloc cannot alias preexisting pointers

On Sun, 12 May 2019, Richard Sandiford wrote: Marc Glisse writes: Hello, this patch lets gcc know that if a pointer existed before the call to malloc, the result of malloc cannot alias it. This is a bit ad hoc and fragile. A small improvement would be, when the 2 statements are in the same bb

Fwd: [Patch] Fix assembler invocation on sparc-sun-solaris2

Hi! I tried building a cross-compiler for `sparc-sun-solaris2`, but the resulting GCC executable wouldn't compile anything, always failing with: "as: unrecognized option '-m32'". After extensive research, I found that `as` takes `--32`/`--64`, instead of `-m32`/`-m64`. The patched GCC now does comp

Re: [C++ PATCH, PING^2] PR60531 - Wrong error about unresolved overloaded function

ping again On 26/04/2019 19:58, Harald van Dijk wrote: ping On 13/04/2019 10:01, Harald van Dijk wrote: Hi, For PR60531, GCC wrongly rejects function templates with explicitly specified template arguments as overloaded. They are resolved by resolve_nondeduced_context, which is normally called

New Swedish PO file for 'gcc' (version 9.1.0)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-9.1.0.sv.po', has jus

Re: [PATCH, X86] Fix PR82920 (code part).

> On 10 May 2019, at 22:22, Uros Bizjak wrote: > > On Fri, May 10, 2019 at 11:03 PM Iain Sandoe wrote: >> >> PR82920 is about CET fails on Darwin. >> >> Initially, this was expected to be just a testsuite issue, however it turns >> out that the indirection thunks code has inconsistent handl

[Darwin, libgcc, comitted] Allow vec save asm to build with modern assembler.

Some of the newer assemblers for Darwin check that the CPU type is consistent with the file type and fail to build when they don’t match. Fixed thus for trunk thanks Iain libgcc/ 2019-05-12 Iain Sandoe * config/rs6000/darwin-vecsave.S: Set .machine appropriately. Index: libgcc/con

Re: [PATCH] fortran: C++ support for generating C prototypes

On Sun, May 12, 2019 at 11:29 AM Janne Blomqvist wrote: > > On Sun, May 12, 2019 at 11:06 AM Thomas Koenig wrote: > > (I thought for a second about guarding about double inclusion, but > > including prototypes twice is harmless, and this should be the > > user's responsibility). > > I thought abo

Re: [PATCH] fortran: C++ support for generating C prototypes

On Sun, May 12, 2019 at 10:36:09PM +0300, Janne Blomqvist wrote: > On Sun, May 12, 2019 at 11:29 AM Janne Blomqvist > wrote: > > > > On Sun, May 12, 2019 at 11:06 AM Thomas Koenig > > wrote: > > > (I thought for a second about guarding about double inclusion, but > > > including prototypes twice

RE: [PATCH] Implement P0966 std::string::reserve should not shrink

It's been a while, but thought I'd check in again now that GCC 9 has been branched, and master is now on GCC 10. I've merged my changes with the latest code and attached a diff... Let me know if there's any thoughts on this. Thanks, -Andrew -Original Message- From: gcc-patches-ow...@g

Re: [PATCH] fortran: C++ support for generating C prototypes

Hi Janne, I do not think we need to add header guards. The headers, as we emit them, contain prototypes only, so repeated inclusions Should be harmless. So. the potential disadvantage would be a teeny bit of compilation time vs the chance of header macro collision and resulting wrong code. Fil

Re: [PATCH] Eliminates phi on branch for CMP result

Jeff Law writes: > On 5/8/19 6:20 AM, Richard Biener wrote: >> On Wed, 8 May 2019, Jiufu Guo wrote: >> >> The main thing the transform does is tail-duplicate the PHI block, >> if we'd just do that followup transforms would do the rest. > One might even claim this is really a transformation for c

Re: Follow-up-fix 2 to "[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)"

> Date: Tue, 30 Apr 2019 11:37:17 -0600 > From: Jeff Law > On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote: > > Here's the follow-up, getting rid of the observed > > alignment-padding in execute/930126-1.c: the x parameter in f > > spuriously being runtime-aligned to BITS_PER_WORD. I separated > >