On Tue, Nov 14, 2023 at 09:47:31PM -0700, Jeff Law wrote:
> > c++: Implement C++26 P1854R4 - Making non-encodable string literals
> > ill-formed [PR110341]
> > This paper voted in as DR makes some multi-character literals
> > ill-formed.
> > 'abcd' stays valid, but e.g. 'á' is newly
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Wednesday, November 15, 2023 3:36 PM
To: juzhe.zh...@rivai.ai
Cc: Kito.cheng ; gcc-patches ;
jeffreyalaw ; Robin Dapp
Subject: Re: Re: [PATCH] RISC-V: Disallow RVV mode address for any
load/store[PR112535]
LGTM,
LGTM, and yeah, I agree that's a code model issue.
On Wed, Nov 15, 2023 at 3:29 PM juzhe.zh...@rivai.ai
wrote:
>
> Yes.
> (set (reg:DI) (subreg:DI (reg:V1DI 155) 0)) become vmv.x.s
>
> So, you will see:
> vsetivli zero,1,e64,m1,ta,ma
> sb zero,%lo(c)(a2)
> vle64.v v1,0(a5)
> lbu a5,%lo(b)(a4)
>
Yes.
(set (reg:DI) (subreg:DI (reg:V1DI 155) 0)) become vmv.x.s
So, you will see:
vsetivli zero,1,e64,m1,ta,ma
sb zero,%lo(c)(a2)
vle64.v v1,0(a5)
lbu a5,%lo(b)(a4)
vse64.v v1,0(a3)
beq a5,zero,.L6
vmv.x.s a5,v1
sw zero,0(a5)
I think the codegen is not good. It should be using scalar load/store.
Curious about the code gen impact, does it make IRA/LRA insert one more
move like (set (reg:DI) (subreg:DI (reg:V1DI 155) 0)) and then (set (mem:SI
(reg:DI)) (const_int 0))?
On Wed, Nov 15, 2023 at 3:15 PM Juzhe-Zhong wrote:
> This patch is quite obvious patch which disallow for load/store
This patch is quite obvious patch which disallow for load/store address register
with RVV mode.
PR target/112535
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimate_address_p): Disallow RVV
modes base address.
gcc/testsuite/ChangeLog:
*
LGTM. You can commit it.
Thanks.
juzhe.zh...@rivai.ai
From: Vineet Gupta
Date: 2023-11-15 14:41
To: gcc-patches
CC: Jeff Law; Robin Dapp; gnu-toolchain; Patrick O'Neill; Juzhe-Zhong; Vineet
Gupta
Subject: [PATCH] RISC-V: fix vsetvli pass testsuite failure [PR/112447]
From: Juzhe-Zhong
From: Juzhe-Zhong
Fixes: f0e28d8c1371 ("RISC-V: Fix failed hoist in LICM of vmv.v.x instruction")
Since above commit, we have the following failure:
FAIL: gcc.c-torture/execute/memset-3.c -O3 -g execution test
The issue was not the commit but it unravled an issue in vsetvli pass.
Here's
* Sam James:
> When posting v3, I guess consider CCing the aarch64 maintainers (or just
> pinging them separately)?
I already pinged them, they are likely busy with posting their patches
before stage 1 closes.
> I'm not really sure how approval of (an earlier version of) this series
> interacts
Following several remarks on a previous patch of _Hashtable I considered
clarifying its implementation.
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the mutable keyword. For
_Prime_rehash_policy methods are exported from the
Hello,
sorry, in the patch I should use targetm.have_atomic instead of
TARGET_HAVE_LIBATOMIC.
---
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
The gdb tests of the libcc1 plugin have been failing lately. I
tracked this down to a crash trying to access an enum's underlying
type. This patch fixes the crash by setting this type.
libcc1/ChangeLog
* libcc1plugin.cc (plugin_build_enum_type): Set
ENUM_UNDERLYING_TYPE.
---
Florian Weimer writes:
> This new series covers:
>
> -Wint-conversion
> -Wimplicit-function-declaration
> -Wimplicit-int
> -Wreturn-mismatch
> -Wincompatible-pointer-types
> -Wdeclaration-missing-parameter-type (new)
>
> There are now gcc.dg/permerror-*.c tests which track the
Florian Weimer writes:
> * Sam James:
>
>> Florian Weimer writes:
>>
>>> Most -Wimplicit-int warnings were unconditionally disabled for system
>>> headers. Only missing types for parameters in old-style function
>>> definitions resulted in warnings. This is inconsistent with the
>>>
* Sam James:
> Florian Weimer writes:
>
>> Most -Wimplicit-int warnings were unconditionally disabled for system
>> headers. Only missing types for parameters in old-style function
>> definitions resulted in warnings. This is inconsistent with the
>> treatment of other permerrors, which are
Florian Weimer writes:
> Most -Wimplicit-int warnings were unconditionally disabled for system
> headers. Only missing types for parameters in old-style function
> definitions resulted in warnings. This is inconsistent with the
> treatment of other permerrors, which are active in system
Could you test it v4096qi ?
Also, VLS modes need to be tested.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-11-15 11:48
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Refine the mask generation for vec_init case 2
From: Pan Li
We take
From: Pan Li
We take vec_init element int mode when generate the mask for
case 2. But actually we don't need as many bits as the element.
The extra bigger mode may introduce some unnecessary insns.
For example as below code:
typedef int64_t v16di __attribute__ ((vector_size (16 * 8)));
void
On 11/14/23 9:12 PM, Lehua Ding wrote:
> I've applied for machine permissions on the compile farm, can you give
> me the way to compile and run tests on PPC64BE machine? I'll take a look
> at it too, thanks a lot.
That's an old system, with too old system libgmp, etc. Let me attempt a
build
On 2023/11/15 7:22, Peter Bergner wrote:
On 11/12/23 6:08 AM, Lehua Ding wrote:
V3 Changes:
1. fix three ICE.
2. rebase
I tested this on powerpc64le-linux and powerpc64-linux. The LE build
bootstrapped fine and it looks like only one testsuite FAIL which I have
to look into why
Hi,
For constants with 16bit values, 'li or lis' can be used to generate
the value. For 34bit constant, 'pli' is ok to generate the value.
For example: 0xULL, "pli 3,1717986918; rldimi 3,3,32,0"
can be used.
Compare with previous:
Hi,
Sometimes, a complicated constant is built via 3(or more)
instructions to build. Generally speaking, it would not be
as faster as loading it from the constant pool (as a few
discussions in PR63281):
* "ld" is one instruction. If consider "address/toc"
adjust, we may count it as 2
Hi,
Trunk gcc supports more constants to be built via two instructions: e.g.
"li/lis; xori/xoris/rldicl/rldicr/rldic".
And then num_insns_constant should also be updated.
Function "rs6000_emit_set_long_const" is used to build complicate
constants; and "num_insns_constant_gpr" is used to compute
PCREL data accesses are only officially supported on ELFv2. We currently
incorrectly enable PCREL on all Power10 compiles in which prefix instructions
are also enabled. Rework the option override code so we only enable PCREL
for those ABIs that actually support it.
Jeevitha has confirmed this
I propose a new attribute for C++, labelled gnu::extended. This attribute
is for asm declarations, and the attribute marks them as extended asm. This
attribute shall contain all of the features of existing extended asm, but
also have additional features, described below.
Hi,
This patch cleans up by_pieces_ninsns and does following things.
1. Do the length and alignment adjustment for by pieces compare when
overlap operation is enabled.
2. Remove unnecessary mov_optab checks.
Bootstrapped and tested on x86 and powerpc64-linux BE and LE with
no regressions. Is
Hi,
This patch cleans up by_pieces_ninsns and does following things.
1. Do the length and alignment adjustment for by pieces compare when
overlap operation is enabled.
2. Remove unnecessary mov_optab checks.
Bootstrapped and tested on x86 and powerpc64-linux BE and LE with
no regressions. Is
On 2023/11/14 0:43, Dimitar Dimitrov wrote:
On Sun, Nov 12, 2023 at 08:08:10PM +0800, Lehua Ding wrote:
V3 Changes:
1. fix three ICE.
2. rebase
Hi,
These patchs try to support subreg coalesce feature in
register allocation passes (ira and lra).
Hi Lehua,
V3 indeed fixes the
LGTM, and BTW...I am thinking we could relax the canonical order
during parsing, did you have interesting and time working on that
item?
On Wed, Nov 15, 2023 at 9:35 AM Patrick O'Neill wrote:
>
> Passing in a base extension in non-canonical order (i, e, g) causes GCC
> to ICE:
> xgcc: error:
On Tue, Nov 14, 2023 at 6:09 PM Arsen Arsenović wrote:
> Hi David,
>
> David Edelsohn writes:
>
> > Arsen,
> >
> > Unfortunately this broke bootstrap on AIX.
> >
> > I had not seen this series of patches.
>
> I've added Bruno to CC as the libintl maintainer, to keep him in the
> loop. Could
Passing in a base extension in non-canonical order (i, e, g) causes GCC
to ICE:
xgcc: error: '-march=rv64ge': ISA string is not in canonical order. 'e'
xgcc: internal compiler error: in add, at
common/config/riscv/riscv-common.cc:671
...
This is fixed by skipping to the next extension when a
Previously our JSON output emitted the JSON all on one line, with
no indentation or newlines to show the structure of the values.
Although it's easy to reformat such output (e.g. with
"python -m json.tool"), I've found it's a pain to need to do so
e.g. my text editor sometimes hangs when opening
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-5473-g2220263f0e032a.
gcc/ChangeLog:
* json.cc (selftest::assert_print_eq): Add "loc" param and use
ASSERT_STREQ_AT.
(ASSERT_PRINT_EQ): New macro.
Sorry for disturbing, looks I have a typo for Richard S's email address, cc the
right email address for awareness.
Pan
-Original Message-
From: Li, Pan2
Sent: Wednesday, November 15, 2023 8:18 AM
To: Jeff Law ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ;
RV64 compare and branch instructions only support 64-bit operands.
At Expand time, the backend conservatively zero/sign extends
its operands even if not needed, such as incoming function args
which ABI/ISA guarantee to be sign-extended already (this is true for
SI, HI, QI operands)
And
Li, Pan2 would like to recall the message, "[PATCH v4] DSE: Allow vector type
for get_stored_val when read < store".
> I wouldn't try to handle that case unless we had actual evidence it was
> useful to do so. Just wanted to point out that unlike pseudos we can
> have multiple modes referencing the same memory location.
Got the point here, thanks Jeff for emphasizing this, .
Pan
-Original Message-
Patch updated to trunk.
This adds support to vectorizable_live_reduction to handle multiple exits by
doing a search for which exit the live value should be materialized in.
Additinally which value in the index we're after depends on whether the exit
it's materialized in is an early exit or
Patch updated to latest trunk:
Hi All,
This changes the PHI node updates to support early breaks.
It has to support both the case where the loop's exit matches the normal loop
exit and one where the early exit is "inverted", i.e. it's an early exit edge.
In the latter case we must always
Patch updated to latest trunk,
This splits the part of the function that does peeling for loops at exits to
a different function. In this new function we also peel for early breaks.
Peeling for early breaks works by redirecting all early break exits to a
single "early break" block and combine
> > OK, but then I think the fix is to not use
> > standard_iv_increment_position (it's a weird API anyway). Instead insert
> before the main exit condition.
>
> I figured as much, Almost done respinning it with the vectorizer's own simpler
> copy.
> Should be out today with the rest.
>
> >
> >
On 11/13/23 11:37 PM, Lehua Ding wrote:
> On 2023/11/14 3:37, Vladimir Makarov wrote:
>> Also besides testing major targets I'd recommend testing at least one big
>> endian target (I'd recommend ppc64be. gcc110.fsfrance.org could be used
>> for this). Plenty RA issues occur because BE targets are
On 11/12/23 6:08 AM, Lehua Ding wrote:
> V3 Changes:
> 1. fix three ICE.
> 2. rebase
I tested this on powerpc64le-linux and powerpc64-linux. The LE build
bootstrapped fine and it looks like only one testsuite FAIL which I have
to look into why it's FAILing.
The BE build did bootstrap, but
Hi David,
David Edelsohn writes:
> Arsen,
>
> Unfortunately this broke bootstrap on AIX.
>
> I had not seen this series of patches.
I've added Bruno to CC as the libintl maintainer, to keep him in the
loop. Could you provide some extra information w.r.t. the failure mode?
I'll try to
On 11/1/23 11:07, Patrick Palka wrote:
On Tue, 31 Oct 2023, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Does it look OK for release branches as well for sake of PR111703?
-- >8 --
potential_constant_expression was incorrectly treating
On Tue, 14 Nov 2023 at 00:27, Cassio Neri wrote:
>
> The current implementation calls __detail::__modulo which is relatively
> expensive.
>
> A better implementation is possible if we assume that x.ok() && y.ok() ==
> true,
> so that n = x.c_encoding() - y.c_encoding() is in [-6, 6]. In this
On Sun, 12 Nov 2023 at 01:34, Cassio Neri wrote:
>
> The following has undefined behaviour (signed overflow) [1]:
> weekday max{sys_days{days{numeric_limits::max()}}};
>
> The issue is in this line when __n is very large and __n + 4 overflows:
> return weekday(__n >= -4 ? (__n + 4) % 7 :
On Sat, 11 Nov 2023 at 23:00, Cassio Neri wrote:
>
> The current implementation returns
> (_M_y & (__is_multiple_of_100 ? 15 : 3)) == 0;
> where __is_multiple_of_100 is calculated using an obfuscated algorithm which
> saves one ror instruction when compared to _M_y % 100 == 0 [1].
>
> In leap
On Sat, 11 Nov 2023 at 16:46, Cassio Neri wrote:
>
> When year_month_day_last::day() was implemented, Dr. Matthias Kretz realised
> that the operation "& 1" wasn't necessary but we did not patch it at that
> time. This patch removes the unnecessary operation.
>
> libstdc++-v3/ChangeLog:
>
>
Tested x86_64-linux. Pushed to trunk. Backports needed too.
-- >8 --
In we pass the int __base parameter to our internal versions
of functions, __bit_width and __countr_zero. Those functions are
only defined for unsigned types, so we need to convert the base to
unsigned. The base must be in
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For decltype((x)) within a lambda where x is not captured, we dubiously
require that the lambda has a capture default, unlike for decltype(x).
This patch fixes this
On 11/14/23 11:35, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
The NON_DEPENDENT_EXPR removal exposed that is_direct_enum_init may end
up checking convertibility of a type-dependent argument.
PR c++/112515
Tested x86_64-linux. Pushed to trunk. Backports needed too.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/112348
* include/std/stacktrace (hash>): Fix
type of hash functio nfor entries.
* testsuite/19_diagnostics/stacktrace/hash.cc: New test.
---
On 11/14/23 16:04, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
Here we're ICEing from strip_typedefs for the partially instantiated
requires-expression when walking its REQUIRES_EXPR_EXTRA_ARGS since it's
a TREE_LIST with
On 11/14/23 10:43, Patrick Palka wrote:
On Fri, 10 Nov 2023, Jason Merrill wrote:
On 11/10/23 10:28, Patrick Palka wrote:
On Fri, 10 Nov 2023, Patrick Palka wrote:
On Thu, 9 Nov 2023, Jason Merrill wrote:
On 11/8/23 16:59, Patrick Palka wrote:
Bootstrapped and regtested on
* Marek Polacek:
> On Tue, Nov 14, 2023 at 06:50:58PM +0100, Florian Weimer wrote:
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -591,6 +591,10 @@ Wdeclaration-after-statement
>> C ObjC Var(warn_declaration_after_statement) Init(-1) Warning
>> Warn when a declaration is found
On 11/14/23 10:58, Marek Polacek wrote:
On Mon, Nov 13, 2023 at 09:26:41PM -0500, Jason Merrill wrote:
On 11/10/23 20:13, Marek Polacek wrote:
On Thu, Nov 09, 2023 at 07:07:03PM -0500, Jason Merrill wrote:
On 11/9/23 14:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu,
The code coverage support uses counters to determine which edges in the control
flow graph were executed. If a counter overflows, then the code coverage
information is invalid. Therefore the counter type should be a 64-bit integer.
In multi-threaded applications, it is important that the counter
This reverts commit 8cdcea51c0fd753e6a652c9b236e91b3a6e0911c.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Do not define
__LIBGCC_GCOV_TYPE_SIZE.
gcc/ChangeLog:
* config/sparc/rtemself.h (SPARC_GCOV_TYPE_SIZE): Remove.
* config/sparc/sparc.cc
Move the counter update to the new gen_counter_update() helper function. Use
it in gimple_gen_edge_profiler() and gimple_gen_time_profiler(). The resulting
gimple instructions should be identical with the exception of the removed
unshare_expr() call. The unshare_expr() call was used in
Sebastian Huber (4):
gcov: Remove TARGET_GCOV_TYPE_SIZE target hook
Add TARGET_HAVE_LIBATOMIC
gcov: Add gen_counter_update()
gcov: Improve -fprofile-update=atomic
gcc/c-family/c-cppbuiltin.cc | 4 +-
gcc/config/rtems.h | 2 +
gcc/config/sparc/rtemself.h | 2 -
Add target data to indicate if libatomic is available.
gcc/ChangeLog:
* config/rtems.h (TARGET_HAVE_LIBATOMIC): Define.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_HAVE_LIBATOMIC): Add.
* target.def (have_libatomic): New.
---
gcc/config/rtems.h | 2 ++
On 11/14/23 12:38, Jakub Jelinek wrote:
On Mon, Nov 13, 2023 at 10:59:52PM -0500, Jason Merrill wrote:
On 11/13/23 06:50, Jakub Jelinek wrote:
The following patch implements C++26 P2864R2 by emitting pedwarn enabled by
the same options as the C++20 and later warnings (i.e. -Wenum-compare,
This is isomorphic to the LLVM changes [1-2].
On LoongArch, the LL and SC instructions has memory barrier semantics:
- LL: +
- SC: +
But the compare and swap operation is allowed to fail, and if it fails
the SC instruction is not executed, thus the guarantee of acquiring
semantics cannot be
On 11/13/23 8:33 PM, Kewen.Lin wrote:
>> if (PCREL_SUPPORTED_BY_OS)
>
>> + else
>> +{
>> + if (TARGET_PCREL
>> + && (rs6000_isa_flags_explicit & OPTION_MASK_PCREL) != 0)
>> +error ("use of %qs is invalid for this target", "-mpcrel");
>>rs6000_isa_flags &=
On Tue, 2023-11-14 at 11:44 +0100, Richard Biener wrote:
> > diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
> > index 2d2e5a3c1ca..f3745d86aea 100644
> > --- a/gcc/simplify-rtx.cc
> > +++ b/gcc/simplify-rtx.cc
> > @@ -4392,7 +4392,7 @@ simplify_ashift:
> > real_convert (, mode,
* Dimitar Dimitrov:
> The -w option was used in gcc.dg/20020206-1.c to ignore warnings if the
> '-fprefetch-loop-arrays' option is not supported by target.
>
> When commit r14-5380-g5c432b0efab54e removed the -w option, some targets
> (arm-none-eabi, pru and possibly others) started failing the
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we're ICEing from strip_typedefs for the partially instantiated
requires-expression when walking its REQUIRES_EXPR_EXTRA_ARGS since it's
a TREE_LIST with non-empty TREE_PURPOSE (to hold the captured
On Sun, Nov 12, 2023 at 08:02:43PM -1000, Iain Sandoe wrote:
> This adds the ability to defer the validation of numeric attribute
> arguments until the sequence is parsed if the attribute being
> handled is one known to be 'clang form'.
>
> We do this by considering the arguments to be strings
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Integration testing of analyzer shows no significant differences.
Pushed to trunk as r14-5464-gcfaaa8b11b8429.
gcc/analyzer/ChangeLog:
PR analyzer/103533
* sm-taint.cc: Remove "experimental" from comment.
*
On Wed, 2023-11-15 at 04:42 +0800, Xi Ruoyao wrote:
> > There seems a better solution as suggested by the GCC internal doc.
> > Section 18.9.16 mentions -fipa-ra:
> >
> > -- Target Hook: bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
> > Set to true if each call that binds to a local
On Wed, 2023-11-15 at 04:26 +0800, Xi Ruoyao wrote:
> On Tue, 2023-11-14 at 20:46 +0800, chenglulu wrote:
> >
> > 在 2023/11/14 下午5:55, Xi Ruoyao 写道:
> > > On Tue, 2023-11-14 at 17:45 +0800, Lulu Cheng wrote:
> > > > + /* When function calls are made through call36, t0 register
> > > > will
On 11/13/23 01:02, Iain Sandoe wrote:
The clang compiler supports essentially arbitrary, per-attribute, syntax and
token forms for attribute arguments. This extends to the case where token
forms are required to be accepted that are not part of the valid set for
standard C or C++.
A motivating
On 11/12/23 07:08, Lehua Ding wrote:
gcc/ChangeLog:
* hard-reg-set.h (struct HARD_REG_SET): New shift operator.
* ira-build.cc (ira_create_object): Adjust.
(find_object): New.
(find_object_anyway): New.
(ira_create_allocno): Adjust.
(get_range):
Arsen,
Unfortunately this broke bootstrap on AIX.
I had not seen this series of patches.
David
On Tue, Nov 14, 2023 at 06:50:58PM +0100, Florian Weimer wrote:
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -591,6 +591,10 @@ Wdeclaration-after-statement
> C ObjC Var(warn_declaration_after_statement) Init(-1) Warning
> Warn when a declaration is found after a statement.
>
>
On Tue, 2023-11-14 at 20:46 +0800, chenglulu wrote:
>
> 在 2023/11/14 下午5:55, Xi Ruoyao 写道:
> > On Tue, 2023-11-14 at 17:45 +0800, Lulu Cheng wrote:
> > > + /* When function calls are made through call36, t0 register
> > > will be
> > > + implicitly modified, so '-fno-ipa-ra' needs to be set
On 11/12/23 07:08, Lehua Ding wrote:
This patch switch the use of live_reg data to live_subreg data.
gcc/ChangeLog:
* ira-build.cc (create_bb_allocnos): Switch.
Switch to what? Although from the patch itself someone can figure it
out, you should write it in the changelog entry.
> From: Dimitar Dimitrov
> Date: Tue, 14 Nov 2023 22:00:14 +0200
> The -w option was used in gcc.dg/20020206-1.c to ignore warnings if the
> '-fprefetch-loop-arrays' option is not supported by target.
>
> When commit r14-5380-g5c432b0efab54e removed the -w option, some targets
> (arm-none-eabi,
The -w option was used in gcc.dg/20020206-1.c to ignore warnings if the
'-fprefetch-loop-arrays' option is not supported by target.
When commit r14-5380-g5c432b0efab54e removed the -w option, some targets
(arm-none-eabi, pru and possibly others) started failing the test:
cc1: warning:
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-5459-g353f146cebbf22.
gcc/c-family/ChangeLog:
* c-warn.cc (conversion_warning): Update call to
global_dc->m_option_enabled to use option_enabled_p.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-5458-g07e568d77f364e.
gcc/ChangeLog:
* diagnostic-show-locus.cc (diagnostic_context::show_locus):
Update for renaming of text callbacks fields.
*
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-5457-gd0bfd6ba3ba77f.
gcc/ChangeLog:
* diagnostic.h (diagnostic_ready_p): Convert from macro to inline
function.
---
gcc/diagnostic.h | 6 +-
1 file changed,
On 11/14/23 12:18, Vladimir Makarov wrote:
On 11/14/23 03:38, Lehua Ding wrote:
This is perfectly fine, the code inside the live_subreg problem has a
branch that goes through similar logic to live_reg if it finds no
subreg inside the program. Then when the optimization level is less
This used to be a warning, enabled by default, without its own option.
A subsequent change could improve diagnostics and provide spelling
hints for declarations like “void function (int32t);”.
gcc/c-family/
* c.opt (Wdeclaration-missing-parameter-type): New.
gcc/c/ChangeLog:
Most -Wimplicit-int warnings were unconditionally disabled for system
headers. Only missing types for parameters in old-style function
definitions resulted in warnings. This is inconsistent with the
treatment of other permerrors, which are active in system headers.
gcc/c/
* c-decl.cc
On Mon, Nov 13, 2023 at 10:49:23PM +0100, Uros Bizjak wrote:
> Combine wants to combine following instructions into an insn that can
> perform both an (arithmetic) operation and set the condition code. During
> the conversion a new RTX is created, and combine passes the RTX code of the
>
The change to build_conditional_expr drops the downgrade
from a pedwarn to warning for builtins.
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
PR c/96284
* c-typeck.cc (build_conditional_expr): Upgrade most pointer
type mismatches to a
Most of these new permerrors are currently not diagnosed in system
headers.
gcc/
PR c/91093
PR c/96284
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
* c-decl.cc (warn_defaults_to): Remove.
(grok_declarator, start_function): Call
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
PR c/96284
* c-typeck.cc (c_finish_return): Use permerrors
for OPT_Wreturn_mismatch diagnostics.
gcc/testsuite/
* gcc.dg/permerror-default.c (return_mismatch_1)
In the future, it may make sense to avoid cascading errors from
the implicit declaration, especially its assumed int return type.
This change here only changes the kind of the diagnostic, not
its wording or consequences.
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
PR c/96284
PR c/106416
* c-typeck.cc (build_conditional_expr): Use permerror_opt for
pointer/integer type mismatches, based on -Wint-conversion.
(pedwarn_permerror_init,
The dg-error directives for gcc.dg/permerror-system.c can be generated
using (for the most part at least):
perl -ne 'print if s,.*(/\* \{ dg-error .*) } \*/$,$1 "" { target *-*-* } $. }
*/,' \
< gcc/testsuite/gcc.dg/permerror-default.c
gcc/testsuite/
* gcc.dg/permerror-default.c: New
This new series covers:
-Wint-conversion
-Wimplicit-function-declaration
-Wimplicit-int
-Wreturn-mismatch
-Wincompatible-pointer-types
-Wdeclaration-missing-parameter-type (new)
There are now gcc.dg/permerror-*.c tests which track the graduation of
warnings to errors.
It turns out
On Mon, Nov 13, 2023 at 10:59:52PM -0500, Jason Merrill wrote:
> On 11/13/23 06:50, Jakub Jelinek wrote:
> > The following patch implements C++26 P2864R2 by emitting pedwarn enabled by
> > the same options as the C++20 and later warnings (i.e. -Wenum-compare,
> > -Wdeprecated-enum-enum-conversion
Following testcase:
struct S1
{
unsigned char val;
unsigned char pad1;
unsigned short pad2;
};
struct S2
{
unsigned char pad1;
unsigned char val;
unsigned short pad2;
};
struct S1 test_and (struct S1 a, struct S2 b)
{
a.val &= b.val;
return a;
}
compiles with -O2 to:
movl
On 14/11/2023 17:01, Christophe Lyon wrote:
Hi,
On 11/13/23 15:26, Richard Earnshaw wrote:
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 1a7bea96c1e..d414cddf4dc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++
On 11/14/23 03:38, Lehua Ding wrote:
This is perfectly fine, the code inside the live_subreg problem has a
branch that goes through similar logic to live_reg if it finds no
subreg inside the program. Then when the optimization level is less
than 2, it doesn't track the subreg. By the way,
Hi,
On 11/13/23 15:26, Richard Earnshaw wrote:
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 1a7bea96c1e..d414cddf4dc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5590,6 +5590,24 @@ proc
Hi Richard,
> +/* Maximum bytes set for an inline memset expansion. With -Os use 3 STP
> + and 1 MOVI/DUP (same size as a call). */
> +#define MAX_SET_SIZE(speed) (speed ? 256 : 96)
> So it looks like this assumes we have AdvSIMD. What about
> -mgeneral-regs-only?
After my strictalign
1 - 100 of 156 matches
Mail list logo
