Hello,
I posted the attached patch in bugzilla some time ago. This includes a
new test case. The patch adds additional checks in key places to catch
eroneous use of semicolons
Regression tested on x86_64,
OK for trunk and later backport to 13?
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr1
The attached patch fixes this one. Se the ChangeLog below for explanation.
OK for trunk?
I think simple enough to backport to 13 as well.
Regards,
Jerry
Author: Jerry DeLisle
Date: Fri Feb 16 17:06:37 2024 -0800
libgfortran: Fix namelist read.
PR libgfortran/107068
l
On Fri, 16 Feb 2024, Maciej W. Rozycki wrote:
> On Fri, 16 Feb 2024, Jakub Jelinek wrote:
>
> > > There is no function prologue to optimise in the VAX case, because all
> > > the frame setup has already been made by the CALLS instruction itself in
> > > the caller. The first machine instructi
On 2/16/24 1:40 PM, Harald Anlauf wrote:
Dear all,
this patch fixes a regression which was a side-effect of r14-8947,
losing the length of a deferred-length character variable when
passed as a dummy.
The new testcase provides a workout for deferred length to improve
coverage in the testsuite.
On 2/10/24 10:10, Matteo Italia wrote:
Il 09/02/24 15:18, Matteo Italia ha scritto:
The Win32 threading model uses __gthr_win32_abs_to_rel_time to convert
the timespec used in gthreads to specify the absolute time for end of
the condition variables timed wait to a milliseconds value relative to
CCing some global reviewers as well, in case anyone has a minute to
take a look please? Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html
On Thu, Jan 25, 2024 at 4:57 PM Lewis Hyatt wrote:
>
> May I please ask again about this one? It's just a couple lines, and I
> think
Can memrefs computed in analyze_loop_vinfo ?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-02-13 21:42
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Adjust vec unit-stride load/store costs.
Hi,
scalar loads provide offset add
Hi,
your suggestion almost did the trick, but caused regressions with
lambda closures in target regions.
Jakub Jelinek wrote:
Ah, and the reason why it doesn't work on target is that it has the
everything is mapped assumption:
if ((ctx->region_type & ORT_TARGET) != 0)
{
if (ctx->
On Fri, Feb 16, 2024 at 10:47:47PM +0100, Jakub Jelinek wrote:
> The following patch works.
Or yet another option would be instead of (sometimes) clearing
declarator->parameter_pack_p when we diagnose this bug for error
recovery ignore the this specifier.
With the following patch (testsuite patch
On Fri, Feb 16, 2024 at 04:39:47PM -0500, Patrick Palka wrote:
> On Fri, 16 Feb 2024, Marek Polacek wrote:
> > + /* We also have to defer checking when we're in a template and couldn't
> > + instantiate & evaluate the noexcept to true/false. */
> > + if (processing_template_decl)
> > +if
> -Original Message-
> From: Marek Polacek
> Sent: Friday, February 16, 2024 11:11 AM
> To: Andrew Pinski (QUIC)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [COMMITTED] c++: Add testcase for this PR [PR97990]
>
> On Fri, Feb 16, 2024 at 11:00:34AM -0800, Andrew Pinski wrote:
> > This
On Fri, Feb 16, 2024 at 10:20:26PM +0100, Jakub Jelinek wrote:
> I've tried that (see below), but am getting
> Excess errors:
> /usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:33:29:
> error: parameter packs not expanded with '...':
And the reason for those is that e.g. on the
Dear all,
this patch fixes a regression which was a side-effect of r14-8947,
losing the length of a deferred-length character variable when
passed as a dummy.
The new testcase provides a workout for deferred length to improve
coverage in the testsuite. Another temporarily disabled test was
re-en
On Fri, 16 Feb 2024, Marek Polacek wrote:
> On Fri, Feb 16, 2024 at 03:58:02PM -0500, Jason Merrill wrote:
> > On 2/15/24 17:17, Marek Polacek wrote:
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > By the ??? below I mean that maybe_instantiate_noexcept could return
On Fri, Feb 16, 2024 at 07:47:18PM +, Qing Zhao wrote:
> This is the 6th version of the patch.
Thanks! I've tested this and it meets all the current behavioral
expectations I've got:
https://github.com/kees/kernel-tools/blob/trunk/fortify/array-bounds.c
Additionally, this builds the Linux ker
On Fri, Feb 16, 2024 at 03:58:02PM -0500, Jason Merrill wrote:
> On 2/15/24 17:17, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > By the ??? below I mean that maybe_instantiate_noexcept could return
> > a tristate, and then maybe_check_overriding_exce
On Thu, 15 Feb 2024, Florian Weimer wrote:
>>> +GCC no longer casts all pointer types to all other pointer types.
>>
>> Do you mean it no longer does so implicitly, or not at all? That is,
>> there are now cases where even an explicit cast such as
>>
>> foo_p = (foo_type*) bar_p
>>
>> no longer w
On Fri, Feb 16, 2024 at 03:47:41PM -0500, Jason Merrill wrote:
> Can we move all the xobj handling down here (where we can trust
> declarator->parameter_pack_p) instead of adding a new variable?
I've tried that (see below), but am getting
Excess errors:
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/expl
Hi Peter,
thanks for your contribution to gfortran! You've found indeed
a solution for a potentially annoying bug.
Am 15.02.24 um 18:50 schrieb Peter Hill:
Dear all,
The attached patch fixes PR105658 by forcing an array temporary to be
created. This is required when passing an array component
On Fri, Feb 16, 2024 at 03:40:39PM -0500, Jason Merrill wrote:
> > --- gcc/cp/cp-objcp-common.cc.jj2024-02-13 12:50:21.666846296 +0100
> > +++ gcc/cp/cp-objcp-common.cc 2024-02-16 20:40:51.374763528 +0100
> > @@ -410,6 +410,15 @@ cp_type_dwarf_attribute (const_tree type
> > return 1;
On 2/14/24 18:33, Iain Sandoe wrote:
On 14 Feb 2024, at 22:59, Iain Sandoe wrote:
On 12 Feb 2024, at 19:59, Jason Merrill wrote:
On 2/10/24 07:30, Iain Sandoe wrote:
On 10 Feb 2024, at 12:07, Jason Merrill wrote:
On 2/10/24 05:46, Iain Sandoe wrote:
On 9 Feb 2024, at 23:21, Iain Sando
On 2/15/24 17:17, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
By the ??? below I mean that maybe_instantiate_noexcept could return
a tristate, and then maybe_check_overriding_exception_spec could check
if (maybe_instantiate_noexcept ().is_unknown ())
On 2/15/24 17:16, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
IMHO trivial enough to go ahead now seeing as it doesn't introduce
new errors.
OK.
-- >8 --
I noticed we don't implement the "unless the overriding function is
defined as deleted" wording adde
On 2/16/24 04:03, Jakub Jelinek wrote:
Hi!
The simple presence of ellipsis as next token after the parameter
declaration doesn't imply it is a parameter pack, it sometimes is, e.g.
if its type is a pack, but sometimes is not and in that case it acts
the same as if the next tokens were , ... inst
On 2/16/24 14:52, Jakub Jelinek wrote:
On Fri, Feb 16, 2024 at 04:52:20PM +0100, Jakub Jelinek wrote:
On Fri, Feb 16, 2024 at 10:48:28AM -0500, Jason Merrill wrote:
On 2/16/24 04:14, Jakub Jelinek wrote:
DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
we emit it), bu
On Fri, Feb 16, 2024 at 04:52:20PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 16, 2024 at 10:48:28AM -0500, Jason Merrill wrote:
> > On 2/16/24 04:14, Jakub Jelinek wrote:
> > > DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
> > > we emit it), but also on anonymous unions
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
source code.
gcc/c/C
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
* gcc.dg/ubsan/flex-array-counted
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This includ
Hi,
This is the 6th version of the patch.
compare with the 5th version, the only difference is:
1. Add the 6th argument to .ACCESS_WITH_SIZE
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
previously, we use the result type of the rou
I had another change to in my local tree which affected
the second dg-error and I "fixed" it unnecessarily. I've tested with a
clean tree this time.
Tested aarch64-linux. Pushed to trunk.
-- >8 --
PR libstdc++/87744
PR libstdc++/113961
libstdc++-v3/ChangeLog:
* testsui
On Fri, Feb 16, 2024 at 11:00:34AM -0800, Andrew Pinski wrote:
> This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add
> one to make sure it does not regress again.
>
> Committed as obvious after a quick test on the testcase.
>
> PR c++/97990
>
> gcc/testsuite/ChangeLog:
>
This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add
one to make sure it does not regress again.
Committed as obvious after a quick test on the testcase.
PR c++/97990
gcc/testsuite/ChangeLog:
* g++.dg/torture/vector-struct-1.C: New test.
Signed-off-by: Andrew P
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote:
>
> There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION
> target. I think claiming for it that it is a lra target is strange (even
> though it effectively returns true for targetm.lra_p ()), unsure if it
> supports asm goto
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote:
>
> Given the recent discussions on IRC started with Andrew P. mentioning that
> an asm goto outputs test should have { target lra } and the lra effective
> target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
> we clearly ha
Thanks! Committed
Edwin
On 2/15/2024 9:27 AM, Mike Stump wrote:
On Feb 12, 2024, at 11:38 AM, Edwin Lu wrote:
There is currently no support for matching at least x lines of assembly
(only scan-assembler-times). This patch would allow setting upper or lower
bounds.
Use case: using different s
On Fri, Feb 16, 2024 at 07:52:17PM +0200, Dimitar Dimitrov wrote:
> The issue in PR112344 is triggered only at -O2, so there is little value
> in running the test at lower optimization levels. At the same time the
That is generally not true.
We had hundreds of cases in the history where a test wr
The issue in PR112344 is triggered only at -O2, so there is little value
in running the test at lower optimization levels. At the same time the
generated code at low and code-size optimization levels is taking a long
time to execute because it loops a few billion iterations.
On the PRU simulator
Fixed by the PR113612 fix r14-8960-g19ac327de421fe.
PR c++/111682
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ86.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/var-templ86.C | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 gcc/testsuite/g++.dg
An update to the 5th version of the patches:
Kees helped me to do more testings, and found one issue:
===
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
On 2/16/24 10:58, Marek Polacek wrote:
On Thu, Feb 15, 2024 at 04:36:40PM -0500, Jason Merrill wrote:
On 2/15/24 10:19, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we have
template
auto is_throwable(T t) -> decltype(throw t, true) {
On Fri, 16 Feb 2024, Jakub Jelinek wrote:
> > There is no function prologue to optimise in the VAX case, because all
> > the frame setup has already been made by the CALLS instruction itself in
> > the caller. The first machine instruction of the callee is technically
> > already past the "pr
On Thu, Feb 15, 2024 at 04:36:40PM -0500, Jason Merrill wrote:
> On 2/15/24 10:19, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Here we have
> >
> >template
> >auto is_throwable(T t) -> decltype(throw t, true) { ... }
> >
> >
Hi!
Ah, and the reason why it doesn't work on target is that it has the
everything is mapped assumption:
if ((ctx->region_type & ORT_TARGET) != 0)
{
if (ctx->region_type & ORT_ACC)
/* For OpenACC, as remarked above, defer expansion. */
shared = false;
else
On Fri, Feb 16, 2024 at 10:48:28AM -0500, Jason Merrill wrote:
> On 2/16/24 04:14, Jakub Jelinek wrote:
> > DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
> > we emit it), but also on anonymous unions/structs (and we didn't emit that
> > attribute there).
> > The followi
On 2/16/24 07:56, Iain Sandoe wrote:
tested on x86_64-darwin, so far. OK for trunk if regression test is
successful on Linux too?
thanks
Iain
--- 8< ---
r14-5310-g879cf9ff45d940 introduced some new handling for spawning sub
processes. The return value from the generic exec_child is examined
On 2/16/24 04:14, Jakub Jelinek wrote:
Hi!
DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
we emit it), but also on anonymous unions/structs (and we didn't emit that
attribute there).
The following patch fixes it.
Should this involve cp_decl_dwarf_attribute like the
On Fri, Feb 16, 2024 at 04:15:05PM +0100, Tobias Burnus wrote:
> I have no idea whether that would - nor whether that would be
> the way forward. - Thoughts?
Don't have time to dive through this now in detail, just want to point out
why we ignore DECL_VALUE_EXPR on the magic var during gimplificat
The following works with PARALLEL but not with TARGET.
OpenMP states the following is supposed to work:
A = 5; // == this->A
B = 6; // == this->B
C[44] = 7; // == this->C; assume 'int C[100]'
#pragma firstprivate(A,C) private(B)
{
A += 5; // Now: A is 10.
B = 7;
On 2/16/24 04:21, Jakub Jelinek wrote:
Hi!
For template parameters, the optional this specifier is in the grammar
template-parameter-list -> template-parameter -> parameter-declaration,
just [dcl.fct/6] says that it is only valid in parameter-list of certain
functions. So, unlike the case of de
On Fri, 16 Feb 2024 at 14:10, Jakub Jelinek wrote:
>
> On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> > Ah, although __atomic_compare_exchange only takes pointers, the
> > compiler replaces that with a call to __atomic_compare_exchange_n
> > which takes the newval by value, whic
The following works with PARALLEL but not with TARGET.
OpenMP states the following is supposed to work:
A = 5; // == this->A
B = 6; // == this->B
C[44] = 7; // == this->C; assume 'int C[100]'
#pragma firstprivate(A,C) private(B)
{
A += 5; // Now: A is 10.
B = 7;
C[44]
On Thu, 15 Feb 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> -- >8 --
>
> One would expect consecutive calls to bytes_in/out::b for streaming
> adjacent bits, as we do for tree flag streaming, to at least be
> optimized by the
tested on x86_64-darwin, so far. OK for trunk if regression test is
successful on Linux too?
thanks
Iain
--- 8< ---
r14-5310-g879cf9ff45d940 introduced some new handling for spawning sub
processes. The return value from the generic exec_child is examined
and needs to be < 0 to signal an error. H
> On Feb 16, 2024, at 6:34 AM, Maciej W. Rozycki wrote:
>
> On Thu, 15 Feb 2024, Paul Koning wrote:
>
>>> On May 15, 2023, at 5:09 PM, Maciej W. Rozycki wrote:
>>>
>>> ...
>>>
>>> I may choose to implement a non-DWARF unwinder instead, as the VAX stack
>>> frame is always fully described
On 16/02/2024 14:34, Thomas Schwinge wrote:
Hi!
On 2024-01-29T11:34:05+0100, Tobias Burnus wrote:
Andrew wrote off list:
"Vector reductions don't work on RDNA, as is, but they're
supposed to be disabled by the insn condition"
This patch disables "fold_left_plus_", which is about
vect
Hi!
On 2024-01-29T11:34:05+0100, Tobias Burnus wrote:
> Andrew wrote off list:
>"Vector reductions don't work on RDNA, as is, but they're
> supposed to be disabled by the insn condition"
>
> This patch disables "fold_left_plus_", which is about
> vectorization and in the code path shown i
On Fri, Feb 16, 2024 at 02:23:54PM +, Maciej W. Rozycki wrote:
> On Fri, 16 Feb 2024, Segher Boessenkool wrote:
>
> > > Conversely no heuristics is required to unwind VAX frames, because they
> > > are fixed in layout by hardware, fully self-described, and with the
> > > hardware frame poin
On Fri, 16 Feb 2024, Segher Boessenkool wrote:
> > Conversely no heuristics is required to unwind VAX frames, because they
> > are fixed in layout by hardware, fully self-described, and with the
> > hardware frame pointer always available.
>
> The downside of the VAX situation of course is tha
On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> Ah, although __atomic_compare_exchange only takes pointers, the
> compiler replaces that with a call to __atomic_compare_exchange_n
> which takes the newval by value, which presumably uses an 80-bit FP
> register and so the padding
Hi!
On 2024-02-16T12:41:06+, Andrew Stubbs wrote:
> On 16/02/2024 12:26, Richard Biener wrote:
>> On Fri, 16 Feb 2024, Andrew Stubbs wrote:
>>> On 16/02/2024 10:17, Richard Biener wrote:
On Fri, 16 Feb 2024, Thomas Schwinge wrote:
> On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
On Fri, 16 Feb 2024 at 12:38, Jonathan Wakely wrote:
>
> On Fri, 2 Feb 2024 at 16:52, xndcn wrote:
> >
> > Thank you for your careful review!
> >
> > > But we don't need a new one if it's going to be used in exactly one test
> > > and if the new option does the same thing for all targets that ru
On Fri, Feb 16, 2024 at 11:34:55AM +, Maciej W. Rozycki wrote:
> Not really, in particular because EH unwinding has to be reliable and
> heuristics inherently is not.
Yup. Which is why I did 0359465c703a for rs6000 six years ago (how time
flies!) The commit message for that includes
T
> On 15 Feb 2024, at 18:05, Richard Sandiford wrote:
>
> Iain Sandoe writes:
>>> On 5 Feb 2024, at 14:56, Iain Sandoe wrote:
>>>
>>> Tested on aarch64-linux,darwin and a cross from aarch64-darwin to linux,
>>> OK for trunk, or some alternative is needed?
>>
>> Hmm.. apparently, this fails
Hi Jakub,
> On Fri, Feb 16, 2024 at 01:32:04PM +0100, Rainer Orth wrote:
>> c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
>>
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
>> FAIL: c-c++-
On Fri, Feb 16, 2024 at 01:32:04PM +0100, Rainer Orth wrote:
> c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
>
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
> FAIL: c-c++-common/asan/swapco
The following addresses the weak bitmap_hash function which results
in points-to analysis taking a long time because of a high collision
rate in one of its bitmap hash tables. Using a better hash function
like in the bitmap.cc hunk below doesn't help unless one also replaces
the hash function in i
On 16/02/2024 12:26, Richard Biener wrote:
On Fri, 16 Feb 2024, Andrew Stubbs wrote:
On 16/02/2024 10:17, Richard Biener wrote:
On Fri, 16 Feb 2024, Thomas Schwinge wrote:
Hi!
On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
I've committed this patch
... as commit c7ec7bd1c6590cf4eed26
On Fri, 2 Feb 2024 at 16:52, xndcn wrote:
>
> Thank you for your careful review!
>
> > But we don't need a new one if it's going to be used in exactly one test
> > and if the new option does the same thing for all targets that run the test.
> Got it, thanks. Now add option "-latomic" directly, bu
c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 execution test
FAIL: c-c++-common/asan/swapcontex
On Fri, 16 Feb 2024, Andrew Stubbs wrote:
> On 16/02/2024 10:17, Richard Biener wrote:
> > On Fri, 16 Feb 2024, Thomas Schwinge wrote:
> >
> >> Hi!
> >>
> >> On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
> >>> I've committed this patch
> >>
> >> ... as commit c7ec7bd1c6590cf4eed267feab490288
On Tue, Feb 13, 2024 at 07:52:01PM -0500, Jason Merrill wrote:
> On 2/10/24 17:57, Nathaniel Shead wrote:
> > The fix for PR107398 weakened the restrictions that lambdas must belong
> > to namespace scope. However this was not sufficient: we also need to
> > allow lambdas keyed to FIELD_DECLs or PA
The following addresses consistency check fails in copy_reference_ops_from_ref
when we are handling out-of-bound array accesses (it's almost impossible
to identically mimic the get_ref_base_and_extent behavior). It also
addresses the case where an out-of-bound constant offset computes to a
-1 off
On Thu, 15 Feb 2024, Paul Koning wrote:
> > On May 15, 2023, at 5:09 PM, Maciej W. Rozycki wrote:
> >
> > ...
> >
> > I may choose to implement a non-DWARF unwinder instead, as the VAX stack
> > frame is always fully described by the hardware and there is never ever a
> > need for debug infor
On 16/02/2024 10:17, Richard Biener wrote:
On Fri, 16 Feb 2024, Thomas Schwinge wrote:
Hi!
On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
I've committed this patch
... as commit c7ec7bd1c6590cf4eed267feab490288e0b8d691
"amdgcn: add -march=gfx1030 EXPERIMENTAL", which the later RDNA3/gfx
Tested x86_64-linux, pushed to trunk.
-- >8 --
PR libstdc++/87744
PR libstdc++/113931
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
---
libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc | 4 ++--
1 fil
Pushed to trunk.
-- >8 --
The configure option is no longer necessary.
libstdc++-v3/ChangeLog:
* doc/xml/manual/debug_mode.xml: Update docs for backtraces.
* doc/html/manual/debug_mode_using.html: Regenerate.
---
libstdc++-v3/doc/html/manual/debug_mode_using.html | 9 -
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/test.xml: Fix spelling of elements.
* doc/html/manual/test.html: Regenerate.
---
libstdc++-v3/doc/html/manual/test.html | 4 ++--
libstdc++-v3/doc/xml/manual/test.xml | 4 ++--
2 files changed, 4 insertions(+)
On Thu, Feb 15, 2024 at 08:41:42PM -0500, Paul Koning wrote:
> > On Feb 15, 2024, at 5:56 PM, Segher Boessenkool
> > wrote:
> >
> > On Thu, Feb 15, 2024 at 07:34:32PM +, Sam James wrote:
> >> I have now started doing this in PR113932.
> >
> > Thank you!
> >
> > Segher
>
> Presumably this
On Fri, 16 Feb 2024, Thomas Schwinge wrote:
> Hi!
>
> On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
> > I've committed this patch
>
> ... as commit c7ec7bd1c6590cf4eed267feab490288e0b8d691
> "amdgcn: add -march=gfx1030 EXPERIMENTAL", which the later RDNA3/gfx1100
> support builds on top of,
Hi!
Given the recent discussions on IRC started with Andrew P. mentioning that
an asm goto outputs test should have { target lra } and the lra effective
target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
we clearly have 14 other targets which don't support LRA and a couple
*sge_ pattern has referenced operand[2] which is
invalid...it should just use `slti` rather than `slti%i2`.
gcc/ChangeLog:
PR target/106543
* config/riscv/riscv.md (*sge_): Fix asm
pattern.
---
gcc/config/riscv/riscv.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
Hi!
On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
> I've committed this patch
... as commit c7ec7bd1c6590cf4eed267feab490288e0b8d691
"amdgcn: add -march=gfx1030 EXPERIMENTAL", which the later RDNA3/gfx1100
support builds on top of, and that's what I'm currently working on
getting proper GCC/
On Thu, Feb 15, 2024 at 7:38 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
Btw, there's the "bitpack" streaming support in data-streamer.h also
added for exactly the same reason, it's likely not easily re-usable
but this kind of appr
Hi!
For template parameters, the optional this specifier is in the grammar
template-parameter-list -> template-parameter -> parameter-declaration,
just [dcl.fct/6] says that it is only valid in parameter-list of certain
functions. So, unlike the case of decl-specifier-seq used in non-terminals
ot
Hi!
DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
we emit it), but also on anonymous unions/structs (and we didn't emit that
attribute there).
The following patch fixes it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-16 Jakub Jelinek
Hi!
The simple presence of ellipsis as next token after the parameter
declaration doesn't imply it is a parameter pack, it sometimes is, e.g.
if its type is a pack, but sometimes is not and in that case it acts
the same as if the next tokens were , ... instead of just ...
The xobj param cannot be
gcc.dg/lto/modref-3 etc. FAIL on Solaris with the native linker:
FAIL: gcc-dg-lto-modref-3-01.exe scan-wpa-ipa-dump modref "parm 1 flags:
no_direct_clobber no_direct_escape"
FAIL: gcc-dg-lto-modref-4-01.exe scan-wpa-ipa-dump modref "parm 1 flags:
no_direct_clobber no_direct_escape"
FAIL: gcc.dg/
90 matches
Mail list logo
