On Wed, Aug 31, 2022 at 11:00 PM Simon Rainer wrote:
>
> Hi,
>
> This patch fixes PR106627. I ran the i386.exp tests on my x86_64-linux-gnu
> machine with a fully bootstrapped checkout. I also tested manually that no
> exception handling code is generated if none of the function versions throws
On Wed, Aug 31, 2022 at 9:21 PM Iain Buclaw wrote:
>
> Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
> > On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> >
> >> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> >> > On Fri, 26 Aug 2022, Richard Biener
On Wed, 31 Aug 2022, Kees Cook wrote:
> On Wed, Aug 31, 2022 at 08:35:12PM +, Qing Zhao wrote:
> > One of the major purposes of the new option -fstrict-flex-array is to
> > encourage standard conforming programming style.
> >
> > So, it might be reasonable to treat -fstrict-flex-array simil
In the example below, 'x' is once placed on the stack frame and then read
into registers as the argument value of bar():
/* example */
struct foo {
int a, b;
};
extern struct foo bar(struct foo);
struct foo test(void) {
struct foo x = { 0, 1 };
return bar(x);
This patch eliminates all clobbers for complex hard registers that will
be overwritten entirely afterwards (supersedence of
3867d414bd7d9e5b6fb2a51b1fb3d9e9e1eae9).
gcc/ChangeLog:
* config/xtensa/xtensa.md: Rewrite the split pattern that performs
the abovementioned process so that
Hi,
This patch changes the sequence of test directives for 3 test cases.
Originally, these 3 cases got failed or unsupported on some platforms, as
their effective target checks depend on compiling options.
Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
Is this okay f
Any feedback regarding this proposal:
https://gcc.gnu.org/pipermail/libstdc++/2021-June/052821.html
On 23/06/21 22:34, François Dumont wrote:
Hi
Following the message to propose an alternative lower_bound and the
reply to use three way comparison I try to implement this.
Before going furthe
The V registers are always clobbered on calls.
gcc/ChangeLog
* config/riscv/riscv.cc (riscv_conditional_register_usage):
Always mark the V registers as clobbered on calls.
---
gcc/config/riscv/riscv.cc | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --g
Hi,
Currently, these two splitters (touched in this patch) are using predicate
`int_reg_operand_not_pseudo`, then they work in split2 pass after RA in
most times, and can not run before RA.
It would not be a bad idea to allow these splitters before RA. Then more
passes (between split1 and split2
Hi,
As mentioned in PR106550, since pli could support 34bits immediate, we could
use less instructions(3insn would be ok) to build 64bits constant with pli.
For example, for constant 0x020805006106003, we could generate it with:
asm code1:
pli 9,101736451 (0x6106003)
sldi 9,9,32
paddi 9,9, 213000
On 8/31/22 6:45 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 06:36:40PM -0500, Peter Bergner wrote:
>> Changes from v1:
>> * Fix spelling typo in git log entry
>> * Fix broken test checking src_ptr's type
>> * Use NOP_EXPR rather than VIEW_CONVERT_EXPR
>> * Change order of dg-options
>>
Committed with title fix, that should be TARGET_CONDITIONAL_REGISTER_USAGE
On Tue, Aug 30, 2022 at 2:28 PM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_conditional_register_usage): Add RVV
> registers.
>
> ---
> gcc/config/riscv/riscv.cc | 9 +++
Committed.
On Tue, Aug 30, 2022 at 2:21 PM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_const_insns): Add cost of poly_int.
> (riscv_output_move): Add csrr vlenb assembly.
> * config/riscv/riscv.md (move_type): Add csrr vlenb type.
>
Thanks, committed!
On Tue, Aug 30, 2022 at 2:15 PM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/constraints.md (TARGET_VECTOR ? V_REGS : NO_REGS): Add
> "vr" constraint.
> (TARGET_VECTOR ? VD_REGS : NO_REGS): Add "vd" constraint.
> (TARGET_VECTOR ? V
Thanks, pushed to trunk.
On Tue, Aug 30, 2022 at 10:58 AM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.h (enum reg_class): Change vype to vtype.
>
> ---
> gcc/config/riscv/riscv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/con
Thanks, pushed with a few minor style fixes.
On Tue, Aug 30, 2022 at 9:51 AM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_convert_vector_bits): Change
> configuration according to TARGET_MIN_VLEN.
> * config/riscv/riscv.h (UNITS_PER_FP_REG):
On Linux/x86_64,
b911ca4231a366ddfd026f190b126bd517f4e640 is the first bad commit
commit b911ca4231a366ddfd026f190b126bd517f4e640
Author: Jonathan Wakely
Date: Fri Aug 26 16:22:21 2022 +0100
libstdc++: Add [[nodiscard]] attribute to and
caused
FAIL: g++.dg/tree-ssa/empty-loop.C -std=g
On Linux/x86_64,
61c4c989034548f481d1f10198447be27fb9a55f is the first bad commit
commit 61c4c989034548f481d1f10198447be27fb9a55f
Author: Richard Sandiford
Date: Tue Aug 30 15:43:47 2022 +0100
Extend SLP permutation optimisations
caused
FAIL: gcc.dg/vect/bb-slp-pr54400.c -flto -ffat-lto-
On Wed, Aug 31, 2022 at 06:36:40PM -0500, Peter Bergner wrote:
> Changes from v1:
> * Fix spelling typo in git log entry
> * Fix broken test checking src_ptr's type
> * Use NOP_EXPR rather than VIEW_CONVERT_EXPR
> * Change order of dg-options
>
> When we expand an MMA disassemble built-in with C++
Changes from v1:
* Fix spelling typo in git log entry
* Fix broken test checking src_ptr's type
* Use NOP_EXPR rather than VIEW_CONVERT_EXPR
* Change order of dg-options
When we expand an MMA disassemble built-in with C++ using a pointer that
is cast to a valid MMA type, the type isn't passed down
On 8/31/22 6:08 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
>> The problem goes away if I use use -O1 or above, I drop -flto or I use
>> the code I originally posted without the ptr_vector_*_type
>>
>> The assert in gimple_canonical_types_compatibl
On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
> The problem goes away if I use use -O1 or above, I drop -flto or I use
> the code I originally posted without the ptr_vector_*_type
>
> The assert in gimple_canonical_types_compatible_p() we're hitting is:
> 13673 default:
> 1367
Implement some changes to the currently supported C2x standard
attributes that have been made to the specification since they were
first implemented in GCC, and some consequent changes:
* maybe_unused is now supported on labels. In fact that was already
accidentally supported in GCC as a result
On Wed, Aug 31, 2022 at 08:35:12PM +, Qing Zhao wrote:
> One of the major purposes of the new option -fstrict-flex-array is to
> encourage standard conforming programming style.
>
> So, it might be reasonable to treat -fstrict-flex-array similar as -pedantic
> (but only for flexible array m
On 8/31/22 4:49 PM, Segher Boessenkool wrote:
> But it is incorrect as well. Instead, we should look if -mpowerpc64 is
> enabled explicitly, and not change it if so.
Sure, I agree with checking for explicit use. That said, I'll let
someone else work on this.
Peter
On Wed, Aug 31, 2022 at 08:16:49PM +, Qing Zhao wrote:
>
> > On Aug 31, 2022, at 4:09 PM, Joseph Myers wrote:
> >
> > On Wed, 31 Aug 2022, Qing Zhao wrote:
> >
> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member
> [] is treated as a valid flexible array) pre
On 8/31/22 3:51 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
>> Question for my own education, when would you use VIEW_CONVERT_EXPR over
>> NOP_EXPR?
>
> VIEW_CONVERT_EXPR is essentially a bit_cast. Only use it when you need
> that, it is sub-opt
On Wed, Aug 31, 2022 at 04:38:02PM -0500, Peter Bergner wrote:
> On 8/31/22 4:07 PM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
> >> Changing OS_MISSING_POWERPC64 as I mentioned would not add
> >> OPTION_MASK_POWERPC64
> >> to our cpu masks when -m
On 8/31/22 4:07 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
>> Changing OS_MISSING_POWERPC64 as I mentioned would not add
>> OPTION_MASK_POWERPC64
>> to our cpu masks when -m32 is used.
>
> So you say this is where the bug is?
For linux64.h whic
> + case GFC_FPE_GFC_FPE_AWAY:
>
> typo?
Absolutely. Didn’t break the build because glibc currently doesn’t define
FE_TONEARESTFROMZERO, but it should in the future (when C2x is included).
FX
This introduces an early exit test to most_specialized_partial_spec for
the common case where we have no partial specializations, which allows
us to avoid some unnecessary work. In passing, clean the function up a
bit.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk
On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
> On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> Right, but haven't the 64-bit Linux kernels been fixed forever to always
> save/restore the full 64-bit hardware regist
Hi,
This patch fixes PR106627. I ran the i386.exp tests on my x86_64-linux-gnu
machine with a fully bootstrapped checkout. I also tested manually that no
exception handling code is generated if none of the function versions throws an
exception.
I don't have access to a machine to test the chang
On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
> ...and of course, now I can't recreate that issue at all and the
> ptr_vector_*_type use work fine now. Strange! ...so ok, changed.
> Maybe the behavior changed since my PR106017 fix went in???
That is my best guess as well. But, h
On 31 August 2022 20:29:12 CEST, FX via Fortran wrote:
+ case GFC_FPE_GFC_FPE_AWAY:
typo?
thanks,
On 8/31/22 07:57, Palmer Dabbelt wrote:
if (flag_pic)
- riscv_cmodel = CM_PIC;
+ riscv_cmodel = CM_MEDANY;
/* We get better code with explicit relocs for CM_MEDLOW, but
worse code for the others (for now). Pick the best default. */
I'm fine either way on this one: having
On 8/31/22 07:57, Palmer Dabbelt wrote:
On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:
Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 3 ---
1 file changed, 3 deletions(
> On Aug 31, 2022, at 4:16 PM, Qing Zhao via Gcc-patches
> wrote:
>
> Okay, I am fine with this.
Another thought on this is:
One of the major purposes of the new option -fstrict-flex-array is to encourage
standard conforming programming style.
So, it might be reasonable to treat -fstrict-
Okay, I am fine with this.
Richard and Kees, what’s your opinion on this?
thanks.
Qing
> On Aug 31, 2022, at 4:09 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao wrote:
>
When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member
[] is treated as a valid f
I missed this testsuite fix in the libstdc++ commit.
Tested x86_64-linux, pushed to trunk.
-- >8 --
std::string now has [[nodiscard]] attributes on most members, causing
-Wunused-result warnings for this test.
gcc/testsuite/ChangeLog:
PR testsuite/106795
* g++.dg/tree-ssa/empty
On Wed, 31 Aug 2022, Qing Zhao wrote:
> >> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member
> >> [] is treated as a valid flexible array) present together,
> >
> > That seems reasonable enough without a warning. If people want a warning
> > for flexible array members in
On Wed, 31 Aug 2022 at 20:27, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
On Wed, 31 Aug 2022 at 20:33, François Dumont wrote:
>
> On 31/08/22 12:11, Jonathan Wakely wrote:
> > On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
> >> After a second thought here is an even cleaner version. No more function
> >> rename, current pretty_print is fine.
> >>
> >> libs
> On Aug 31, 2022, at 3:52 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao wrote:
>
>> Does the above mean that -std=gnu89 does not support C99 flexible array
>> member, then
>
> No.
>
> Flexible array members are supported by GCC in all C standards modes. The
> C90 standard d
On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> No. Instead, it just works!
>
> Try this:
> ===
> typedef float vf __attribute__((vector_size(16)));
> vf f(float x)
> {
> x *= 42;
> return (vf){x, x, x, x};
> }
> ===
> w
On Wed, 31 Aug 2022, Qing Zhao wrote:
> Does the above mean that -std=gnu89 does not support C99 flexible array
> member, then
No.
Flexible array members are supported by GCC in all C standards modes. The
C90 standard doesn't support them, but that's irrelevant to what GCC
supports; it just
> On Aug 31, 2022, at 3:29 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>
>>> How is level 3 (thus -fstrict-flex-array) interpreted when you specify
>>> -std=c89? How for -std=gnu89?
>>
>> 1. what’s the major difference between -std=c89 and -std=gnu89 on
On 31/08/22 12:11, Jonathan Wakely wrote:
On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
After a second thought here is an even cleaner version. No more function
rename, current pretty_print is fine.
libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
Add _GLIBC
On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> >> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
> >
> > Oh? Why should it disable -maltivec?
On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> > How is level 3 (thus -fstrict-flex-array) interpreted when you specify
> > -std=c89? How for -std=gnu89?
>
> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible
> array? (Checked online, cannot find a concrete ans
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__advance_fn::operator()): Add
parentheses in assert condition to avoid -Wparentheses warning.
* include/std/ranges: (take_view::take_view): Uglify 'base'.
> On Aug 31, 2022, at 2:55 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Aug 31, 2022, at 1:21 PM, Joseph Myers wrote:
>>
>> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>>
"a GNU extension" suggests a particular language feature, but I think
you're actually refer
Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
> On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
>
>> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
>> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>> >
>> >> I was hoping Joseph would ch
> On Aug 31, 2022, at 1:21 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>
>>> "a GNU extension" suggests a particular language feature, but I think
>>> you're actually referring here to a whole language version rather than an
>>> individual feature.
>>
>
On 8/31/22 8:59 AM, Peter Bergner wrote:
> On 8/31/22 4:22 AM, Kewen.Lin wrote:
>> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>>> - tree src_type = TREE_TYPE (src_ptr);
>>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>>> + ? build_pointer_type (v
This adds new F2018 features, that are not really enabled (because their
runtime support is optional).
1. Add the new IEEE_AWAY rounding mode. It is unsupported on all known targets,
but could be supported by glibc and AIX as part of the C2x proposal. Testing
for now is minimal, but once a targ
On 8/31/2022 10:40 AM, John David Anglin wrote:
On 2022-08-31 11:35 a.m., Jeff Law wrote:
It looks like you removed the pa-bsd and pa-osf targets too. Those
were so niche that I doubt anyone else would notice.
That should be okay. I have never heard of anyone building these.
There is no co
On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> > "a GNU extension" suggests a particular language feature, but I think
> > you're actually referring here to a whole language version rather than an
> > individual feature.
>
> Is “not supported by GNU extension GNU89” better?
There are
On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> >
> >> I was hoping Joseph would chime in here - I recollect debugging this kind
> >> of thing and a thread
On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
>> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
>
> Oh? Why should it disable -maltivec? -mvsx makes a little sense on
> one hand, but totally none on the other
On 2022-08-31 11:35 a.m., Jeff Law wrote:
It looks like you removed the pa-bsd and pa-osf targets too. Those were so
niche that I doubt anyone else would notice.
That should be okay. I have never heard of anyone building these. There is no
config for these in config.gcc.
hppa*-*-openbsd* an
On 8/31/22 11:07, Jakub Jelinek wrote:
On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:
It could be more explicit, but I think we can assume that from the existing
wording; it says it designates the named character. If there is no such
character, that cannot be satisfied, so it mu
On 8/25/2022 3:39 AM, Kong, Lingling via Gcc-patches wrote:
Hi,
The conditional mult reduction cannot be recognized with current GCC. The
following loop cannot be vectorized.
Now add MULT_EXPR recognition for conditional scalar reduction.
float summa(int n, float *arg1, float *arg2)
{
On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> > Should *any* explicit command line flag ever be disabled like that?
> > (Not talking about things like -m32 -m64, ...
>
> In a general sense, I'd agree that the answer is no, but we
On 8/29/2022 2:11 PM, Jan-Benedict Glaw wrote:
Hi Jeff!
On Sun, 2022-08-28 15:32:53 -0600, Jeff Law via Gcc-patches
wrote:
On 8/28/2022 1:50 AM, Jan-Benedict Glaw wrote:
On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches
wrote:
This makes defaults.h choose DWARF2_DEBUG i
On 8/17/2022 5:11 AM, Richard Biener via Gcc-patches wrote:
The following started as making the backward threader m_imports
use the tree representation. Since that interfaces to a list
representation bitmap in ranger by copying rewriting the tree
to list to perform the copy is inefficient in
Hi!
On Fri, Aug 26, 2022 at 10:50:00PM -0500, Peter Bergner wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand
(The perfect tense of cast is "cast").
> machinery and we end up using the base
On 8/25/2022 3:42 AM, Martin Liška wrote:
Hi.
I wrote a scipt that runs autoconf in all folders that have configure.ac
file and same for autoheader (where AC_CONFIG_HEADERS is present) and
this is the output.
The script can be seen here:
https://github.com/marxin/script-misc/blob/master/gcc-
On 8/22/2022 3:39 AM, Martin Liška wrote:
On 4/28/22 18:10, Jeff Law via Gcc-patches wrote:
As I mentioned in the original thread, my change to pr94157_0 was an attempt to
avoid these warnings by passing a magic flag to the linker. Of course we may
not be using GNU ld. Or we may be on a n
On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> Should *any* explicit command line flag ever be disabled like that?
> (Not talking about things like -m32 -m64, ...
In a general sense, I'd agree that the answer is no, but we do have
dependent options like -maltivec and -mvsx, etc., so a -mno-altiv
On 8/28/2022 5:09 AM, Jan-Benedict Glaw wrote:
Hi!
The nvptx backend defines ASM_OUTPUT_DEF along with
ASM_OUTPUT_DEF_FROM_DECLS. Much like the rs6000 coff target, nvptx
triggers an unused variable warning:
/usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_S
On 8/23/2022 5:49 AM, Surya Kumari Jangala via Gcc-patches wrote:
sched1: Fix -fcompare-debug issue in schedule_region [PR105586]
In schedule_region(), a basic block that does not contain any real insns
is not scheduled and the dfa state at the entry of the bb is not copied
to the fallthru ba
On 8/31/2022 1:21 AM, Martin Liška wrote:
Sending v3 of the patch that includes John's comments.
Ready to be installed?
Thanks,
Martin
ChangeLog:
* configure: Regenerate.
* configure.ac: Delete hpux9 and hpux10.
config/ChangeLog:
* mh-pa-hpux10: Removed.
contrib/C
Could you also clean up all __riscv_cmodel_pic checking in
gcc/testsuite/gcc.target/riscv/predef-*.c?
On Wed, Aug 31, 2022 at 10:58 PM Palmer Dabbelt wrote:
>
> On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:
> > Came across this deprecated symbol when looking around for
> > -mexpli
On Aug 31, 2022, Xi Ruoyao wrote:
> On Sat, 2022-07-09 at 10:11 -0600, Jeff Law via Gcc-patches wrote:
>> Once Alex is OK with this patch, then it'll be good to go.
>>
>> jeff
> Gentle ping as a distro maintainer :).
Oops, thanks, sorry, I seem to have missed it the first time around.
The pat
On Wed, Aug 31, 2022 at 05:07:29PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Given what you said above, I think that is what we want for the last 2
> for C++23, the question is if it is ok also for C++20/C17 etc. and whether
> it should depend on -pedantic or -pedantic-errors or GNU vs. ISO mod
On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
> Test case bswap64-4.c suffers the issue as its comments:
>
> /* On some versions of dejagnu this test will fail when
>biarch testing with RUNTESTFLAGS="--target_board=unix
>'{-m64,-m32}'" due to -m32 being added on the command
>
On 8/29/2022 8:30 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 4:27 PM Jakub Jelinek wrote:
On Mon, Aug 29, 2022 at 04:20:16PM +0200, Aldy Hernandez wrote:
Sure, I can add the HONOR_NANS, but can we even "see" a NAN in the IL
for -ffinite-math-only?
Sure, you can, e.g.
On 8/29/2022 8:42 AM, Toon Moene wrote:
On 8/29/22 16:36, Aldy Hernandez wrote:
On Mon, Aug 29, 2022 at 4:30 PM Toon Moene wrote:
On 8/29/22 16:15, Aldy Hernandez wrote:
But even with -ffinite-math-only, is there any benefit to propagating
a known NAN? For example:
The original inten
On 8/29/2022 8:15 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 4:08 PM Toon Moene wrote:
On 8/29/22 15:54, Jakub Jelinek via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
For convenience, singleton_p() returns false for a NAN. IMO
On 8/29/2022 7:54 AM, Jakub Jelinek via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
For convenience, singleton_p() returns false for a NAN. IMO, it makes
the implementation cleaner, but I'm not wed to the idea if someone
objects.
If singleton_p() is us
On Wed, Aug 31, 2022 at 05:33:21PM +0800, Kewen.Lin wrote:
> It's meant to update "lxv" to "p?lxv" and should leave the
> "lvx" unchanged. So this is to fix the typo accordingly.
>
> I'll push this soon if no objections.
Please go ahead. Out of interest, did you see failures from this, was
it j
On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:
> It could be more explicit, but I think we can assume that from the existing
> wording; it says it designates the named character. If there is no such
> character, that cannot be satisfied, so it must be ill-formed.
Ok.
> > So, we c
On Tue, 30 Aug 2022 10:48:30 PDT (-0700), Vineet Gupta wrote:
CM_PIC is no longer doing anything directly. Removing it might
potentially affect USE_LOAD_ADDRESS_MACRO() but seems unlikely.
At least in the short term, there's kind of a mess here that needs to
get sorted out but just removing CM
On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:
Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/riscv/riscv-c
On 8/31/22 4:33 AM, Kewen.Lin via Gcc-patches wrote:
> Commit r12-2266 updated the scanned assembly content from
>
> "{\mlvx\M|\mlxv\M|\mlxvd2x\M}"
>
> to
>
> "{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"
>
> for the test case pr86731-fwrapv-longlong.c unexpectedly.
>
> It's meant to update "lxv" to "p
On 8/31/22 10:35, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote:
If
#define z(x) 0
#define a z(
int x = a\NARG);
is valid in C and C++ <= 20 then
#define z(x) 0
#define a z(
int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
is too and shall prepr
The tests for sizeless SVE types include checks that the types
are handled for initialisation purposes in the same way as scalars.
GNU C and C2x now allow scalars to be initialised using empty braces,
so this patch updates the SVE tests to match.
Tested on aarch64-linux-gnu & pushed.
Richard
gc
On 8/30/2022 8:50 AM, Richard Sandiford wrote:
Jeff Law via Gcc-patches writes:
On 8/25/2022 7:07 AM, Richard Sandiford via Gcc-patches wrote:
Currently SLP tries to force permute operations "down" the graph
from loads in the hope of reducing the total number of permutations
needed or (in t
On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote:
> If
> #define z(x) 0
> #define a z(
> int x = a\NARG);
> is valid in C and C++ <= 20 then
> #define z(x) 0
> #define a z(
> int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
> is too and shall preprocess to int x = 0; too.
When processing USE predicates we can drop from the AND chain,
when procsssing DEF predicates we can drop from the OR chain. Do
that instead of giving up completely. This also removes cases
that should never trigger.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* gimple-
On 8/31/22 10:15, Jakub Jelinek wrote:
On Wed, Aug 31, 2022 at 09:55:29AM -0400, Jason Merrill wrote:
On 8/31/22 07:14, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
This hunk now seems worth factoring out of the four places it occurs.
It also seems the c
Hum, slightly amended patch, after checking 32-bit results on another linux
machine.
The test for FMA has been made a bit less strict, because otherwise we have
surprised on 387 arithmetic due to excess precision.
Final patch is attached. Regression-tested on x86_64-pc-linux-gnu, both 32- and
6
On 8/30/22 17:37, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 11:18:20PM +0200, Jakub Jelinek via Gcc-patches wrote:
On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:
I'm seeing build failures of glibc for powerpc64, as illustrated by the
following C code:
#if 0
\NARG
#endif
(the
On Wed, Aug 31, 2022 at 09:55:29AM -0400, Jason Merrill wrote:
> On 8/31/22 07:14, Jakub Jelinek wrote:
> > On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
> > > This hunk now seems worth factoring out of the four places it occurs.
> > >
> > > It also seems the comment for _cpp_vali
On 8/31/22 4:33 AM, Kewen.Lin wrote:
> @@ -1,7 +1,8 @@
> /* { dg-do compile { target { powerpc*-*-* } } } */
> /* { dg-skip-if "" { powerpc*-*-aix* } } */
> -/* { dg-options "-O2 -mpowerpc64" } */
> /* { dg-require-effective-target ilp32 } */
> +/* { dg-options "-O2 -mpowerpc64" } */
> +/* { dg-
On 8/31/22 07:14, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
This hunk now seems worth factoring out of the four places it occurs.
It also seems the comment for _cpp_valid_utf8 needs to be updated: it
currently says it's not called when parsing a string.
Hi, Joseph,
Thanks a lot for your comment.
> On Aug 30, 2022, at 6:53 PM, Joseph Myers wrote:
>
> On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote:
>
>> Hi, Joseph and Nathan,
>>
>> Could you please review the C and C++ FE parts of the patch?
>>
>> https://gcc.gnu.org/pipermail/gcc-patch
On 8/31/22 4:22 AM, Kewen.Lin wrote:
> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>> - tree src_type = TREE_TYPE (src_ptr);
>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>> + ? build_pointer_type (vector_quad_type_node)
>> + :
Hi,
These functions were added in Fortran 2018:
https://gcc.gnu.org/wiki/Fortran2018Status
When it comes to floating-point and IEEE compliance, gfortran fully implements
the 2003 and 2008 standards. In a series of patch, as time permits, I would
like to add all Fortran 2018 features before the
1 - 100 of 139 matches
Mail list logo
