We've had customer demand for these multilibs. We'd be happy to
maintain this change locally, but I thought I'd contribute the patch,
just in case there's wider interest in them. WDYT?
for gcc/ChangeLog
* config/riscv/t-elf-multilib: Add multilibs for rv64im,
rv64imc, and rv
Hi
Does it update config.sub and config.guess, I know it's already
stage 4, but the config.* stuff update should be harmless things,
and we need this for RISC-V big-endian support, which is already
supported in binutils 2.36.
This imports from:
sha1 6faca61810d335c7837f320733fe8e15a1431fc2
Chan
On Tue, 23 Feb 2021, Kito Cheng wrote:
> Hi
>
> Does it update config.sub and config.guess, I know it's already
> stage 4, but the config.* stuff update should be harmless things,
> and we need this for RISC-V big-endian support, which is already
> supported in binutils 2.36.
>
> This imports fr
Hi!
Because of LWG 467, std::char_traits::lt compares the values
cast to unsigned char rather than char, so even when char is signed
we get unsigned comparision. std::char_traits::compare uses
__builtin_memcmp and that works the same, but during constexpr evaluation
we were calling __gnu_cxx::cha
Hi!
fold_read_from_constant_string and expand_expr_real_1 have code to optimize
constant reads from string (tree vs. rtl).
If the STRING_CST array type has zero low bound, index is fold converted to
sizetype and so the compare_tree_int works fine, but if it has some other
low bound, it calls size_
On Tue, Feb 23, 2021 at 4:48 AM acsawdey--- via Gcc-patches
wrote:
>
> From: Aaron Sawdey
>
> This patch implements a RTL pass that looks for pc-relative loads of the
> address of an external variable using the PCREL_GOT relocation and a
> single load or store that uses that external address.
>
>
On Tue, 23 Feb 2021, Jakub Jelinek wrote:
> Hi!
>
> fold_read_from_constant_string and expand_expr_real_1 have code to optimize
> constant reads from string (tree vs. rtl).
> If the STRING_CST array type has zero low bound, index is fold converted to
> sizetype and so the compare_tree_int works f
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565350.html
patch, P2 PR99085 ice-on-valid-code fix in fixup_partitions.
Thanks
Jakub
This is a backport of adding cost tables for A64FX.
2021-02-23 Qian Jianhua
gcc/ChangeLog:
* config/aarch64/aarch64-cost-tables.h (a64fx_extra_costs): New.
* config/aarch64/aarch64.c (a64fx_addrcost_table): New.
(a64fx_regmove_cost, a64fx_vector_cost): New.
(a64f
> For MIPS N64 and N32:
> add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
> add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
>
> gcc/ada/ChangeLog:
> PR ada/98996
> * Makefile.rtl: add 128Bit operation file to MIPS
> N64 and N32 (LIBGNAT_TARGET_PAIRS, EXTRA_GNATRTL_
Hello.
The patch is about confusion that brings ICF when it merged 2 variables
with different alignments (when ASAN is used).
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR sanitizer/99168
* ipa-ic
Hi Alexandre:
We've added a new configure option to allow you to override that
without changing source code.
For example:
--with-multilib-generator="rv32i-ilp32--c;rv32im-ilp32--c;rv32iac-ilp32--;rv32imac-ilp32--;rv32imafc-ilp32f-rv32imafdc-;rv64im-lp64--;rv64imc-lp64--;rv64imfc-lp64f--;rv64imac-
Committed, thanks!
On Tue, Feb 23, 2021 at 4:18 PM Richard Biener wrote:
>
> On Tue, 23 Feb 2021, Kito Cheng wrote:
>
> > Hi
> >
> > Does it update config.sub and config.guess, I know it's already
> > stage 4, but the config.* stuff update should be harmless things,
> > and we need this for RISC-
Arnaud Charlet 于2021年2月23日周二 下午5:07写道：
>
> > For MIPS N64 and N32:
> > add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
> > add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
> >
> > gcc/ada/ChangeLog:
> > PR ada/98996
> > * Makefile.rtl: add 128Bit operation file to MIPS
>
> > > For MIPS N64 and N32:
> > > add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
> > > add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
> > >
> > > gcc/ada/ChangeLog:
> > > PR ada/98996
> > > * Makefile.rtl: add 128Bit operation file to MIPS
> > > N64 and N32 (LIBGN
On Tue, Feb 23, 2021 at 8:48 AM Richard Biener wrote:
>
> On Mon, 22 Feb 2021, Uros Bizjak wrote:
>
> > The intention of HONOR_REG_ALLOC_ORDER is to ensure that IRA allocates
> > registers in the order given by REG_ALLOC_ORDER. However in
> > ira_better_spill_reload_regno_p, there is still a plac
Arnaud Charlet 于2021年2月23日周二 下午5:33写道：
>
> > > > For MIPS N64 and N32:
> > > > add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
> > > > add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
> > > >
> > > > gcc/ada/ChangeLog:
> > > > PR ada/98996
> > > > * Makefile.rtl: add 128B
It is found by ada s-pack96.adb ftbfs, due to 96bit load: 96 = 64 + 32.
While the 32bit pair of l r is mark as SUBREG, so they are
not in SImode, make it fail to find suitable insn.
gcc/ChangeLog:
PR target/98996
* config/mips/mips.c (mips_expand_ext_as_unaligned_load):
If
For MIPS N64 and N32:
add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
gcc/ada/ChangeLog:
PR ada/98996
* Makefile.rtl:
add 128Bit operation file for MIPS N64 and N32 to
LIBGNAT_TARGET_PAIRS and EXTRA_GNA
For MIPSr6, we may wish to use compact-branches only.
Currently, we have to use `always' option, while it is mark as conflict
with pre-R6.
cc1: error: unsupported combination: ‘mips32r2’ -mcompact-branches=always
Just ignore -mcompact-branches=always for pre-R6.
This patch also defines
__mip
For R6+ target, it allows to configure gcc to use compact branches only.
gcc/ChangeLog:
* config.gcc: add -with-compact-branches=policy build option.
* doc/install.texi: Likewise.
---
gcc/config.gcc | 12 +++-
gcc/doc/install.texi | 19 +++
2 files ch
The patch is LLVM backport.
Applied to master.
/home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_value.cpp:77:25: runtime
error: left shift of 0xfffb by 96 places cannot be
represented in type '__int128'
#0 0x7754edfe in __ubsan::Value::getSIntValue() c
On Feb 23, 2021, Kito Cheng wrote:
> We've added a new configure option to allow you to override that
> without changing source code.
Ah, nice, thanks! I'll add a note on our internal patch to switch to
that when we switch to GCC 11.
I take your response as confirming my expectation that the
>>> I did generate the ChangeLog by contrib/mklog.py by:
>>> contrib/mklog.py 0002_MY_PATCH.patch
>>> and get an empty ChangeLog template.
>>>
>>> gcc/ada/ChangeLog:
>>>
>>>* ChangeLog:
>>>* Makefile.rtl:
>>>
>>> So, should I keep it as is?
>>
>> The ChangeLog file is gene
Hi All,
This is a straightforward fix that had the side-effect of uncovering an
invalid testcase, class_assign_4.f90. I had worked up a new test, based on
the one in the PR, and found that another brand determined that it is
invalid according to F2018, C15100.
I was unable to find a way to use a
On Tue, Feb 23, 2021 at 10:42 AM Martin Liška wrote:
>
> Hello.
>
> The patch is about confusion that brings ICF when it merged 2 variables
> with different alignments (when ASAN is used).
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
Can't
Hi Paul,
On 23.02.21 12:52, Paul Richard Thomas via Gcc-patches wrote:
This is a straightforward fix that had the side-effect of uncovering an
invalid testcase, class_assign_4.f90. I had worked up a new test, based on
the one in the PR, and found that another brand determined that it is
invalid
Hi Jason,
Jason Merrill wrote:
> On 2/22/21 3:59 PM, Iain Sandoe wrote:
>> * I was not able to see any way in which the instantiation process
>> could be made to bail in this case and re-try for non-constexpr.
>
> Many of the other places that set cp_function_chain->invalid_constexpr
> cond
This patch reimplements std::chrono::year_month_day::_S_from_days() which
retrieves a date from the number of elapsed days since 1970/01/01. The new
implementation is based on Proposition 6.3 of Neri and Schneider, "Euclidean
Affine Functions and Applications to Calendar Algorithms" available at
h
This patch reimplements std::chrono::year_month_day::_M_days_since_epoch()
which calculates the number of elapsed days since 1970/01/01. The new
implementation is based on Proposition 6.2 of Neri and Schneider, "Euclidean
Affine Functions and Applications to Calendar Algorithms" available at
https
This patch reimplements std::chrono::year::is_leap(). Leap year check is
ubiquitously implemented (including here) as:
y % 4 == 0 && (y % 100 != 0 || y % 400 == 0).
The rationale being that testing divisibility by 4 first implies an earlier
return for 75% of the cases, therefore, avoiding th
This patch reimplements std::chrono::year_month_day_last:day() which yields the
last day of a particular month. The current implementation uses a look-up table
implemented as an unsigned[12] array. The new implementation instead
is based on
the fact that a month m in [1, 12], except for m == 2 (F
On 2/23/21 12:56 PM, Richard Biener wrote:
Can't we fix the asan runtime? Does the same issue happen when merging
two comdat with different alignment and LTO?
All right, there's a detail explanation what happens.
Let's consider the following example:
struct my_struct
{
unsigned long volatil
On Tue, Feb 23, 2021 at 3:22 PM Martin Liška wrote:
>
> On 2/23/21 12:56 PM, Richard Biener wrote:
> > Can't we fix the asan runtime? Does the same issue happen when merging
> > two comdat with different alignment and LTO?
>
> All right, there's a detail explanation what happens.
> Let's consider
On 2/23/21 3:32 PM, Richard Biener wrote:
On Tue, Feb 23, 2021 at 3:22 PM Martin Liška wrote:
On 2/23/21 12:56 PM, Richard Biener wrote:
Can't we fix the asan runtime? Does the same issue happen when merging
two comdat with different alignment and LTO?
All right, there's a detail explanati
On Tue, Feb 23, 2021 at 3:41 PM Martin Liška wrote:
>
> On 2/23/21 3:32 PM, Richard Biener wrote:
> > On Tue, Feb 23, 2021 at 3:22 PM Martin Liška wrote:
> >>
> >> On 2/23/21 12:56 PM, Richard Biener wrote:
> >>> Can't we fix the asan runtime? Does the same issue happen when merging
> >>> two co
On 2/23/21 3:55 PM, Richard Biener wrote:
On Tue, Feb 23, 2021 at 3:41 PM Martin Liška wrote:
On 2/23/21 3:32 PM, Richard Biener wrote:
On Tue, Feb 23, 2021 at 3:22 PM Martin Liška wrote:
On 2/23/21 12:56 PM, Richard Biener wrote:
Can't we fix the asan runtime? Does the same issue happen
Hi, Richard,
> On Feb 9, 2021, at 11:36 AM, Richard Biener wrote:
>
> On Tue, 9 Feb 2021, Qing Zhao wrote:
>>
>> Yes, I understand that without a working testing case to repeat the error,
>> it’s very hard to debug and fix the issue.
>>
>> However, providing a testing case for this bug is re
Unnamed types with a typedef name for linkage were always troublesome in
modules. This is the underlying cause of that trouble -- we were
creating incorrect type structures. Classes have an implicit
self-reference, and we created that for unnamed classes too. It turns
out we make use of th
libstdc++-v3/
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Upd
[CC Jason for any further comments/clarification]
On 2/9/21 10:49 AM, Martin Sebor wrote:
On 2/8/21 4:11 PM, Jeff Law wrote:
On 2/8/21 3:44 PM, Martin Sebor wrote:
On 2/8/21 3:26 PM, Jeff Law wrote:
On 2/8/21 2:56 PM, Martin Sebor wrote:
On 2/8/21 12:59 PM, Jeff Law wrote:
On 1/19/21
On Mon, 22 Feb 2021, Patrick Palka wrote:
> This makes the hexadecimal section of the long double std::to_chars
> testcase more robust by avoiding false-negative FAILs due to printf
> using a different leading hex digit than us, and by additionally
> verifying the correctness of the hexadecimal fo
As I mentioned in the patch for adding _Float128 <-> Decimal conversions, there
are two test cases that fail if you configure the compiler to use IEEE 128-bit
long double or 64-bit long double. That is because these tests are explicitly
testing that the long double is a pair of doubles (i.e. IBM 1
On Fri, Jan 15, 2021 at 06:16:43PM +, Joseph Myers wrote:
> On Thu, 14 Jan 2021, Michael Meissner via Gcc-patches wrote:
>
> > +return [check_runtime_nocache ppc_long_double_ovveride_ibm128 {
>
> > +return [check_runtime_nocache ppc_long_double_ovveride_ieee128 {
>
> > +return [c
[PATCH 1/3] Add long double target-supports on PowerPC.
This patch add several more selections to target-supports.exp:
* 3 selections for the current long double format;
* 3 selections if we can change the long double format to a particular
value.
* 3 functions to return
[PATCH 2/3] Force long double to be IBM 128-bit on PowerPC test, PR
target/70117.
This patch fixes the pr70117 test to use IBM 128-bit long double.
I have run tests on a little endian power9 system with 3 compilers. There
were no regressions with these patches, and the two tests in the followin
[PATCH 3/3] Force IBM long double for conversion test on PowerPC.
The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use
the IBM 128-bit extended double format. In particular, some of the tests
expect an infinity to be created if decimal values that are converted that are
As discussed in the PR, the Makefile fragment lacks a double '$' to
get the return-code from GCC invocation, resulting is CMSE support
missing from multilibs.
I checked that the simple patch proposed in the PR fixes the problem.
2021-02-23 Christophe Lyon
Hau Hsu
PR target/99157
libgcc/
* c
Hi Tobias,
→ Can you add also a testcase that which triggers the error message you
> see in the unpatched class_assign_4.f90?
> > I was unable to find a way to use a typebound operator with a polymorphic
> > result
> I am confused – the attach testcase does seem to work fine with current
> GCC.
Hi Paul,
On 23.02.21 18:39, Paul Richard Thomas via Fortran wrote:
Can you elaborate?
The polymorphic result must be allocatable or pointer for the dynamic type
to be transmitted. This means that the function cannot be elemental. If the
result of the non-elemental function is an array, gfc resp
Hi Richi,
The attached testcase shows a bug where two nodes end up with the same pointer.
During the loop that analyzes all the instances
in optimize_load_redistribution_1 we do
if (value)
{
SLP_TREE_REF_COUNT (value)++;
SLP_TREE_CHILDREN (root)[i] = value;
Adding attribute access to declarations of functions that take
VLA arguments relies on the front end adding attribute "arg spec"
to each VLA parameter. Like the VLA bounds in attribute access,
the same VLA bounds in attribute "arg spec" can cause trouble
during LTO streaming which expects front e
On Tue, Feb 23, 2021 at 2:17 AM Alexandre Oliva wrote:
> I take your response as confirming my expectation that the defaults are
> to remain unchanged for now, and I will thus proceed under this
> assumption.
>
If we add default multilibs for you, then to be fair, we need to add
default multilib
On 2/23/21 8:20 AM, Iain Sandoe wrote:
Hi Jason,
Jason Merrill wrote:
On 2/22/21 3:59 PM, Iain Sandoe wrote:
* I was not able to see any way in which the instantiation process
could be made to bail in this case and re-try for non-constexpr.
Many of the other places that set cp_functio
On 2/22/21 7:03 PM, Jason Merrill wrote:
On 2/22/21 8:00 PM, Martin Sebor wrote:
On 2/22/21 4:08 PM, Jason Merrill wrote:
On 2/13/21 7:31 PM, Martin Sebor wrote:
The test case in PR 99074 invokes dynamic_cast with the this pointer
in a non-static member function called on a null pointer. The
On 19/02/2021 7:12 pm, Kwok Cheung Yeung wrote:
I have included the current state of my patch. All task-detach-* tests pass when
executed without offloading or with offloading to GCN, but with offloading to
Nvidia, task-detach-6.* hangs consistently but everything else passes (probably
because
Dear all,
under certain circumstances a call to MATMUL for rank-2 times rank-1
would invoke a highly tuned rank-2 times rank-2 algorithm which could
lead to invalid reads and writes. The solution is to check the rank
of the second argument to matmul and fall back to a regular algorithm
for rank-1
On 2/23/21 11:02 AM, Martin Sebor wrote:
[CC Jason for any further comments/clarification]
On 2/9/21 10:49 AM, Martin Sebor wrote:
On 2/8/21 4:11 PM, Jeff Law wrote:
On 2/8/21 3:44 PM, Martin Sebor wrote:
On 2/8/21 3:26 PM, Jeff Law wrote:
On 2/8/21 2:56 PM, Martin Sebor wrote:
On 2/8/2
On Tue, Feb 23, 2021 at 09:43:51PM +, Kwok Cheung Yeung wrote:
> On 19/02/2021 7:12 pm, Kwok Cheung Yeung wrote:
> > I have included the current state of my patch. All task-detach-* tests
> > pass when executed without offloading or with offloading to GCN, but
> > with offloading to Nvidia, tas
From: Thomas Rodgers
* This revises the previous version to fix std::__condvar::wait_until() usage.
This is a substantial rewrite of the atomic wait/notify (and timed wait
counterparts) implementation.
The previous __platform_wait looped on EINTR however this behavior is
not required by the sta
On 2/5/21 12:28 PM, Segher Boessenkool wrote:
> On Fri, Feb 05, 2021 at 04:11:30PM +0100, Florian Weimer wrote:
>> * Peter Bergner:
>>> On 2/5/21 4:28 AM, Florian Weimer wrote:
Maybe add a check that the compatibility builtins are flagged as
availble using __has_builtin?
>>>
>>> Do you me
Rename next_insn_prefixed_p for improved clarity.
Bootstrap/regtest on powerpc64le with no new regressions. Ok for trunk?
-Pat
2021-02-22 Pat Haugen
gcc/
* config/rs6000/rs6000.c (next_insn_prefixed_p): Rename.
(rs6000_final_prescan_insn): Adjust.
(rs6000_asm_output_
I like the idea.
On Dienstag, 23. Februar 2021 14:25:10 CET Cassio Neri via Libstdc++ wrote:
> ((__m ^ (__m >> 3)) & 1) | 30
Note that you can drop the `& 1` part. 30 in binary is 0b0. ORing with a
value in [0, 0b01101] will only toggle the last bit.
--
Hi!
On Tue, Feb 23, 2021 at 12:05:34AM +, Neven Sajko wrote:
> On Mon, 22 Feb 2021 at 16:30, Segher Boessenkool
> wrote:
> > On Mon, Feb 15, 2021 at 11:22:52PM +, Neven Sajko via Gcc-patches wrote:
> > > There is a long-standing, but undocumented GCC inline assembly feature
> > > that's p
Hi!
On Tue, Feb 23, 2021 at 04:00:42PM -0600, Peter Bergner wrote:
> (mma_assemble_pair): Add compatibility built-in.
s/Add/New/ is better (it makes clear you do not add something to the
(already existing) mma_assemble_pair, that it is in fact new here).
> (mma_init_builtins): USE VSX
Hi!
On Tue, Feb 23, 2021 at 04:12:42PM -0600, Pat Haugen wrote:
> gcc/
> * config/rs6000/rs6000.c (next_insn_prefixed_p): Rename.
> (rs6000_final_prescan_insn): Adjust.
> (rs6000_asm_output_opcode): Likewise.
Excellent. Okay for trunk and 10. Thank you!
Segher
On 2/23/21 2:52 PM, Jason Merrill wrote:
On 2/23/21 11:02 AM, Martin Sebor wrote:
[CC Jason for any further comments/clarification]
On 2/9/21 10:49 AM, Martin Sebor wrote:
On 2/8/21 4:11 PM, Jeff Law wrote:
On 2/8/21 3:44 PM, Martin Sebor wrote:
On 2/8/21 3:26 PM, Jeff Law wrote:
On 2/8
On 2/23/21 4:53 PM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Feb 23, 2021 at 04:00:42PM -0600, Peter Bergner wrote:
>> (mma_assemble_pair): Add compatibility built-in.
> s/Add/New/ is better (it makes clear you do not add something to the
> (already existing) mma_assemble_pair, that it is
vec_insert defines the element argument type to be signed int by ELFv2
ABI, When expanding a vector with a variable rtx, convert the rtx type
SImode.
gcc/ChangeLog:
2021-02-24 Xionghu Luo
PR target/98914
* config/rs6000/rs6000.c (rs6000_expand_vector_set): Convert
elt_
On Tue, 23 Feb 2021, Qing Zhao wrote:
> Hi, Richard,
>
> > On Feb 9, 2021, at 11:36 AM, Richard Biener wrote:
> >
> > On Tue, 9 Feb 2021, Qing Zhao wrote:
> >>
> >> Yes, I understand that without a working testing case to repeat the error,
> >> it’s very hard to debug and fix the issue.
> >>
Hi Marcus:
I just spend some time on those two testcase, I think this those two
testcase could just skip in big-endinan.
> FAIL: gcc.target/riscv/shift-and-1.c scan-assembler-not andi
> FAIL: gcc.target/riscv/shift-and-2.c scan-assembler-not andi
However seems like rv32be has still has some stra
71 matches
Mail list logo
