On Wed, 21 Jun 2023, Richard Biener via Gcc-patches wrote:
> > > int32_t x = (int32_t)0x1.0p32;
> > > int32_t y = (int32_t)(int64_t)0x1.0p32;
> > >
> > > sets x to 2147483647 and y to 0.
>
> Hmm, good question. GENERIC has a direct truncation to unsigned char
> for example, the C standard genera
On Thu, 19 Oct 2023, Florian Weimer wrote:
> diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
> index 6e044b4afbc..1da622160a3 100644
> --- a/gcc/c/c-typeck.cc
> +++ b/gcc/c/c-typeck.cc
> @@ -11281,17 +11281,10 @@ c_finish_return (location_t loc, tree retval, tree
> origtype)
>if ((warn
On Fri, 20 Oct 2023, Florian Weimer wrote:
> gcc/c/
>
> PR c/109827
> PR other/44209
> * c-typeck.cc (build_conditional_expr): Use OPT_Wint_conversion
> for pointer/integer mismatch warnings.
>
> gcc/testsuite/
>
> * gcc.dg/Wint-conversion-3.c: New.
OK.
--
Josep
On Fri, 20 Oct 2023, Florian Weimer wrote:
> gcc/c/
>
> PR c/109826
> PR other/44209
> * c-typeck.cc (build_conditional_expr): Use
> OPT_Wincompatible_pointer_types for pointer mismatches.
> Emit location information for the operand.
>
> gcc/testsuite/
>
> *
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 23 Oct 2023, Qing Zhao wrote:
> I prefer to implement this in gimplification phase since I am more
> familiar with the code there.. (I think that implementing it in
> gimplification should be very similar as implementing it in FE? Or do I
> miss anything here?)
>
> Joseph, if implement
On Sat, 28 Oct 2023, Barnabás Pőcze wrote:
> An external declaration following an inline definition is not redundant
> because it forces the compiler to emit an external definition for the
> function.
> That is,
>
> inline void f(void) { }
> [extern] void f(void);
>
> should not trigger the
On Mon, 30 Oct 2023, Robin Dapp wrote:
> Hi,
>
> this patch adds expanders for fmin and fmax and the associated
> cond and reduc ones. As per RISC-V V spec 1.0 vfmin/vfmax are
> IEEE 754-2008 compliant so that should be ok.
Aren't they actually the IEEE 754-2019 operations (with different
sign
On Mon, 30 Oct 2023, Barnabás Pőcze wrote:
> Hi
>
>
> 2023. október 30., hétfő 19:01 keltezéssel, Joseph Myers írta:
>
> > On Sat, 28 Oct 2023, Barnabás Pőcze wrote:
> >
> > > An external declaration following an inline definition is not redundant
> >
On Tue, 31 Oct 2023, Qing Zhao wrote:
> 2.3 A new semantic requirement in the user documentation of "counted_by"
>
> For the following structure including a FAM with a counted_by attribute:
>
> struct A
> {
>size_t size;
>char buf[] __attribute__((counted_by(size)));
> };
>
> for
On Tue, 31 Oct 2023, Martin Uecker wrote:
> > + if (TREE_CODE (arg) == INTEGER_CST
> > + && tree_int_cst_lt (arg, TYPE_SIZE_UNIT (ttl)))
What if TYPE_SIZE_UNIT (ttl) is not an INTEGER_CST? I don't see any tests
of the case of assigning to a pointer to a variably sized type.
On Wed, 1 Nov 2023, Martin Uecker wrote:
> Am Dienstag, dem 31.10.2023 um 22:19 + schrieb Joseph Myers:
> > On Tue, 31 Oct 2023, Martin Uecker wrote:
> >
> > > > + if (TREE_CODE (arg) == INTEGER_CST
> > > > + &
On Thu, 2 Nov 2023, Sam James wrote:
> maintainer-scripts/
> * gcc_release: Use HTTPS for links.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 2 Nov 2023, Sam James wrote:
> maintainer-scripts/
> * gcc_release: Cleanup whitespace.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 3 Nov 2023, Richard Biener wrote:
> The following tries to clarify the __builtin_constant_p documentation,
> stating that the argument expression is not evaluated and side-effects
> are discarded. I'm struggling to find the correct terms matching
> what the C language standard would call
At the June WG14 meeting, WG14 decided it preferred to keep C23 as the
informal name for the next revision of the C standard, despite
publication not being before 2024 (publication is due in 2024 whether
or not technical changes at the January meeting result in an FDIS
ballot being needed). At the
On Fri, 17 Feb 2023, Martin Uecker via Gcc-patches wrote:
> Here is a patch for PR108375.
This patch is OK.
> and another C FE patch for PR105660:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611817.html
This one is also OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 21 Feb 2023, Thomas Schwinge wrote:
> Is the attached v2
> "Add '-Wno-complain-wrong-lang', and use it in
> 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere"
> OK?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote:
> +@item
> +The structure with a C99 flexible array member is the field of
> +another union, for example:
> +
> +@smallexample
> +struct flex1 @{ int length1; char data1[]; @}
> +struct flex2 @{ int length2; char data2[]; @}
> +
> +union out_
On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote:
> But the following:
>
> struct flex1 { int length1; char data1[]; };
> struct flex2 { int length2; char data2[]; };
> union union_flex { struct flex1 f1; struct flex2 f2; }; /* this is C
> standard. */
>
> struct out_flex { int n; union
On Wed, 1 Mar 2023, Jakub Jelinek via Gcc-patches wrote:
> 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
OK.
On Sat, 6 May 2023, Roger Sayle wrote:
> An analysis of backend UNSPECs reveals that two of the most common UNSPECs
> across target backends are for copysign and bit reversal. This patch
> adds RTX codes for these expressions to allow their representation to
> be standardized, and them to optimiz
WG14 decided that __has_c_attribute should return the same value
(equal to the intended __STDC_VERSION__ value) for all standard
attributes in C2x, with values associated with when an attribute was
added to the working draft (or had semantics added or changed in the
working draft) only being used i
For C2x it was decided that _Atomic would be completely ignored on
function return types (just as was done for qualifiers in C11 DR#423),
to eliminate the potential for an rvalue returned by a function having
_Atomic-qualified type when an rvalue resulting from lvalue-to-rvalue
conversion could not
C2X removes a restriction that the only declarations in the
declaration part of a 'for' loop are declarations of objects with
storage class auto or register. Implement this change, making the
diagnostics into pedwarn_c11 calls instead of errors (as usual for
features added in a new standard versio
WG14 decided to change the printf %B format from a recommended
extension to an optional feature defined in normative text. Thus,
change the format checking to handle %B like %b, so not diagnosing it
with -Wformat -std=c2x -pedantic, just as with other optional
normatively defined features (such as
On Thu, 18 May 2023, Martin Uecker via Gcc-patches wrote:
> + /* we still have to evaluate size expressions */
Comments should start with a capital letter and end with ". ".
> diff --git a/gcc/testsuite/gcc.dg/nested-vla-1.c
> b/gcc/testsuite/gcc.dg/nested-vla-1.c
> new file mode 100644
>
C2x makes it clear that thread-local declarations can never be
tentative definitions (the legacy feature of C where you can e.g. do
"int i;" more than once at file scope, possibly with one of the
declarations initialized, and it counts as exactly one definition),
but are always definitions in the a
On Fri, 19 May 2023, Martin Uecker via Gcc-patches wrote:
> Thanks Joseph!
>
> Revised version attached. Ok?
The C front-end changes and tests are OK.
> But I wonder whether we generally need to do something
> about
>
> sizeof *x
>
> when x is NULL or not initialized. This is quite common
On Fri, 19 May 2023, Martin Uecker via Gcc-patches wrote:
> Repost for stage 1.
>
>
> C: Remove dead code related to type compatibility across TUs.
>
> Code to detect struct/unions across the same TU is not needed
> anymore. Code for determining compatibility of tagged types is
On Fri, 19 May 2023, Qing Zhao via Gcc-patches wrote:
> +GCC extension accepts a structure containing an ISO C99 @dfn{flexible array
"The GCC extension" or "A GCC extension".
> +@item
> +A structure containing a C99 flexible array member, or a union containing
> +such a structure, is the middle
On Mon, 22 May 2023, Martin Uecker via Gcc-patches wrote:
> +static void
> +add_decl_expr(location_t loc, enum decl_context decl_context, tree type,
> tree *expr)
Missing space before '(', and the line should be wrapped to be no more
than 80 columns.
The C front-end changes are OK with those f
The documentation in this case is OK, though claims about how a future
version will behave have a poor track record (we tend to end up with such
claims persisting in the documentation even though the change in question
didn't get made and might sometimes no longer be considered desirable).
--
What happens if the field giving the number of elements is in a contained
anonymous structure or union?
struct s {
struct { size_t count; };
int array[] __attribute__ ((element_count ("count")));
};
This ought to work - a general principle in C is that anonymous structures
and unions are tr
On Wed, 20 Jan 2021, Nathan Sidwell wrote:
> On 1/19/21 6:27 PM, Joseph Myers wrote:
> > On Tue, 19 Jan 2021, Nathan Sidwell wrote:
> >
> > > Joseph,
> > > I was relying on this patch on the modules branch, but didn't realize the
> > > implications
On Thu, 21 Jan 2021, Nathan Sidwell wrote:
> Do you want expandargv altered alongs the lines you mention? Or a bug filed?
> [in order for my patch to be acceptable]
The patch is OK as-is. Filing a bug for expandargv handling of missing
files might be a good idea; it seems very arbitrary that @
On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote:
> TEST Data
I'd still like to see the test data / code used to produce the accuracy
and performance results made available somewhere (presumably with a link
then being provided in the commit message).
> + if ((mode == TYPE_MO
On Mon, 25 Jan 2021, Patrick McGehearty wrote:
> On 1/21/2021 5:04 PM, Joseph Myers wrote:
> > On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote:
> >
> > > TEST Data
> > I'd still like to see the test data / code used to produce the accuracy
> &g
On Mon, 25 Jan 2021, Patrick McGehearty via Gcc-patches wrote:
> Anyway, once I created the tarball and gzipped it,
> I found it shrank to 100Kbytes. Rather than have further
> delays, I've attached the gzip file to this email.
Thanks. The next patch version can include the URL of this file in t
On Tue, 26 Jan 2021, Richard Biener wrote:
> If it is an initializer from constants we gimplify to a series of
> assigns it might be still useful. OTOH, I'm not sure whether
> a const auto is really readonly in C or if it is safe to assume
> the stack part is writable and thus casting away the co
On Mon, 1 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
> The message which contains the attached gzipped tarball of the
> development test programs is:
> https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg254210.html
> I'll include that link in the new patch as well.
I think it's best
On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote:
> +/* Return true of T1 and T2 are matching types for the purposes of
> + redeclaring a variable or a function without a prototype (i.e.,
> + considering just its return type). */
I think this comment is confusing (it suggests it's chec
On Thu, 4 Feb 2021, Nathan Sidwell wrote:
> We used to check all unknown input files, even when passing them to a
> compiler. But that caused problems. However, not erroring out on
> non-existent would-be-linker inputs confuses configure machinery that
> probes the compiler to see if it ac
On Thu, 4 Feb 2021, Martin Sebor via Gcc-patches wrote:
> Okay, that's much simpler. Thanks for nudging me in the right
> direction! How's the attached patch? Retested on x86_64-linux.
OK, minus the addition of gcc/testsuite/c-c++-common/array-lit.s which
looks like a mistake.
--
Joseph S. M
Binary constants aren't mentioned individually in this list because
they are covered by the general wording about features previously
supported as extensions. Allowing duplicate standard attributes isn't
mentioned as it's considered a minor change of details of a feature
supported in GCC 10, rathe
On Sun, 7 Feb 2021, Mike Frysinger via Gcc-patches wrote:
> +# NB: Makefile.in isn't listed as it's not always generated.
> +generated_files = {'aclocal.m4', 'config.h.in', 'configure'}
libiberty/aclocal.m4 isn't a generated file either.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 10 Feb 2021, Marek Polacek via Gcc-patches wrote:
> Freeing the condition chain needs to use vec_free which does ->release,
> or we leak memory.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> gcc/c/ChangeLog:
>
> * c-parser.c (c_parser_if_statement): Use vec_
On Thu, 18 Feb 2021, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcase ICEs on i686-linux, because c_finish_return wraps
> c_fully_folded retval back into EXCESS_PRECISION_EXPR, but when the function
> return type is void, we don't call convert_for_assignment on it that would
On Tue, 2 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
> if (mode == TYPE_MODE (double_type_node))
> - ; /* Empty suffix correct. */
> + {
> + ; /* Empty suffix correct. */
> + memcpy (modename, "DBL", 4);
> + }
> else if (mode =
On Fri, 19 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
> > Here you're properly computing the mapping from mode to float.h macro
> > prefix (though I think "modename" is a confusing name for the variable
> > used for float.h macro prefixes; to me, "modename" suggests the names such
> > as
This change appears to have broken builds for powerpc in a configuration
that bootstraps a cross toolchain starting with a GCC build with no libc
available.
Specifically, such a bootstrap build uses --disable-decimal-float among
other options (in the first GCC build before libc has been built),
On Wed, 24 Feb 2021, Segher Boessenkool wrote:
> The other option, which we need for correctness *anyway*, is to have
> libgcc do the conversion without using any specific libc.
Which ends up being quite complicated (see e.g.
https://www.cl.cam.ac.uk/~jrh13/papers/decimal.pdf for a more detailed
On Fri, 26 Feb 2021, Michael Meissner via Gcc-patches wrote:
> Joseph, does this patch fix your problem?
Yes, this fixes the build without libc done by build-many-glibcs.py.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 3 Mar 2021, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> build_va_arg calls the middle-end mark_addressable, which e.g. requires that
> cfun is non-NULL. The following patch calls instead
> c_common_mark_addressable_vec
> which is the c-family variant similarly to the FE c_mark_addres
On Wed, 3 Mar 2021, Michael Meissner via Gcc-patches wrote:
> As we have discussed many times, on 32-bit BE, you cannot use hardware
> _Float128 support on power9/power10 because there is no TImode in 32-bit.
> Various machine independent parts of GCC require an integer type to be the
> same
> si
This introduced an ICE building glibc for i686.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
https://sourceware.org/pipermail/libc-testresults/2021q1/007615.html
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 2 Aug 2021, liuhongt via Gcc-patches wrote:
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 7979e240426..dc673c89bc8 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -23352,6 +23352,8 @@ ix86_get_excess_precision (enum excess_precision_type
On Tue, 3 Aug 2021, Thomas Schwinge wrote:
> Hi!
>
> Is the attached OK to push?
>
> No violations found per:
>
> $ find -type f -name \*.opt | xargs grep -F 'Init(' | grep -v -F 'Var('
>
> ..., and manually verified the error condition.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 6 Aug 2021, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Aug 06, 2021 at 11:53:56AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > Actually, there is another change in P1949R7 that I haven't touched
> > in the patch and not sure what the implications are.
> >
> > To the preprocessing-t
On Mon, 9 Aug 2021, Uecker, Martin wrote:
> Evaluate arguments of sizeof that are structs of variable size.
>
> Evaluate arguments of sizeof for all types of variable size
> and not just for VLAs. This fixes some issues related to
> [PR29970] where statement expressions need to be evaluated
> so
On Mon, 9 Aug 2021, Uecker, Martin wrote:
> I am still trying to figure out what the branch guarded
> by c_vla_type_p is for in c_expr_sizeof_type. The comment
> talks about [*], but how would you apply sizeof to
> such an array? One can form something like
The comment describes a requirement on
On Tue, 10 Aug 2021, Sebastian Huber wrote:
> If -fprofile-update=atomic is used, then the target must provide atomic
> operations for the counters of the type returned by get_gcov_type().
> This is a 64-bit type for targets which have a 64-bit long long type.
> On 32-bit targets this could be an
On Tue, 10 Aug 2021, Sebastian Huber wrote:
> Ok, I understood how I can add a compiler provided define for libgcov. What is
> not clear to me is how I can add a target hook, set a default value, and
> customize it for a target/system. Is this described here
>
> https://gcc.gnu.org/onlinedocs/gcc
On Wed, 11 Aug 2021, Sebastian Huber wrote:
> 64-bit atomic operations. Allow targets to override the default type
> size with the new TARGET_GCOV_TYPE_SIZE target macro.
Hook, not macro.
> diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
> index f79f939bd10f..e85b60c79f49
On Thu, 12 Aug 2021, Sebastian Huber wrote:
> If -fprofile-update=atomic is used, then the target must provide atomic
> operations for the counters of the type returned by get_gcov_type().
> This is a 64-bit type for targets which have a 64-bit long long type.
> On 32-bit targets this could be an
On Thu, 12 Aug 2021, Martin Uecker wrote:
> Evaluate type arguments of sizeof that are structs of variable size [PR101838]
>
> Evaluate type arguments of sizeof for all types of variable size
> and not just for VLAs. This fixes PR101838 and some issues related
> to PR29970 where statement expres
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> This patch resolves the failure of powerpc64 long double complex divide
> in native ibm long double format after the patch "Practical improvement
> to libgcc complex divide".
This description is not consistent with the patch.
__div
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> > This file includes quad-float128.h, which does some remapping from TF to
> > KF depending on __LONG_DOUBLE_IEEE128__.
> >
> > I think you probably need to have a similar __LONG_DOUBLE_IEEE128__
> > conditional here. If __LONG_DOUB
On Mon, 24 May 2021, Uecker, Martin wrote:
> - else if (VOID_TYPE_P (TREE_TYPE (type1))
> -&& !TYPE_ATOMIC (TREE_TYPE (type1)))
> - {
> - if ((TREE_CODE (TREE_TYPE (type2)) == ARRAY_TYPE)
> - && (TYPE_QUALS (strip_array_types (TREE_TYPE (type2)))
> -
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> If _divkc3.c is not intended to provide a version of complex divide
> that handles IBM-128 format, then where should that option be handled?
That should be the function __divtc3. (A single libgcc binary supports
multiple long doub
On Fri, 13 Aug 2021, Andreas Schwab wrote:
> On Aug 12 2021, Patrick McGehearty via Gcc-patches wrote:
>
> > diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c
> > index a1d29d2..2b229c8 100644
> > --- a/libgcc/config/rs6000/_divkc3.c
> > +++ b/libgcc/config/rs6000/_divk
On Thu, 26 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> The only complex divide routines in $HOME/usr/lib64/libgcc_s.so.1 are:
> __divdc3, __divsc3, __divtc3
Because no symbol versions are assigned to the KFmode symbols in the .ver
files, so they are only exported from libgcc.a.
I thin
On Thu, 26 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> The revision retains the use of __LIBGCC_DF_* in .../rs6000/_divkc3.c
> instead of __LIBGCC_KF_* since some older but still supported environments
> do not recognize the KF floating point mode properly. This change has a
That part o
This commit introduces an ICE building libgcc for 32-bit SPARC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133
--
Joseph S. Myers
jos...@codesourcery.com
On Sun, 13 Sep 2020, Uecker, Martin wrote:
> Hi Joseph,
>
> here is the (unfinished) patch to support
> mixing of labels in C2X.
I think there should be explicit tests for old standard versions
(c11-labels-1.c etc.) that these usages are errors with -pedantic-errors
with the old -std option, a
On Mon, 14 Sep 2020, Marek Polacek via Gcc-patches wrote:
> so I followed suit. In the C++ FE this was rather easy, because
> finish_parenthesized_expr already set TREE_NO_WARNING. In the C FE
> it was trickier; I've added a NOP_EXPR to discern between the non-()
> and () versions.
This sort of
On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote:
> Joseph, do you have any concerns with or comments on the most
> recent patch or is it okay as is?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
I'm not yet convinced by the logic for extracting an array bound from
On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote:
> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552500.html
>
> Aldy provided a bunch of comments on this patch but I'm still looking
> for a formal approval.
This patch is OK.
> > Some testing revealed that the code has diff
On Wed, 16 Sep 2020, Jeff Law via Gcc-patches wrote:
> ISTM this is a lot like the problem we have where we inline functions
> with static data. To fix those we use STB_GNU_UNIQUE. But I don't see
> any code in the C front-end which would utilize STB_GNU_UNIQUE. It's
> support seems limited to
This introduces an ICE building the glibc testsuite for alpha (bisected),
s390 and sparc (symptoms appear the same, not bisected to confirm the
exact revision). See bug 97078.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 16 Sep 2020, Martin Sebor via Gcc-patches wrote:
> Attached is an updated revision of the patch. Besides the tweaks
> above it also contains a cosmetic change to the warning issued
> for mismatches in unspecified VLA bounds: it points at the decl
> with more of them to guide the user to s
On Thu, 17 Sep 2020, Jason Merrill via Gcc-patches wrote:
> The C++ changes are OK. A C maintainer will need to sign off on the changes
> there.
The C front-end changes are OK.
Note: for a long time there used to be actual (undesired) semantic
differences between the C and C++ loop handling, b
On Thu, 24 Sep 2020, Tobias Burnus wrote:
> Hi all,
>
> we got the user comment that it is far from obvious to
> use -foffload=-latomic if the following error shows up:
>
> unresolved symbol __atomic_compare_exchange_16
> collect2: error: ld returned 1 exit status
> mkoffload: fatal error:
On Thu, 24 Sep 2020, Michael Meissner via Gcc-patches wrote:
> To map the math functions, typically this patch changes l to f128.
> However there are some exceptions that are handled with this patch.
glibc 2.32 added __*ieee128 names for the *f128 functions, to allow the
long double functions to
On Fri, 2 Oct 2020, Tobias Burnus wrote:
> However, this flag can be added into the offload-target's libgomp.spec,
> which avoids all kind of issues. That's what this patch now does.
>
> I tested it with x86_64-gnu-linux w/o + w/ nvptx-none. Result:
> * x86_64-gnu-linux's libgomp.spec:
> "*link
On Sun, 4 Oct 2020, H.J. Lu via Gcc-patches wrote:
> This email is generated by an automated script. Does GCC BZ have
> an email gateway?
Bugzilla has a REST API that you can use to interact with it via JSON
messages over HTTP. contrib/mark_spam.py has an example to mark bugs as
spam. glibc'
On Thu, 8 Oct 2020, JeanHeyd Meneide via Gcc-patches wrote:
> * gcc/doc/cpp.texi: Document new predefined macro.
This documentation doesn't seem sufficient to use the macros. Do they
expand to (narrow) string literals? To an unquoted sequence of
characters? I think from the implement
On Mon, 12 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> > We don't claim in glibc to support old snapshots from master, so checking
> > for __GNUC_PREREQ (13, 0) and failing for such older GCC 13 versions is
> > fine.
>
> Ok, makes sense, especially if it is applied on the glibc side a few
C2x has changed the rules for defining INFINITY in so it is
no longer defined when float does not support infinities, instead of
being defined to an expression that overflows at translation time.
Thus, make the definition conditional on __FLT_HAS_INFINITY__ (this is
already inside a C2x-conditiona
On Thu, 22 Sep 2022, Torbjörn SVENSSON via Gcc-patches wrote:
> This patch stops reporting fails for Arm targets with single
> precision floating point unit for types wider than 32 bits (the width
> of float on arm-none-eabi).
>
> As reported in PR102017, fenv is reported as supported in recent
>
There are some new requirements in C2x where GCC already behaves as
required (for all standard versions), where previous standard versions
either had weaker requirements permitting the GCC behavior, or were
arguably defective in what they said in that area. Add tests that
specifically verify GCC b
On Mon, 26 Sep 2022, Lulu Cheng wrote:
> +GTM_longjmp:
> +cfi_startproc
> +GPR_L $s0, $r5, 3*SZ_GPR
> +GPR_L $s1, $r5, 4*SZ_GPR
> +GPR_L $s2, $r5, 5*SZ_GPR
> +GPR_L $s3, $r5, 6*SZ_GPR
> +GPR_L $s4, $r5, 7*SZ_GPR
> +GPR_L $s5, $r5, 8*SZ_
This introduces an ICE building libgcc for ia64-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088
https://sourceware.org/pipermail/libc-testresults/2022q3/010294.html
--
Joseph S. Myers
jos...@codesourcery.com
C2x adds a standard [[noreturn]] attribute (which can also be spelt
[[_Noreturn]] for use with ), so allowing non-returning
functions to be declared in a manner compatible with C++; the
_Noreturn function specifier remains available but is marked
obsolescent.
Implement this attribute. It's more r
On Fri, 30 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> What isn't in the patch but I think we'll need to also change are some
> minimal set of __builtin_*bf16 builtins. Seems for _Float16, GCC provides
> all the __builtin_*f16 (and for C/ObjC even with *f16 names), but there is
> no glibc su
C2x changes the definition of *_EPSILON to apply only to
normalized numbers. The effect is that LDBL_EPSILON for IBM long
double becomes 0x1p-105L instead of 0x1p-1074L.
There is a reasonable case for considering this a defect fix - it
originated from the issue reporting process (DR#467), though
On Tue, 4 Oct 2022, Jakub Jelinek via Gcc-patches wrote:
> Yet another problem is because I've only enabled the bf16/BF16 suffixes in
> C++ because for C it might clash with some later extension. Am I right to
> fear about that, or do you think C will never standardize suffixes that
> would clash
On Tue, 4 Oct 2022, Qing Zhao via Gcc-patches wrote:
> + { "strict_flex_array", 1, 1, false, false, false, false,
> + handle_strict_flex_array_attribute, NULL },
You're not requiring that the attribute be applied to a declaration here.
> +static tree
> +handle_str
On Wed, 5 Oct 2022, Torbjörn SVENSSON via Gcc-patches wrote:
> -/* These should be defined if and only if signaling NaNs are supported
> - for the given types. If the testsuite gains effective-target
> - support for targets not supporting signaling NaNs, or not
> - supporting them for all t
On Wed, 5 Oct 2022, Qing Zhao via Gcc-patches wrote:
> + /* if not the last field, return false. */
Comments should start with an uppercase letter.
> + /* if not an array field, return false. */
> + /* if there is a strict_flex_array attribute attached to the field,
> + override the fl
101 - 200 of 2946 matches
Mail list logo
