On 11/16/21 01:55, Jeff Law wrote:
On 11/15/2021 10:33 AM, Siddhesh Poyarekar wrote:
Instead of comparing LEN and SIZE only if they are constants, use their
ranges to decide if LEN will always be lower than or same as SIZE.
This change ends up putting the stringop-overflow warning line number
> On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:
> > Ping, can we conclude on the name? IMHO, -Wbidirectional is just fine,
> > but changing the name is a trivial operation.
>
> Here's a patch with a better name (suggested by Jonathan W.). Otherwise no
> changes.
Thanks for im
Yes - direct use of any builtin is not to be encouraged, in user code.
This __builtin_bit_cast patch is intended to encourage experimentation
with array copy semantics now, on truck, in preparation for P1997.
The builtin bit_cast is strictly more powerful than the std::bit_cast
library function t
split_nonconstant_init was doing the wrong thing for both the initialization
and cleanup here; we know the size from the initializer, and we can pass it
along. This doesn't make the testcase work, since the y destructor is still
broken, but it removes the wrong error for the aggregate initializati
Excerpts from Seija K. via Gcc-patches's message of November 12, 2021 9:29 pm:
> diff --git a/gcc/d/dmd/ctfeexpr.c b/gcc/d/dmd/ctfeexpr.c
> index a8e97833ad0..401ed748f43 100644
> --- a/gcc/d/dmd/ctfeexpr.c
> +++ b/gcc/d/dmd/ctfeexpr.c
> @@ -1350,8 +1350,7 @@ int ctfeRawCmp(Loc loc, Expression *e1,
On Sat, 13 Nov 2021, Maxim Blinov wrote:
> the target specifically requires it, or you manually provide
> --enable-off-stack-trampolines when configuring gcc/libgcc.
If you're adding a new configure option, it needs documenting in
install.texi.
--
Joseph S. Myers
jos...@codesourcery.com
This performs the following modifications to our local copy of fast_float
in order to make it more readily usable in our std::from_chars
implementation:
* Remove system #includes
* Replace stray call to assert
* Use the standard library chars_format and from_chars_result types
libstdc++-v3/
This makes fast_float handle the situation where std::from_chars is
specified to return result_out_of_range, i.e. when the parsed value
is outside the representable range of the floating-point type.
libstdc++-v3/ChangeLog:
* src/c++17/fast_float/LOCAL_PATCHES: Update.
* src/c++17/
This makes our std::from_chars implementation use fast_float for parsing
chars_format::scientific/fixed/general parsing into binary32/64 values.
For chars_format::hex (and long double) we still use the fallback
implementation that goes through the strtod family of functions.
libstdc++-v3/ChangeLog
This copies the fast_float library[1] into the compiled-in library
sources. We're going to use this library in our floating-point
std::from_chars implementation for faster and more portable parsing of
binary32/64 decimal strings.
[1]: https://github.com/fastfloat/fast_float
Series tested on x86_
The only source change is a speedup to pow5Factor.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* src/c++17/ryu/MERGE: Update the commit hash.
* src/c++17/ryu/d2s_intrinsics.h: Merge from Ryu's master
branch.
---
libstdc++-v3/src/c+
Hi,
thanks for the patch and sorry for the delay in reviewing.
On Sat, Nov 06, 2021 at 08:17:23PM -0400, Will Wray via Gcc-patches wrote:
> This patch aims to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227.
>
> There are two underlying bugs in the designated initialization of char array
I've left SiFive and have a new gmail account because it is convenient
to use with git send-email. I'm planning to use this for my RISC-V
work. My tuliptree address still works, it just isn't as convenient.
* MAINTAINERS: Update my address.
---
MAINTAINERS | 2 +-
1 file changed, 1 inse
Nitpicking time. It's spelled "ones' complement" rather than "one's
complement". I didn't go into config/.
Ok for trunk?
gcc/ChangeLog:
* doc/implement-c.texi: Fix spelling.
* doc/md.texi: Likewise.
* expmed.c (emit_store_flag_int): Likewise.
* optabs.c (expand_
> On Nov 15, 2021, at 8:48 PM, Marek Polacek via Gcc-patches
> wrote:
>
> Nitpicking time. It's spelled "ones' complement" rather than "one's
> complement".
Is that so? I see Wikipedia claims it is, but there are no sources for that
claim. (There is an assertion that it is "discussed at
Hi,
The patch optimizes the code generation for vec_xl_sext builtin. Now all the
sign extensions are done on VSX registers directly.
Bootstrapped and tested on powerpc64le-linux with no regressions. Is this
okay for trunk? Any recommendations? Thanks a lot.
ChangeLog
2021-11-16 Haochen
On Tue, Nov 16, 2021 at 02:01:47AM +, Koning, Paul via Gcc-patches wrote:
>
>
> > On Nov 15, 2021, at 8:48 PM, Marek Polacek via Gcc-patches
> > wrote:
> >
> > Nitpicking time. It's spelled "ones' complement" rather than "one's
> > complement".
>
> Is that so? I see Wikipedia claims it
On 11/12/2021 7:37 AM, Martin Liška wrote:
@Alexandre: PING
On 10/18/21 12:05, Richard Biener wrote:
On Mon, Oct 18, 2021 at 10:54 AM Martin Liška wrote:
The macros correspond 1:1 to an option flags and make it harder
to find all usages of the flags.
Patch can bootstrap on x86_64-linux-g
On 11/15/2021 1:31 PM, Martin Sebor via Gcc-patches wrote:
Declaring a function with a prototype at block scope and
then redeclaring it without a prototype at file scope results
in losing the prototype but not the attribute access that was
implicitly added to the function decl based on the pro
On 11/13/2021 6:10 AM, Iain Sandoe via Gcc-patches wrote:
When saving, if we cannot obtain a suitable memory segment there
is no point in continuing, so exit with an error.
When reading in the PCH, we have a situation that the read-in
data will replace the line tables used by the diagnostics
From: Andrew Pinski
So while working on PR 103228 (and a few others), I noticed the testcase for PR
94785
was failing. The problem is that the nop_convert moved from being inside the
IOR to be
outside of it. I also noticed the patch for PR 103228 was not needed to
reproduce the
issue either.
T
On 11/15/2021 7:53 PM, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
So while working on PR 103228 (and a few others), I noticed the testcase for PR
94785
was failing. The problem is that the nop_convert moved from being inside the
IOR to be
outside of it. I also noticed the patch
When failing to transform equivalent, but slighly different cases of
atomic bit test and operations to their canonical forms, return
immediately.
gcc/
PR middle-end/103268
* tree-ssa-ccp.c (optimize_atomic_bit_test_and): Add a missing
return.
gcc/testsuite/
PR mi
On 11/15/2021 8:18 PM, H.J. Lu via Gcc-patches wrote:
When failing to transform equivalent, but slighly different cases of
atomic bit test and operations to their canonical forms, return
immediately.
gcc/
PR middle-end/103268
* tree-ssa-ccp.c (optimize_atomic_bit_test_and): A
From: Andrew Pinski
Currently we fold (type) X op CST into (type) (X op ((type-x) CST)) when the
conversion widens
but not when the conversion is a nop. For the same reason why we move the
widening conversion
(the possibility of removing an extra conversion), we should do the same if the
conve
On Mon, Nov 15, 2021 at 2:50 PM Jeff Law wrote:
>
>
>
> On 11/15/2021 1:25 AM, Ilya Lipnitskiy via Gcc-patches wrote:
> > musl only uses PT_GNU_STACK to set default thread stack size and has no
> > executable stack support[0], so there is no reason not to emit the
> > .note.GNU-stack section on mu
musl only uses PT_GNU_STACK to set default thread stack size and has no
executable stack support[0], so there is no reason not to emit the
.note.GNU-stack section on musl builds.
[0]:
https://lore.kernel.org/all/20190423192534.gn23...@brightrain.aerifal.cx/T/#u
gcc/ChangeLog:
* configur
On Tue, Nov 16, 2021, 03:20 Marek Polacek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Tue, Nov 16, 2021 at 02:01:47AM +, Koning, Paul via Gcc-patches
> wrote:
> >
> >
> > > On Nov 15, 2021, at 8:48 PM, Marek Polacek via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> > >
> > > Nit
101 - 128 of 128 matches
Mail list logo
