Hi!
As reported in the PR, for __has_unique_object_representations we
were treating unnamed bitfields as named ones, which is wrong, they
are actually padding.
THe following patch fixes that. Ok for trunk (and what about release
branches later?)?
2023-03-14 Jakub Jelinek
PR
Hi!
On Fri, Mar 10, 2023 at 01:49:38PM -0500, Jason Merrill via Gcc-patches wrote:
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp2a/concepts-lambda3.C: Run at lower std levels,
> but expect errors.
I'm seeing
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C -std=c++11 compilation failed
On Thu, Mar 09, 2023 at 07:36:21PM +, Tamar Christina via Gcc-patches wrote:
> PR target/108583
> * gcc.dg/mla_1.c: New test.
The testcase FAILs on all targets but AArch64 (maybe ARM is fine too).
While f1/g1 are compilable on all targets and f3/g3 with -Wno-psabi in
dg-options,
On Mon, Mar 13, 2023 at 10:02:41PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> > The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> > gdbhooks, which expects tree_code_type to always be available. I considered
> >
On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> gdbhooks, which expects tree_code_type to always be available. I considered
> trying to make gdbhooks more robust, but it seemed simpler to define
>
Hi!
On Tue, Mar 07, 2023 at 05:50:39PM +, Jonathan Wakely via Gcc-patches wrote:
> I guess you want to regenerate the powerpc64 ones now. The others are
> all OK for trunk.
So the following patch updates powerpc64 which has been excluded from
the last patch (the difference between the older
On Mon, Mar 13, 2023 at 08:59:15AM +0100, Aldy Hernandez wrote:
> > Yes, sure - I just noticed that we're forced to use high-level API for
> > something that's quite low-level and should be internal (a range
> > "breaking" internal consistency checks).
>
> Yeah, let's fix the API. No sense
On Thu, Mar 09, 2023 at 07:44:53PM -0500, Marek Polacek wrote:
> On Thu, Mar 09, 2023 at 09:44:49AM +0100, Jakub Jelinek wrote:
> > On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote:
> > > I think this is a reasonable way to address the regression, so OK.
> >
> > It is true that both
On Fri, Mar 10, 2023 at 06:54:10PM +0100, Thomas Koenig via Gcc-patches wrote:
> Hello world, here's the patch that was discussed.
>
> Regression-tested. OK for trunk?
>
> Since this appeared only in gcc13, I see no need for a backport.
> I will also document this in the changes file.
>
> Best
Hi!
This is on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html
and
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613724.html
patches (to be precise, the latter isn't essential for it), I've
realized that for the PR107703 bugfix in the first patch I haven't
On Fri, Mar 10, 2023 at 11:50:39AM +, Richard Sandiford wrote:
> > Will test it momentarily (including the patch it depends on):
Note, testing still pending, I'm testing in a Fedora scratch build
and that is quite slow (lto bootstrap and the like).
> A naive question:
>
> > ---
On Fri, Mar 10, 2023 at 08:43:02AM +, Richard Sandiford wrote:
> > So, either __bf16 should be also extended floating-point type
> > like decltype (0.0bf16) and std::bfloat16_t and in that case
> > it is fine if it mangles u6__bf16, or __bf16 will be a distinct
> > type from the latter two,
>
On Fri, Mar 10, 2023 at 08:53:37AM +, Richard Biener wrote:
> Meh - I wonder if we can avoid all this by making float_widen_lhs_range
> friend of frange and simply access m_min/m_max directly and use the
> copy-CTOR to copy bounds and nan state ... after all verify_range
> will likely fail
Hi!
I'd like to ping this patch (as I wrote a week ago, NightStrike has tested
it):
On Fri, Mar 03, 2023 at 07:44:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > > 2023-02-22 Jakub Jelinek
> > >
> > > PR target/107998
> > > * config.gcc (x86_64
, Feb 02, 2023 at 03:30:29PM +0100, Jakub Jelinek via Gcc-patches wrote:
> The recent change to undo the tree_code_type/tree_code_length
> excessive duplication apparently broke building the Linux kernel
> plugin. While it is certainly desirable that GCC plugins are built
> with the s
Hi!
I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
- PR107558 - P2 - c++: Don't clear TREE_READONLY for -fmerge-all-constants
for non-aggregates
Thanks
Jakub
On Thu, Nov 24, 2022 at 10:13:55AM +0100, Jakub Jelinek via Gcc-patches
Hi!
On Wed, Mar 01, 2023 at 01:32:43PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Thoug
-map: Fix up -f*-prefix-map= (3 variants)
Thanks
Jakub
On Fri, Jan 20, 2023 at 04:05:55PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Nov 01, 2022 at 01:46:20PM -0600, Jeff Law via Gcc-patches wrote:
> > > This does cause a change of behaviour if users were previo
On Thu, Mar 09, 2023 at 05:14:11PM +, Richard Sandiford wrote:
> We decided to keep the current mangling of __bf16 and use it for
> std::bfloat16_t too. __bf16 will become a non-standard arithmetic type.
> This will be an explicit diversion from the Itanium ABI.
>
> I think that's equivalent
Hi!
This patch, incremental to the just posted one, improves the reverse
operation ranges significantly by widening just by 0.5ulp in each
direction rather than 1ulp. Again, REAL_VALUE_TYPE has both wider
exponent range and wider mantissa precision (160 bits) than any
supported type, this patch
Hi!
The following patch does two things (both related to range extension
around the boundaries).
The first part (in the 2 real_isfinite blocks) is to make the ranges
narrower when the old boundaries are minimum and/or maximum representable
finite number. In that case frange_nextafter gives -Inf
Hi!
The following testcase FAILs, because starting with r12-6028
the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one 8-bit
bitfield and one 8-bit char field.
The reason is that when end_of_class attempts to compute dsize, it simply
adds byte_position of the field and
On Thu, Mar 09, 2023 at 10:03:20AM -0800, Andrew Pinski via Gcc-patches wrote:
> The problem here is after r13-4748-g2a27ae32fabf85, in some
> cases we were calling inform without a corresponding warning.
> This changes the logic such that we only cause that to happen
> if there was a warning
On Wed, Mar 08, 2023 at 09:38:43AM +, Richard Biener via Gcc-patches wrote:
> The following plugs one place in extract_muldiv where it should avoid
> folding when sanitizing overflow.
>
> I'm unsure about the testcase, I didn't find any that tests for
> a runtime sanitizer error ...
>
>
On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote:
> I think this is a reasonable way to address the regression, so OK.
It is true that both C and C++ (including c++14_down and c++17 and later
where the latter have different ordering rules) evaluate the lhs of
MODIFY_EXPR after rhs,
Hi!
The following testcase is reduced from miscompilation of scipy package.
If we have say lhs = [1., 1.] - [1., 1.] and want to compute the range
of lhs from it, we correctly determine it is [0., 0.] (if computations
are exact, we generally don't try to round them further in
frange_arithmetic).
On Thu, Mar 09, 2023 at 08:09:02AM +0100, Gerald Pfeifer wrote:
> I struggled a bit understanding this and so have come up with what I
> hope is simpler (without changing the meaning).
>
> What do you think of the change below?
LGTM, thanks.
>
> diff --git a/htdocs/gcc-13/porting_to.html
On Wed, Mar 08, 2023 at 10:13:39AM +, Jonathan Wakely wrote:
> On Wed, 8 Mar 2023 at 07:25, Richard Biener wrote:
> >
> > On Wed, 8 Mar 2023, Alexander Monakov wrote:
> >
> > >
> > > On Tue, 7 Mar 2023, Jonathan Wakely wrote:
> > >
> > > > > Shouldn't this use the idiom suggested in
On Wed, Mar 08, 2023 at 04:54:20PM +0800, Hongyu Wang wrote:
> > Seems for many ICVs the default values are done through
> > gomp_default_icv_values, but that doesn't cover wait_policy.
> > For other vars, the defaults are provided through just initializers of
> > those vars on the var
On Wed, Mar 08, 2023 at 04:21:46PM +0800, Hongyu Wang wrote:
> Hongyu Wang 于2023年3月8日周三 16:07写道：
> >
> > > I think the right spot to fix this would be instead in initialize_icvs,
> > > change the
> > > icvs->wait_policy = 0;
> > > in there to
> > > icvs->wait_policy = -1;
> > > That way it
On Wed, Mar 08, 2023 at 02:31:38PM +0800, Hongyu Wang wrote:
> Hi,
>
> When OMP_WAIT_POLICY is not specified, current implementation will cause
> icv flag GOMP_ICV_WAIT_POLICY unset, so global variable wait_policy
> will remain its uninitialized value. Set it to -1 when the flag is not
>
On Tue, Mar 07, 2023 at 07:51:03PM +0100, Bernhard Reutner-Fischer wrote:
> While it's a nice idea, there have been resentments towards (visible)
> C++ in the fortran frontend and especially the library, i think.
I thought libgfortran is written in C and Fortran and doesn't use gmp/mpfr,
so this
Hi!
In my recent rtti.cc change I assumed when emitting the support tinfos
that the tinfos for the fundamental types haven't been created yet.
Normally (in libsupc++.a (fundamental_type_info.o)) that is the case,
but as can be seen on the testcase, one can violate it by using typeid
etc. in the
On Mon, Mar 06, 2023 at 11:27:16AM +0100, Robin Dapp wrote:
> > This broke the tests, I'm seeing syntax errors:
> > ERROR: gcc.dg/vect/slp-3.c -flto -ffat-lto-objects: error executing
> > dg-final: syntax error in target selector "target ! vect_partial_vectors
> > || vect32 || s390_vx"
> >
On Mon, Mar 06, 2023 at 03:08:00PM +, Richard Sandiford via Gcc-patches
wrote:
> Segher Boessenkool writes:
> > On Mon, Mar 06, 2023 at 12:47:06PM +, Richard Sandiford wrote:
> >> How about the patch below?
> >
> > What about it? What would make it any better than the previous?
>
> It
On Mon, Mar 06, 2023 at 11:01:18AM +, Richard Biener wrote:
> + auto_mpfr =(const auto_mpfr &) = delete;
> + auto_mpz =(const auto_mpz &) = delete;
Just formatting nit, space before (.
Looks like nice improvement and thanks Jonathan for the suggestions ;)
Jakub
Hi!
On aarch64, powerpc64le and s390x-linux I'm seeing another syntax error
which didn't show up on x86_64-linux nor i686-linux:
ERROR: gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects: error executing
dg-final: syntax error in target selector "target ! vect_load_lanes &&
Hi!
On Thu, Mar 02, 2023 at 07:23:32PM +0100, Robin Dapp via Gcc-patches wrote:
> this patch changes SLP test expectations. As we only vectorize when no
> more than one rgroup is present, no vectorization is performed.
This broke the tests, I'm seeing syntax errors:
ERROR: gcc.dg/vect/slp-3.c
Hi!
The following patch adjusts remaining references to the removed m_vecdata
array from vec.h in various comments.
Tested on x86_64-linux, ok for trunk?
2023-03-04 Jakub Jelinek
PR middle-end/109006
* vec.cc (test_auto_alias): Adjust comment for removal of
On Fri, Mar 03, 2023 at 08:54:32AM -0500, David Malcolm wrote:
> Thanks for working on this.
>
> Patch is OK, but I wonder if it would even better to just hardcode
> caret_max_width as 80 here, to better eliminate that influence from
> from the environment in the unit tests? I think all of the
On Wed, Feb 22, 2023 at 01:02:58PM +, Jonathan Yong wrote:
> On 2/22/23 09:25, Jakub Jelinek wrote:
> > As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
> > and has one important problem, two different multilib options -m64 and -m32,
> > but MULTILIB_DIRNAMES with just one
On Fri, Mar 03, 2023 at 06:07:48PM +, Jonathan Wakely via Gcc-patches wrote:
> This fixes Jakub's second testcase. The printer needs to do slightly
> different things depending on whether the gdbval obejct is a vec or a
> pointer to a vec.
>
> OK for trunk?
>
> -- >8 --
>
> gcc/ChangeLog:
>
On Fri, Mar 03, 2023 at 05:45:59PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Mar 03, 2023 at 04:44:39PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > OK for trunk?
> >
> > gcc/ChangeLog:
> >
>
> Please add
> PR middle-end/109006
&
On Fri, Mar 03, 2023 at 04:44:39PM +, Jonathan Wakely via Gcc-patches wrote:
> OK for trunk?
>
> gcc/ChangeLog:
>
Please add
PR middle-end/109006
here
> * gdbhooks.py (VecPrinter): Adjust for new vec layout.
Ok with that, thanks.
> gcc/gdbhooks.py | 6 +-
> 1 file
On Thu, Mar 02, 2023 at 11:48:04AM -0500, Jason Merrill wrote:
> > The stmtexpr19.C testcase used to be rejected as it has a static
> > variable in statement expression in constexpr context, but as that
> > static variable is initialized by constant expression, when P2647R1
> > was implemented we
Hi!
The following patch fixes 2 issues with the -Wnonnull warning.
One, fixed by the second hunk, is that the warning wording is bogus
since r11-3305, instead of printing
warning: argument 1 to ‘int[static 7]’ is null where non-null expected
[-Wnonnull]
it prints
warning: argument 1 to
Hi!
gimple_fold_builtin_fputs when folding fputs into fwrite emits the third
argument (INTEGER_CST) with incorrect type - get_maxval_strlen or c_strlen
return ssizetype, while fwrite argument is size_type_node.
The following patch fixes that, I've skimmed through the rest of
gimple-fold.cc and in
Hi!
As mentioned in the PR, GCC's diagnostics self-tests fail if $COLUMNS < 42.
Guarding each self-test with if (get_terminal_width () > 41) or similar
would be a maintainance nightmare (PR has a patch to do so without
reformatting to make it work for $COLUMNS in [30, 41] inclusive, but
I'm
On Thu, Mar 02, 2023 at 01:43:30PM +, Jonathan Yong via Gcc-patches wrote:
> On 3/2/23 10:46, Richard Sandiford wrote:
> > > diff --git a/gcc/testsuite/gcc.dg/memchr-3.c
> > > b/gcc/testsuite/gcc.dg/memchr-3.c
> > > index c38d9cf3349..af1b26ef3ae 100644
> > > ---
On Fri, Mar 03, 2023 at 12:05:09AM +0100, Gerald Pfeifer wrote:
> On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> > +
> > +#include
>
> Oops, in HTML we need to spell "<" as "" and ">" as " - otherwise
> the above would be seen as a tag by the name of stdlib.h. ;-)
>
> I pushed the follow-up patch
Hi!
Tobias mentioned on IRC that assume attribute wasn't mentioned in
changes.html. The P1774R8 entry was missing for C++, so I went through
projects/cxx-status.html#cxx23 and filled in all the missing papers
which have been implemented newly in GCC 13, plus a small note for C family
about
Hi!
On Wed, Mar 01, 2023 at 05:50:47PM -0500, Jason Merrill wrote:
> > And then there is a question whether we want to emit rtti for
> > _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless
> > of whether the target supports them at all or not.
> > Emitting them always would
Hi!
On Fri, Feb 10, 2023 at 10:06:03AM +0100, Gerald Pfeifer wrote:
> Yes, thank you! Two minor suggestions/questions below:
>
> > --- a/htdocs/gcc-13/changes.html
> > +++ b/htdocs/gcc-13/changes.html
> > + -fexcess-precision=fast. The option affects mainly
>
> Here I'd say "mainly
Hi!
In the following testcase we try to std::bit_cast a (pair of) integral
value(s) which has some non-zero bits in the place of x86 long double
(for 64-bit 16 byte type with 10 bytes actually loaded/stored by hw,
for 32-bit 12 byte) and starting with my PR104522 change we reject that
as
Hi!
The PR108503 temporary DECL_HAS_VALUE_EXPR_P clearing code can ICE
during recovery, because cp_finish_decomp when it detects errors and
reports them clears DECL_HAS_VALUE_EXPR_P, clears DECL_VALUE_EXPR and
sets TREE_TYPE of the structured binding vars to error_mark_node.
The PR108503 code had
On Wed, Mar 01, 2023 at 03:25:00PM -0800, Andrew Pinski via Gcc-patches wrote:
> The problem here is after r13-4748-g2a27ae32fabf85, in some
> cases we were calling inform without a corresponding warning.
> This changes the logic such that we only cause that to happen
> if there was a warning
On Sat, Jan 21, 2023 at 04:31:52PM +, i.nixman--- via Gcc-patches wrote:
> > Why?
>
> could you explain which of the nine lines are you talking about?
All the uselessly changed ones.
> > As for the rest, it would help if you could list the exact glibc commits
> > which you've ported to
On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
> When combining -g1 with -flto we run into the DIE location annotation
> machinery for globals calling dwarf2out_late_global_decl but not
> having any early generated DIE for function scope statics. In
> this process we'd generate a
On Tue, Feb 28, 2023 at 02:06:43PM +0100, Tobias Burnus wrote:
> (This is marked as P1 regression)
>
> Since the structure handling updates, a hash is now used to find expressions
> which are identical;
> unfortunately, this mishandles 'volatile' vars as expressions involving them
> are not
On Tue, Feb 28, 2023 at 05:18:25PM +0100, Tobias Burnus wrote:
> OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546]
>
> For is_device_ptr, optional checks should only be done before calling
> libgomp, afterwards they are NULL either because of absent or, by
> chance,
Hi!
On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Thoughts on this? I guess my preference would be the BF -> SF -> TI
> > path because we won't nee
Hi!
I'd like to ping a few pending patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
- PR107846 - P1 - c-family: Account for integral promotions of left shifts
for -Wshift-overflow warning
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html
-
Hi!
On Tue, Feb 28, 2023 at 10:59:03PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Feb 28, 2023 at 07:19:40PM +, Qing Zhao wrote:
> > Understood.
> > So, your patch fixed this bug, and then [0] arrays are instrumented by
> > default with this patch.
>
On Tue, Feb 28, 2023 at 11:04:42AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Feb 28, 2023 at 12:51:06AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > And then there is a question whether we want to emit rtti for
> > _Float{16,32,64,128}, _Float{32,64,128}x and d
Hi!
When these tree codes were introduced, expand_debug_expr hasn't been
updated to handle them. For the VEC_*_EXPR we currently mostly punt, the
non-vector ones can be handled easily. In release compilers this doesn't
ICE, but with checking we ICE so that we make sure to handle all the needed
On Tue, Feb 28, 2023 at 07:19:40PM +, Qing Zhao wrote:
> Understood.
> So, your patch fixed this bug, and then [0] arrays are instrumented by
> default with this patch.
>
> > Well, it would complain about
> > struct S { int a; int b[0]; int c; } s;
> > ... [1] ...
> > for C++, but not for
On Wed, Feb 15, 2023 at 01:44:08PM +, Jonathan Yong via Gcc-patches wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/harden-sls-6.c: fix warning on LLP64
> targets.
>
> Attached patch OK?
> From c0572a1e95c6f569980d6b7454c8dc293f07389e Mon Sep 17 00:00:00 2001
> From:
On Tue, Feb 28, 2023 at 04:13:28PM +, Qing Zhao wrote:
> > On Feb 28, 2023, at 3:26 AM, Jakub Jelinek via Gcc-patches
> > wrote:
> > I think -fstrict-flex-arrays* options can be considered as language
> > mode changing options, by default flexible member-like arr
On Tue, Feb 28, 2023 at 12:05:20PM +, Richard Biener via Gcc-patches wrote:
> > + p = _POINTER_TO (TREE_TYPE (t));
> > + else if (TREE_CODE (t) == REFERENCE_TYPE && !TYPE_REF_IS_RVALUE (t))
> > + p = _REFERENCE_TO (TREE_TYPE (t));
> > + if (p)
> > + {
> > + tree t2;
> > +
On Tue, Feb 28, 2023 at 09:43:37AM +, Richard Biener wrote:
> We try to make sure to put all built types into the type merging
> machinery, so I think it shouldn't happen - but then I cannot rule
> it out. I'm also not sure whether duplicates would really pose
> a problem here (other than
Hi!
On Tue, Feb 28, 2023 at 12:51:06AM +0100, Jakub Jelinek via Gcc-patches wrote:
> And then there is a question whether we want to emit rtti for
> _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless
> of whether the target supports them at all or not.
If t
On Tue, Feb 28, 2023 at 08:58:20AM +, Richard Biener wrote:
> > Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained
> > inside of build_{pointer,reference}_type_for_mode and those routines
> > ensure that the pointer/reference type added to the chain is really
> >
On Tue, Feb 28, 2023 at 09:02:47AM +, Richard Biener wrote:
> > While this isn't really a regression, the -fstrict-flex-arrays*
> > option is new in GCC 13 and so I think we should make -fsanitize=bounds
> > play with it well from the beginning.
> >
> > The current behavior is that
Hi!
While this isn't really a regression, the -fstrict-flex-arrays*
option is new in GCC 13 and so I think we should make -fsanitize=bounds
play with it well from the beginning.
The current behavior is that -fsanitize=bounds considers all trailing
arrays as flexible member-like arrays and both
On Mon, Feb 27, 2023 at 06:26:04PM -0500, Jason Merrill wrote:
> > The following patch instead adds a target hook which allows the backend
> > to temporarily tweak registered types such that emit_support_tinfos
> > emits whatever is needed.
>
> Why handle these types differently from the DFP
On Mon, Feb 27, 2023 at 09:01:15PM +, Richard Sandiford via Gcc-patches
wrote:
> Jakub Jelinek writes:
> > On Mon, Feb 27, 2023 at 08:43:27PM +, Richard Sandiford wrote:
> >> My argument was that !SHIFT_COUNT_TRUNCATED and
> >> C?Z_DEFINED_VALUE_AT_ZERO==0 mean that the behaviour is
On Mon, Feb 27, 2023 at 08:43:27PM +, Richard Sandiford wrote:
> My argument was that !SHIFT_COUNT_TRUNCATED and
> C?Z_DEFINED_VALUE_AT_ZERO==0 mean that the behaviour is undefined
> only in the sense that target-independent code doesn't know what
> the behaviour is. !SHIFT_COUNT_TRUNCATED
On Mon, Feb 27, 2023 at 07:51:21PM +, Richard Sandiford wrote:
> I think RTL and gimple are different in that respect.
> SHIFT_COUNT_TRUNCATED's effect on shifts is IMO a bit like
> CTZ_DEFINED_VALUE_AT_ZERO's effect on CTZ: it enumerates common
> target-specific behaviour, but doesn't turn
On Mon, Feb 27, 2023 at 03:34:11PM +, Richard Sandiford wrote:
> > The following testcase is miscompiled on aarch64. The problem is that
> > aarch64 with TARGET_SIMD is !SHIFT_COUNT_TRUNCATED target with
> > targetm.shift_truncation_mask (DImode) == 0 which has HAVE_conditional_move
> > true.
On Fri, Feb 24, 2023 at 02:47:39PM +0100, Richard Biener wrote:
> * vec.h (vec::m_vecdata): Remove.
> (vec::m_vecpfx): Align as T to avoid
> changing alignment of vec and simplifying
> address.
> (vec::address): Compute as this + 1.
> (vec::embedded_size): Use
On Fri, Feb 24, 2023 at 02:46:21PM +0100, Richard Biener wrote:
> As preparation to remove m_vecdata in the vl_embed vector this
> changes references to it into calls to address ().
>
> As I was here it also fixes ::contains to avoid repeated bounds
> checking and the same issue in ::lower_bound
On Fri, Feb 24, 2023 at 12:15:04PM +, Richard Biener wrote:
> > > Anyway, I wonder if you get the -Werror=stringop-overflow= errors during
> > > bootstrap that I got with my version or not.
>
> Yes, I get this as well, not sure how to suppress it. I guess there's
> no standard way to get at
On Fri, Feb 24, 2023 at 12:15:04PM +, Richard Biener wrote:
> > > Also, I think it needs to be MAX (N, 2) instead of N, because auto_vec
> > > ctors use MAX (N, 2). We could also change all those to MAX (N, 1)
> > > now, but it can't be N because m_data[sizeof (T) * 0] is invalid in
> > >
Hi!
I've noticed the description of these wasn't updated when the mask2
argument has been added in 2019.
Committed to trunk as obvious.
2023-02-24 Jakub Jelinek
* config/i386/i386-builtin.def: Update description of BDESC
and BDESC_FIRST in file comment to include mask2.
---
On Fri, Feb 24, 2023 at 11:54:54AM +, Jonathan Wakely wrote:
> > The comment needs adjustment and don't we need
> > alignas (T) alignas (vec_prefix) ?
>
> Yes. If alignas(T) is less than the natural alignment then this will
> be an error. We want it to be the larger of the two alignments, so
On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote:
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -586,8 +586,8 @@ public:
>unsigned allocated (void) const { return m_vecpfx.m_alloc; }
>unsigned length (void) const { return m_vecpfx.m_num; }
>bool is_empty (void) const { return
On Fri, Feb 24, 2023 at 12:32:45PM +0100, Richard Biener via Gcc-patches wrote:
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -614,7 +614,7 @@ public:
>T *bsearch (const void *key, int (*compar)(const void *, const void *));
>T *bsearch (const void *key,
> int (*compar)(const void
On Fri, Feb 24, 2023 at 11:59:53AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > This needs to be alignas(T) unsigned char m_data[sizeof(T) * N];
>
> unsigned char m_data[MAX (N, 2) * sizeof (T)];
>
> if we want to preserve current behavior I think.
>
> I've scre
On Fri, Feb 24, 2023 at 10:30:00AM +, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 10:24, Jakub Jelinek wrote:
> >
> > On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Maybe this would work, vl_relative even could be vl
On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Maybe this would work, vl_relative even could be vl_embed.
> Because vl_embed I believe is used in two spots, part of
> auto_vec where it is followed by m_data and on heap or GGC
> allocated memo
On Fri, Feb 24, 2023 at 09:55:13AM +, Jonathan Wakely wrote:
> > You would still be accessing past the end of the
> > vec::m_vecdata array which is UB.
>
> My thinking is something like:
>
> // New tag type
> struct vl_relative { };
>
> // This must only be used as a member subobject of
On Fri, Feb 24, 2023 at 09:50:33AM +, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
> >
> > Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> > like (which we need because standard C++ doesn't have flexible array members
> > nor [0]
On Fri, Feb 24, 2023 at 09:34:46AM +, Richard Biener wrote:
> > Looking at vec::operator[] which just does
> >
> > template
> > inline const T &
> > vec::operator[] (unsigned ix) const
> > {
> > gcc_checking_assert (ix < m_vecpfx.m_num);
> > return m_vecdata[ix];
> > }
> >
> > the whole
Hi!
The following testcase ICEs on x86_64-linux with -m32. The problem is
we create an artificial thunk and because of -fPIC, ia32 and thunk
destination which doesn't bind locally can't use a mi thunk.
The ICE is because during expansion to RTL we see SSA_NAME for a PARM_DECL,
but the PARM_DECL
Hi!
The builtins used in avx512bf16vlintrin.h implementation need both
avx512bf16 and avx512vl ISAs, which the header ensures for them, but
the builtins weren't actually requiring avx512vl, so when used by hand
with just -mavx512bf16 -mno-avx512vl it resulted in ICEs.
Fixed by adding
On Fri, Feb 24, 2023 at 10:00:01AM +0100, Martin Liška wrote:
> As mentioned in the PR, when we use LTO, we wrongly use ltrans output
> file name as a module name of a global variable. That leads to a
> non-reproducible output.
>
> After the suggested change, we emit context name of normal global
On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote:
> > > * vec.h (auto_vec): Turn m_data storage into
> > > uninitialized unsigned char.
> >
> > Given that we actually never reference the m_data array anywhere,
> > it is just to reserve space, I think even the alignas(T) there is
Hi!
On Wed, Feb 22, 2023 at 02:33:42PM -0300, Alexandre Oliva via Gcc-patches wrote:
> When a multi-source module is found to be unsupported, we fail
> module_cmi_p and subsequent sources. Override proc unsupported to
> mark the result in module_do, and test it to skip module_cmp_p and
>
On Thu, Feb 23, 2023 at 01:54:27PM +0100, Richard Biener wrote:
> The following avoids default-initializing auto_vec storage for
> non-POD T since that's not what the allocated storage fallback
> will do and it's also not expected for existing cases like
>
> auto_vec, 64> elts;
>
> which exist
On Wed, Feb 22, 2023 at 04:23:33AM -0800, Yash Shinde wrote:
> From: Khem Raj
>
> Adapter from
>
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00899.html
>
> This fix was debated but hasnt been applied gcc upstream since
> they expect musl to support '@' in symbol versioning which is
> a
501 - 600 of 4686 matches
Mail list logo
