On Mon, May 29, 2023 at 07:17:42PM +0100, Roger Sayle wrote:
> The only change that was unanticipated was the tweak to ix86_match_ccmode.
> Oddly, CCZmode is allowable for CCmode, but CCCmode isn't. Given that
So another option would be to use CCZmode for the ptestz cases and keep
CCmode for ptes
On Tue, May 30, 2023 at 10:03:05AM +0200, Eric Botcazou wrote:
> > We want to be able to treat such things as invariant somehow even if we
> > can't do that for references to user data that might be changed by
> > intervening code.
> >
> > That is, indicate that we know that the _REF actually refe
On Tue, May 30, 2023 at 04:36:34PM -0400, Jason Merrill wrote:
> Note that it is fine to treat p->fld as invariant in C++ if fld is
> TREE_READONLY and p is itself invariant. The implementation is allowed to
> assume that other code didn't destroy *p and create a new object with a
> different valu
On Wed, May 31, 2023 at 03:04:03PM +0100, Jonathan Wakely via Gcc-patches wrote:
> On Wed, 31 May 2023 at 13:23, Jonathan Wakely via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
> > Tested powerpc64le-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > As suggested by Jakub in the PR, this just hard
On Thu, Jun 01, 2023 at 11:37:37AM +0100, Jonathan Wakely via Gcc-patches wrote:
> In https://gcc.gnu.org/PR109954 I suggested also adding:
>
> "N.B., using @option{-march} might be required to produce code suitable
> for a specific CPU family, e.g., @option{-march=i486}."
>
> I realise that that
On Fri, Jun 02, 2023 at 06:18:38PM +0200, Rainer Orth wrote:
> Hi Alex,
>
> > g:7aae58b04b92303ccda3ead600be98f0d4b7f462 introduced -Wformat errors
> > breaking bootstrap on some targets. This patch fixes that.
> >
> > Committed as obvious.
> >
> > Thanks,
> > Alex
> >
> > gcc/ChangeLog:
> >
> >
On Thu, Jun 01, 2023 at 05:27:56PM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
> --- a/gcc/internal-fn.h
> +++ b/gcc/internal-fn.h
> @@ -20,6 +20,10 @@ along with GCC; see the file COPYING3. If not see
> #ifndef GCC_INTERNAL_FN_H
> #define GCC_INTERNAL_FN_H
>
> +#include "insn-codes.h"
Hi!
internal-fn.h since yesterday includes insn-opinit.h, which is a generated
header.
One of my bootstraps today failed because some m2 sources started compiling
before insn-opinit.h has been generated.
Normally, gcc/Makefile.in has
# In order for parallel make to really start compiling the expe
Hi!
The following patch introduces {add,sub}c5_optab and pattern recognizes
various forms of add with carry and subtract with carry/borrow, see
pr79173-{1,2,3,4,5,6}.c tests on what is matched.
Primarily forms with 2 __builtin_add_overflow or __builtin_sub_overflow
calls per limb (with just one fo
On Tue, Jun 06, 2023 at 11:31:42PM +0100, Roger Sayle wrote:
>
> This patch resolves PR target/110104, a missed optimization on x86 around
> adc with memory operands. In i386.md, there's a peephole2 after the
> pattern for *add3_cc_overflow_1 that converts the sequence
> reg = add(reg,mem); mem =
On Tue, Jun 06, 2023 at 05:17:05PM -0700, Andrew Pinski via Gcc-patches wrote:
> While working on `bool0 ? bool1 : bool2` I noticed that
> zero_one_valued_p does not match on the constant zero
> as in that case tree_nonzero_bits will return 0 and
> that is different from 1.
>
> OK? Bootstrapped an
Hi!
I'm getting
+FAIL: gcc.target/i386/3dnow-1.c (internal compiler error: Segmentation fault
signal terminated program cc1)
+FAIL: gcc.target/i386/3dnow-1.c (test for excess errors)
+FAIL: gcc.target/i386/3dnow-2.c (internal compiler error: Segmentation fault
signal terminated program cc1)
+FAI
Hi!
We have expand_doubleword_clz for a couple of years, where we emit
double-word CLZ as if (high_word == 0) return CLZ (low_word) + word_size;
else return CLZ (high_word);
We can do something similar for CTZ and FFS IMHO, just with the 2
words swapped. So if (low_word == 0) return CTZ (high_wor
Hi!
This test apparently contains 3 problematic floating point constants,
1e126, 4.91e-6 and 5.547e-6. These constants suffer from double rounding
when -fexcess-precision=standard evaluates double constants in the precision
of Intel extended 80-bit long double.
As written in the PR, e.g. the firs
On Thu, Jun 08, 2023 at 10:05:43AM +0100, Jonathan Wakely via Gcc-patches wrote:
> > Looking at assembly, one of the differences I see is that the "after"
> > version has calls to realloc_insert(), while "before" version seems to have
> > them inlined [2].
> >
> > [1]
> > https://git.linaro.org/too
Hi!
The pr96024.f90 testcase ICEs on big-endian hosts. The problem is
that length->val.integer is accessed after checking
length->expr_type == EXPR_CONSTANT, but it is a CHARACTER constant
which uses length->val.character union member instead and on big-endian
we end up reading constant 0x100
On Fri, Jun 09, 2023 at 11:02:48AM +0200, Richard Biener via Gcc-patches wrote:
> > Currently both gcc-13 and trunk are at the same library version,
> > libstdc++.so.6.0.32
> >
> > But with this addition to trunk we need to bump that .32 to .33, meaning
> > that gcc-13 and trunk diverge. If we want
On Fri, Jun 09, 2023 at 11:06:04AM +0200, Richard Biener via Gcc-patches wrote:
> On Fri, Jun 9, 2023 at 3:48 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > So for the attached testcase, we assumed that zero_one_valued_p would
> > be the value [0,1] but currently zero_one_valued_p matches also
On Fri, Jun 09, 2023 at 08:37:20PM +0800, Xi Ruoyao wrote:
> Ping (in hopes that someone can review before the weekend).
>
> On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote:
> > We used to skip ifunc check when CX16 is available. But now we use
> > CX16+AVX+Intel/AMD for the "perfect" 16b load
Hi!
The following patch is an attempt to implement the C23 stdckdint.h
header on top of our GNU extension - __builtin_{add,sub,mul}_overflow
builtins.
I have looked at gnulib stdckdint.h and they are full of workarounds
for various compilers, EDG doesn't do this, clang <= 14 can't multiply
__int1
On Sat, Jun 10, 2023 at 12:37:40PM +0200, Jakub Jelinek via Gcc-patches wrote:
> I think changing __builtin_classify_type behavior after 35 years
> would be dangerous, shall we introduce a new similar builtin which
> would just never promote the argument/perform array/function/enum
>
On Mon, Jun 12, 2023 at 11:20:00AM +0100, Tamar Christina via Gcc-patches wrote:
> Hi All,
>
> Looks like I forgot to regenerate config.in which
> causes updates when you enable maintainer mode.
>
> Bootstrapped aarch64-none-linux-gnu.
>
> Committed under obvious rule.
Do you use the DEFAULT_MA
On Mon, Jun 12, 2023 at 01:53:26PM +0100, Tamar Christina wrote:
> gcc/ChangeLog:
>
> * config.in: Regenerate.
> * configure: Regenerate.
> * configure.ac: Remove DEFAULT_MATCHPD_PARTITIONS.
Ok, thanks.
Jakub
Hi!
As I mentioned in my stdckdint.h mail, I think having __ prefixed
keywords for the typeof_unqual keyword which can be used in earlier
language modes can be useful, not all code can be switched to C23
right away.
The following patch implements that. It keeps the non-C23 behavior
for it for th
Hi!
As mentioned in my stdckdint.h mail, __builtin_classify_type has
a problem that argument promotion (the argument is passed to ...
prototyped builtin function) means that certain type classes will
simply never appear.
I think it is too late to change how it behaves, lots of code in the
wild mig
Hi!
The following patch is an updated version of the patch I've posted
on Saturday, on top of the 2 patches I've posted a few minutes ago.
Bootstrapped/regtested on x86_64-linux and i686-linux.
2023-06-12 Jakub Jelinek
* Makefile.in (USER_H): Add stdckdint.h.
* ginclude/stdck
On Mon, Jun 12, 2023 at 09:51:02PM +, Joseph Myers wrote:
> On Sat, 10 Jun 2023, Jakub Jelinek via Gcc-patches wrote:
>
> > I have looked at gnulib stdckdint.h and they are full of workarounds
> > for various compilers, EDG doesn't do this, clang <= 14 can't m
Hi!
On Tue, Jun 06, 2023 at 11:42:07PM +0200, Jakub Jelinek via Gcc-patches wrote:
> The following patch introduces {add,sub}c5_optab and pattern recognizes
> various forms of add with carry and subtract with carry/borrow, see
> pr79173-{1,2,3,4,5,6}.c tests on what is matched.
> Pri
On Tue, Jun 13, 2023 at 08:40:36AM +, Richard Biener wrote:
> I suspect re-association can wreck things even more here. I have
> to say the matching code is very hard to follow, not sure if
> splitting out a function matching
>
>_22 = .{ADD,SUB}_OVERFLOW (_6, _5);
>_23 = REALPART_EXPR
On Wed, Jun 07, 2023 at 09:42:22AM +0100, Andre Vieira (lists) wrote:
> I do need those includes and sorry I broke your bootstrap it didn't show up
> on my aarch64-unknown-linux-gnu bootstrap, I'm guessing the rules there were
> just run in a different order. Glad you were able to fix it :)
Unfort
On Tue, Jun 13, 2023 at 03:10:48PM +, Joseph Myers wrote:
> > So why does C2X say
> > Recommended practice
> > It is recommended to produce a diagnostic message if type2 or type3 are
> > not suitable integer types, or if *result is not a modifiable lvalue of
> > a suitable integer type.
> > ?
>
Hi!
As can be seen in the testcase, we don't diagnose #include/#include_next
of a non-existent header if __has_include/__has_include_next is done for
that header first.
The problem is that we normally error the first time some header is not
found, but in the _cpp_FFK_HAS_INCLUDE case obviously don
Hi!
I've noticed that standard_sse_constant_opcode emits some spurious
whitespace around tab, that isn't something which is done for
any other instruction and looks wrong.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2023-06-13 Jakub Jelinek
*
On Tue, Jun 13, 2023 at 07:54:25PM -0700, Paul Eggert wrote:
> I don't see how you could implement __has_include_next() for
> arbitrary non-GCC compilers, which is what we'd need for glibc users. For
> glibc internals we can use "#include_next" more readily, since we assume a
> new-enough GCC. I.e.
On Tue, Jun 13, 2023 at 01:29:04PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > > + else if (addc_subc)
> > > + {
> > > + if (!integer_zerop (arg2))
> > > + ;
> > > + /* x = y + 0 + 0; x = y - 0 - 0;
On Wed, Jun 14, 2023 at 12:25:46PM +, Richard Biener wrote:
> I think that's still very much desirable so this followup looks OK.
> Maybe you can re-base it as prerequesite though?
Rebased then (of course with the UADDC/USUBC handling removed from this
first patch, will be added in the second
Hi!
On Wed, Jun 14, 2023 at 12:35:42PM +, Richard Biener wrote:
> At this point two pages of code without a comment - can you introduce
> some vertical spacing and comments as to what is matched now? The
> split out functions help somewhat but the code is far from obvious :/
>
> Maybe I'm co
On Wed, Jun 14, 2023 at 04:34:27PM +0200, Uros Bizjak wrote:
> LGTM for the x86 part. I did my best, but those peephole2 patterns are
> real PITA to be reviewed thoroughly.
>
> Maybe split out peephole2 pack to a separate patch, followed by a
> testcase patch. This way, bisection would be able to
On Wed, Jun 14, 2023 at 04:45:48PM +0200, Uros Bizjak wrote:
> +;; Helper peephole2 for the addcarry and subborrow
> +;; peephole2s, to optimize away nop which resulted from uaddc/usubc
> +;; expansion optimization.
> +(define_peephole2
> + [(set (match_operand:SWI48 0 "general_reg_operand")
> +
On Fri, Jul 14, 2023 at 04:56:18PM +0100, Richard Sandiford via Gcc-patches
wrote:
> Summary: We'd like to be able to specify some attributes using
> keywords, rather than the traditional __attribute__ or [[...]]
> syntax. Would that be OK?
Will defer to C/C++ maintainers, but as you mentioned,
On Wed, Jul 19, 2023 at 01:58:21PM +0800, Hongtao Liu wrote:
> > LGTM, if you need someone to rubber-stamp the patch. I'm not really
> > versed in this part of the compiler, so please wait a day if someone
> > has anything to say about the patch.
> Thanks, pushed to trunk.
I see some regressions m
Hi!
As the following testcase shows, wi::divmod_internal doesn't handle
correctly signed division with precision > 64 when the dividend (and likely
divisor as well) is the type's minimum and the precision isn't divisible
by 64.
A few lines above what the patch hunk changes is:
/* Make the divis
Hi!
I've noticed a comment typo, this patch fixes that.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2023-07-19 Jakub Jelinek
* tree-switch-conversion.h (class bit_test_cluster): Fix comment typo.
--- gcc/tree-switch-conversion.h.jj 2023-
On Tue, Jul 18, 2023 at 01:25:45PM +0200, Richard Biener wrote:
>
> PR middle-end/61747
> * internal-fn.cc (expand_vec_cond_optab_fn): When the
> value operands are equal to the original comparison operands
> preserve that equality by re-using the comparison expansion.
>
On Wed, Jul 19, 2023 at 01:36:23PM +, Richard Biener wrote:
> > If we have a match between at least one of the comparison operands and
> > op2/op3, I think having equivalency there is perhaps more important than
> > the canonicalization, but it would be nice not to break it even if there
> > is
Hi!
IEEE754 says that x + (-x) and x - x result in +0 in all rounding modes
but rounding towards negative infinity, in which case the result is -0
for all finite x. x + x and x - (-x) if it is zero retain sign of x.
Now, range_arithmetic implements the normal rounds to even rounding,
and as the a
On Mon, Jul 24, 2023 at 03:29:54PM -0400, Drew Ross via Gcc-patches wrote:
> So would something like
>
> (simplify
> (rshift (nop_convert? (lshift @0 INTEGER_CST@1)) @@1)
> (with { tree stype = build_nonstandard_integer_type (1, 0); }
> (if (INTEGRAL_TYPE_P (type)
> && !TYPE_UNSIGNED (typ
On Mon, Jul 24, 2023 at 07:39:05PM +, Joseph Myers wrote:
> On Mon, 24 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
>
> > I believe it is only +- which has this problematic behavior and I think
>
> fma has the same property (of rounding-mode-dependent exact results), but
On Mon, Jul 24, 2023 at 09:43:10PM +0200, Tobias Burnus wrote:
> This patch adds diagnostic for additional code alongside a nested teams
> in a target region.
>
> The diagnostic is happening soon after parsing such that expressions
> in clauses are not yet expanded - those would end up before TEAM
On Tue, Jul 25, 2023 at 03:25:57PM -0400, Drew Ross wrote:
> > With that fixed I think for non-vector integrals the above is the most
> suitable
> > canonical form of a sign-extension. Note it should also work for any
> other
> > constant shift amount - just use the appropriate intermediate precis
On Tue, Jul 25, 2023 at 03:42:21PM -0400, David Edelsohn via Gcc-patches wrote:
> Hi, Drew
>
> Thanks for addressing this missed optimization.
>
> The testcase includes an incorrect assumption: signed char, which
> causes the testcase to fail on PowerPC.
>
> Should the testcase be updated to spe
On Tue, Jul 25, 2023 at 11:01:54AM -0700, Patrick O'Neill wrote:
> Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by
> Jeff Law.
> If there aren't any objections I'll commit this cherry-picked series
> on Thursday (July 27th).
Please don't before 13.2 will be released, the bran
On Thu, Jul 27, 2023 at 12:00:56PM +, Richard Biener wrote:
> The following fixes the lack of simplification of a vector shift
> by an out-of-bounds shift value. For scalars this is done both
> by CCP and VRP but vectors are not handled there. This results
> in PR91838 differences in outcome
On Thu, Jul 27, 2023 at 01:07:58PM +, Richard Biener wrote:
> On Thu, 27 Jul 2023, Jakub Jelinek wrote:
>
> > On Thu, Jul 27, 2023 at 12:00:56PM +, Richard Biener wrote:
> > > The following fixes the lack of simplification of a vector shift
> > > by an out-of-bounds shift value. For scala
[PATCH 0/5] GCC _BitInt support [PR102989]
The following patch series introduces support for C23 bit-precise integer
types. In short, they are similar to other integral types in many ways,
just aren't subject for integral promotions if smaller than int and they can
have even much wider precisions
Hi!
This patch adds the library helpers for multiplication, division + modulo
and casts from and to floating point.
As described in the intro, the first step is try to reduce further the
passed in precision by skipping over most significant limbs with just zeros
or sign bit copies. For multiplica
Hi!
This patch adds the C FE support, c-family support, small libcpp change
so that 123wb and 42uwb suffixes are handled plus glimits.h change
to define BITINT_MAXWIDTH macro.
The previous two patches really do nothing without this, which enables
all the support.
2023-07-27 Jakub Jelinek
On Thu, Jul 27, 2023 at 07:15:28PM +0200, Jakub Jelinek via Gcc-patches wrote:
> testcases, I've been using
> https://defuse.ca/big-number-calculator.htm
> tool, a randombitint tool I wrote (will post as a reply to this) plus
> LLVM trunk on godbolt and the WIP GCC support
On Thu, Jul 27, 2023 at 06:41:44PM +, Joseph Myers wrote:
> On Thu, 27 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
>
> > - _BitInt(N) bit-fields aren't supported yet (the patch rejects them); I'd
> > like
> > to enable those incrementally, but do
Hi!
The comments about _Atomic _BitInt made me figure out I forgot (although
earlier was planning to do that) to implement __builtin_clear_padding
support for _BitInt.
The following patch (incremental to the _BitInt series) does that.
2023-07-28 Jakub Jelinek
PR c/102989
* gi
On Thu, Jul 27, 2023 at 07:06:03PM +, Joseph Myers wrote:
> I think there should be tests for _Atomic _BitInt types. Hopefully atomic
> compound assignment just works via the logic for compare-and-exchange
> loops, but does e.g. atomic_fetch_add work with _Atomic _BitInt types?
So, there ar
On Fri, Jul 28, 2023 at 04:03:39PM +0200, Martin Uecker wrote:
> > On Thu, Jul 27, 2023 at 07:06:03PM +, Joseph Myers wrote:
> > > I think there should be tests for _Atomic _BitInt types. Hopefully
> > > atomic
> > > compound assignment just works via the logic for compare-and-exchange
> >
On Fri, Jul 28, 2023 at 04:53:30PM +0200, Martin Uecker wrote:
> > The thing is that user doesn't have much control over those
> > padding bits, so whether _Atomic operations on long double (when it is 80
> > bit and stores from hw actually store 10 bytes rather than 12 or 16), or
> > _BitInt(37) o
On Fri, Jul 28, 2023 at 11:05:42AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jul 27, 2023 at 06:41:44PM +, Joseph Myers wrote:
> > On Thu, 27 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
> >
> > > - _BitInt(N) bit-fields aren't supported yet (the pa
On Fri, Jul 28, 2023 at 06:03:33PM +, Joseph Myers wrote:
> You could e.g. have a table up to 10^(N-1) for some N, and 10^N, 10^2N
> etc. up to 10^6144 (or rather up to 10^6111, which can then be multiplied
> by a 34-digit integer significand), so that only one multiplication is
> needed to
On Tue, Aug 01, 2023 at 03:20:33PM -0400, Drew Ross via Gcc-patches wrote:
> Canonicalizes (signed x << c) >> c into the lowest
> precision(type) - c bits of x IF those bits have a mode precision or a
> precision of 1. Also combines this rule with (unsigned x << c) >> c -> x &
> ((unsigned)-1 >> c)
On Wed, Aug 02, 2023 at 10:04:26AM +0200, Richard Biener via Gcc-patches wrote:
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -1157,8 +1157,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >
> > /* Simplify ~X & X as zero. */
> > (simplify
> > - (bit_and:c (convert? @0) (convert? (bit_not @0))
On Thu, Jun 30, 2022 at 01:40:24PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > +/* The initial ICV values for the host, which are configured with
> > environment
> > + variables without a suffix, e.g. OMP_NUM_TEAMS. */
> > +struct gomp_initial_icv
On Thu, Jun 30, 2022 at 03:31:00PM +, Qing Zhao wrote:
> > No, that’s not true. A FIELD_DELC is only shared for cv variants of a
> > structure.
>
> Sorry for my dump questions:
>
> 1. What do you mean by “cv variants” of a structure?
const/volatile qualified variants. So
> 2. For the fo
On Thu, Jun 30, 2022 at 03:21:15PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jun 30, 2022 at 01:40:24PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > > +/* The initial ICV values for the host, which are configured with
> > > environment
> > > + v
Hi!
As the following self-test testcase shows, wi::shifted_mask sometimes
doesn't create canonicalized wide_ints, which then fail to compare equal
to canonicalized wide_ints with the same value.
In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and prec 128,
while wi::shifted_mask
On Fri, Jul 01, 2022 at 12:55:08PM +, Qing Zhao wrote:
> If so, comparing to the current implemenation to have all the checking in
> middle-end, what’s the
> major benefit of moving part of the checking into FE, and leaving the other
> part in middle-end?
The point is recording early what F
On Fri, Jul 01, 2022 at 03:06:05PM +0200, Tobias Burnus wrote:
> --- a/gcc/fortran/parse.cc
> +++ b/gcc/fortran/parse.cc
> @@ -1168,7 +1168,8 @@ decode_omp_directive (void)
> }
>switch (ret)
> {
> -case ST_OMP_DECLARE_TARGET:
> +/* Set omp_target_seen; exclude ST_OMP_DECLARE_T
On Fri, Jul 01, 2022 at 04:12:55PM +0200, Aldy Hernandez wrote:
> > --- a/gcc/wide-int.h
> > +++ b/gcc/wide-int.h
> > @@ -1373,10 +1373,13 @@ namespace wi
> > : public int_traits {};
> > }
> >
> > -/* An array of N wide_int-like objects that can be put at the end of
> > - a variable-sized
On Fri, Jul 01, 2022 at 05:41:27PM +0200, Tobias Burnus wrote:
> --- a/gcc/fortran/dump-parse-tree.cc
> +++ b/gcc/fortran/dump-parse-tree.cc
> @@ -1414,6 +1414,11 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
> case OMP_MAP_TO: fputs ("to:", dumpfile); break;
> case OMP_
On Fri, Jul 01, 2022 at 06:31:48PM +0200, Tobias Burnus wrote:
> This is done in openmp.cc during parsing. The merging you quoted (in
> parse.cc) happens
> after the whole input file has been parsed and resolved. For your test case,
> the
> following error is shown:
>
> test.f90:1:15:
>
> 1
On Fri, Jul 01, 2022 at 06:47:48PM +0200, Aldy Hernandez wrote:
> > So, you are looking for something like trailing_wide_ints but where that
> > N is actually a runtime value? Then e.g. the
> > struct {unsigned char len;} m_len[N];
> > member can't work properly either, because it isn't constant
On Fri, Jul 01, 2022 at 07:43:28PM +0200, Aldy Hernandez wrote:
> You can still say N=255 and things continue to work as they do now, since
> m_len[] is still statically determined. The only difference is that before,
> the size of the structure would be 2+1+255+sizeof(int) whereas now it would
> b
On Fri, Jul 01, 2022 at 11:08:16PM +0200, Tobias Burnus wrote:
>gomp_mutex_lock (®ister_lock);
>
> + if (omp_requires_mask && omp_requires_mask != omp_req)
I'd use if (omp_req && omp_requires_mask && omp_requires_mask != omp_req)
e.g. for the case of mixing GCC <= 12 compiled code with GCC
On Mon, Jul 04, 2022 at 12:15:00PM +0200, Martin Liška wrote:
> I've made the mistake multiple times while doing a bisection.
> One would expect that gcc-descr w/o an argument would print
> revision for the current HEAD and not master.
> Thus change it.
>
> Ready to be installed?
> Thanks,
> Marti
On Mon, Jul 04, 2022 at 04:10:03PM +0200, Tobias Burnus wrote:
> This patch adds support for the OpenMP 5.2 syntax for the linear clause,
> following the C/C++ patch. The testcases are modified versions from the
> C/C++ ones, plus one added one for duplicated modifiers.
>
> At least to me it is no
On Thu, Jun 30, 2022 at 01:40:24PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Jun 10, 2022 at 03:59:37PM +0200, Marcel Vollweiler wrote:
> > > I'm not sure we can rely on execv on all targets that do support libgomp.
> > > Any reason why you actually ne
On Mon, Jun 27, 2022 at 06:31:18PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Because the late evaluation of the initializer could have touched
> the destination, so we need to reevaluate it.
> Same reason why we call get_or_insert_ctor_field again in the second
> loop as we ca
On Mon, Jul 04, 2022 at 06:09:31PM +0200, Tobias Burnus wrote:
> thanks for the comment & spec referral. I have now updated the patch –
> and included the new C/Fortran testcase.
Thanks.
> + while (true)
> + {
> + old_loc = gfc_current_locus;
> +
On Mon, Jul 04, 2022 at 08:29:37PM +0200, Tobias Burnus wrote:
> Fortran part to C/C++
> commit r13-1002-g03b71406323ddc065b1d7837d8b43b17e4b048b5
>
> gcc/fortran/ChangeLog:
>
> * gfortran.h (gfc_omp_namelist): Update by creating 'linear' struct,
> move 'linear_op' as 'op' to id and a
On Tue, Jul 05, 2022 at 04:44:41PM -0400, Jason Merrill wrote:
> On 7/4/22 11:50, Jakub Jelinek wrote:
> > On Mon, Jun 27, 2022 at 06:31:18PM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
>
> > > > Hmm, why do we need to handle complex in the !preeval case? I&#x
On Tue, Jul 05, 2022 at 04:44:41PM -0400, Jason Merrill wrote:
> But preeval should always be true, so we'd never reach the new handling in
> the if (!preeval) block. Certainly the new testcase doesn't exercise this
> code.
Ok, changed now.
I had to keep the ctors[i] = valp; statement in the !pr
Hi!
This function would have UB if called with empty candidates vector
(accessing p[-1] where p is malloc (0) result).
As analyzed in the PR, we never call it with empty vector, so this just
adds an assertion to make it clear.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Hi!
__builtin_unreachable and __ubsan_handle_builtin_unreachable don't
use vops, they are marked const/leaf/noreturn/nothrow/cold.
But __builtin_trap uses vops, isn't const, just leaf/noreturn/nothrow/cold.
This is I believe so that when users explicitly use __builtin_trap in their
sources they ge
Hi!
The following patch is partially a workaround for bogus warnings
when the compiler isn't able to fold _M_disjunct call into constant
false, but also an optimization attempt - assuming _M_disjunct (__s)
is rare, the patch should shrink code size for the common case and
use library or for non-st
Hi!
When -dx option is used (didn't know we have it and no idea what is it
useful for), we just expand functions to RTL and then omit all further
RTL passes, so the normal functions aren't actually emitted into assembly,
just variables.
The following testcase ICEs, because we don't emit the method
On Wed, Jul 27, 2022 at 09:33:47AM +, Richard Biener wrote:
> > __builtin_unreachable and __ubsan_handle_builtin_unreachable don't
> > use vops, they are marked const/leaf/noreturn/nothrow/cold.
> > But __builtin_trap uses vops, isn't const, just leaf/noreturn/nothrow/cold.
> > This is I believ
Hi!
-fprefetch-loop-arrays isn't supported on ia32 with just -march=i386 and
similar, the following patch adds extra options similar testcases use.
2022-07-27 Jakub Jelinek
PR tree-optimization/106397
* gcc.dg/pr106397.c: For ia32, add dg-additional-options
-march=i686
Hi!
These tests fail on ia32, because we get -Wpsabi warnings.
Fixed by adding -Wno-psabi. The pr94920.C test still fails the
ABS_EXPR scan-tree-dump though, I think we'll need to add vect
options and use vect_int effective target or something similar.
2022-07-27 Jakub Jelinek
PR tre
On Wed, Jul 27, 2022 at 10:09:34AM +, Richard Biener wrote:
> > We chose to sanitize not just explicit user __builtin_unreachable calls,
> > but also the internally generated __builtin_unreachable calls (with the
> > one exception of fall through to end of C++ function returning non-void,
> > w
Note, the ChangeLog entry formatting is wrong and in various places
the code formatting as well. In gcc/rust/ you can choose different
formatting if there are strong reasons for that, but at least it should be
consistent and ideally documented.
None of the gcc/doc, gcc/config, gcc/config/i386 dir
Hi!
Tobias mentioned in PR106449 that fold_build_pointer_plus already
fold_converts the second argument to sizetype if it doesn't already
have an integral type gimple compatible with sizetype.
So, this patch simplifies the callers of fold_build_pointer_plus in
omp-expand so that they don't do tho
Hi!
There were 2 issues visible on this new testcase, one that we didn't have
special POINTER_TYPE_P handling in a few spots of expand_omp_simd - for
pointers we need to use POINTER_PLUS_EXPR and need to have the non-pointer
part in sizetype, for non-rectangular loop on the other side we can rely
Hi!
The allowed syntaxes of atomic compare don't allow ()s around the condition
of ?:, but we were accepting it in one case for C++.
Fixed thusly.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2022-07-29 Jakub Jelinek
PR c++/106448
* parser.cc (c
On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
> The 'only on the vectorized code path' remains the same though as vect_recog
> also only happens on the vectorized code path right?
if conversion (in some cases) duplicates a loop and guards one copy with
an i
1 - 100 of 4686 matches
Mail list logo
