On 10/12/19 3:56 AM, Richard Sandiford wrote:
> Wilco Dijkstra writes:
>> Hi Richard,
>>
>>> If global_char really is a char then isn't that UB?
>>
>> No why?
>
> Well, "simple expressions like _char + 0xff00" made it sound
> like there really was a:
>
>extern char global_char;
>
>
Hi,
Segher Boessenkool wrote:
On Sat, Oct 12, 2019 at 10:13:16PM +0100, Iain Sandoe wrote:
(this is a bug reported against Fortran, but actually is a generic insn
selection problem for m64 powerpc-darwin. In fact, I’d say it renders
the 64b multilib unusable).
The solution proposed is
Hi!
On Sat, Oct 12, 2019 at 10:13:16PM +0100, Iain Sandoe wrote:
> (this is a bug reported against Fortran, but actually is a generic insn
> selection problem for m64 powerpc-darwin. In fact, I’d say it renders
> the 64b multilib unusable).
>
> The solution proposed is Darwin-local (it's a
I hadn’t realised it had been so long since I posted this:
ping.
Iain Sandoe wrote:
> If an assembler is used that supports .cfi_xxx, then (usually) GCC's
> configuration will detect this and try to use it to generate frame insns.
>
> This will not work for Darwin since the default
Hi Folks,
(this is a bug reported against Fortran, but actually is a generic insn
selection problem for m64 powerpc-darwin. In fact, I’d say it renders
the 64b multilib unusable).
The solution proposed is Darwin-local (it's a long-standing bug and it
would be intended to back-port it).
This is the second patch in a series of changes intended to fix glibc/23296.
This bug
is a data race in the setting of function descriptors during lazy binding. If
a descriptor
is updated between the loading of the function target address and the PIC
global pointer
in another thread,
This is the first patch in a series of changes intended to fix glibc/23296.
This bug
is a data race in the setting of function descriptors during lazy binding. If
a descriptor
is updated between the loading of the function target address and the PIC
global pointer
in another thread,
When we're using the LLVM-based assembler (the default on modern Darwin)
the ordering of stubs and non-lazy symbol pointers is important.
Interleaving the output (current GCC behaviour) leads to crashes which
prevents us from building code with symbol stubs.
To resolve this, we order the output
It's only called from darwin.c.
tested on x86_64-darwin16,
applied to mainline
thanks
Iain
gcc/ChangeLog:
2019-10-12 Iain Sandoe
* config/darwin-protos.h (machopic_finish): Delete.
* config/darwin.c (machopic_finish): Make static.
diff --git a/gcc/config/darwin-protos.h
Older versions of GCC emit empty .constructor/.destructor sections
whenever building for C++. In fact, these sections are only used for
kernel mode code - so don't emit them unless that's what we're
building.
tested on x86_64-darwin16, powerpc-darwin9,
applied to mainline
thanks
Iain
Hi,
I think I have resolved all the issues (see attached patch and test
case).
Basically, the patch now walks through the refs and looks at the
latest thing that could be an array or a scalar.
Regarding CLASS in argument lists without an explicit interface:
I think that this is disallowed
On Wed, 25 Sep 2019 16:38:25 PDT (-0700), jos...@codesourcery.com wrote:
On Tue, 24 Sep 2019, Palmer Dabbelt wrote:
The documentation used to indicate that the inline keyword was only
supported by c99 and c11, whereas in fact it is supported by c99 and all
newer standards.
gcc/ChangeLog
This patch fixes a warning from pa.c.
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
Index: gcc/config/pa/pa.c
===
--- gcc/config/pa/pa.c (revision 276877)
+++ gcc/config/pa/pa.c (working copy)
@@ -535,7 +535,7 @@
On 10/12/19 12:10 PM, Bernd Edlinger wrote:
[snip snip]
So instead I'd like to adjust the doc of -Wshadow to reflect the implementation
and remove the if(warn_shadow_local) to have C and C++ behave identical and
hopefully now in sync with the doc.
Bootstrapped and reg-tested on
On 10/11/19 6:31 PM, Jason Merrill wrote:
> On 10/10/19 2:06 PM, Bernd Edlinger wrote:
>> On 10/10/19 7:49 PM, Jason Merrill wrote:
>>> On 10/10/19 10:42 AM, Bernd Edlinger wrote:
Hi,
this fixes a crash when -Wshadow=compatible-local is
enabled in the testcase
On Sat, Oct 12, 2019 at 10:21:56AM -0400, David Malcolm wrote:
> It seems like instead it's displaying this:
>
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wshadow=local-Wshadow=local%1B]8
That's what it does for me (well, with weird escapes at both ends). And
if run inside a
Le sam. 12 oct. 2019 à 17:44, Romain Geissler
a écrit :
>
> It looks like this creates the following error when I try to bootstrap
> clang 9.0.0 using the latest gcc and libstdc++ from trunk. Note that
> with g++, there is no problem, however it looks like clang++ has some
> problem with the new
Le ven. 11 oct. 2019 à 17:50, Jonathan Wakely a écrit :
>
> By using the built-in we don't need to match a partial specialization
> for std::is_same and don't need to instantiate std::is_same at all for
> uses of std::is_same_v.
>
> * include/std/type_traits (is_same): Replace partial
On 10/12/19 4:21 PM, David Malcolm wrote:
> On Sat, 2019-10-12 at 07:00 +, Bernd Edlinger wrote:
>> Hi David,
>>
>> I just wanted to say that this does not work right on ubuntu 14.04 at
>> least:
>>
>> g++ -Wshadow=local -Wno-shadow=compatible-local -S Wshadow-1.c
>> Wshadow-1.c: In
The function Defining_Entity recently gained new parameters with default
values, namely Empty_On_Errors and Concurrent_Subunit. It turns out that
these new parameters are not really necessary and can be easily removed,
which will also save a few bytes in the final binary.
Tested on
On Sat, 2019-10-12 at 07:00 +, Bernd Edlinger wrote:
> Hi David,
>
> I just wanted to say that this does not work right on ubuntu 14.04 at
> least:
>
> g++ -Wshadow=local -Wno-shadow=compatible-local -S Wshadow-1.c
> Wshadow-1.c: In function 'void foo(int*, int*)':
> Wshadow-1.c:8:9:
Hi Steve,
In the F2018 standard: C1550 (R1526) If MODULE appears in the prefix
of a module subprogram and a binding label is specified, it
shall be the same as the binding label specified in the corresponding
module procedure interface body.
While it does not say explicitly that a repeat binding
Hi Steve,
As I remarked on the PR thread, it is one of the less harmful bits of
code that I introduced :-)
OK to commit.
Thanks
Paul
On Sat, 12 Oct 2019 at 01:17, Steve Kargl
wrote:
>
> The patch is fairly self-explanatory. OK to commit?
>
> 2019-10-11 Steven G. Kargl
>
> PR
On October 12, 2019 10:44:06 AM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>As mentioned in the PR and on IRC, tree_could_trap_p is described
>as taking GIMPLE expressions only, but in fact we rely on it not
>crashing
>when feeded GENERIC, just for GENERIC it will not handle expressions
>recursively
Hi Richi,
> -Original Message-
> From: Richard Biener
> Sent: Friday, October 11, 2019 8:02 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> Subject: Re: [PATCH 1/2][GCC][RFC][middle-end]: Add SLP pattern matcher.
>
> On Tue, 8 Oct 2019, Tamar Christina wrote:
Richard Sandiford writes:
> Wilco Dijkstra writes:
>> We can do all kinds of arithmetic based on pointers, either using
>> pointer types or converted to uintptr_t. Note that the optimizer
>> actually creates these expressions, for example arr[N-x] can be
>> evaluated as ([0] + N) - x. So this
Wilco Dijkstra writes:
> Hi Richard,
>
>> If global_char really is a char then isn't that UB?
>
> No why?
Well, "simple expressions like _char + 0xff00" made it sound
like there really was a:
extern char global_char;
Only _char and _char + 1 are defined in that case.
I was probably
On Sat, Oct 12, 2019 at 4:15 PM Jakub Jelinek wrote:
>
> Hi!
>
> > gcc/
> > * config/i386/avx512fintrin.h (_mm_mask_roundscale_ss,
> > _mm_maskz_roundscale_ss, _mm_maskz_roundscale_round_ss,
> > _mm_maskz_roundscale_round_ss, _mm_mask_roundscale_sd,
> >
Hi!
On Sat, Oct 12, 2019 at 11:22:15AM +0800, Jiufu Guo wrote:
> As expected in the PR, when a function is marked with no-vsx, we would
> assume user has good reason to disable VSX code generation for the function.
> To avoid VSX code generation, this function should not be inlined into VSX
>
Hi!
As mentioned in the PR and on IRC, tree_could_trap_p is described
as taking GIMPLE expressions only, but in fact we rely on it not crashing
when feeded GENERIC, just for GENERIC it will not handle expressions
recursively and we have generic_expr_could_trap_p for that that calls
Hi!
The following patch adds diagnostics if the same function serves as variant
for multiple base functions and there is a mismatch in the construct
selector set. Additionally, it adds a start of a function that says if a
context selector matches the OpenMP context, doesn't or we don't know yet.
Hi!
> gcc/
> * config/i386/avx512fintrin.h (_mm_mask_roundscale_ss,
> _mm_maskz_roundscale_ss, _mm_maskz_roundscale_round_ss,
> _mm_maskz_roundscale_round_ss, _mm_mask_roundscale_sd,
> _mm_maskz_roundscale_sd, _mm_mask_roundscale_round_sd,
>
On Sat, Oct 12, 2019 at 7:58 AM Steve Kargl
wrote:
>
> On Fri, Oct 11, 2019 at 09:56:15PM -0700, Steve Kargl wrote:
> > In PR fortran/91513, Damian Rouson points out that the Fortran
> > does contain the words "impure variable".
>
> Geez. That is a messed up sentence.
>
> In PR fortran/91513,
Hi:
This patch is enabling missing avx512f intrinsics listed as
_mm_mask_roundscale_sd
_mm_mask_roundscale_round_sd
_mm_maskz_roundscale_sd
_mm_maskz_roundscale_round_sd
_mm_mask_roundscale_ss
_mm_mask_roundscale_round_ss
_mm_maskz_roundscale_ss
_mm_maskz_roundscale_round_ss
Bootstrap ok,
Hi David,
I just wanted to say that this does not work right on ubuntu 14.04 at least:
g++ -Wshadow=local -Wno-shadow=compatible-local -S Wshadow-1.c
Wshadow-1.c: In function 'void foo(int*, int*)':
Wshadow-1.c:8:9: warning: declaration of 'int d' shadows a parameter
35 matches
Mail list logo
