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 &global_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 Darwi
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 lon
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 implementa
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). Howeve
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, _dl_runti
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, _dl_runtim
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 o
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 b/gc
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
gcc/ChangeLo
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 becau
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
2019-
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 x86_64-pc-linu
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 g++.dg/parse/crash
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 h
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 spec
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 function
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 x86_64-suse-
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: warning
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 fortr
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 (&arr[0] + N) - x. So thi
Wilco Dijkstra writes:
> Hi Richard,
>
>> If global_char really is a char then isn't that UB?
>
> No why?
Well, "simple expressions like &global_char + 0xff00" made it sound
like there really was a:
extern char global_char;
Only &global_char and &global_char + 1 are defined in that case.
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,
> > _mm_maskz_roundscale
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
> fu
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
tree_could_trap
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,
> _mm_maskz_roundscale_round
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, Dami
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, reg
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
[]8;;https://gcc.gnu.org/o
35 matches
Mail list logo
