On Wed, Apr 06, 2022 at 08:13:24AM +0200, Richard Biener wrote:
> On Tue, 5 Apr 2022, Jakub Jelinek wrote:
>
> > On Tue, Apr 05, 2022 at 11:28:53AM +0200, Richard Biener wrote:
> > > > In GIMPLE, we call:
> > > > && gimple_builtin_call_types_compatible_p (stmt, fndecl)
> > > > but that is insuff
On 4/4/22 22:07, Joseph Myers wrote:
On Mon, 4 Apr 2022, Martin Liška wrote:
Ignore:
Checking 86d8e0c0652ef5236a460b75c25e4f7093cc0651: FAILED
ERR: line should start with a tab: "This reverts commits r12-7804 and
r12-7929."
ERR: could not deduce ChangeLog file
It seems Jason pushed the revisi
Hi!
And here is the follow-up patch that does the argument checking
on GENERIC. It ensures TYPE_MAIN_VARIANT == TYPE_MAIN_VARIANT
compatibility on the arguments, except for pointer arguments like
FILE *, const struct tm * etc. that would never match that way
and similarly to the gimple one also c
Hi.
The patch documents the newly added parameter. One question I have is
if it's fine listing it under 'i386 and x86_64 targets'?
Cheers,
Martin
gcc/ChangeLog:
* doc/invoke.texi: Document it.
---
gcc/doc/invoke.texi | 8
1 file changed, 8 insertions(+)
diff --git a/gcc/doc/
On 05/04/2022 22:07, Jørgen Kvalsvik wrote:
In action it looks pretty similar to the branch coverage. The -g short
opt carries no significance, but was chosen because it was an available
option with the upper-case free too.
gcov --conditions:
3: 17:void fn (int a, int b, int c, int
On Wed, 6 Apr 2022, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 08:13:24AM +0200, Richard Biener wrote:
> > On Tue, 5 Apr 2022, Jakub Jelinek wrote:
> >
> > > On Tue, Apr 05, 2022 at 11:28:53AM +0200, Richard Biener wrote:
> > > > > In GIMPLE, we call:
> > > > > && gimple_builtin_call_types_
> -Original Message-
> From: Martin Liška
> Sent: Wednesday, April 6, 2022 3:35 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao
> Subject: [PATCH] docs: Document new param x86-stlf-window-ninsns.
>
> Hi.
>
> The patch documents the newly added parameter. One question I have is if
On Wed, 6 Apr 2022, Jakub Jelinek wrote:
> Hi!
>
> And here is the follow-up patch that does the argument checking
> on GENERIC. It ensures TYPE_MAIN_VARIANT == TYPE_MAIN_VARIANT
> compatibility on the arguments, except for pointer arguments like
> FILE *, const struct tm * etc. that would never
On Wed, Apr 06, 2022 at 09:49:25AM +0200, Richard Biener wrote:
> On trees we'd use tree_[sign_]nop_conversion () instead of
> useless_type_conversion_p, I think it's OK to allow all such
> pointer conversions. In the end this probably means being
> more forgiving than TYPE_MAIN_VARIANT equivalenc
On Wed, 6 Apr 2022, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 09:49:25AM +0200, Richard Biener wrote:
> > On trees we'd use tree_[sign_]nop_conversion () instead of
> > useless_type_conversion_p, I think it's OK to allow all such
> > pointer conversions. In the end this probably means being
The negate propagation optimizations in reassoc did not look out for
abnormal SSA coalescing issues. The following fixes that.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-06 Richard Biener
PR tree-optimization/105163
* tree-ssa-reassoc.cc (repropagate
Richard Biener via Gcc-patches writes:
> On Wed, 6 Apr 2022, Jakub Jelinek wrote:
>
>> On Wed, Apr 06, 2022 at 08:13:24AM +0200, Richard Biener wrote:
>> > On Tue, 5 Apr 2022, Jakub Jelinek wrote:
>> >
>> > > On Tue, Apr 05, 2022 at 11:28:53AM +0200, Richard Biener wrote:
>> > > > > In GIMPLE, we
On Tue, Apr 05, 2022 at 04:56:55PM -0500, Segher Boessenkool wrote:
> > Or there are variant patches in the PR, either a minimal version of
> > this patch, or one that records regno and adjusts all SUBST_MODE uses.
>
> I like this one best I think :-)
>
> > Also, not sure I like very much a funct
On Wed, Apr 06, 2022 at 09:41:44AM +0100, Richard Sandiford wrote:
> But it seems like the magic incantation to detect “real” built-in
> function calls is getting longer and longer. Can we not abstract this
> in a single place rather than have to repeat the same long sequence in
> multiple places?
Hi!
On 2021-01-14T15:50:23+0100, I wrote:
> I'm raising here an issue with HSA libgomp plugin code changes from a
> while ago. While HSA is now no longer relevant for GCC master branch,
> the same code has also been copied into the GCN libgomp plugin.
Here is another small clean-up patch (to ena
This avoids -Wvector-operation-performance diagnostics for vectorizer
produced code. It's unfortunate the warning_at code in
tree-vect-generic.cc needs adjustments but the diagnostic suppression
code doesn't magically suppress those otherwise.
Bootstrap / regtest running on x86_64-unknown-linux-g
On Wed, Apr 06, 2022 at 11:20:47AM +0200, Thomas Schwinge wrote:
> However, the libgomp GCN plugin is unconditionally built against the
> GCC-shipped 'include/hsa*.h' header files, and at run time does
> 'dlopen("libhsa-runtime64.so.1")', so there is no system-provided HSA Runtime
> library "used f
On Wed, 6 Apr 2022, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 09:41:44AM +0100, Richard Sandiford wrote:
> > But it seems like the magic incantation to detect “real” built-in
> > function calls is getting longer and longer. Can we not abstract this
> > in a single place rather than have to r
Hi Jakub!
On 2022-04-06T11:24:17+0200, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 11:20:47AM +0200, Thomas Schwinge wrote:
>> However, the libgomp GCN plugin is unconditionally built against the
>> GCC-shipped 'include/hsa*.h' header files, and at run time does
>> 'dlopen("libhsa-runtime64.so
> -Original Message-
> From: Alex Coplan
> Sent: Thursday, March 31, 2022 5:20 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [PATCH][GCC 9] arm: Fix ICEs with compare-and-swap and -
> march=armv8-m.base [PR99977]
>
> Hi,
>
> This is a backport o
On 4/5/22 17:14, Thomas Schwinge wrote:
Hi!
Still catching up with GCC/nvptx back end changes... %-)
In the following I'm not discussing the patch to document
"gcc-12: Nvptx updates", but rather one aspect of the
"gcc-12: Nvptx updates" themselves. ;-)
On 2022-03-30T14:27:41+0200, Tom de Vr
Hi!
On 2021-01-14T15:50:23+0100, I wrote:
> I'm raising here an issue with HSA libgomp plugin code changes from a
> while ago. While HSA is now no longer relevant for GCC master branch,
> the same code has also been copied into the GCN libgomp plugin.
Here is another small clean-up patch (to ena
On Wed, Apr 06, 2022 at 11:52:23AM +0200, Richard Biener wrote:
> On Wed, 6 Apr 2022, Jakub Jelinek wrote:
>
> > On Wed, Apr 06, 2022 at 09:41:44AM +0100, Richard Sandiford wrote:
> > > But it seems like the magic incantation to detect “real” built-in
> > > function calls is getting longer and lon
We should avoid mismatched argument values (integers for pointers)
when doing modref queries. This is the third place to guard.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-06 Richard Biener
PR ipa/105166
* ipa-modref-tree.cc (modref_access_node::get_a
On Wed, 6 Apr 2022, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 11:52:23AM +0200, Richard Biener wrote:
> > On Wed, 6 Apr 2022, Jakub Jelinek wrote:
> >
> > > On Wed, Apr 06, 2022 at 09:41:44AM +0100, Richard Sandiford wrote:
> > > > But it seems like the magic incantation to detect “real” bui
Jakub Jelinek writes:
> On Wed, Apr 06, 2022 at 11:52:23AM +0200, Richard Biener wrote:
>> On Wed, 6 Apr 2022, Jakub Jelinek wrote:
>>
>> > On Wed, Apr 06, 2022 at 09:41:44AM +0100, Richard Sandiford wrote:
>> > > But it seems like the magic incantation to detect “real” built-in
>> > > function c
The find_insert_point logic around deciding whether to insert
before or after the found insertion point does not handle
the case of _12 = ..;, _12, 1.0 well. The following puts the
logic into find_insert_point itself instead.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-0
Another MIPS function return ABI fix. Ok for trunk?
--
This fixes tmpdir-g++.dg-struct-layout-1/{t032,t059} failure. Clang++
ignores C++17 empty bases in return values as well.
gcc/
* config/mips/mips.cc (mips_fpr_return_fields): Ignore
cxx17_empty_base_field_p fields.
---
gcc
Fixes gcc.dg/torture/pr91323.c fail for MIPS. Ok for trunk?
LTGT should trap for unordered operands (see discussion in bugzilla),
but c.ueq does not trap for qNaN. Use c.ngl as it handles non-NaN
operands like c.ueq, but traps for qNaN as we want for LTGT.
gcc/
PR target/91323
*
Hi!
On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote:
> Especially for distributions it is undesirable to need to have proprietary
> CUDA libraries and headers installed when building GCC.
> I've talked to our lawyers and they said that the cuda.h header included
> in this patch doesn't infringe
On Wed, Apr 06, 2022 at 02:39:18PM +0200, Thomas Schwinge wrote:
> ... so that it may be used by other projects that inherit GCC's 'include'
> directory.
>
> include/
> * cuda/cuda.h: New file.
> libgomp/
> * plugin/cuda/cuda.h: Remove file.
> * plugin/plugin-nvptx.c
Complex lowering cannot currently deal with asm gotos with _Complex
output operands. Emit a sorry instead of ICEing, those should not
appear in practice.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK for trunk and branch?
Thanks,
Richard.
2022-04-06 Richard Biener
PR midd
On Wed, Apr 06, 2022 at 08:33:40PM +0800, Xi Ruoyao via Gcc-patches wrote:
> Another MIPS function return ABI fix. Ok for trunk?
>
> --
>
> This fixes tmpdir-g++.dg-struct-layout-1/{t032,t059} failure. Clang++
> ignores C++17 empty bases in return values as well.
>
> gcc/
> * config/mips
On Wed, 2022-04-06 at 14:44 +0200, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 08:33:40PM +0800, Xi Ruoyao via Gcc-patches wrote:
> > Another MIPS function return ABI fix. Ok for trunk?
> >
> > --
> >
> > This fixes tmpdir-g++.dg-struct-layout-1/{t032,t059} failure. Clang++
> > ignores C++17
v2: Add psABI warning and test.
--
This fixes tmpdir-g++.dg-struct-layout-1/{t032,t059} failure. Clang++
also ignores C++17 empty bases in return values.
gcc/
* config/mips/mips.cc (mips_fpr_return_fields): Ignore
cxx17_empty_base_field_p fields and set an indicator.
(mi
This bug was an object/value confusion; we are interested in the size
of *b.ip, but instead the code was calculating the size of b.ip itself.
This seems to be because compute_objsize will compute the size of whatever
object it can find in the argument: if you pass it a VAR_DECL, it gives you
the s
The patch for PR92024 changed -Wshadow=compatible-local to warn if either
new or old decl was a type, but the rationale only talked about the case
where both are types. If only one is, they aren't compatible.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/100608
gcc/cp/ChangeLog:
On Wed, Apr 06, 2022 at 09:44:33PM +0800, Xi Ruoyao wrote:
> @@ -6527,6 +6554,27 @@ mips_function_value_1 (const_tree valtype, const_tree
> fn_decl_or_type,
>if (has_cxx_zero_width_bf)
> use_fpr = 0;
>
> + if (TARGET_HARD_FLOAT
> + && warn_psabi
> + && use_fpr != 0
On Fri, Feb 11, 2022 at 07:55:50PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Something like the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c16
> will still be needed with adjusted testcase from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c15 such that
> __builtin_clear_paddin
> From: Jonathan Wakely
> Date: Tue, 5 Apr 2022 20:47:58 +0200
> On Tue, 5 Apr 2022, 17:44 Hans-Peter Nilsson via
> Libstdc++,
> mailto:libstdc%2b...@gcc.gnu.org>>
> wrote:
> Ok to commit?
> -- 8< --
>
> Without this, for a target where alignment and structure-sizes are b
On Fri, Mar 25, 2022 at 07:55:56PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Mar 25, 2022 at 07:48:33PM +0100, Jakub Jelinek wrote:
> > We then wouldn't propagate TREE_DEPRECATED/TREE_UNAVAILABLE from templates
> > to their instantiations and wouldn't diagnose static data members in Ope
On Wed, Apr 06, 2022 at 09:49:25AM +0200, Richard Biener wrote:
> On trees we'd use tree_[sign_]nop_conversion () instead of
> useless_type_conversion_p, I think it's OK to allow all such
> pointer conversions. In the end this probably means being
> more forgiving than TYPE_MAIN_VARIANT equivalenc
On Wed, 2022-04-06 at 16:34 +0200, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 09:44:33PM +0800, Xi Ruoyao wrote:
> > @@ -6527,6 +6554,27 @@ mips_function_value_1 (const_tree valtype,
> > const_tree fn_decl_or_type,
> > if (has_cxx_zero_width_bf)
> > use_fpr = 0;
> >
> > +
On 4/6/22 10:41, Jakub Jelinek wrote:
On Fri, Feb 11, 2022 at 07:55:50PM +0100, Jakub Jelinek via Gcc-patches wrote:
Something like the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c16
will still be needed with adjusted testcase from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c15
We were attempting to issue a -Wctad-maybe-unsupported warning even when
complain=tf_none, which led to a crash in the first testcase below and a
bogus error during SFINAE in the second testcase.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/11?
PR c++/105
On 3/25/22 14:08, Jason Merrill wrote:
On 3/25/22 12:34, Jakub Jelinek wrote:
Hi!
cplus_decl_attributes can be called with attributes equal to
error_mark_node, there are some spots in the function that test
it or decl_attributes it calls starts with:
if (TREE_TYPE (*node) == error_mark_node
On 4/6/22 11:11, Patrick Palka wrote:
We were attempting to issue a -Wctad-maybe-unsupported warning even when
complain=tf_none, which led to a crash in the first testcase below and a
bogus error during SFINAE in the second testcase.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this l
On 4/6/2022 6:44 AM, Richard Biener via Gcc-patches wrote:
Complex lowering cannot currently deal with asm gotos with _Complex
output operands. Emit a sorry instead of ICEing, those should not
appear in practice.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK for trunk and branch?
On 3/31/2022 9:54 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
As discussed in PR102024, zero width bitfields might not be the only ones
causing ABI issues at least on mips, zero size arrays or (in C only) zero
sized (empty) structures can be problematic too.
The following patch adds some co
On 3/31/2022 2:30 AM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, various tests on sh-elf ICE like:
make check-gcc RUNTESTFLAGS="compile.exp='pr104327.c pr58332.c pr81360.c
pr84425.c'"
FAIL: gcc.c-torture/compile/pr104327.c -O0 (internal compiler error:
'global_options' are modified
On Wed, Apr 06, 2022 at 11:18:32AM -0400, Jason Merrill wrote:
> > Why not check at the beginning of the function?
>
> You just pinged this patch, but I haven't seen a response to this question.
I thought the
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592368.html
is the response to that
Document ABI changes in r12-7961, 7962, and 8023. Ok for wwwdocs?
---
htdocs/gcc-12/changes.html | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 4f2ee77f..c924bca3 100644
--- a/htdocs/gcc-
On 3/31/2022 12:56 AM, Martin Liška wrote:
Hi.
Before the patch we have:
$ gcc-11 --help | grep target-help
--target-help Display target specific command line options.
$ gcc-11 --help=common | grep target-help
--target-help Alias for --help=target.
and --target-
On 3/25/2022 3:51 AM, Richard Biener via Gcc-patches wrote:
We have
return VIEW_CONVERT_EXPR( VEC_PERM_EXPR < {<<< Unknown tree:
compound_literal_expr
V D.1984 = { 0 }; >>>, { 0 }} , {<<< Unknown tree:
compound_literal_expr
V D.1985 = { 0 }; >>>, { 0 }} , { 0, 0 } > &
This test fails with error "AltiVec argument passed to unprototyped
function", but the code (in rs6000.c:invalid_arg_for_unprototyped_fn,
from 2005) actually tests for any vector type argument. It also does
not fail on Darwin, not reflected here though.
Andreas, s390 has this same hook code, you
Here, because of problems with the new warning-control code and expressions
that change location, the suppress_warning on the INDIRECT_REF didn't work.
Those problems still need to be worked out, but it's simple to avoid needing
to use suppress_warning in the first place by using a reference instea
On 4/6/22 11:26, Jakub Jelinek wrote:
On Wed, Apr 06, 2022 at 11:18:32AM -0400, Jason Merrill wrote:
Why not check at the beginning of the function?
You just pinged this patch, but I haven't seen a response to this question.
I thought the
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/
On 4/6/22 03:23, Richard Biener wrote:
This avoids -Wvector-operation-performance diagnostics for vectorizer
produced code. It's unfortunate the warning_at code in
tree-vect-generic.cc needs adjustments but the diagnostic suppression
code doesn't magically suppress those otherwise.
It seems li
Thanks!
On Wed, 6 Apr 2022, 15:42 Hans-Peter Nilsson, wrote:
> > From: Jonathan Wakely
> > Date: Tue, 5 Apr 2022 20:47:58 +0200
>
> > On Tue, 5 Apr 2022, 17:44 Hans-Peter Nilsson via
> > Libstdc++,
> > mailto:libstdc%2b...@gcc.gnu.org>>
> > wrote:
> > Ok to commit?
> > -- 8< ---
Hi!
So, the core of this problem is once again that regno_reg_rtx is
reallocated. It will be another decade until we got rid of all fallout
of breaking that guarantee :-(
On Wed, Apr 06, 2022 at 10:50:40AM +0200, Jakub Jelinek wrote:
> On Tue, Apr 05, 2022 at 04:56:55PM -0500, Segher Boessenkool
>From bf51c49f1481001c7b3223474d261dcbf9365eda Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Fri, 1 Apr 2022 22:27:13 -0400
Subject: [PATCH] Add zero_extendditi2. Improve lxvr*x code generation.
This pattern adds zero_extendditi2 so that if we are extending DImode to
TImode, and we want
On Sat, Mar 12, 2022 at 07:40:08PM -, Roger Sayle wrote:
> My recent testcase for PR c++/84964.C stress tests the middle-end by
> attempting to pass a UINT_MAX sized structure on the stack. Although
> my fix to PR84964 avoids the ICE after sorry() on x86_64 and similar
> targets, a related iss
On 4/5/22 10:33 PM, Peter Bergner via Gcc-patches wrote:
> On 4/5/22 5:32 PM, Segher Boessenkool wrote:
>> On Tue, Apr 05, 2022 at 05:06:50PM -0500, Peter Bergner wrote:
>>>
>>> + /* Handle longcall attributes. */
>>> + if ((INTVAL (cookie) & CALL_LONG) != 0
>>> + && GET_CODE (func_desc)
On targets that return this from cdtors, cxx_eval_call_expression may
flag flowing off the end of a dtor. That's preempted for ctors, and
avoided entirely when dtors return void, but when they return this,
the return value should be conceptually disregarded, without making
room for such internal
This patch fixes a divergence in line numbers in diagnostics and,
presumably, debug information, between targets whose cdtors return
this and those that don't.
The problem was visible in g++.dg/cpp2a/constexpr-dtor3.C: while the
dtor call in the cleanup for f4 was expected at the closing brace,
On Wed, Apr 06, 2022 at 04:36:49PM -0300, Alexandre Oliva via Gcc-patches wrote:
>
> On targets that return this from cdtors, cxx_eval_call_expression may
> flag flowing off the end of a dtor. That's preempted for ctors, and
> avoided entirely when dtors return void, but when they return this,
>
On Wed, 2022-04-06 at 14:21 -0400, Michael Meissner wrote:
> From bf51c49f1481001c7b3223474d261dcbf9365eda Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Fri, 1 Apr 2022 22:27:13 -0400
> Subject: [PATCH] Add zero_extendditi2. Improve lxvr*x code generation.
>
Hi,
> This pattern adds
On Apr 6, 2022, Marek Polacek wrote:
> On Wed, Apr 06, 2022 at 04:36:49PM -0300, Alexandre Oliva via Gcc-patches
> wrote:
>> else
>> {
>> result = *ctx->global->values.get (res);
>> - if (result == NULL_TREE && !*non_constant_p)
>> + if (result == NULL_TREE && !*non_constant_p
On Fri, 2022-04-01 at 12:26 -0400, Eric Gallager wrote:
> On Fri, Apr 1, 2022 at 9:28 AM David Malcolm via Gcc-patches
> wrote:
> >
> > Further jit doc fixes, which fix links to
> > gcc_jit_function_type_get_param_type and gcc_jit_struct_get_field.
> >
> > I also regenerated libgccjit.texi (not
Dear all,
the logic for checking the allocate-coshape-spec in an ALLOCATE
statement was sort of sideways, and allowed to pass invalid
specifications to the code generation.
The fix seems obvious (to me).
Regtested on x86_64-pc-linux-gnu. OK for mainline?
(12 or wait for 13?).
Thanks,
Harald
F
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype, string-index, and
first-to-check. The last two specify the position in the function
parameter list. r63030 clarified that "Since non-static C++ methods have
an implicit this argument, the arguments of such
Hello! Thanks for your feedback. I've tried to take into account your
comments. New patch applied to the letter.
The only thing I have not removed is the check_std_c2x () function. From my
point of view -Wformat-overflow shouldn't be thrown if the standard < C2X.
So it's protection for false trigg
On 4/6/22 15:36, Alexandre Oliva wrote:
Please adjust your patch subject lines for the new guidelines adopted as
part of the git transition:
https://gcc.gnu.org/contribute.html#patches
e.g. [PATCH] c++: tolerate cdtors returning this in constexpr [PRn]
On targets that return this from c
On 4/6/22 15:37, Alexandre Oliva wrote:
Need to adjust this subject line, as well.
This patch fixes a divergence in line numbers in diagnostics and,
presumably, debug information, between targets whose cdtors return
this and those that don't.
The problem was visible in g++.dg/cpp2a/constexpr-d
On 4/6/22 15:45, Marek Polacek via Gcc-patches wrote:
On Wed, Apr 06, 2022 at 04:36:49PM -0300, Alexandre Oliva via Gcc-patches wrote:
On targets that return this from cdtors, cxx_eval_call_expression may
flag flowing off the end of a dtor. That's preempted for ctors, and
avoided entirely when
Another brown paper bag fix for MIPS :(.
This failure was not detected running mips.exp=pr102024-* with a cross
compiler, so I just spotted it now running the test natively.
---
The body of func is optimized away with -flto -fno-fat-lto-objects, so
the psABI inform is not emitted, causing a test
In gcc/toplev.c, there's the comment:
/* A local time stamp derived from the time of compilation. It will be
zero if the system cannot provide a time. It will be -1u, if the
user has specified a particular random seed. */
unsigned local_tick;
This is affirmed by init_local_tick()'
On Wed, Apr 6, 2022 at 3:44 PM Jason A. Donenfeld wrote:
>
> In gcc/toplev.c, there's the comment:
>
> /* A local time stamp derived from the time of compilation. It will be
> zero if the system cannot provide a time. It will be -1u, if the
> user has specified a particular random see
My cleanup in r12-296 cleared TREE_HAS_CONSTRUCTOR on digested class
initializers, but we leave it set for vectors, since we can't wrap them in
TARGET_EXPR.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/105187
gcc/cp/ChangeLog:
* typeck2.cc (store_init_value): Allow TREE
We were already checking COMPLETE_TYPE_P to recognize instantiation of a
generic lambda, but didn't consider that we might be nested in a non-generic
lambda.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101717
gcc/cp/ChangeLog:
* lambda.cc (lambda_expr_this_capture): Ch
We've had a diagnostic for this, but since r10-6571 added an assert to
splice_late_return_type, we need to diagnose before we call it.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101051
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Reject conversion with trailing retur
Disable float128 tests on VxWorks, PR target/104253.
In PR target/104253, it was pointed out the that test case added as part
of fixing the PR does not work on VxWorks because float128 is not
supported on that system. I have modified the three tests for float128 so
that they are manually excluded
On 4/6/22 17:32, Segher Boessenkool wrote:
> This test fails with error "AltiVec argument passed to unprototyped
> function", but the code (in rs6000.c:invalid_arg_for_unprototyped_fn,
> from 2005) actually tests for any vector type argument. It also does
> not fail on Darwin, not reflected here t
On Wed, 6 Apr 2022, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 09:49:25AM +0200, Richard Biener wrote:
> > On trees we'd use tree_[sign_]nop_conversion () instead of
> > useless_type_conversion_p, I think it's OK to allow all such
> > pointer conversions. In the end this probably means being
On Thu, Apr 7, 2022 at 12:44 AM Jason A. Donenfeld via Gcc-patches
wrote:
>
> In gcc/toplev.c, there's the comment:
>
> /* A local time stamp derived from the time of compilation. It will be
> zero if the system cannot provide a time. It will be -1u, if the
> user has specified a part
On Wed, 6 Apr 2022, Martin Sebor wrote:
> On 4/6/22 03:23, Richard Biener wrote:
> > This avoids -Wvector-operation-performance diagnostics for vectorizer
> > produced code. It's unfortunate the warning_at code in
> > tree-vect-generic.cc needs adjustments but the diagnostic suppression
> > code
86 matches
Mail list logo
