On 4/12/22 18:50, Marek Polacek wrote:
DR 2352 changed the definitions of reference-related (so that it uses
"similar type" instead of "same type") and of reference-compatible (use
a standard conversion sequence). That means that reference-related is
now more broad, which means that we will be
Hi,
As PR104482 shown, it's one regression about the handlings when
the argument number is more than the one of built-in function
prototype. The new bif support only catches the case that the
argument number is less than the one of function prototype, but
it misses the case that the argument
On Apr 12, 2022, Segher Boessenkool wrote:
> Hi!
> On Mon, Apr 11, 2022 at 08:57:07PM -0300, Alexandre Oliva wrote:
>> If neither 128-bit long double format is available, skip pr60203.c.
>>
>> Tested with gcc-11 targeting ppc64-vx7r2, with neither long double
>> format enabled. Ok to install?
Eliminate power8 fusion options, use power8 tuning, PR target/102059
This is V4 of the patch. Compared to V3 of the patch, GCC will just
ignore -m{,no-}power8-fusion and -m{,no-}power8-fusion-sign.
The splitting of signed halfword and word loads into unsigned load and
sign extension is now
on 2022/4/13 3:11 AM, Segher Boessenkool wrote:
> On Tue, Apr 12, 2022 at 10:02:06AM +0800, Kewen.Lin wrote:
>> on 2022/4/11 11:42 PM, Segher Boessenkool wrote:
>>> On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
Nice, I confirmed this makes ICE gone, I've filed one new PR
On Apr 12, 2022, Segher Boessenkool wrote:
> On Mon, Apr 11, 2022 at 08:59:41PM -0300, Alexandre Oliva wrote:
>>
>> gcc.target/powerpc/fold-vec-insert-double.c is compiled with -mvsx,
>> while the expected asm output depends on target has_arch_pwr7, which
>> is tested for without -mvsx.
>>
>>
DR 2352 changed the definitions of reference-related (so that it uses
"similar type" instead of "same type") and of reference-compatible (use
a standard conversion sequence). That means that reference-related is
now more broad, which means that we will be binding more things directly.
The
On Mon, 2022-04-11 at 19:56 -0400, David Malcolm wrote:
> On Fri, 2022-04-08 at 16:37 -0400, Antoni Boucher wrote:
> > On Fri, 2022-04-08 at 15:36 -0400, David Malcolm wrote:
>
> [...snip...]
>
> >
> >
>
> > > So I think I'm waiting on an updated version of the sized-
> > > integer-
> > >
On Sat, 2022-04-09 at 13:50 -0400, Antoni Boucher wrote:
> Here's the updated patch.
>
> On Fri, 2022-04-08 at 15:01 -0400, David Malcolm wrote:
> > On Sun, 2022-01-30 at 20:38 -0500, Antoni Boucher via Gcc-patches
> > wrote:
> > > Hi.
> > > This patch adds support for setting the alignment of
On Mon, 2022-01-24 at 17:55 -0500, David Malcolm wrote:
> On Sun, 2022-01-23 at 12:34 -0500, Antoni Boucher wrote:
> > Thanks for the review.
> > Here's the updated patch.
>
> Tnanks. The updated patch looks good to me, but we need to get release
> manager approval for adding stuff in stage 4;
On Wed, 2022-02-09 at 20:33 -0500, Antoni Boucher wrote:
> Here's the updated patch.
Thanks.
I updated the patch somewhat:
* fixed up some hunks that didn't quite apply
* tweaked the comment in all-non-failing-tests.h
* fixed continuation lines in .rst ". function::" clause
*
Tested powerpc64-linux, pushed to trunk.
-- >8 --
As reported in PR libbacktrace/105240, libbacktrace leaks memory when
using malloc for allocations. I originally thought it would be simpler
to just use malloc unconditionally (because it's supported on all
targets) but the leaks make that
Tested powerpc64-linux, pushed to trunk.
-- >8 --
If a large stacktrace is reduced to a max depth that is less than half
the capacity it will now be reallocated to remove the unused capacity.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::current): Reallocate
Tested powerpc64-linux, pushed to trunk.
-- >8 --
Because std::basic_stacktrace is an allocator-aware container its
elements should be initialized using allocator_traits::construct and
destroyed using allocator_traits::destroy.
This adds new _M_clone and _M_assign helper functions to construct
Tested powerpc64-linux, pushed to trunk.
-- >8 --
We can avoid the overhead of handling a bad_alloc exception from
std::allocator::allocate by just calling the
nothrow operator new instead.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::_Impl::_M_allocate):
Tested powerpc64-linux, pushed to trunk.
-- >8 --
This adds an alternative callback for use in the overload of
basic_stacktrace::current that takes a max_depth parameter. The new
callback will not allow the container to grow past the initial capacity,
which is set to the specified maximum depth.
On Sat, 2022-04-09 at 14:05 -0400, Antoni Boucher wrote:
> Here's the updated patch.
Thanks.
I updated the patch somewhat:
* fixed up some hunks that didn't quite apply
* whitespace fixes
* added a missing comment
* regenerated .texinfo from .rst
* test-bitcast.c failed for me; the bitcast of
On Fri, 2022-04-08 at 16:29 -0400, Antoni Boucher wrote:
> David, it seems you missed this email that contains the updated patch
> and a few questions.
>
> Attaching the patch again.
>
> Thanks for the reviews!
Thanks for the patch.
I updated the patch to fix some minor nits:
- Some whitespace
There were two problems with this testcase: we weren't copying the target
attribute from the second declaration to the global alias for the first
one (duplicate_decls hunk), and then we were treating the third one as
matching the earlier one even though both are versioned (decls_match hunk).
The
While considering the PR102071 patch for backporting, I noticed that I was
considering the alignment of the array new cookie even when there isn't one
because we aren't allocating an array.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102071
gcc/cp/ChangeLog:
* init.cc
On 4/12/22 15:48, Patrick Palka wrote:
On Wed, Feb 16, 2022 at 2:47 PM Patrick Palka wrote:
On Tue, 15 Feb 2022, Jason Merrill wrote:
On 2/15/22 17:00, Patrick Palka wrote:
On Tue, 15 Feb 2022, Jason Merrill wrote:
On 2/15/22 15:13, Patrick Palka wrote:
On Tue, 15 Feb 2022, Patrick
On 4/12/22 14:44, Patrick Palka wrote:
On Tue, Apr 12, 2022 at 12:33 PM Jason Merrill wrote:
On 4/12/22 12:17, Patrick Palka wrote:
Here after dependent substitution of {Ts...} into the alias 'wrap',
since we never partially instantiate a requires-expr, we end up with a
requires-expr whose
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 Merrill wrote:
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype,
On Wed, Feb 16, 2022 at 2:47 PM Patrick Palka wrote:
>
> On Tue, 15 Feb 2022, Jason Merrill wrote:
>
> > On 2/15/22 17:00, Patrick Palka wrote:
> > > On Tue, 15 Feb 2022, Jason Merrill wrote:
> > >
> > > > On 2/15/22 15:13, Patrick Palka wrote:
> > > > > On Tue, 15 Feb 2022, Patrick Palka wrote:
Hi GCC community,
I need to have ability to point to custom repository in gcc_release script.
This small patch 1) does add a parameter "-g" to add custom repository to
gcc_release , 2) does add a line to download prerequisites before building GCC
(download_prerequisites) which is not present
On Tue, Apr 12, 2022 at 10:02:06AM +0800, Kewen.Lin wrote:
> on 2022/4/11 11:42 PM, Segher Boessenkool wrote:
> > On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
> >> Nice, I confirmed this makes ICE gone, I've filed one new PR
> >> PR105213 for GCC13 further tracking by associating
Hi!
On Mon, Apr 11, 2022 at 08:57:07PM -0300, Alexandre Oliva wrote:
> If neither 128-bit long double format is available, skip pr60203.c.
>
> Tested with gcc-11 targeting ppc64-vx7r2, with neither long double
> format enabled. Ok to install?
Can you use check_effective_target_longdouble128
On Tue, Apr 12, 2022 at 12:33 PM Jason Merrill wrote:
>
> On 4/12/22 12:17, Patrick Palka wrote:
> > Here after dependent substitution of {Ts...} into the alias 'wrap',
> > since we never partially instantiate a requires-expr, we end up with a
> > requires-expr whose REQUIRES_EXPR_EXTRA_ARGS
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 Merrill wrote:
> > > On 4/1/22 15:14, Marek Polacek wrote:
> > > > Attribute format takes three arguments: archetype, string-index, and
> > > >
RA now chooses GEN_OR_VSX_REGS in most cases. This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes. We can fix that by putting a small penalty on the
instruction
On Mon, Apr 11, 2022 at 08:59:41PM -0300, Alexandre Oliva wrote:
>
> gcc.target/powerpc/fold-vec-insert-double.c is compiled with -mvsx,
> while the expected asm output depends on target has_arch_pwr7, which
> is tested for without -mvsx.
>
> In some of our configurations, that have altivec and
On Mon, Apr 11, 2022 at 10:47:53AM +0800, HAO CHEN GUI wrote:
> There are two issues left in this PR. One is pr56605.c. My patch fixes it.
> Another is prefix-no-update.c. The patch Segher proposed in 103197 could fix
> it.
So today all remaining problems will be fixed. Thanks for shepherding
On Mon, Apr 11, 2022 at 08:54:14PM -0300, Alexandre Oliva wrote:
> How about this less strict change instead?
>
> ppc: testsuite: PROMOTE_MODE fallout pr56605 [PR102146]
>
> The test expects a compare of DImode values, but after the removal of
> PROMOTE_MODE from rs6000/, we get SImode. Adjust
As a side-effect, a patch I have for PR 70321 causes the failure of
gcc.target/i386/pr65105-5.c by generating the code:
vmovq (%eax), %xmm1
vpand %xmm1, %xmm2, %xmm0
vpxor %xmm0, %xmm2, %xmm0
vpunpcklqdq %xmm0, %xmm0, %xmm0
vptest %xmm0, %xmm0
On Tue, Apr 12, 2022 at 5:42 PM Roger Sayle wrote:
>
>
> This stand-alone patch avoids (-Os) regressions from a fix for PR 70321.
>
> The simple test case below has the unfortunate property that on x86_64
> it is larger when compiled with -Os than when compiled with -O2.
>
> int foo(char x)
> {
>
On 4/12/22 12:17, Patrick Palka wrote:
Here after dependent substitution of {Ts...} into the alias 'wrap',
since we never partially instantiate a requires-expr, we end up with a
requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an
ARGUMENT_PACK_SELECT (which just resolves to the parameter
Here after dependent substitution of {Ts...} into the alias 'wrap',
since we never partially instantiate a requires-expr, we end up with a
requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an
ARGUMENT_PACK_SELECT (which just resolves to the parameter pack Ts).
Then when looking up the
> Am 12.04.2022 um 17:08 schrieb Thomas Schwinge :
>
> Hi!
>
>> On 2022-04-12T15:45:03+0200, Richard Biener wrote:
>>> On Tue, 12 Apr 2022, Thomas Schwinge wrote:
>>> On 2022-04-07T15:04:15+0200, Richard Biener via Gcc-patches
>>> wrote:
On Thu, 7 Apr 2022, Jan Hubicka wrote:
>>
This stand-alone patch avoids (-Os) regressions from a fix for PR 70321.
The simple test case below has the unfortunate property that on x86_64
it is larger when compiled with -Os than when compiled with -O2.
int foo(char x)
{
return (x & 123) != 0;
}
The issue is x86's complex instruction
Hi!
On 2022-04-12T15:45:03+0200, Richard Biener wrote:
> On Tue, 12 Apr 2022, Thomas Schwinge wrote:
>> On 2022-04-07T15:04:15+0200, Richard Biener via Gcc-patches
>> wrote:
>> > On Thu, 7 Apr 2022, Jan Hubicka wrote:
>> >> > On Thu, 7 Apr 2022, Jan Hubicka wrote:
>> >> > > this patch fixes
The following reverts the DCE change back to the original behavior
which should be handled well during the propagation stage. That
should fix the failures Thomas Schwinge is reporting.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-12 Richard Biener
PR
On 3/24/22 17:06, Jason Merrill wrote:
On 3/22/22 16:59, Marek Polacek via Gcc-patches wrote:
On Tue, Mar 22, 2022 at 08:39:21PM +, Ed Catmur wrote:
If two arrays do not have the exact same element type including
qualification, this could be e.g. f(int (&&)[]) vs. f(int const
(&)[]),
On Tue, 2022-04-12 at 10:03 -0400, David Malcolm wrote:
> I've pushed the following change to the website, covering -fanalyzer
> changes in GCC 12.
(sorry, forgot to put wwwdocs in the subject)
>
> ---
> htdocs/gcc-12/changes.html | 115
> +
> 1 file
I've pushed the following change to the website, covering -fanalyzer
changes in GCC 12.
---
htdocs/gcc-12/changes.html | 115 +
1 file changed, 115 insertions(+)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 4652304d..d907ed22
On Tue, 12 Apr 2022, Thomas Schwinge wrote:
> Hi!
>
> On 2022-04-07T15:04:15+0200, Richard Biener via Gcc-patches
> wrote:
> > On Thu, 7 Apr 2022, Jan Hubicka wrote:
> >> > On Thu, 7 Apr 2022, Jan Hubicka wrote:
> >> > > this patch fixes miscompilation of gnatmake. Modref attempts to track
>
Hi!
On 2022-04-07T15:04:15+0200, Richard Biener via Gcc-patches
wrote:
> On Thu, 7 Apr 2022, Jan Hubicka wrote:
>> > On Thu, 7 Apr 2022, Jan Hubicka wrote:
>> > > this patch fixes miscompilation of gnatmake. Modref attempts to track
>> > > memory
>> > > accesses relative to the base pointers
Dan Li writes:
> Gentile ping for this :), thanks.
>
> Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590906.html
Sorry, I should have realised this at the time, but I don't think
we can do this after all. The ABI requires us to set up the frame
chain before assigning to the
The test failure in PR101755 is due to the gimple optimizers getting
smarter. But really we are just testing that RTL expansion is doing
the right thing and annotating a constant accordingly. So rework the
test to use GIMPLE input and simplify the code entirely. Also, this
test only ever
On Mon, Apr 11, 2022 at 12:44:32AM +0200, Jan Hubicka via Gcc-patches wrote:
> Hi,
> the testcase triggers ICE since computation overflows on two accesses
> that are very far away d->b[-144115188075855873] and d->b[144678138029277184].
> This patch makes the relevant part of modref to use
When a FP conversion is removed we have to eventually clean EH.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-12 Richard Biener
PR tree-optimization/105235
* tree-ssa-math-opts.cc (execute_cse_conv_1): Clean EH and
return whether the CFG
On 08/04/2022 15:48, Przemyslaw Wirkus via Gcc-patches wrote:
Hi,
This patch is removing unnecessary armv9-a multilib variant which was
introduced in commit 32ba7860ccaddd5219e6dae94a3d0653e124c9dd (add
armv9-a architecture to -march). Now armv9-a(+simd) multilibs point to
already existing
The following properly checks tree_fits_poly_int64_p before converting
a size to a poly_int64.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-12 Richard Biener
PR tree-optimization/105232
* tree.cc (component_ref_size): Bail out for too large
or
Vectorizer loop versioning tries to version outer loops if possible
but fails to check whether it can actually split the single exit
edge as it will do.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-12 Richard Biener
PR tree-optimization/105226
*
So far z16 was identified as arch14. After the machine has been
announced we can now add the real name.
gcc/ChangeLog:
* common/config/s390/s390-common.cc: Rename PF_ARCH14 to PF_Z16.
* config.gcc: Add z16 as march/mtune switch.
* config/s390/driver-native.cc
54 matches
Mail list logo
