Hi Gaius,
apologies, I thought you had pushed the updated patch and only now
realized it's not in yet.
Please look into the few bits below and then go ahead and push.
On Mon, 6 Feb 2023, Gaius Mulley wrote:
> * htdocs/frontends.html: An update to say the front end is now in
> the de
On Sat, 2023-01-07 at 06:52 +, Jonathan Yong via Gcc-patches wrote:
> On 1/6/23 18:10, Jakub Jelinek wrote:
> > On Sat, Jan 07, 2023 at 02:01:05AM +0800, LIU Hao via Gcc-patches
> > wrote:
> > > libgomp/
> > >
> > > PR middle-end/108300
> > > * config/mingw32/proc.c: Define `WI
On 3/3/23 3:32 PM, Iain Sandoe wrote:
On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran
wrote:
On 2 March 2023 02:23:10 CET, Jerry D wrote:
On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran
wrote:
Hi Michael Collison:
It's REALLY NOT OK that you didn't mention RiVAI and Ju-Zhe in either
changelog or add he as co-author,
apparently you HAVE references and even copy his code from
https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next
On 3/3/23 12:50, Marek Polacek wrote:
On Fri, Mar 03, 2023 at 11:25:06AM -0500, Jason Merrill wrote:
On 3/2/23 16:24, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:
@@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
const int& y = (f(1), 42); //
Ping...
> From: Hans-Peter Nilsson
> Date: Fri, 24 Feb 2023 20:16:03 +0100
>
> Ok to commit?
> -- >8 --
> Those multi-line-patterns are literal. Sometimes a regexp
> needs to be matched. This is a start: just three elements
> are supported: "(" ")" and the compound ")?" (and on second
> though
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.
CRIS defines DATA_ALIGNMENT such that alignment can be
applied differently to different data of the same type, when
"references to it must bind to the current definition"
(varasm.cc:align_variable). Here, it means that more
alignment is then applied to g, but not f, so the test-case
fails because
CRIS has no conditional execution and no conditional moves.
* gcc.dg/ifcvt-4.c: Add cris-*-* to skip list.
---
gcc/testsuite/gcc.dg/ifcvt-4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/ifcvt-4.c b/gcc/testsuite/gcc.dg/ifcvt-4.c
index 46245f0d0
Committed as obvious.
-- >8 --
* g++.dg/cpp0x/pr84497.C: Handle USER_LABEL_PREFIX == "_" on
scan-assembler identifiers.
* gcc.dg/debug/btf/btf-enum64-1.c, gcc.dg/ipa/symver1.c: Ditto.
---
gcc/testsuite/g++.dg/cpp0x/pr84497.C | 6 +++---
gcc/testsuite/gcc.dg/debug/b
>> This series of patches adds foundational support for RISC-V
>> autovectorization. These patches are based on the current upstream rvv
>> vector intrinsic support and is not a new implementation. Most of the
>> implementation consists of adding the new vector cost model, the
>> autovectorizat
> On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran
> wrote:
>
> On 2 March 2023 02:23:10 CET, Jerry D wrote:
>> On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
>>> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via
>>> Fortran wrote:
libgfortran/caf/
Successfully tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6467-gdf0184906a7b86.
gcc/testsuite/ChangeLog:
PR analyzer/109016
* gcc.dg/analyzer/omp-parallel-for-1.c: New test.
* gcc.dg/analyzer/omp-parallel-for-get-min.c: New test.
Signed-off-by: David Malcolm
---
On 2 March 2023 02:23:10 CET, Jerry D wrote:
>On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
>> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via
>> Fortran wrote:
>>> libgfortran/caf/single.c |6 ++
>>> libgfortran/io/async.c |6 ++
>>> libgf
On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> + A new statement attribute for C++23 href="https://wg21.link/p1774r8";>P1774R8 Portable
> + assumptions support also in C or older C++:
This reads a bit odd to me: is there a comma missing after P1774R8?
And maybe a colon before? Or something like
Previously, the analyzer lacked a known_function implementation of
sprintf, and thus would handle calls to sprintf with the "anything could
happen" fallback.
Whilst working on PR analyzer/107565 I noticed that this was preventing
a lot of genuine memory leaks from being reported for Doom; fixing
t
Jakub's r13-6441-gdbeccab7a1f5dc fix for PR tree-optimization/108988
has fixed this failing analyzer test.
Successfully tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6465-gd3ef73867e3f70.
gcc/testsuite/ChangeLog:
PR tree-optimization/108988
* gcc.dg/analyzer/pr99716-1.c (t
On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> Tobias mentioned on IRC that assume attribute wasn't mentioned in
> changes.html. The P1774R8 entry was missing for C++, so I went through
> projects/cxx-status.html#cxx23 and filled in all the missing papers
> which have been implemented newly in GCC 13,
On Thu, 2 Mar 2023, Jonathan Wakely via Gcc-patches wrote:
> Pushed to wwwdocs.
Thank you!
> +If an allocator type Alloc
Note that HTML 5 complains about the use of and we are using
instead.
I just pushed the following patch addressing that. (The diff looks a bit
bigger due to changes re
On Fri, Mar 03, 2023 at 10:24:07PM +0100, Mikael Morin wrote:
> Hello,
>
> Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :
> > On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> > > - if (attr->class_ok)
> > > -/* Class container has already been built. */
Hi!
On Fri, Feb 03, 2023 at 12:53:05AM -0500, Michael Meissner wrote:
> This patch reworks how the complex multiply and divide built-in functions are
> done.
> I tested all 3 patchs for PR target/107299 on:
Is this part of the proposed commit message? As Ke Wen pointed out, it
is wrong. Most o
Hello,
Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
- if (attr->class_ok)
-/* Class container has already been built. */
+ /* Class container has already been built with same name. */
+ if (attr->cla
Hi Steve,
Am 03.03.23 um 20:57 schrieb Steve Kargl via Gcc-patches:
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
- if (attr->class_ok)
-/* Class container has already been built. */
+ /* Class container has already been built with same name. */
+ if (attr-
Hi!
On Fri, Feb 03, 2023 at 12:49:12AM -0500, Michael Meissner wrote:
> This patch updates the IEEE 128-bit types used in libgcc.
>
> At the moment, we cannot build GCC when the target uses IEEE 128-bit long
> doubles, such as building the compiler for a native Fedora 36 system. The
> build dies
On Mar 3, 2023, Alexandre Oliva wrote:
> Hello, Florian,
> On Mar 3, 2023, Florian Weimer wrote:
>> * Alexandre Oliva via Gcc-patches:
>>> +// Make sure it's not optimized out, not even with LTO.
>>> +asm ("" : : "rm" (depend));
>> If the m constraint is used, this may never emit the
Hello, Florian,
On Mar 3, 2023, Florian Weimer wrote:
> * Alexandre Oliva via Gcc-patches:
>> +// Make sure it's not optimized out, not even with LTO.
>> +asm ("" : : "rm" (depend));
> If the m constraint is used, this may never emit the symbol name and
> thus not create a reference af
* Alexandre Oliva via Gcc-patches:
> +// Make sure it's not optimized out, not even with LTO.
> +asm ("" : : "rm" (depend));
If the m constraint is used, this may never emit the symbol name and
thus not create a reference after all.
On Feb 3, 2023, Jonathan Wakely wrote:
> This one slipped through the cracks, sorry.
Oh, nice, thanks, I'd missed the review too, for a whole month :-)
I've just found the unread message. I'll have a happier weekend. I did
not even recall this patch was still pending, and this very test was
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> - if (attr->class_ok)
> -/* Class container has already been built. */
> + /* Class container has already been built with same name. */
> + if (attr->class_ok
> + && ts->u.derived->components->attr.dimension
On Mar 3, 2023, Jonathan Wakely wrote:
> On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely wrote:
>> And those expressions aren't ever optimized away as unused?
> Oh, I missed that they're called after casting them
*nod*
> That would be UB to call them through the wrong pointer type, so the
> co
Hi,
GDC's run-time library doesn't implement the RTTI-based overload of
va_arg, document it on the missing features page.
Bootstrapped and regression tested, committed to mainline.
Regards,
Iain.
---
PR d/108763
gcc/d/ChangeLog:
* implement-d.texi (Missing Features): Document
On Wed, Feb 22, 2023 at 01:02:58PM +, Jonathan Yong wrote:
> On 2/22/23 09:25, Jakub Jelinek wrote:
> > As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
> > and has one important problem, two different multilib options -m64 and -m32,
> > but MULTILIB_DIRNAMES with just one
On Thu, Feb 9, 2023 at 7:54 PM Andrew Pinski via Gcc-patches
wrote:
>
> The problem here is that aarch64_expand_setmem does not change the alignment
> for strict alignment case.
> This is version 4 of the fix, major changes from the last version is fixing
> the way store pairs are handled which al
On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely wrote:
>
>
> On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva wrote:
>
>> On Mar 3, 2023, Jonathan Wakely wrote:
>>
>> > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely
>> wrote:
>> >> Jakub previously suggested doing this for PR 61841, which was a simila
On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva wrote:
> On Mar 3, 2023, Jonathan Wakely wrote:
>
> > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely wrote:
> >> Jakub previously suggested doing this for PR 61841, which was a similar
> >> problem with pthread_create:
> >>
> >> __asm ("" : : "r" (&pt
On Fri, Mar 03, 2023 at 06:07:48PM +, Jonathan Wakely via Gcc-patches wrote:
> This fixes Jakub's second testcase. The printer needs to do slightly
> different things depending on whether the gdbval obejct is a vec or a
> pointer to a vec.
>
> OK for trunk?
>
> -- >8 --
>
> gcc/ChangeLog:
>
On Fri, 3 Mar 2023 at 17:50, Alexandre Oliva via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
>
> We're getting regressions after ugprading to GDB 13 in a few of the
> libstdc++ pretty-printing tests. It might seem like a GDB regression,
> but that update has a new symbol reader, and Tom Tromey says
This fixes Jakub's second testcase. The printer needs to do slightly
different things depending on whether the gdbval obejct is a vec or a
pointer to a vec.
OK for trunk?
-- >8 --
gcc/ChangeLog:
PR middle-end/109006
* gdbhooks.py (VecPrinter): Handle vec as well as vec*.
---
gc
Some of the rs6000 call patterns, on some ABIs, issue multiple opcodes
out of a single call insn, but the call (bl) or jump (b) is not always
the last opcode in the sequence.
This does not seem to be a problem for exception handling tables, but
the return_pc attribute in the call graph output in
On Fri, 3 Mar 2023 at 17:01, Jakub Jelinek wrote:
> On Fri, Mar 03, 2023 at 05:45:59PM +0100, Jakub Jelinek via Gcc-patches
> wrote:
> > On Fri, Mar 03, 2023 at 04:44:39PM +, Jonathan Wakely via
> Gcc-patches wrote:
> > > OK for trunk?
> > >
> > > gcc/ChangeLog:
> > >
> >
> > Please add
> >
Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl
can call check_initializer even in a template for a constexpr initializer.
Here we are rejecting
extern const Q q;
template
constexpr auto p = q(0);
even though q has a constexpr operator(). It's deemed non-con
On Fri, Mar 03, 2023 at 11:25:06AM -0500, Jason Merrill wrote:
> On 3/2/23 16:24, Marek Polacek wrote:
> > On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:
> > > > @@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
> > > > const int& y = (f(1), 42); // NULL_TREE
> > > >
We're getting regressions after ugprading to GDB 13 in a few of the
libstdc++ pretty-printing tests. It might seem like a GDB regression,
but that update has a new symbol reader, and Tom Tromey says it
exposes a latent problem in the pretty-printer, namely, when a name is
not defined locally in
On Mar 3, 2023, Jonathan Wakely wrote:
> On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely wrote:
>> Jakub previously suggested doing this for PR 61841, which was a similar
>> problem with pthread_create:
>>
>> __asm ("" : : "r" (&pthread_create)); would not be optimized away.
>>
>>
>> That would
Hi!
On Fri, Mar 03, 2023 at 04:29:57PM +0530, Surya Kumari Jangala wrote:
> On 27/02/23 9:58 pm, Segher Boessenkool wrote:
> > On Wed, Jan 04, 2023 at 01:58:19PM +0530, Surya Kumari Jangala wrote:
> >> + register swaps of permuting loads/stores have been removed. */
> >
> > If it really mean
Le 02/03/2023 à 18:18, Andrew Stubbs a écrit :
On 01/03/2023 16:56, Paul-Antoine Arras wrote:
This patch introduces instruction patterns for conditional min and max
operations (cond_{f|s|u}{max|min}) in the GCN machine description. It
also allows the exec register to be saved in SGPRs to avoid
On Fri, Mar 03, 2023 at 05:45:59PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Mar 03, 2023 at 04:44:39PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > OK for trunk?
> >
> > gcc/ChangeLog:
> >
>
> Please add
> PR middle-end/109006
> here
> > * gdbhooks.py (VecPrinter):
On Fri, Mar 03, 2023 at 04:44:39PM +, Jonathan Wakely via Gcc-patches wrote:
> OK for trunk?
>
> gcc/ChangeLog:
>
Please add
PR middle-end/109006
here
> * gdbhooks.py (VecPrinter): Adjust for new vec layout.
Ok with that, thanks.
> gcc/gdbhooks.py | 6 +-
> 1 file change
OK for trunk?
gcc/ChangeLog:
* gdbhooks.py (VecPrinter): Adjust for new vec layout.
---
gcc/gdbhooks.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
index c9dea9bf828..78e6c97c30d 100644
--- a/gcc/gdbhooks.py
+++ b/gcc/gdbhook
On 3/2/23 16:24, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:
@@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
const int& y = (f(1), 42); // NULL_TREE
const int& z = f(f(1)); // f(f(1))
- EXPR is the initializer. */
+ EXPR is the i
On Mar 3, 2023, at 12:40 AM, Xi Ruoyao via Gcc-patches
wrote:
>
> Some trivial test case fixes. Ok for trunk?
Ok.
On 3/3/23 09:58, Patrick Palka wrote:
In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appear
On 3/3/23 10:18, Jakub Jelinek wrote:
On Thu, Mar 02, 2023 at 11:48:04AM -0500, Jason Merrill wrote:
The stmtexpr19.C testcase used to be rejected as it has a static
variable in statement expression in constexpr context, but as that
static variable is initialized by constant expression, when P26
On Thu, Mar 02, 2023 at 11:48:04AM -0500, Jason Merrill wrote:
> > The stmtexpr19.C testcase used to be rejected as it has a static
> > variable in statement expression in constexpr context, but as that
> > static variable is initialized by constant expression, when P2647R1
> > was implemented we a
On 3/2/23 19:13, Robin Dapp wrote:
> Hi,
>
> we seem to flip flop between the "high" and "not low" variants of load on
> condition. Accept both in the affected test cases.
>
> Going to commit this as obvious.
>
> Regards
> Robin
>
> --
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s39
On 3/2/23 16:24, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to commit a4c6bd0821099f6b8c0f64a96ffd9d01a025c413
> introducing a runtime check for alignment for 16 byte atomic
> compare-exchange, load, and store.
>
> Bootstrapped and regtested on s390.
> Ok for mainline and gcc-{12,11,
On 3/2/23 19:17, Robin Dapp wrote:
> Hi,
>
> When compiling on a system where binutils do not yet support the 'z16'
> name assembling fails with -march=native which we currently interpret
> as -march=z16 (on a z16 machine). This patch uses -march=arch14
> instead.
>
> Is it OK?
Ok. Thanks!
And
In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appears in one (we process
a local specializat
Committed as obviously correct. Enable LRA for the moxie port.
gcc/ChangeLog:
* config/moxie/moxie.cc (TARGET_LRA_P): Remove.
diff --git a/gcc/config/moxie/moxie.cc b/gcc/config/moxie/moxie.cc
index dcf87ef98a1..2132b6e48a3 100644
--- a/gcc/config/moxie/moxie.cc
+++ b
Committed as obviously correct. Required to make LRA for moxie work.
gcc/ChangeLog:
* config/moxie/constraints.md (A, B, W): Change
define_constraint to define_memory_constraint.
diff --git a/gcc/config/moxie/constraints.md b/gcc/config/moxie/constraints.md
in
On Fri, 2023-03-03 at 10:35 +0100, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, GCC's diagnostics self-tests fail if $COLUMNS
> < 42.
> Guarding each self-test with if (get_terminal_width () > 41) or
> similar
> would be a maintainance nightmare (PR has a patch to do so without
> reforma
Hi Haochen,
On 03.03.23 10:56, HAO CHEN GUI via Gcc-patches wrote:
Sure, I will merge it into the patch and do the regression test.
Thanks :-)
Additionally, Kewen suggested:
Since this test case is powerpc only, I think it can be moved to
gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fort
On 13/02/2023 20.27, Rasmus Villemoes wrote:
> The .su files generated with -fstack-usage are arguably debug info. In
> order to make builds more reproducible, apply the same remapping logic
> to the recorded file names as for when producing the debug info
> embedded in the object files.
>
> To th
On Thu, Mar 2, 2023 at 3:02 PM Costas Argyris wrote:
>
> Thanks for the review.
>
> What is the next step please?
Somebody pushed the patch already.
Richard.
> Thanks,
> Costas
>
> On Thu, 2 Mar 2023 at 10:08, Richard Biener
> wrote:
>>
>> On Thu, Mar 2, 2023 at 10:21 AM Costas Argyris
>> w
On Fri, 3 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes 2 issues with the -Wnonnull warning.
>
> One, fixed by the second hunk, is that the warning wording is bogus
> since r11-3305, instead of printing
> warning: argument 1 to ‘int[static 7]’ is null where non-null expected
On Fri, Mar 3, 2023 at 9:58 AM Xi Ruoyao via Gcc-patches
wrote:
>
> On Fri, 2023-03-03 at 16:54 +0800, Xi Ruoyao wrote:
> > The driver emits a warning when -fstack-check and
> > -fstack-clash-protection are used together, but the message refers to
> > "-fstack-clash_protection" (underline instead
On Fri, Mar 3, 2023 at 9:30 AM Alexandre Oliva wrote:
>
> On Feb 17, 2023, Richard Biener wrote:
>
> >> * gimple-ssa-warn-access.cc
> >> (pass_waccess::check_dangling_stores): Skip non-stores.
> >>
> >> for gcc/testsuite/ChangeLog
> >>
> >> * g++.dg/warn/Wdangling-pointer.C (warn_init_ref_member
On Thu, Mar 2, 2023 at 7:24 PM Robin Dapp via Gcc-patches
wrote:
>
> Hi,
>
> this patch changes SLP test expectations. As we only vectorize when no
> more than one rgroup is present, no vectorization is performed.
>
> I was also considering using a separate target selector (something like
> vect_
Partial PRE ends up miscompiling the testcase in PR109002, likely
involving a corner case when inifinite loops are involved. The
following avoids the miscompilation by addressing a long-standing
oddity that manifests in odd partial partial redundancies eliminated
that are full redundancies. The o
On 27/02/23 9:58 pm, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jan 04, 2023 at 01:58:19PM +0530, Surya Kumari Jangala wrote:
>> In the routine rs6000_analyze_swaps(), special handling of swappable
>> instructions is done even if the webs that contain the swappable
>> instructions are not opti
Hi!
The following patch fixes 2 issues with the -Wnonnull warning.
One, fixed by the second hunk, is that the warning wording is bogus
since r11-3305, instead of printing
warning: argument 1 to ‘int[static 7]’ is null where non-null expected
[-Wnonnull]
it prints
warning: argument 1 to ‘int[stat
On Fri, 3 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> gimple_fold_builtin_fputs when folding fputs into fwrite emits the third
> argument (INTEGER_CST) with incorrect type - get_maxval_strlen or c_strlen
> return ssizetype, while fwrite argument is size_type_node.
> The following patch fixes that, I
Hi Tobias,
在 2023/3/3 17:29, Tobias Burnus 写道:
> But could you also include the 'gcc/fortran/intrinsic.cc' change
> proposed in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613030.html (and
> acknowledged by Steve)?
Sure, I will merge it into the patch and do the regression test.
Addi
On Tue, 21 Feb 2023 at 08:34, Rainer Orth wrote:
> This patch updates the libstdc++ Solaris baselines for GCC 13.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (Solaris 11.3
> and 11.4).
>
> Ok for trunk?
>
OK, thanks.
On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely wrote:
>
>
> On Fri, 3 Mar 2023 at 08:20, Alexandre Oliva via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> On Feb 17, 2023, Jonathan Wakely wrote:
>>
>> > The proper fix is to ensure the program has a non-weak reference to
>> > pthread_join withou
Hi!
gimple_fold_builtin_fputs when folding fputs into fwrite emits the third
argument (INTEGER_CST) with incorrect type - get_maxval_strlen or c_strlen
return ssizetype, while fwrite argument is size_type_node.
The following patch fixes that, I've skimmed through the rest of
gimple-fold.cc and in
Hi!
As mentioned in the PR, GCC's diagnostics self-tests fail if $COLUMNS < 42.
Guarding each self-test with if (get_terminal_width () > 41) or similar
would be a maintainance nightmare (PR has a patch to do so without
reformatting to make it work for $COLUMNS in [30, 41] inclusive, but
I'm afraid
On Fri, 3 Mar 2023 at 08:20, Alexandre Oliva via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> On Feb 17, 2023, Jonathan Wakely wrote:
>
> > The proper fix is to ensure the program has a non-weak reference to
> > pthread_join without extra help (or use a recent glibc where it always
> > works).
>
>
Thanks!
Le jeu. 2 mars 2023 à 23:54, David Malcolm a écrit :
> On Thu, 2023-03-02 at 23:35 +0100, Guillaume Gomez wrote:
> > I don't have push rights so if you could push it, it'd be super
> > appreciated!
>
> Done, as r13-6425-g6b432c0f777ab9; I took the liberty of slightly
> tweaking the subje
Hi Haochen,
thanks for fixing 'gcc/fortran/target-memory.cc'.
But could you also include the 'gcc/fortran/intrinsic.cc' change
proposed in
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613030.html (and
acknowledged by Steve)?
This will replace "Unclassifiable statement" by "Cannot simpli
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Alexandre
> Oliva via Gcc-patches
> Sent: Friday, March 3, 2023 8:24 AM
> To: Christophe Lyon
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [arm] adjust tests for quotes around +cdec
> -Original Message-
> From: Alexandre Oliva
> Sent: Friday, February 17, 2023 7:12 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw
> Subject: [PATCH] [arm] adjust expectations for armv8_2-fp16-move-[12].c
>
>
> Commit 3a7ba8fd0cda387809e4902328af2473662b6a4
Hi,
The patch passed regression test on Power linux platforms. Sorry for missing
the information.
Gui Haochen
在 2023/3/3 17:12, HAO CHEN GUI via Gcc-patches 写道:
> Hi,
> The patch escalates the failure when Hollerith constant to real conversion
> fails in native_interpret_expr. It finally repo
> -Original Message-
> From: Alexandre Oliva
> Sent: Friday, February 17, 2023 7:14 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw
> Subject: [PATCH] [PR51534] [arm] split out pr51534 test for softfp
>
>
> The test uses arm_hard_ok and arm_softfp_ok as if t
On 2023-03-03 16:54 jiawei wrote:
>
>The Mask flag in the single TargetVariable is not enough due to more
>and more extensions were added.So I optimize the defination of Mask
>flag, please refer to the below case:
>There are some new MASK flags for 'v' extension(ZVL32B,ZVL64B,...,ZVL65536B),
>but
Hi,
The patch escalates the failure when Hollerith constant to real conversion
fails in native_interpret_expr. It finally reports an "Unclassifiable
statement" error.
The patch of pr95450 added a verification for decoding/encoding checking
in native_interpret_expr. native_interpret_expr may fa
> -Original Message-
> From: Alexandre Oliva
> Sent: Friday, February 17, 2023 7:36 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> ramana@gmail.com; Kyrylo Tkachov ;
> Andrea Corallo
> Subject: [PATCH] [arm] complete vmsr/vmrs blank and case adjustment
> -Original Message-
> From: Alexandre Oliva
> Sent: Friday, February 17, 2023 7:39 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> ramana@gmail.com; Kyrylo Tkachov
> Subject: [PATCH] [PR104882] [arm] require mve hw for mve run test
>
>
> The pr10488
On Fri, 2023-03-03 at 16:54 +0800, Xi Ruoyao wrote:
> The driver emits a warning when -fstack-check and
> -fstack-clash-protection are used together, but the message refers to
> "-fstack-clash_protection" (underline instead of dash).
Forgot: Ok for trunk? Though I think it's obvious but let's fol
> The Mask flag in the single TargetVariable is not enough due to more> and
> more extensions were added.So I optimize the defination of Mask> flag, please
> refer to the below case:> There are some new MASK flags for 'v'
> extension(ZVL32B,ZVL64B,...,ZVL65536B),> but these MASK flags can't stor
On 3/3/23 09:24, Alexandre Oliva wrote:
Hello, Christophe,
On Feb 22, 2023, Christophe Lyon wrote:
OK thanks for the clarification.
(and for the other cleanup patches!)
Was this meant as approval? I hadn't taken it as such.
Unfortunately, no, I don't have such powers :-)
Otherwi
The driver emits a warning when -fstack-check and
-fstack-clash-protection are used together, but the message refers to
"-fstack-clash_protection" (underline instead of dash).
gcc/ChangeLog:
* toplev.cc (process_options): Fix the spelling of
"-fstack-clash-protection".
---
gcc/to
The Mask flag in the single TargetVariable is not enough due to more
and more extensions were added.So I optimize the defination of Mask
flag, please refer to the below case:
There are some new MASK flags for 'v' extension(ZVL32B,ZVL64B,...,ZVL65536B),
but these MASK flags can't store into x_target
Once upon the time we used to save two registers unnecessarily, costing
16 bytes. Now the issue seems fixed (not sure by which commit though),
adjust the stack offsets to reflex the change.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/stack-check-cfa-1.c (dg-final): Adjust
exp
Stack protector will affect stack layout and break the expectation of
these tests, causing test failures if GCC is configured with
--enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/prolog-opt.c (dg-options): Add
-fno-stack-protector.
* gcc.target/loonga
Some trivial test case fixes. Ok for trunk?
Xi Ruoyao (2):
LoongArch: testsuite: Disable stack protector for some tests
LoongArch: testsuite: Adjust stack offsets in stack-check-cfa tests
gcc/testsuite/gcc.target/loongarch/prolog-opt.c| 2 +-
gcc/testsuite/gcc.target/loongarch/stack
On Feb 17, 2023, Richard Biener wrote:
>> * gimple-ssa-warn-access.cc
>> (pass_waccess::check_dangling_stores): Skip non-stores.
>>
>> for gcc/testsuite/ChangeLog
>>
>> * g++.dg/warn/Wdangling-pointer.C (warn_init_ref_member): Add
>> two new variants, one fixed, one xfailed.
>> * c-c++-common/
On Feb 17, 2023, Alexandre Oliva wrote:
> * gcc.target/arm/armv8_2-fp16-move-1.c: Combine vcmp and vcmpe
> expected counts into a single pattern.
> * gcc.target/arm/armv8_2-fp16-move-2.c: Accept conditional
> return and reversed conditions.
Ping?
https://gcc.gnu.org/piper
On Feb 17, 2023, Alexandre Oliva wrote:
> PR target/51534
> * gcc.target/arm/pr51534.c: Split softfp variant into...
> * gcc.target/arm/pr51534s.c: ... this, and support ARM too.
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612189.html
--
Alexandre Oliva, hap
On Feb 20, 2023, Andrea Corallo via Gcc-patches wrote:
> Alexandre Oliva writes:
>> Back in September last year, some of the vmsr and vmrs patterns had an
>> extraneous blank removed, and the case of register names lowered, but
>> another instance remained, and so did a few testcases.
> I'm not
1 - 100 of 105 matches
Mail list logo
