Hi!
As discussed earlier, using build_nonstandard_integer_type blindly for all
INTEGRAL_TYPE_Ps is problematic now that we have BITINT_TYPE, because it
always creates an INTEGRAL_TYPE with some possibly very large precision.
The following patch attempts to deal with 3 such spots in match.pd, other
Hi!
clearenv function just sets environ to NULL (after sometimes freeing it),
rather than setting it to a pointer to NULL, and our code was assuming
it is always non-NULL.
Fixed thusly, the change seems to be large but actually is just
+ if (environ)
for (env = environ; *env != 0; env++)
pl
Hi!
On Tue, Sep 12, 2023 at 05:27:30PM +, Joseph Myers wrote:
> On Tue, 12 Sep 2023, Jakub Jelinek via Gcc-patches wrote:
>
> > And by ensuring we never create 1-bit signed BITINT_TYPE e.g. the backends
> > don't need to worry about them.
> >
> > But I adm
Hi!
On Tue, Sep 12, 2023 at 09:02:55AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches
> > wrote:
> > &g
Hi!
I'd like to ping a couple of C++ patches. All of them together
with the 2 updated patches posted yesterday have been
bootstrapped/regtested on x86_64-linux and i686-linux again yesterday.
- c++: Implement C++26 P2361R6 - Unevaluated strings [PR110342]
https://gcc.gnu.org/pipermail/gcc-patc
On Thu, Aug 24, 2023 at 04:30:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
> The following patch on top of PR110349 patch (weak dependency,
> only for -Wc++26-extensions, I could split that part into an independent
> patch) and PR110342 patch (again weak dependency, this time mainly
On Tue, Aug 22, 2023 at 09:39:11AM +0200, Jakub Jelinek via Gcc-patches wrote:
> The following patch implements the C++26 P2169R4 paper.
> As written in the PR, the patch expects that:
> 1) https://eel.is/c++draft/expr.prim.lambda.capture#2
>"Ignoring appearances in ini
Hi!
I'd like to ping this patch.
The C++ FE part has been approved by Jason already with a minor change
I've made in my copy.
Are the remaining parts ok for trunk?
On Fri, Aug 11, 2023 at 10:48:19AM +0200, Jakub Jelinek via Gcc-patches wrote:
> 2023-08-11 Jakub Jelin
On Mon, Sep 18, 2023 at 11:04:16AM +0200, Richard Biener via Gcc-patches wrote:
> > Note genmatch should warn (or error out) if this gets detected so I filed
> > PR 111446
> > which I will be looking into next week or the week after so we don't run
> > into
> > this issue again.
> >
> > P
On Thu, Sep 14, 2023 at 01:23:13PM +, Richard Biener via Gcc-patches wrote:
> diff --git a/libgomp/team.c b/libgomp/team.c
> index 54dfca8080a..e5a86de1dd0 100644
> --- a/libgomp/team.c
> +++ b/libgomp/team.c
> @@ -756,8 +756,9 @@ gomp_team_start (void (*fn) (void *), void *data,
> unsigned nt
On Tue, Sep 12, 2023 at 01:34:43PM -0400, Marek Polacek via Gcc-patches wrote:
> On Tue, Sep 12, 2023 at 01:27:44PM -0400, Jason Merrill via Gcc-patches wrote:
> > Tested x86_64-pc-linux-gnu, applying to trunk.
> >
> > -- 8< --
> >
> > The argument might not already be an integer.
> >
> > PR
On Tue, Sep 12, 2023 at 10:27:18AM +, Richard Biener wrote:
> On Mon, 11 Sep 2023, Jakub Jelinek wrote:
> > And, also I think it is undesirable when being asked for signed_type_for
> > of unsigned _BitInt(1) (which is valid) to get signed _BitInt(1) (which is
> > invalid, the standard only allo
On Tue, Sep 12, 2023 at 09:04:16AM +0200, Tobias Burnus wrote:
> Done now. What's not caught is, e.g., a value change by calling a
> function which modifies its parameter:
>
> omp_allocator_t a = ...; int v; foo(a); #pragma omp allocate(v) allocator(a)
>
> as the current check is only whether 'a'
On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches
> wrote:
> > Thanks for the report,
> >
> > After investigation it seems the location of the new dejagnu direc
On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches wrote:
> Thanks for the report,
>
> After investigation it seems the location of the new dejagnu directive for
> C++ differs depending on the configuration.
> The expected warning is still emitted, but its location differ sl
Hi!
When discussing PR111369 with Andrew Pinski, I've realized that
I haven't added BITINT_TYPE handling to range_check_type. Right now
(unsigned) max + 1 == (unsigned) min for signed _BitInt,l so I think we
don't need to do the extra hops for BITINT_TYPE (though possibly we don't
need them for I
Hi!
The following testcase ICEs, because vn_walk_cb_data::push_partial_def
uses a fixed size buffer (64 target bytes) for its
construction/deconstruction of partial stores and fails if larger precision
than that is needed, and the PR93582 changes assert push_partial_def
succeeds (and check the var
On Mon, Sep 11, 2023 at 09:27:48AM -0400, David Malcolm via Gcc-patches wrote:
> On Sun, 2023-09-10 at 16:36 +0200, Guillaume Gomez wrote:
> > When going through the code, I saw a lot of trailing whitespace
> > characters so I decided to write a small script that would remove
> > them. I didn't exp
On Mon, Sep 11, 2023 at 03:21:54PM +0200, Tobias Burnus wrote:
> + if (TREE_STATIC (var))
> + {
> + if (allocator == NULL_TREE && allocator_loc == UNKNOWN_LOCATION)
> + error_at (loc, "% clause required for "
> +"static variable %qD", var);
> + e
Hi!
One question to David below, CCed.
On Mon, Sep 11, 2023 at 01:44:07PM +0200, Tobias Burnus wrote:
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -681,6 +681,11 @@ decl_jump_unsafe (tree decl)
>if (VAR_P (decl) && C_DECL_COMPOUND_LITERAL_P (decl))
> return false;
>
> + if (fl
On Mon, Sep 11, 2023 at 12:06:19PM +0100, Jonathan Wakely via Gcc-patches wrote:
> Tested x86_64-linux, powerpc-aix, and minimally tested on macOS 12.6
> (darwin 21.6.0).
>
> OK for trunk?
>
> -- >8 --
>
> contrib/ChangeLog:
>
> PR other/111359
> * gcc-git-customization.sh: Check fo
On Fri, Sep 08, 2023 at 02:58:40PM +0200, Arthur Cohen wrote:
> From: Raiki Tamura
>
> libcpp/ChangeLog:
>
> * charset.cc (check_xid_property):new function to check XID_Start and
> XID_Continue
> * include/cpplib.h (check_xid_property):add enum representing XID
> properties
Just r
Hi!
The recent pp_wide_int changes for _BitInt support (because not all
wide_ints fit into the small fixed size digit_buffer anymore) apparently
broke
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c (test for excess errors)
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c 2 blank line
On Fri, Sep 08, 2023 at 10:25:42AM +0200, Christophe Lyon wrote:
> Revert "libstdc++: Use GLIBCXX_CHECK_LINKER_FEATURES for cross-builds
> (PR111238)"
>
> diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
> index 8f7b01e0563..0c60149d7f6 100644
> --- a/libstdc++-v3/ChangeLog
> +++ b
On Thu, Sep 07, 2023 at 10:18:37AM -0600, Sandra Loosemore wrote:
> This ICE was caused by an invalid assumption that all BIND_EXPRs have
> a non-null BIND_EXPR_BLOCK. In C++ these do exist and are used for
> temporaries introduced in expressions that are not full-expressions.
> Since they have no
On Thu, Sep 07, 2023 at 10:20:19AM +0200, Christophe Lyon via Gcc-patches wrote:
> On Tue, 5 Sept 2023 at 16:38, Tobias Burnus wrote:
>
> > That's based on the fail
> > https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
> > and on the discussion on IRC.
> >
>
> Sorry I didn't notice the p
On Thu, Sep 07, 2023 at 11:30:53AM +0200, Tobias Burnus wrote:
> contrib/gcc-changelog: Check whether revert-commit exists
>
> contrib/ChangeLog:
>
> * gcc-changelog/git_commit.py (GitCommit.__init__):
> Handle commit_to_info_hook = None; otherwise, if None,
> regard it as error
On Thu, Sep 07, 2023 at 10:36:02AM +0200, Thomas Schwinge wrote:
> Minor comment/question: are we doing away with the property that
> 'assert'-like "calls" must not have side effects? Per 'gcc/system.h',
> this is "OK" for 'gcc_assert' for '#if ENABLE_ASSERT_CHECKING' or
> '#elif (GCC_VERSION >= 4
On Tue, Sep 05, 2023 at 10:40:26PM +, Joseph Myers wrote:
> Additional tests I think should be added (for things I expect should
> already work):
>
> * Tests for BITINT_MAXWIDTH in . Test that it's defined for
> C2x, but not defined for C11/C17 (the latter independent of whether the
> targ
Hi!
Thanks for the patch reviews (and to Richi and Uros as well) and everyone
who participated in discussions.
Here is the updated version of the C _BitInt support [PR102989] patch
I've committed to trunk in addition to the rest of the series (except the
_BitInt a ? ~b : b match.pd fix patch, whi
On Tue, Sep 05, 2023 at 03:07:15PM -0700, Andrew Pinski wrote:
> Note I notice another all to build_nonstandard_integer_type in this
> match pattern which might also need to be fixed:
> /* For (x << c) >> c, optimize into x & ((unsigned)-1 >> c) for
>unsigned x OR truncate into the precision(ty
On Tue, Sep 05, 2023 at 02:42:39PM -0700, Andrew Pinski wrote:
> On Tue, Sep 5, 2023 at 12:31 AM Jakub Jelinek via Gcc-patches
> > Recent match.pd changes trigger ICE in build_minus_one_cst, apparently
> > I forgot to handle BITINT_TYPE in these (while I've handled it i
On Tue, Sep 05, 2023 at 02:27:10PM -0700, Andrew Pinski wrote:
> > I admit it isn't really clear to me what do you want to achieve by the
> > above build_nonstandard_integer_type. Is it because of BOOLEAN_TYPE
> > or perhaps ENUMERAL_TYPE as well?
>
> Yes I was worried about types where the preci
Hi!
Now that _Float{16,32,64,128,32x,64x,128x} and
{f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard,
I think it is undesirable to pedwarn about these for -std=c2x, so this
patch uses pedwarn_c11 instead. In c-family/, we don't have that function
and am not sure it would be ve
On Mon, Sep 04, 2023 at 11:14:41PM -0600, Jeff Law wrote:
>
>
> On 9/4/23 14:58, Hamza Mahfooz wrote:
> > Currently, we give up in fold_strstr_to_strncmp() if the length of the
> > the second argument to strstr() isn't known to us by the time we hit
> > that function. However, we can instead inse
Hi!
I've noticed a typo in a comment, fixed thusly.
Committed to trunk as obvious.
2023-09-05 Jakub Jelinek
* tree-ssa-tail-merge.cc (replace_block_by): Fix a comment typo:
avreage -> average.
--- gcc/tree-ssa-tail-merge.cc.jj 2023-07-11 13:40:40.253431941 +0200
+++ gcc
Hi!
Recent match.pd changes trigger ICE in build_minus_one_cst, apparently
I forgot to handle BITINT_TYPE in these (while I've handled it in
build_zero_cst).
Will commit as obvious together with the rest of the series when the last
patches are approved.
2023-09-05 Jakub Jelinek
PR c/
On Wed, Aug 09, 2023 at 12:19:54PM -0700, Andrew Pinski via Gcc-patches wrote:
> PR tree-optimization/110937
> PR tree-optimization/100798
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -6460,6 +6460,20 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>(if (cmp == NE_EXPR)
> { co
On Thu, Aug 24, 2023 at 03:14:32PM +0200, Jan Hubicka via Gcc-patches wrote:
> this patch extends verifier to check that all probabilities and counts are
> initialized if profile is supposed to be present. This is a bit complicated
> by the posibility that we inline !flag_guess_branch_probability
On Fri, Sep 01, 2023 at 09:48:22PM +, Joseph Myers wrote:
> This patch is OK with these fixes.
Thanks, here is an updated patch, thanks for catching the _Decimal128
bug. Will post testsuite additions/adjustment patch as follow-up on Monday.
2023-09-02 Jakub Jelinek
PR c/102989
li
On Fri, Sep 01, 2023 at 09:32:22PM +, Joseph Myers wrote:
> This patch is OK with those fixes.
Thanks, here is the updated patch. Queued with the rest of approved
patches.
2023-09-02 Jakub Jelinek
PR c/102989
gcc/
* doc/libgcc.texi (Bit-precise integer arithmetic function
On Fri, Sep 01, 2023 at 03:24:54PM +0200, Jakub Jelinek via Gcc-patches wrote:
> So like this?
>
> It actually changes behaviour on the
> void foo (int x) try {} catch (int x) {} case, where previously
> this triggered the
>|| (TREE_CODE
On Thu, Aug 31, 2023 at 05:46:28PM -0400, Jason Merrill wrote:
> I've suggested this to Core.
Thanks.
> > So, I'm not really sure what to do. Intuitively the patch seems right
> > because even block externs redeclare stuff and change meaning of the
> > identifiers and void foo () { int i; extern
On Thu, Aug 31, 2023 at 03:52:22PM -0400, Jason Merrill wrote:
> On 8/31/23 03:20, Jakub Jelinek wrote:
> > As the following testcase shows, while check_local_shadow diagnoses most of
> > the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's
> > name is redeclared inside of the
On Thu, Aug 31, 2023 at 10:24:10AM -0700, Andrew Pinski via Gcc-patches wrote:
> This patch adds the following match patterns to optimize these:
> /* (a != b) ? (a - b) : 0 -> (a - b) */
These tests FAIL on i686-linux, with
.../gcc/testsuite/gcc.dg/pr110915-1.c:8:1: warning: MMX vector return wit
On Wed, Aug 30, 2023 at 03:25:11PM -0700, Andrew Pinski via Gcc-patches wrote:
> This simple patch extends the min_value/max_value match to vector integer
> types.
> Using uniform_integer_cst_p makes this easy.
These tests FAIL on i686-linux, with
.../gcc/testsuite/gcc.dg/pr110915-1.c:8:1: warnin
On Fri, Sep 01, 2023 at 07:34:16PM +0800, Hongyu Wang wrote:
> > On Fri, Sep 01, 2023 at 05:07:53PM +0800, Hongyu Wang wrote:
> > > Jakub Jelinek via Gcc-patches 于2023年8月31日周四
> > > 17:44写道：
> > > >
> > > > On Thu, Aug 31, 2023 at 04:20:19PM +
On Fri, Sep 01, 2023 at 05:07:53PM +0800, Hongyu Wang wrote:
> Jakub Jelinek via Gcc-patches 于2023年8月31日周四 17:44写道：
> >
> > On Thu, Aug 31, 2023 at 04:20:19PM +0800, Hongyu Wang via Gcc-patches wrote:
> > > For vector move insns like vmovdqa/vmovdqu, their evex cou
On Thu, Aug 31, 2023 at 01:11:57PM -0400, Jason Merrill wrote:
> > 2023-08-28 Jakub Jelinek
> >
> > PR c++/111069
> > gcc/
> > * common.opt (fabi-version=): Document version 19.
> > * doc/invoke.texi (-fabi-version=): Likewise.
> > gcc/c-family/
> > * c-opts.cc (c_common_post_op
On Thu, Aug 31, 2023 at 12:37:59PM +, Richard Biener via Gcc-patches wrote:
> The following keeps dumping SSA def stmt RHS during diagnostic
> reporting only for gimple_assign_single_p defs which means
> memory loads. This avoids diagnostics containing PHI nodes
> like
>
> warning: 'realloc
On Thu, Aug 31, 2023 at 01:26:37PM +0200, Filip Kastl wrote:
> Regarding debug info coverage: I didn't notice any additional guality
> testcases
> failing after I applied the patch. *Is there any other way how I should check
> debug info coverage?*
I'm usually using https://github.com/pmachata/dw
On Thu, Aug 31, 2023 at 04:20:19PM +0800, Hongyu Wang via Gcc-patches wrote:
> For vector move insns like vmovdqa/vmovdqu, their evex counterparts
> requrire explicit suffix 64/32/16/8. The usage of these instruction
> are prohibited under AVX10_1 or AVX512F, so for AVX2+APX_F we select
> vmovaps/v
On Thu, Aug 31, 2023 at 11:26:26AM +0200, Richard Biener wrote:
> On Thu, Aug 31, 2023 at 10:25 AM Hongyu Wang via Gcc-patches
> wrote:
> >
> > From: Kong Lingling
> >
> > Disable EGPR usage for below legacy insns in opcode map2/3 that have vex
> > but no evex counterpart.
> >
> > insn list:
> >
On Thu, Aug 31, 2023 at 04:20:17PM +0800, Hongyu Wang via Gcc-patches wrote:
> From: Kong Lingling
>
> In inline asm, we do not know if the insn can use EGPR, so disable EGPR
> usage by default from mapping the common reg/mem constraint to non-EGPR
> constraints. Use a flag mapx-inline-asm-use-gp
On Thu, Aug 31, 2023 at 06:02:36AM +, waffl3x via Gcc-patches wrote:
> From e485a79ec5656e72ba46053618843c3d69331eab Mon Sep 17 00:00:00 2001
> From: Waffl3x
> Date: Thu, 31 Aug 2023 01:05:25 -0400
> Subject: [PATCH] P0847R7 (deducing this) Initial support
>
> Most things should be functiona
Hi!
C++17 had in [basic.block.scope]/2
"A parameter name shall not be redeclared in the outermost block of the function
definition nor in the outermost block of any handler associated with a
function-try-block."
and in [basic.block.scope]/4 similar rule for selection/iteration
statements. My read
Hi!
As the following testcase shows, while check_local_shadow diagnoses most of
the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's
name is redeclared inside of the compound-stmt of a function-try-block.
There is in that case an extra scope (sk_try with parent artificial
sk
On Wed, Aug 30, 2023 at 01:54:46PM +0200, Richard Biener via Gcc-patches wrote:
> * gcc.dg/tree-ssa/forwprop-42.c: New testcase.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-42.c
> @@ -0,0 +1,17 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O -fdump-tree-cddce1" } */
>
On Wed, Aug 30, 2023 at 12:47:42PM +0200, Tobias Burnus wrote:
> > For switches, there is the case of the switch jumping across declaration
> > of an automatic var which is not initialized/constructed (I think in that
> > case there is normally no warning/error and happens a lot in the wild
> > inc
On Tue, Aug 29, 2023 at 03:42:27PM -0400, Marek Polacek via Gcc-patches wrote:
> + if (UNLIKELY (flag_hardened)
> + && (opt->code == OPT_D || opt->code == OPT_U))
> + {
> + if (!fortify_seen_p)
> + fortify_seen_p = !strncmp (opt->arg, "_FORTIFY_SOURCE",
Hi!
The following testcase is miscompiled since r279392 aka
r10-5451-gef29b12cfbb4979
The strlen pass has adjust_last_stmt function, which performs mainly strcat
or strcat-like optimizations (say strcpy (x, "abcd"); strcat (x, p);
or equivalent memcpy (x, "abcd", strlen ("abcd") + 1); char *q = s
Hi!
The following testcase shows that we mishandle bit insertion for
info->bitsize >= 64. The problem is in using unsigned HOST_WIDE_INT
shift + subtraction + build_int_cst to compute mask, the shift invokes
UB at compile time for info->bitsize 64 and larger and e.g. on the testcase
with info->bi
On Tue, Aug 29, 2023 at 06:56:40PM +0200, Tobias Burnus wrote:
> On 29.08.23 18:28, Jakub Jelinek wrote:
> > One thing is that for C++ one needs to be careful about vars optimized
> > by NRV by the FE.
> Thanks for the warning.
> > And, just from the gimplify_bind_expr function name,
>
> (I forgot
On Tue, Aug 29, 2023 at 06:12:58PM +0200, Tobias Burnus wrote:
> This adds support for
> #pragma omp allocate(var-list) [allocator(..) align(..)]
>
> While the spec permits stack and static variables, this patch only
> adds support for stack variables - keeping the 'sorry' for static
> variables
On Tue, Aug 29, 2023 at 04:21:44PM +0100, Nick Clifton via Gcc-patches wrote:
> Currently the top level configure.ac file sets the minimum required
> version of texinfo to be 4.7. I would like to propose changing this
> to 6.8.
>
> The reason for the change is that the bfd documentation
On Tue, Aug 29, 2023 at 11:42:48AM +0100, Richard Sandiford wrote:
> > I'll note tree-ssa-loop-niter.cc also uses GMP in some cases, widest_int
> > is really trying to be poor-mans GMP by limiting the maximum precision.
>
> I'd characterise widest_int as "a wide_int that is big enough to hold
> al
On Tue, Aug 29, 2023 at 09:49:59AM +, Richard Biener wrote:
> The simplest way would probably to keep widest_int at
> WIDE_INT_MAX_PRECISION like we have now and assert that this is
> enough at ::to_widest time (we probably do already). And then
> declare uses with more precision need to use
Hi!
The uaddc/usubc usual matching is of the .{ADD,SUB}_OVERFLOW pair in the
middle, which adds/subtracts carry-in (from lower limbs) and computes
carry-out (to higher limbs). Before optimizations (unless user writes
it intentionally that way already), all the steps look the same, but
optimizatio
Hi!
While the _BitInt series isn't committed yet, I had a quick look at
lifting the current lowest limitation on maximum _BitInt precision,
that wide_int can only support wide_int until WIDE_INT_MAX_PRECISION - 1.
Note, other limits if that is lifted are INTEGER_CST currently using 3
unsigned cha
Hi!
Sorry, testing revealed an unused uchar *outbuf; declaration breaking the
build, here is the same patch with that one line removed,
bootstrapped/regtested on x86_64-linux and i686-linux (on top of the earlier
POR110341 patch).
On Sat, Aug 26, 2023 at 01:11:06PM +0200, Jakub Jelinek via Gcc
Hi!
On Thu, Aug 24, 2023 at 06:39:10PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > Maybe do this in mangle_decomp, based on the actual mangling in process
> > instead of this pseudo-mangling?
>
> Not sure that is possible, for 2 reasons:
> 1) determine_local_discriminat
Hi!
On Mon, Aug 21, 2023 at 05:24:02PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Jakub Jelinek (12):
> expr: Small optimization [PR102989]
> lto-streamer-in: Adjust assert [PR102989]
> phiopt: Fix phiopt ICE on vops [PR102989]
> Middle-end _BitInt support [PR1029
On Wed, Aug 23, 2023 at 05:22:00PM +0200, Aldy Hernandez via Gcc-patches wrote:
> BTW, we batted some ideas on how to get this work, and it seems this
> is the cleaner route with the special cases nestled in the operators
> themselves. Another idea is to add unordered relations, but that
> would r
Hi!
The following incremental patch to the PR110341 posted patch uses
a special conversion callback instead of conversion from host charset
(UTF-8/UTF-EBCDIC) to UTF-32, and also ignores all diagnostics from the
second cpp_interpret_string which should just count chars. The UTF-EBCDIC
is untested
Hi!
This paper voted in as DR makes some multi-character literals ill-formed.
'abcd' stays valid, but e.g. 'á' is newly invalid in UTF-8 exec charset
while valid e.g. in ISO-8859-1, because it is a single character which needs
2 bytes to be encoded.
The following patch does that by checking (only
Hi!
The following patch implements
CWG 2406 - [[fallthrough]] attribute and iteration statements
The genericization of some loops leaves nothing at all or just a label
after a body of a loop, so if the loop is later followed by
case or default label in a switch, the fallthrough statement isn't
dia
On Wed, Aug 23, 2023 at 04:23:00PM -0400, Jason Merrill wrote:
> I'd be surprised if this would affect any real code, but I suppose so. In
> any case I'd like to fix this at the same time as the local statics, to
> avoid changing their mangled name twice.
Ok.
Running now into a problem with abi ta
On Thu, Aug 24, 2023 at 05:47:09PM +0200, Richard Biener via Gcc-patches wrote:
> > Do you think that the pass is worthy of inclusion into upstream GCC? What
> > are
> > some things that I should change? Should I try to put the pass in different
> > places in passes.def?
>
> The most obvious plac
Hi!
The following patch on top of PR110349 patch (weak dependency,
only for -Wc++26-extensions, I could split that part into an independent
patch) and PR110342 patch (again weak dependency, this time mainly
because it touches the same code in cp_parser_static_assert and
nearby spot in udlit-error1
Hi!
The following patch implements C++26 unevaluated-string.
As it seems to me just extra pedanticity, it is implemented only for
-std=c++26 or -std=gnu++26 and later and only if -pedantic/-pedantic-errors.
Nothing is done for inline asm, while the spec changes those, it changes it
to a balanced t
On Tue, Aug 22, 2023 at 12:53:19PM -0600, Sandra Loosemore wrote:
> > All these c-c++-common testsuite changes will now FAIL after the C patch but
> > before the C++. It is nice to have the new c-c++-common tests in a separate
> > patch, but these tweaks which can't be just avoided need the tempor
Hi!
Now that Richi has acked all the middle-end _BitInt patches (but am
deferring committing those until also the C FE and libgcc patches are
approved), I'd like to ping this patch.
Thanks!
On Wed, Aug 09, 2023 at 08:19:41PM +0200, Jakub Jelinek via Gcc-patches wrote:
> The followi
On Wed, Aug 23, 2023 at 08:03:58AM +, Jiang, Haochen wrote:
> We could first work on -mevex512 then further discuss -mavx10.1-256/512 since
> these -mavx10.1-256/512 is quite controversial.
>
> Just to clarify, -mno-evex512 -mavx512f should not enable 512 bit vector
> right?
I think it shoul
On Wed, Aug 23, 2023 at 01:57:59AM +, Jiang, Haochen wrote:
> > > Let's assume there's no detla now, AVX10.1-512 is equal to
> > > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG,VPOPCNTDQ}
> > > > other stuff.
> > > > The current common/config/i386/i386-common.cc OPTION_MASK_ISA*SET
On Tue, Aug 22, 2023 at 10:25:51AM +0200, FX Coudert wrote:
> > Revised patch. I does the job on darwin, can you check that it still tests
> > the functions on Linux?
> > And if so, OK to commit?
>
> With the correct file, sorry.
Seems to work for me, I see
... -DNONSTDFUNC=1 ...
on the test's c
On Tue, Aug 22, 2023 at 10:35:55PM +0800, Hongtao Liu wrote:
> Let's assume there's no detla now, AVX10.1-512 is equal to
> AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG, VPOPCNTDQ}
> > other stuff.
> > The current common/config/i386/i386-common.cc OPTION_MASK_ISA*SET* would be
> > lik
On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote:
> Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit
> evex instruction patterns.
Why?
Internally for md etc. purposes, we should have the current
TARGET_AVX512* etc. ISA flags, plus one new one, whatever we call it
(TA
On Sun, Jul 23, 2023 at 04:15:21PM -0600, Sandra Loosemore wrote:
> OpenMP 5.0 removed the restriction that multiple collapsed loops must
> be perfectly nested, allowing "intervening code" (including nested
> BLOCKs) before or after each nested loop. In GCC this code is moved
> into the inner loop
On Sun, Jul 23, 2023 at 04:15:20PM -0600, Sandra Loosemore wrote:
> gcc/testsuite/ChangeLog
> * c-c++-common/gomp/imperfect-attributes.c: New.
> * c-c++-common/gomp/imperfect-badloops.c: New.
> * c-c++-common/gomp/imperfect-blocks.c: New.
> * c-c++-common/gomp/imperfect-exte
On Sun, Jul 23, 2023 at 04:15:19PM -0600, Sandra Loosemore wrote:
> OpenMP 5.0 removed the restriction that multiple collapsed loops must
> be perfectly nested, allowing "intervening code" (including nested
> BLOCKs) before or after each nested loop. In GCC this code is moved
> into the inner loop
> New common C/C++ testcases are in a separate patch.
>
> gcc/c-family/ChangeLog
> * c-common.h (c_omp_check_loop_binding_exprs): Declare.
> * c-omp.cc: Include tree-iterator.h.
> (find_binding_in_body): New.
> (check_loop_binding_expr_r): New.
> (LOCATION_OR): New.
>
On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote:
> > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option
> > name to represent whether the effective ISA set allows 512-bit vectors or
> > not. I think -mavx10.1 -mno-avx512cd should be fine. And, -mavx10.1-256
> > o
On Sun, Jul 23, 2023 at 04:15:17PM -0600, Sandra Loosemore wrote:
> In order to detect invalid jumps in and out of intervening code in
> imperfectly-nested loops, the front ends need to insert some sort of
> marker to identify the structured block sequences that they push into
> the inner body of t
On Sun, Jul 23, 2023 at 04:15:16PM -0600, Sandra Loosemore wrote:
> Here is the latest version of my imperfectly-nested loops patches.
> Compared to the initial version I'd posted in April
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617103.html
>
> this version includes many minor co
On Mon, Aug 21, 2023 at 05:32:04PM +, Joseph Myers wrote:
> I think the libgcc functions (i.e. those exported by libgcc, to which
> references are generated by the compiler) need documenting in libgcc.texi.
> Internal functions or macros in the libgcc patch need appropriate comments
> speci
On Tue, Aug 22, 2023 at 10:43:54AM +0200, Tobias Burnus wrote:
> On 22.08.23 09:25, Richard Biener wrote:
> > On Mon, Aug 21, 2023 at 6:23 PM Tobias Burnus
> > wrote:
> > > ...
> > Err, so the OMP standard doesn't put any constraints on what to allow
> > inside the
> > variants? Is declare vari
On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches wrote:
> I think internally we should have conditional 512bit support work across
> AVX512 and AVX10.
>
> I also think it makes sense to _internally_ have AVX10.1 (10.1!) just
> enable the respective AVX512 features. AVX10.2
On Tue, Aug 22, 2023 at 10:16:37AM +0200, FX Coudert wrote:
> Revised patch. I does the job on darwin, can you check that it still tests
> the functions on Linux?
Seems the attached patch doesn't match what was discussed in this thread.
And for that DWARF patch, I'd like to see what different out
Hi!
As mentioned in the PR, these types are supported in C++ since GCC 13,
so we shouldn't confuse users.
Ok for trunk?
2023-08-22 Jakub Jelinek
PR c++/106652
* doc/extend.texi (_Float): Drop obsolete sentence that the
types aren't supported in C++.
--- gcc/doc/exten
Hi!
As can be seen on the testcase, we weren't correctly mangling
static/thread_local structured bindings (C++20 feature) at function/block
scope. The following patch fixes that by using what write_local_name
does for those cases (note, structured binding mandling doesn't use the
standard path be
1 - 100 of 1097 matches
Mail list logo
