Hi,
> can you check the following patch?
Why restrict it to powerpc-freebsd only, and not all freebsd? Do they differ?
Otherwise it looks ok to me, but probably should be tested on a glibc non-x86
target.
In any case, this will be for the new branch, when stage 1 reopens.
FX
On 4/13/22 09:30, Richard Biener via Gcc wrote:
>
> Status
> ==
>
> The gcc-11 branch is now frozen in preparation for a GCC 11.3 release
> candidate and the GCC 11.3 release next week. All changes now require
> release manager approval.
Hi,
I would like to push:
https://gcc.gnu.org/piper
>
> optimize_function_for_speed ()?
>
Yes, updated patch with optimize_function_for_speed_p()
gcc/ChangeLog:
PR target/105034
* config/i386/i386-features.cc (pass_stv::gate()): Add
optimize_function_for_speed_p ().
gcc/testsuite/ChangeLog:
PR target/105034
* gcc.target/i386/pr105034.c: New t
On Thu, 14 Apr 2022, Andreas Krebbel wrote:
> On 4/13/22 09:30, Richard Biener via Gcc wrote:
> >
> > Status
> > ==
> >
> > The gcc-11 branch is now frozen in preparation for a GCC 11.3 release
> > candidate and the GCC 11.3 release next week. All changes now require
> > release manager app
On Thu, Apr 14, 2022 at 9:55 AM Hongyu Wang wrote:
>
> >
> > optimize_function_for_speed ()?
> >
>
> Yes, updated patch with optimize_function_for_speed_p()
>
> gcc/ChangeLog:
>
> PR target/105034
> * config/i386/i386-features.cc (pass_stv::gate()): Add
> optimize_function_for_speed_p ().
>
> gc
> >virtual bool gate (function *)
>
> please name the parameter ...
>
> > {
> >return ((!timode_p || TARGET_64BIT)
> > - && TARGET_STV && TARGET_SSE2 && optimize > 1);
> > + && TARGET_STV && TARGET_SSE2 && optimize > 1
> > + && optimize_function_for_speed_p (cfun)
On Thu, Apr 14, 2022 at 10:31 AM Hongyu Wang wrote:
>
> > >virtual bool gate (function *)
> >
> > please name the parameter ...
> >
> > > {
> > >return ((!timode_p || TARGET_64BIT)
> > > - && TARGET_STV && TARGET_SSE2 && optimize > 1);
> > > + && TARGET_STV && TARGET_S
> As a general comment it would be nicer if the cost metric itself would focus
> on size costs when optimizing for size and speed costs when optimizing for
> speed so that individual STV opportunities can be enabled/disabled based
> on it.
Agreed. I think the cost computation should consider insn
This fixes some misleading text in the libstdc++ manual that says the
docs for the gcc-11 branch refer to mainline.
Richi, is this OK for the gcc-11 branch now? It's been wrong for 11.1
and 11.2, but it would still be nice to fix.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/status
On Thu, 14 Apr 2022, Jonathan Wakely wrote:
> This fixes some misleading text in the libstdc++ manual that says the
> docs for the gcc-11 branch refer to mainline.
>
> Richi, is this OK for the gcc-11 branch now? It's been wrong for 11.1
> and 11.2, but it would still be nice to fix.
Yes, it's O
On Thu, 14 Apr 2022 at 11:36, Richard Biener wrote:
>
> On Thu, 14 Apr 2022, Jonathan Wakely wrote:
>
> > This fixes some misleading text in the libstdc++ manual that says the
> > docs for the gcc-11 branch refer to mainline.
> >
> > Richi, is this OK for the gcc-11 branch now? It's been wrong for
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/precompiled/stdc++.h: Include and
for C++23.
---
libstdc++-v3/include/precompiled/stdc++.h | 4
1 file changed, 4 insertions(+)
diff --git a/libstdc++-v3/include/precompiled/stdc++.h
b
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/105269
* include/bits/stl_vector.h (__cpp_lib_constexpr_vector):
Define.
* include/c_compatibility/stdatomic.h (__cpp_lib_stdatomic_h):
Define.
* include/std/o
On Thu, 14 Apr 2022, Jonathan Wakely wrote:
> On Thu, 14 Apr 2022 at 11:36, Richard Biener wrote:
> >
> > On Thu, 14 Apr 2022, Jonathan Wakely wrote:
> >
> > > This fixes some misleading text in the libstdc++ manual that says the
> > > docs for the gcc-11 branch refer to mainline.
> > >
> > > Ric
> 2022-04-13 Jakub Jelinek
>
> PR target/105247
> * simplify-rtx.cc (simplify_const_binary_operation): For shifts
> or rotates by VOIDmode constant integer shift count use word_mode
> for the operand if int_mode is narrower than word.
>
> * gcc.c-torture/compile/p
This applies the following optimizations to the integer std::from_chars
implementation:
1. Use a lookup table for converting an alphanumeric digit to its
base-36 value instead of using a range test (for 0-9) and switch
(for a-z and A-Z). The table is constructed using a C++14
con
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Patrick Palka
> via Gcc-patches
> Sent: Thursday, April 14, 2022 1:31 PM
> To: gcc-patches@gcc.gnu.org
> Cc: libstd...@gcc.gnu.org
> Subject: [PATCH] libstdc++: Optimize integer std::from_c
On Thu, 14 Apr 2022, Patrick Palka wrote:
> This applies the following optimizations to the integer std::from_chars
> implementation:
>
> 1. Use a lookup table for converting an alphanumeric digit to its
> base-36 value instead of using a range test (for 0-9) and switch
> (for a-z and
Richard Biener writes:
> When doing BB vectorization the scalar cost compute is derailed
> by patterns, causing lanes to be considered live and thus not
> costed on the scalar side. For the testcase in PR104010 this
> prevents vectorization which was done by GCC 11. PR103941
> shows similar case
On Thu, 14 Apr 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > When doing BB vectorization the scalar cost compute is derailed
> > by patterns, causing lanes to be considered live and thus not
> > costed on the scalar side. For the testcase in PR104010 this
> > prevents vectorization
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-8159-gb209a349268d24.
gcc/analyzer/ChangeLog:
PR analyzer/105252
* svalue.cc (cmp_cst): When comparing VECTOR_CSTs, compare the
types of the encoded elements before calling cmp_cst on them
PR analyzer/104308 initially reported about a
-Wanalyzer-use-of-uninitialized-value diagnostic using UNKNOWN_LOCATION
when complaining about certain memmove operations where the source
is uninitialized.
In r12-7856-g875342766d4298 I fixed the missing location for
a stmt generated by gimple_fold_bu
The following mitigates a problem in combine distribute_notes which
places an original REG_EH_REGION based on only may_trap_p which is
good to test whether a non-call insn can possibly throw but not if
actually it does or we care. That's something we decided at RTL
expansion time where we possibly
Richard Biener writes:
> On Thu, 14 Apr 2022, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > When doing BB vectorization the scalar cost compute is derailed
>> > by patterns, causing lanes to be considered live and thus not
>> > costed on the scalar side. For the testcase in PR104010
On 22-04-14 09:05:17, FX wrote:
> Hi,
>
> > can you check the following patch?
>
> Why restrict it to powerpc-freebsd only, and not all freebsd? Do they differ?
amd64 and i386 on all systems use a different setting and are not affected.
For FreeBSD-supported architectures that are not amd64, i386
On 05/04/22 06:05 +, Arnaud Charlet wrote:
Thank you for the feedback. Should I remove it and resuply the patch or
can you/GCC maintainers do the modification before merging?
Can you please resubmit it?
I'll let others comment on the need to sign a contributor agreement, my
understanding i
On 07/04/22 11:46 -0700, Palmer Dabbelt wrote:
The RISC-V port requires libatomic to be linked in order to resolve
various atomic functions, which results in builds that have
"--with-libstdcxx-lock-policy=auto" defaulting to mutex-based locks.
Changing this to direct atomics breaks the ABI, this
On Thu, 14 Apr 2022 at 13:32, Patrick Palka via Libstdc++
wrote:
>
> This applies the following optimizations to the integer std::from_chars
> implementation:
>
> 1. Use a lookup table for converting an alphanumeric digit to its
> base-36 value instead of using a range test (for 0-9) and sw
On Thu, 14 Apr 2022 08:08:17 PDT (-0700), jwak...@redhat.com wrote:
On 07/04/22 11:46 -0700, Palmer Dabbelt wrote:
The RISC-V port requires libatomic to be linked in order to resolve
various atomic functions, which results in builds that have
"--with-libstdcxx-lock-policy=auto" defaulting to mut
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and 11/10
once the branch is unfrozen?
PR libstdc++/104858
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__minmax_fn): Avoid dereferencing
__first twice at the start.
* testsuite/25_algorithms/minm
On Thu, 14 Apr 2022 at 16:18, Palmer Dabbelt wrote:
>
> On Thu, 14 Apr 2022 08:08:17 PDT (-0700), jwak...@redhat.com wrote:
> > On 07/04/22 11:46 -0700, Palmer Dabbelt wrote:
> >>The RISC-V port requires libatomic to be linked in order to resolve
> >>various atomic functions, which results in build
On Thu, 14 Apr 2022 08:22:05 PDT (-0700), jwak...@redhat.com wrote:
On Thu, 14 Apr 2022 at 16:18, Palmer Dabbelt wrote:
On Thu, 14 Apr 2022 08:08:17 PDT (-0700), jwak...@redhat.com wrote:
> On 07/04/22 11:46 -0700, Palmer Dabbelt wrote:
>>The RISC-V port requires libatomic to be linked in order
On Thu, 14 Apr 2022 at 16:21, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and 11/10
> once the branch is unfrozen?
>
> PR libstdc++/104858
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_algo.h (__minmax_fn): Avoid derefer
On Apr 13, 2022, Alexandre Oliva wrote:
> * gcc.target/powerpc/pr79004.c: Prune the -mfloat128 warning.
I failed to mention that this fixed a problem in the test, but that was
not enough for this test to pass; here's an incremental patch that is.
Some of the asm opcodes expected by pr790
On Mon, 4 Apr 2022 at 11:54, Philipp Fent via Libstdc++
wrote:
>
> This improves the debug output for C++20 spans.
> Before:
> {static extent = 18446744073709551615, _M_ptr = 0x7fffb9a8,
> _M_extent = {_M_extent_value = 2}}
> Now with StdSpanPrinter:
> std::span of length 2 = {1, 2}
Hi!
On Sat, Apr 17, 2021 at 06:19:02AM -0300, Alexandre Oliva wrote:
> On Apr 12, 2021, Segher Boessenkool wrote:
> > On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
> >> Several compile tests that use the __ieee128 type do not ensure it is
> >> defined. This patch adds -mfloat1
Hi,
This patch adds support for omp_get_max_teams, omp_set_num_teams, and
omp_{gs}et_teams_thread_limit on offload devices.
The patch builds on the following patches which are submitted, but not yet
approved/committed:
- [PATCH] OpenMP, libgomp: Environment variable syntax extension.
https://gcc
On Wed, Apr 13, 2022 at 08:37:40PM -0300, Alexandre Oliva wrote:
> On Apr 17, 2021, Alexandre Oliva wrote:
> > On Apr 12, 2021, Segher Boessenkool wrote:
> My supposition was wrong. It turned out to be just because in
> vxworks.h, for TARGET_VXWORKS7, there's:
>
> #define TARGET_FLOAT128_ENABLE
On Thu, 14 Apr 2022 at 11:55, Richard Biener wrote:
>
> On Thu, 14 Apr 2022, Jonathan Wakely wrote:
>
> > On Thu, 14 Apr 2022 at 11:36, Richard Biener wrote:
> > >
> > > On Thu, 14 Apr 2022, Jonathan Wakely wrote:
> > >
> > > > This fixes some misleading text in the libstdc++ manual that says the
On Wed, Apr 13, 2022 at 08:58:18PM -0300, Alexandre Oliva wrote:
>
> Multiple bfp tests expect -mcpu=power[89] to enable the __ieee128
> type, but on targets that #define TARGET_FLOAT128_ENABLE_TYPE 0, that
> is not the case. Since they are compile-time tests and effective
> target support for po
libstdc++-v3/ChangeLog:
* doc/xml/manual/intro.xml: Fix comment.
---
libstdc++-v3/doc/xml/manual/intro.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/doc/xml/manual/intro.xml
b/libstdc++-v3/doc/xml/manual/intro.xml
index 86ed6964b6a..548b632b6e4 1006
On Thu, 14 Apr 2022 at 16:24, Palmer Dabbelt wrote:
>
> On Thu, 14 Apr 2022 08:22:05 PDT (-0700), jwak...@redhat.com wrote:
> > On Thu, 14 Apr 2022 at 16:18, Palmer Dabbelt wrote:
> >>
> >> On Thu, 14 Apr 2022 08:08:17 PDT (-0700), jwak...@redhat.com wrote:
> >> > On 07/04/22 11:46 -0700, Palmer D
On Apr 14, 2022, Segher Boessenkool wrote:
> Hi!
> On Sat, Apr 17, 2021 at 06:19:02AM -0300, Alexandre Oliva wrote:
>> On Apr 12, 2021, Segher Boessenkool wrote:
>> > On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
>> >> Several compile tests that use the __ieee128 type do not e
On Thu, Apr 14, 2022 at 01:56:39PM -0300, Alexandre Oliva wrote:
> On Apr 14, 2022, Segher Boessenkool wrote:
> > On Sat, Apr 17, 2021 at 06:19:02AM -0300, Alexandre Oliva wrote:
> >> On Apr 12, 2021, Segher Boessenkool wrote:
> >> > On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote
This reimplements std::has_single_bit using the well-known bit-twiddilng
trick[1], which is much faster than popcount on x86_64.
Note that when __x is signed and maximally negative then this
implementation invokes UB due to signed overflow, whereas the previous
implementation would return true. T
On Apr 14, 2022, Segher Boessenkool wrote:
> Lol, the dates line up very well, I didn't realise it was from 2021 :-)
Heh, indeed. Same testsuite results cleanup season, too ;-)
>> The relevant fact, described in yesterday's message, is that -mfloat128
>> is not enabled by default, even with -m
When a captured variable is type-dependent, we've expressed the type of the
capture field and proxy with a decltype variant. But if the type is "the
current instantiation", we need to be able to see that so that we can do
lookup inside it just like we could with the captured variable itself.
I al
On Thu, 14 Apr 2022 at 19:17, Patrick Palka via Libstdc++
wrote:
>
> This reimplements std::has_single_bit using the well-known bit-twiddilng
> trick[1], which is much faster than popcount on x86_64.
Is that always true for all microarchitectures? We have
https://gcc.gnu.org/PR97759 on this topic
Some targets use 'long long unsigned int' for unsigned HW int, and this
leads to a Werror=format= fail for two print cases in jit-playback.cc
introduced in r12-8117-g30f7c83e9cfe (Add support for bitcasts [PR104071])
As discussed on IRC, casting to (long) seems entirely reasonable for the
values (
On Thu, Apr 14, 2022 at 2:59 PM Jonathan Wakely wrote:
>
> On Thu, 14 Apr 2022 at 19:17, Patrick Palka via Libstdc++
> wrote:
> >
> > This reimplements std::has_single_bit using the well-known bit-twiddilng
> > trick[1], which is much faster than popcount on x86_64.
>
> Is that always true for al
Assertions were originally enabled in the compiled-in floating-point
std::to_chars implementation to help shake out any bugs, but they
apparently impose a significant performance penalty, in particular for
the hex formatting which is around 25% slower with assertions enabled.
This seems too high of
Here we issue a wrong error for the
template>> void g();
line in the testcase. I surmise that's because we mistakenly parse
C_many as a placeholder-type-specifier, and things go wrong from
there. We are in a default argument so we should reject parsing C_many
as a placeholder-type-specifier,
When -fpatchable-function-entry= is enabled, certain C++ codes fails to
link because of generated references to discarded sections in
__patchable_function_entry section. This commit fixes this problem by
puting those references in a COMDAT section.
Boostrapped and regtested on x86_64 linux.
OK fo
The constexpr constructor checking code got confused by the expansion of a
trivial copy constructor; we don't need to do that checking for defaulted
ctors, anyway.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104646
gcc/cp/ChangeLog:
* constexpr.cc (maybe_save_constexpr
On Mon, Apr 11, 2022 at 11:28 AM Sören Tempel wrote:
>
> Ian Lance Taylor wrote:
> > What I was hoping from my earlier question was that you could tell me
> > the exact lines to write in the current sources that will compile on
> > MUSL. Don't include , don't refer to earlier patches as
> > that
On Apr 14, 2022, Segher Boessenkool wrote:
> Yes, that is a problem. None of our testcases are set up for compilers
> with weird defaults (and this is not specific to rs6000).
> I do not want to change many thousands of test cases to not use defaults
> anymore, to specify everything everywhere
PR analyzer/105264 reports that the analyzer can fail to treat
(PTR + IDX) and PTR[IDX] as referring to the same memory under
some situations.
There are various ways in which this can happen when IDX is a
symbolic value, due to having several ways in which such memory
regions can be referred to sy
The expression pretty-printing code crashed on a location wrapper with no
type, and didn't know what to do with a USING_DECL.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102987
gcc/cp/ChangeLog:
* error.cc (dump_expr): Handle USING_DECL.
[VIEW_CONVERT_EXPR]: Ju
There's been an extension for a long time to allow applying 'unsigned' to an
int typedef, but that was confusing the integer promotion code. Fixed by
forgetting about the typedef in that case.
I'm going to make this an unconditional pedwarn in stage 1.
Tested x86_64-pc-linux-gnu, applying to tru
On 4/14/22 16:24, Marek Polacek wrote:
Here we issue a wrong error for the
template>> void g();
line in the testcase. I surmise that's because we mistakenly parse
C_many as a placeholder-type-specifier, and things go wrong from
there. We are in a default argument so we should reject parsin
On 4/13/22 19:17, Marek Polacek wrote:
On Tue, Apr 12, 2022 at 04:01:14PM -0400, Jason Merrill wrote:
On 4/12/22 14:38, Marek Polacek wrote:
On Mon, Apr 11, 2022 at 04:39:22PM -0400, Jason Merrill wrote:
On 4/8/22 15:21, Marek Polacek wrote:
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Mer
Hi,
Complile _mm_crc32_u8/16/32/64 intrinsics with -mcrc32
would meet target specific option mismatch. Correct target pragma
to fix.
Bootstrapped/regtest on x86_64-pc-linux-gnu{-m32,}.
Ok for master and backport to GCC 11?
gcc/ChangeLog:
* config/i386/smmintrin.h: Correct target pragma
62 matches
Mail list logo
