On Wed, Dec 07, 2022 at 04:38:14PM +0100, Aldy Hernandez wrote:
> > So, perhaps a combination of that, change frange_nextafter to do the above
> > and change frange_arithmetic for the initial inexact rounding only to
> > do it by hand using range_nextafter and starting from value.
>
> Either way
On Wed, Dec 07, 2022 at 04:26:14PM +0100, Aldy Hernandez wrote:
> This chunk...
>
> ...is quite similar to this one. Could you abstract this?
It differs in various small details, plus comment content.
Anyway, here it is reworked such that those various small details
are based on whether inf is
On Wed, Dec 07, 2022 at 04:21:09PM +0100, Aldy Hernandez wrote:
> On 12/7/22 13:10, Jakub Jelinek wrote:
> > + switch (code)
> > + {
> > + case PLUS_EXPR:
> > + case MINUS_EXPR:
> > + // ibm-ldouble-format documents 1ulp for + and -.
> > +
Hi!
As mentioned in PR107967, ibm-ldouble-format documents that
+- has 1ulp accuracy, * 2ulps and / 3ulps.
So, even if the result is exact, we need to widen the range a little bit.
The following patch does that. I just wonder what it means for reverse
division (the op1_range case), which we
On Fri, Nov 25, 2022 at 01:57:35PM +0100, Martin Liška wrote:
> PR target/107551
>
> gcc/ChangeLog:
>
> * config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path
> as for PR103661.
> * doc/extend.texi: Fix "x86-64" use.
>
> gcc/testsuite/ChangeLog:
>
> *
Hi!
The addition of PLUS/MINUS/MULT/RDIV_EXPR frange handlers causes
miscompilation of some of the libm routines, resulting in lots of
glibc test failures. A part of them is purely PR107608 fold-overflow-1.c
etc. issues, say when the code does
return -0.5 / 0.0;
and expects division by zero to
On Tue, Dec 06, 2022 at 08:56:09AM -0600, Segher Boessenkool wrote:
> > In the past, _Float128 was a C extended type,
> > but now it is a part of the C/C++ 2x standards.
>
> Only if you select a new enough -std=, it still is an extended type if
> not?
No, as an extension
Hi!
With -msoft-float we ICE on __bf16 comparisons, because the
insns we want to use under the hood (cbranchsf4 and cstoresf4)
after performing the fast extensions aren't available.
The following patch copies the conditions from the c*sf4 expanders
to the corresponding c*bf4 expanders.
Hi!
add_options_for_ieee has:
if { [istarget alpha*-*-*]
|| [istarget sh*-*-*] } {
return "$flags -mieee"
}
if { [istarget rx-*-*] } {
return "$flags -mnofpu"
}
but ieee.exp doesn't use add_options_for_ieee, instead it has:
if { [istarget "alpha*-*-*"]
On Tue, Dec 06, 2022 at 10:50:20AM +0100, Richard Biener wrote:
> When we end up isolating a nullptr path it happens we diagnose
> accesses to offsetted nullptr objects. The current diagnostics
> have no good indication that this happens so the following records
> the fact that our heuristic
On Tue, Dec 06, 2022 at 10:32:40AM +0100, Tobias Burnus wrote:
> + omp_get_mapped_ptr API routines. The assume and assumes
assume and assumes please
> + directives, the begin/end declare target syntax in C/C++
> + and device-specific ICV settings with environment variables are now
On Tue, Dec 06, 2022 at 09:59:17AM +0100, Tobias Burnus wrote:
> This patch updates the OpenMP implementation status, based on libgomp.texi.
> For the release notes, it also moves 'non-rectangular loop nests' up as that's
> a 5.0 not a 5.1 feature.
> And in line with libgomp.texi, it adds to
On Mon, Dec 05, 2022 at 09:54:09PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Dec 05, 2022 at 03:43:16PM -0500, Andrew MacLeod wrote:
> > Id actually prefer to avoid passing the tree code around... we're trying to
> > avoid that sort of thing even though Aldy temporarily
Hi!
According to
https://gcc.gnu.org/pipermail/gcc-regression/2022-December/077258.html
my patch caused some ICEs, e.g. the following testcase ICEs.
The problem is that lower_bound and upper_bound methods on a france assert
that the range isn't VR_NAN or VR_UNDEFINED.
All the op1_range/op2_range
On Mon, Dec 05, 2022 at 03:43:16PM -0500, Andrew MacLeod wrote:
> Id actually prefer to avoid passing the tree code around... we're trying to
> avoid that sort of thing even though Aldy temporarily introduced them to
> range-ops. Hes suppose to remove that next stage 1 :-P Ideally anything
>
Hi!
On Mon, Dec 05, 2022 at 02:29:36PM +0100, Aldy Hernandez wrote:
> > So like this for multiplication op1/2_range if it passes bootstrap/regtest?
> > For division I'll need to go to a drawing board...
>
> Sure, looks good to me.
Ulrich just filed PR107972, so in the light of that PR the
On Thu, Nov 24, 2022 at 03:09:02PM +0100, Marcel Vollweiler wrote:
> gcc/ChangeLog:
>
> * gimplify.cc (optimize_target_teams): Set initial num_teams_upper
> to "-2" instead of "1" for non-existing num_teams clause in order to
> disambiguate from the case of an existing num_teams
On Mon, Dec 05, 2022 at 10:54:41AM +0100, Aldy Hernandez wrote:
> > Do you mind if I try that incrementally and only if it doesn't make the
> > code too large/too unreadable?
>
> Sure. And don't feel obligated to implement it either. range-ops is a
> never ending pit of possible optimizations.
Hi!
As reported in the PR, the following pr106805.c testcase is miscompiled
with the default -ftrapping-math, because we fold all the comparisons into
constants and don't raise any exceptions.
The match.pd pattern handles just simple comparisons, from those
EQ/NE are quiet and don't raise
On Mon, Dec 05, 2022 at 10:20:53AM +0100, Aldy Hernandez wrote:
> > For the division, [-0., 0.] / VARYING is computed (IMHO correctly)
> > as [-0., 0.] +-NAN, because 0 / anything but 0 or NAN is still
> > 0 and 0 / 0 is NAN and ditto 0 / NAN. And then we just
> > float_binary_op_range_finish,
On Thu, Nov 24, 2022 at 07:13:38PM -0700, Sandra Loosemore wrote:
> This patch is a followup to my not-yet-reviewed patch
>
> [PATCH v4] OpenMP: Generate SIMD clones for functions with "declare target"
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606218.html
>
> In comments on a
Hi!
On Tue, Aug 16, 2022 at 09:14:06AM +0100, Richard Sandiford via Gcc-patches
wrote:
> IMO the correct low-effort fix is to save and restore recog_data
> in ix86_vector_duplicate_value. It's a relatively big copy,
> but the current code is pretty wasteful anyway (allocating at
> least a new
On Thu, Dec 01, 2022 at 01:35:38PM +, Andrew Stubbs wrote:
> > Maybe better add -ffat-lto-objects to dg-additional-options and drop
> > the dg-skip-if (if it works with that, for all similar tests)?
>
> The tests are already run with -ffat-lto-objects and the test still fails
> (pattern found
On Wed, Nov 30, 2022 at 01:52:08PM -0500, Jason Merrill wrote:
> It looks like we're already deducing the type for the underlying S variable
> in cp_convert_omp_range_for, we just aren't updating the types of the
> individual bindings.
You're right. With this patch (still incremental against the
Hi!
On the first testcase we've regressed since 12 at -O2:
- movq8(%rsi), %rax
- movq%rdi, %r8
- movq(%rsi), %rdi
+ movq(%rsi), %rax
+ movq8(%rsi), %r8
movl%edx, %ecx
- shrdq %rdi, %rax
- movq%rax, (%r8)
+ xorl
On Wed, Nov 30, 2022 at 09:18:14AM -0800, apinski--- via Gcc-patches wrote:
> gcc/c/ChangeLog:
>
> PR c/107926
> * c-typeck.cc (process_init_element):
> Move the ceck for string cst until
> after the error message.
Just a ChangeLog nit, not a patch review for which I
On Tue, Nov 29, 2022 at 11:05:33PM +0100, Jakub Jelinek wrote:
> On Tue, Nov 29, 2022 at 04:38:50PM -0500, Jason Merrill wrote:
> > > --- gcc/testsuite/g++.dg/gomp/for-21.C.jj 2020-01-12 11:54:37.178401867
> > > +0100
> > > +++ gcc/testsuite/g++.dg/gomp/for-21.C2022-11-29 13:06:59.038410557
On Wed, Nov 30, 2022 at 03:17:30PM +, Andrew Stubbs wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/vect-simd-clone-16.c
> @@ -0,0 +1,89 @@
> +/* { dg-require-effective-target vect_simd_clones } */
> +/* { dg-additional-options "-fopenmp-simd -fdump-tree-optimized" } */
> +/* {
Hi!
The r13-1100-gacb1e6f43dc2bbedd124 change added match.pd narrowing
of left shifts, and while I believe the C++ FE calls the warning on unfolded
trees, the C FE folds them and so left shifts where integral promotion
happened and so were done in int type will be usually narrowed back to
Hi!
r13-254-gdd3c7873a61019e9 added an optimization for {a, +, a} (x-1),
but as can be seen on the following testcase, the way it is written
where chrec_fold_multiply is called with type doesn't work for pointers:
res = build_int_cst (TREE_TYPE (x), 1);
res =
On Tue, Nov 29, 2022 at 04:38:50PM -0500, Jason Merrill wrote:
> > --- gcc/testsuite/g++.dg/gomp/for-21.C.jj 2020-01-12 11:54:37.178401867
> > +0100
> > +++ gcc/testsuite/g++.dg/gomp/for-21.C 2022-11-29 13:06:59.038410557
> > +0100
> > @@ -54,9 +54,9 @@ void
> > f6 (S ()[10])
> > {
>
Hi!
The PR84469 patch I've just posted regresses the for-21.C testcase,
when in OpenMP loop there are at least 2 associated loops and
in a template outer structured binding with non type dependent expression
is used in the expressions of some inner loop, we don't diagnose those
any longer, as the
Hi!
As shown on the decomp56.C testcase, if the range for expression
when using structured bindings is not type dependent, we deduce
the finish the structured binding types only when not in template
(cp_convert_range_for takes care of that), but if in templates,
do_range_for_auto_deduction is
Hi!
While for the normal cases it seems to be correct to implement
reverse multiplication (op1_range/op2_range) through division
with float_binary_op_range_finish, reverse division (op1_range)
through multiplication with float_binary_op_range_finish or
(op2_range) through division with
Hi!
The following testcase fails since my changes to make also
opts_set saved/restored upon function target/optimization changes
(before it has been acting as "has this option be ever explicit
anywhere?").
The problem is that for ix86_abi we depend on the opts_set
value for it in
On Tue, Nov 08, 2022 at 02:36:17PM +, Julian Brown wrote:
> @@ -3258,6 +3273,7 @@ c_omp_address_inspector::get_origin (tree t)
> || TREE_CODE (t) == SAVE_EXPR)
> t = TREE_OPERAND (t, 0);
>else if (TREE_CODE (t) == INDIRECT_REF
> +&& TREE_TYPE
On Mon, Nov 14, 2022 at 09:46:15PM -0700, Sandra Loosemore wrote:
> --- a/gcc/omp-simd-clone.cc
> +++ b/gcc/omp-simd-clone.cc
> @@ -51,6 +51,210 @@ along with GCC; see the file COPYING3. If not see
> #include "stringpool.h"
> #include "attribs.h"
> #include "omp-simd-clone.h"
> +#include
On Thu, Nov 24, 2022 at 06:48:01PM +0100, Tobias Burnus wrote:
> libgomp: Add no-target-region rev offload test + fix plugin-nvptx
>
> OpenMP permits that a 'target device(ancestor:1)' is called without being
> enclosed in a target region - using the current device (i.e. the host) in
> that case.
On Fri, Nov 25, 2022 at 11:34:35AM +0100, Tobias Burnus wrote:
> Update libgomp.texi's OpenMP implementation status.
> The 5.1 changes are taken from Jakub's comment at
> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602639.html
> (sorry for taking that long to incorporate those).
>
>
On Fri, Nov 25, 2022 at 01:39:04PM +0800, liuhongt wrote:
> Update in V3:
> Remove !flag_signaling_nans since there's already HONOR_NANS (BFmode).
>
> Here's the patch:
>
> After supporting real __bf16, the implementation of _mm_cvtsbh_ss went
> wrong.
>
> The patch add a builtin to generate
On Tue, Nov 22, 2022 at 10:09:06AM -0500, Jason Merrill wrote:
> > Though, shall we have those [on|off] options at all?
> > Those are inconsistent with all other boolean options gcc has.
> > Every other boolean option is -fwhatever for it being on
> > and -fno-whatever for it being off, shouldn't
On Thu, Nov 24, 2022 at 11:01:40AM +0100, Florian Weimer via Gcc-patches wrote:
> * Joseph Myers:
>
> > On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote:
> >
> >> Without this change, finish_declspecs cannot tell that whether there
> >> was an erroneous type specified, or no type at all.
Hi!
On Thu, Nov 24, 2022 at 09:37:54AM +0800, haochen.jiang wrote:
> 8a0fce6a51915c29584427fd376b40073c328090 is the first bad commit
> commit 8a0fce6a51915c29584427fd376b40073c328090
> Author: Jakub Jelinek
> Date: Wed Nov 23 19:09:31 2022 +0100
>
> c: Fix compile time hog in
Hi!
asan_emit_stack_protection and functions it calls have various asserts that
verify sanity of the stack protection instrumentation. But, that
verification can easily fail if we've diagnosed a frame offset overflow.
asan_emit_stack_protection just emits some extra code in the prologue,
if
Hi!
Upstream fast_float came up with a cheaper test for
fegetround () == FE_TONEAREST using one float addition, one subtraction
and one comparison. If we know we are rounding to nearest, we can use
fast path in more cases as before.
The following patch merges those changes into libstdc++.
Hi!
As mentioned in the PR, Solaris apparently can handle right
printf ("%.0Lf\n", 1e+202L * __DBL_MAX__);
which prints 511 chars long number, but can't handle
printf ("%.0Lf\n", 1e+203L * __DBL_MAX__);
nor
printf ("%.0Lf\n", __LDBL_MAX__);
properly, instead of printing 512 chars long number for
Hi!
The following testcase ICEs, because OpenMP lowering for shared clause
on l variable with REFERENCE_TYPE creates POINTER_TYPE to REFERENCE_TYPE.
The reason is that the automatic variable has non-trivial construction
(reference to a lambda) and -fmerge-all-constants is on and so TREE_READONLY
On Thu, Nov 24, 2022 at 09:22:00AM +0800, liuhongt via Gcc-patches wrote:
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -130,6 +130,7 @@ (define_c_enum "unspec" [
>;; For AVX/AVX512F support
>UNSPEC_SCALEF
>UNSPEC_PCMP
> + UNSPEC_CVTBFSF
>
>;; Generic math
On Wed, Nov 23, 2022 at 08:28:20PM +0800, liuhongt via Gcc-patches wrote:
> After supporting real __bf16 type, implementation of mm_cvtsbh_ss went wrong.
> The patch supports extendbfsf2/truncsfbf2 with pslld/psrld,
> and then refined the intrinsic with implicit conversion.
This is not correct.
On Wed, Nov 23, 2022 at 10:34:39AM +0100, Tobias Burnus wrote:
> On 11.11.22 16:13, Tobias Burnus wrote:
> > This patch adds TR11 to the history of OpenMP releases – and it does
> > an update of the implementation status.
> >
> > OK?
LGTM, thanks.
Jakub
Hi!
There can be too many extensions and seems I didn't get everything right in
the previously posted patch.
The following incremental patch ought to fix that.
The code can deal with quite a few sign/zero extensions at various spots
and it is important to deal with all of them right.
On the
Hi!
The complex multiplications result in deeply nested set of many SAVE_EXPRs,
which takes even on fast machines over 5 minutes to walk.
This patch fixes that by using walk_tree_without_duplicates where it is
instant.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Hi!
fast_float library relies on size_t being 32-bit or larger and float/double
being IEEE single/double. Otherwise we only use strtod/strtof.
In 3 spots I've used fast_float namespace stuff unconditionally in one
function, which breaks the build if fast_float is disabled.
Fixed thusly,
Hi!
As reported in the PR, since special_fname_builtin () call has been
introduced, the diagnostics code compares filename against _("")
rather than "", which means that if self tests are performed
with the string being translated, one self-test fails.
The following patch fixes that.
On Tue, Nov 22, 2022 at 09:41:24AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Nov 21, 2022 at 06:31:47PM -0500, Jason Merrill via Gcc-patches wrote:
> > Tested x86_64-pc-linux-gnu, and also manually changing the
> > HAVE_DECL_STRCHRNUL
> > flag. OK for
Hi!
The following patch fixes multiple bugs in warn_for_sign_compare related to
the BIT_NOT_EXPR related warnings.
My understanding is that what those 3 warnings are meant to warn (since 1995
apparently) is the case where we have BIT_NOT_EXPR of a zero-extended
value, so in result_type the value
On Mon, Nov 21, 2022 at 06:31:47PM -0500, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu, and also manually changing the HAVE_DECL_STRCHRNUL
> flag. OK for trunk?
>
> -- 8< --
>
> The Contracts implementation uses strchrnul, which is a glibc extension, so
> bootstrap broke on
Hi!
I've noticed
+FAIL: compiler driver --help=c++ option(s): "^ +-.*[^:.]\$" absent from
output: " -fcontract-build-level=[off|default|audit] Specify max contract
level to generate runtime checks for"
error, this is due to missing dot at the end of the description.
The second part of the
On Mon, Nov 21, 2022 at 12:59:15PM +0100, Christophe Lyon wrote:
> My previous patch to add a sanity check to genmultilib actually
> checked the number of dirnames with the number of "sets of options"
> rather than the number of options, thus breaking the build on some
> targets.
>
> To avoid
On Mon, Nov 21, 2022 at 12:22:32PM +0100, Thomas Neumann via Gcc-patches wrote:
> > When dynamically linking a fast enough machine hides the latency, but when
> > Statically linking or on slower devices this change caused a 5x increase in
> > Instruction count and 2x increase in cycle count before
On Mon, Nov 21, 2022 at 12:57:15PM +0300, Yuri Gribov wrote:
> From 4729f2db3f1b6b40ef0124e4a645788d7f66f426 Mon Sep 17 00:00:00 2001
> From: Yuri Gribov
> Date: Sun, 14 Aug 2022 08:42:44 +0300
> Subject: [PATCH] asan: fix unsafe optimization of Asan checks.
>
> gcc/
> PR
On Mon, Nov 21, 2022 at 09:19:24AM +0100, Martin Liška wrote:
> The patch fixes ChangeLog format that is right now checked by server
> hook.
>
> @Jakub: Can you please approve it? The change is mechanically done.
LGTM, thanks.
You even don't need to write ChangeLog entries for changes
to
Hi!
As the following testcase shows, the swap_rtx_condition function
in reg-stack can result in different code generation between -g and -g0.
The function is doing the changes as it goes, so does analysis and
changes together, which makes it harder to deal with DEBUG_INSNs,
where normally
On Fri, Oct 21, 2022 at 10:23:14AM +0200, Uros Bizjak wrote:
> OK, but now we have two more copies of a function that effectively
> extends BF to SF. Can you please split this utility function out and
> use it here and in cbranchbf4/cstorebf4? I'm talking about this part:
>
> + op =
Hi!
While reporting PR107748 (where is a problem with non-uglified names,
but I've left it out because it needs fixing anyway), I've noticed
various spots where identifiers in *intrin.h headers weren't uglified.
The following patch fixed those that are related to unions (I've grepped
for
On Fri, Nov 18, 2022 at 11:24:45AM -0500, Jason Merrill wrote:
> > Right, that's the C++17 implicit constexpr for lambdas, finish_function:
> >
> >/* Lambda closure members are implicitly constexpr if possible. */
> >if (cxx_dialect >= cxx17
> >&& LAMBDA_TYPE_P (CP_DECL_CONTEXT
On Fri, Nov 18, 2022 at 10:03:18AM -0500, Marek Polacek wrote:
> > the lambda operator() when still a template as constexpr and then
> > cp_finish_decl -> diagnose_static_in_constexpr pedwarns on it.
> > For the above perhaps we could figure out there is a static int k; in the
> > operator() and
On Fri, Nov 18, 2022 at 11:37:42AM +0100, Aldy Hernandez wrote:
> > Practically strictly
> > preserving IEEE exceptions is only important for a very small audience, and
> > for that even INEXACT will matter (but we still have -ftrapping-math
> > by default).
> > For that audience likely all
On Thu, Nov 17, 2022 at 07:28:56PM -0500, Jason Merrill wrote:
> On 11/17/22 15:42, Jakub Jelinek wrote:
> > On Thu, Nov 17, 2022 at 07:42:40PM +0100, Jakub Jelinek via Gcc-patches
> > wrote:
> > > I thought for older C++ this is to catch
> > > void
> >
On Fri, Nov 18, 2022 at 09:45:22AM +0800, liuhongt via Gcc-patches wrote:
> This should fix incorrect error when call those builtin with
> -mavxneconvert and w/o -mavx512bf16 -mavx512vl.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
> Ready to push to trunk.
>
> gcc/ChangeLog:
>
On Thu, Nov 17, 2022 at 07:15:05PM -0500, Marek Polacek wrote:
> > --- gcc/cp/decl.cc.jj 2022-11-16 14:44:43.692339668 +0100
> > +++ gcc/cp/decl.cc 2022-11-17 20:53:44.102011594 +0100
> > @@ -5600,6 +5600,57 @@ groktypename (cp_decl_specifier_seq *typ
> >return type;
> > }
> >
> >
On Thu, Nov 17, 2022 at 07:42:40PM +0100, Jakub Jelinek via Gcc-patches wrote:
> I thought for older C++ this is to catch
> void
> foo ()
> {
> constexpr int a = ({ static constexpr int b = 2; b; });
> }
> and for C++23 the only 3 spots that diagnose those.
> But perha
On Thu, Nov 17, 2022 at 06:59:45PM +, Joseph Myers wrote:
> On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:
>
> > So... is the optimization wrong? Are we not allowed to substitute
> > that NAN if we know it's gonna happen? Should we also allow F F F F F
> > in the test? Or
On Thu, Nov 17, 2022 at 09:42:18AM -0500, Jason Merrill wrote:
> > --- gcc/cp/constexpr.cc.jj 2022-11-17 08:48:30.530357181 +0100
> > +++ gcc/cp/constexpr.cc 2022-11-17 09:56:50.479522863 +0100
> > @@ -7098,7 +7098,8 @@ cxx_eval_constant_expression (const cons
> > && (TREE_STATIC (r)
On Wed, Nov 16, 2022 at 03:26:32PM -0500, Jason Merrill wrote:
> On 11/16/22 09:46, Jakub Jelinek wrote:
> > On Wed, Nov 16, 2022 at 09:33:27AM -0500, Jason Merrill wrote:
> > > > and at that point I fear decl_maybe_constant_var_p will not work
> > > > properly. Shall this hunk be moved somewhere
On Mon, Nov 14, 2022 at 09:55:29PM +, Joseph Myers wrote:
> On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
>
> > So, I wonder if we don't need to add a target hook where targets will be
> > able to provide upper bound on error for floating point functions for
>
On Wed, Nov 16, 2022 at 03:40:02PM +, Tamar Christina wrote:
> > Even:
> >
> > --- gcc/match.pd.jj 2022-11-15 07:56:05.240348804 +0100
> > +++ gcc/match.pd2022-11-16 16:35:34.854080956 +0100
> > @@ -8259,7 +8259,7 @@ and,
> > (simplify
> >(op (vec_perm @0 @0 @2) (vec_perm @1 @1 @2))
On Wed, Nov 16, 2022 at 04:30:06PM +0100, Richard Biener via Gcc-patches wrote:
> On Wed, Nov 16, 2022 at 4:29 PM Richard Biener
> wrote:
> >
> > On Wed, Nov 16, 2022 at 4:25 PM Tamar Christina
> > wrote:
> > >
> > > Hi,
> > >
> > > This patch is causing several ICEs because it changes the
On Wed, Nov 16, 2022 at 09:33:27AM -0500, Jason Merrill wrote:
> > and at that point I fear decl_maybe_constant_var_p will not work
> > properly. Shall this hunk be moved somewhere else (cp_finish_decl?)
> > where we can already call it, or do the above in start_decl for
> > cxx_dialect < cxx20
On Wed, Nov 16, 2022 at 08:20:34AM -0500, Jason Merrill wrote:
> > Ok. But there is another issue, the
> > https://eel.is/c++draft/expr.const#5.2
> > spot that P2647R1 is changing didn't exist in C++20, it was only added with
> > P2242R3. So, if one would treat P2647R1 as a DR for C++20, one has
On Wed, Nov 16, 2022 at 01:45:19PM +, Jonathan Wakely wrote:
> > On Mon, 14 Nov 2022 at 13:57, Jakub Jelinek wrote:
> >
> >> Hi!
> >>
> >> As filed by Jonathan in the PR, I've screwed up the requires syntax
> >> in the extended floating point specialization:
> >> -
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 need to waste
> 32: 00015e10 321 FUNCGLOBAL DEFAULT 13
> __fixbfti@@G
On Tue, Nov 15, 2022 at 05:57:26PM -0500, Jason Merrill wrote:
> > So, my understanding of this is we shouldn't check TYPE_ALIGN in
> > layout_compatible_type_p, but instead DECL_ALIGN in
> > next_common_initial_seqence.
>
> Agreed.
>
> > +#if __cpp_lib_is_layout_compatible >= 201907L
> >
On Tue, Nov 15, 2022 at 06:22:36PM -0500, Jason Merrill wrote:
> > Here is another version of the patch that passed bootstrap/regtest, the only
> > change are tweaks to 2 further testcases.
> >
> > 2022-11-13 Jakub Jelinek
> >
> > * decl.cc (grokdeclarator): Implement
> > CWG2635 -
Hi!
While DI <-> BF conversions can be handled (and are) through
DI <-> XF <-> BF and for narrower integral modes even sometimes
through DF or SF, because XFmode has 64-bit mantissa and so all
the DImode values are exactly representable in XFmode.
That is not the case for TImode, and while e.g.
On Tue, Nov 15, 2022 at 04:49:27PM -0500, Jason Merrill wrote:
> > Or do you want to outline the
> > if (result != error_mark_node
> > && TREE_CODE (TREE_TYPE (cand->fn)) != METHOD_TYPE
> > && TREE_SIDE_EFFECTS (obj))
> > {
> > /* But avoid the implicit
Hi!
The following testcase ICEs, because when !HONOR_NANS but
HONOR_SIGNED_ZEROS, if we see
lhs = op1 * op2;
and know that lhs is [-0.0, 0.0] and op2 is [0.0, 0.0], the
division of these two yields UNDEFINED and clear_nan () on it
fails an assert. With HONOR_NANS it would actually result in
a
On Wed, Nov 16, 2022 at 12:27:02AM +, Jonathan Wakely wrote:
> On Tue, 15 Nov 2022 at 23:50, Jakub Jelinek wrote:
> >
> > On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
> > > > Here is an updated patch that passed bootstrap/regtest, the only
> > > > change is another testcase
On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
> > Here is an updated patch that passed bootstrap/regtest, the only
> > change is another testcase tweak.
> >
> > 2022-11-13 Jakub Jelinek
> >
> > gcc/c-family/
> > * c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_constexpr
> >
On Tue, Nov 15, 2022 at 02:31:19PM +, Jonathan Wakely via Gcc-patches wrote:
> Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
>
> -- >8 --
>
> std::format gives linker errors on targets that define __float128 but
> do not support using it with std::to_chars. This improves the
On Tue, Nov 15, 2022 at 01:49:36PM +0100, Martin Liška wrote:
> On 11/15/22 11:07, Jakub Jelinek wrote:
> > On Tue, Nov 15, 2022 at 11:02:53AM +0100, Martin Liška wrote:
> >>> Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd
> >>> like to cherry pick some commits from LLVM [to
Hi!
On Mon, Nov 14, 2022 at 06:29:44PM -0500, Jason Merrill wrote:
> Indeed. The code in build_new_method_call for this case has the comment
>
> /* In an expression of the form `a->f()' where `f' turns
> out to be a static member function, `a' is
>
On Tue, Nov 15, 2022 at 08:13:45PM +0800, Yixuan Chen wrote:
> From: Oria Chen
>
> gcc/testsuite/ChangeLog:
>
> 2022-11-15 Yixuan Chen
>
> * gcc.dg/fold-overflow-1.c: Optimize testcase, because riscv will use
> ".LC0" intead of ".LC1" and ".LC2" with "-O" compile option
This is
On Tue, Nov 15, 2022 at 11:02:53AM +0100, Martin Liška wrote:
> > Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd
> > like to cherry pick some commits from LLVM [to fix some stupid errors
> > I've made in LoongArch libasan :(].
>
> I'm sorry but I was really busy with the
On Tue, Nov 15, 2022 at 09:54:00AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Nov 14, 2022 at 07:00:54PM -0500, Jason Merrill wrote:
> > > The following patch adds parsing of attributes to concept definition,
> > > allows deprecated attribute to be specified
On Mon, Nov 14, 2022 at 07:00:54PM -0500, Jason Merrill wrote:
> > The following patch adds parsing of attributes to concept definition,
> > allows deprecated attribute to be specified (some ugliness needed
> > because CONCEPT_DECL is a cp/*.def attribute and so can't be mentioned
> > in c-family/
Hi!
I've noticed I've made a typo in the name of the function.
Fixed thusly.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed
as obvious to trunk.
2022-11-15 Jakub Jelinek
* cp-tree.h (next_common_initial_seqence): Rename to ...
On Mon, Nov 14, 2022 at 09:06:10AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 11/13/22 13:48, Philipp Tomsich wrote:
> > The Ventana VT1 core supports quad-issue and instruction fusion.
> > This implemented TARGET_SCHED_MACRO_FUSION_P to keep fusible sequences
> > together and adds idiom
On Mon, Nov 14, 2022 at 07:30:18AM -0700, Jeff Law via Gcc-patches wrote:
> To Jakub's concern. I thought sqrt was treated like +-/* WRT accuracy
> requirements by IEEE. ie, for any input there is a well defined answer for
> a confirming IEEE implementation. In fact, getting to that .5ulp
Hi!
As filed by Jonathan in the PR, I've screwed up the requires syntax
in the extended floating point specialization:
-requires(__complex_type<_Tp>::type)
+requires requires { typename __complex_type<_Tp>::type; }
and doing this change resulted in lots of errors because
901 - 1000 of 4686 matches
Mail list logo
