RISC-V will put those variable on srodata rather than rodata.
gcc/testsuite/ChangeLog:
* gcc.dg/array-quals-1.c: Allow srodata.
---
gcc/testsuite/gcc.dg/array-quals-1.c | 40 ++--
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/gcc/testsuite/gcc.dg
This fixes a premature optimization in the range intersection code
which assumes earlier branches have to be taken, not taking into
account that for symbolic ranges we cannot always compare endpoints.
The fix is to instantiate the compare deemed redundant (which then
fails as undecidable for the te
On Tue, 5 Jan 2021, Joseph Myers wrote:
> On Tue, 5 Jan 2021, Richard Biener wrote:
>
> > would maybe result in a surprising result. One alternative
> > would be to make the attribute have the signedness specified as well
> > (C doesn't accept 'unsigned _Bool' or 'signed _Bool') or
> > simply na
On 1/5/21 3:04 PM, Uros Bizjak wrote:
Hello!
For some reason git commit hook does not record my patches to PRs,
mentioned in the commit message. Some recent examples:
PR 98521:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=951bdbde6ade56eb63af1dfa18777348a8a0d89e
and PR98522:
https://gcc.gnu.o
On Wed, Jan 06, 2021 at 08:50:43AM +0100, Richard Biener wrote:
> > Theoretically we could exclude the range of the no-loc function
> > from the .debug_ranges, then gdb would not even step into the function.
>
> I'd argue we're failing to emit a .endloc at the end of functions
> (rather than issue
The underlying bug was fixed by Marc in July 2019:
2019-07-10 Marc Glisse
* wide-int.h (wi::lshift): Reject negative values for the fastpath.
and Richard B. agreed to the backport onto the 9 branch.
Bootstrapped/regtested and applied on the 9 branch.
2021-01-06 Eric Botcazou
On Jan 4, 2021, Richard Biener wrote:
> Hmm - while the change looks good, doesn't it end up
> calling end_imm_use_stmt_tranverse twice for those
> uses still calling BREAK_FROM_IMM_USE_STMT?
It does. I'd considered introducing a separate method to call
end_imm_use_stmt_traverse if imm is not
> currently there is a problem when debugging a virtual thunk. That is
> a decl with DECL_IGNORED_P. Currently the line information displayed
> in gdb is completely bogus, thus the last line of whatever function
> is immediately before the PC of the thunk.
DECL_IGNORED_P means completely ignored
On 5 Jan 2021, Alan Modra via Binutils told this:
> It doesn't apply due to gcc missing binutils 87279e3cef5b2c5 changes
> too. I could fix that easily enough but I'm going to ask that you
> post a combined patch to bring the gcc repo up to date with any libctf
> changes.
Oops! That never occurr
On 1/6/21 12:49 PM, Eric Botcazou wrote:
>> currently there is a problem when debugging a virtual thunk. That is
>> a decl with DECL_IGNORED_P. Currently the line information displayed
>> in gdb is completely bogus, thus the last line of whatever function
>> is immediately before the PC of the th
This pulls in the toplevel portions of these binutils-gdb commits:
1ff6de031241c59d0ff bfd, ld: add CTF section linking
87279e3cef5b2c54f4a libctf: installable libctf as a shared library
c59e30ed1727135f8ef libctf: new testsuite
* Makefile.def: Sync with binutils-gdb:
(de
On 1/6/21 8:25 AM, Martin Liška wrote:
Anyway, I've got a workaround that I'm going to push.
It's fixed now.
@Ian: Can you please try to push the changes now?
Thanks,
Martin
On 1/6/21 10:53 AM, Martin Liška wrote:
I'll debug that with Jakub.
https://github.com/AdaCore/git-hooks/issues/18
Hi Iain,
>> This patch removes the disabling of libphobos when the Solaris/x86
>> assembler is being used.
>>
>> Since r11-6373, D symbols are now compressed using back references, this
>> helped reduce the average symbol length by a factor of about 3, while
>> the longest symbol shrank from 41613
PING
On 12/4/20 2:30 PM, Martin Liška wrote:
On 12/4/20 10:03 AM, Richard Biener wrote:
Otherwise 0001- looks good to me.
Pushed that to master.
As said I'd like to see opinions
from others on the
driver / backend communication for 0002.
To be honest, we moved back to the original impleme
PING^2
On 12/4/20 2:45 PM, Martin Liška wrote:
PING
May I please ping the patch, it's waiting here for a review
for quite some time.
Thanks,
Martin
On 7/23/20 12:17 PM, Martin Liška wrote:
On 7/21/20 6:07 AM, Fangrui Song wrote:
If the value does not contain any path component separator (e.
On Wed, Jan 06, 2021 at 02:49:13PM +0800, Hongtao Liu wrote:
> ix86_expand_fp_vec_cmp/ix86_expand_int_vec_cmp are used by vec_cmpmn
> for vector comparison to vector mask, but ix86_expand_sse_cmp(which is
> called in upper 2 functions.) may return integer mask whenever integer
> mask is available
Found some build issue on MacOS, will update v2 patches in next few days
On Mon, Jan 4, 2021 at 5:49 PM Kito Cheng wrote:
>
> This patch set introduce new set of architecture extension test macros
> which is accept on riscv-c-api-doc[1] recently.
>
> The motivation of this scheme is have an unify
Hi Harald,
OK for master? Open branches where testcase class_61.f90 exists?
OK for both (as you wrote, this one is really obvious).
Best regards
Thomas
PR98560 is about a case in which the vectoriser initially generates:
mask_1 = a < 0;
mask_2 = mask_1 & ...;
res = VEC_COND_EXPR ;
The vectoriser thus expects res to be calculated using vcond_mask.
However, we later manage to fold mask_2 to mask_1, leaving:
mask_1 = a < 0;
res = VEC_CON
This patch follows on from the previous one for the PR and
makes sure that we can handle == as well as <. Previously
we assumed without checking that IFN_VCONDEQ was available
if IFN_VCOND or IFN_VCONDU wasn't.
The patch also fixes the definition of the IFN_VCOND* functions.
The optabs are conver
"Maciej W. Rozycki" writes:
> On Wed, 16 Dec 2020, Maciej W. Rozycki wrote:
>
>> > CONST_DOUBLE_ATOF ("0", VOIDmode) seems malformed though, and I'd expect
>> > it to assert in REAL_MODE_FORMAT (via the format_helper constructor).
>> > I'm not sure the patch is strictly safer than the status quo.
On 06/01/2021 11:20, Daniel Engel wrote:
> Hi Christophe,
>
> On Wed, Dec 16, 2020, at 9:15 AM, Christophe Lyon wrote:
>> On Wed, 2 Dec 2020 at 04:31, Daniel Engel wrote:
>>>
>>> Hi Christophe,
>>>
>>> On Thu, Nov 26, 2020, at 1:14 AM, Christophe Lyon wrote:
Hi,
On Fri, 13 Nov 202
C++ sized deallocation only came in C++14, so this test wasn't
working properly in C++11, which isn't tested by default. Fixed
thus by constraining the dg-errors to C++14 only.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
PR testsuite/98566
* g++.dg/wa
The Zihintpause extension uses an opcode from the 'fence' opcode range
to add a true hint instruction (i.e. if it is not supported on any
given platform, the 'fence' that is encoded will not enforce any
specific ordering on memory accesses) for entering a low-power state
(e.g. in an idle thread).
In the first testcase below, we incorrectly reject the use of the
protected non-static member A::var0 from C::g() because
check_accessibility_of_qualified_id, at template parse time, determines
that the access doesn't go through 'this'. (This happens because the
dependent base B of C doesn't have
Use __SIZEOF_LONG__ and __SIZEOF_LONG_LONG__ to determine the type of
streamoff at compile time instead of _GLIBCXX_HAVE_INT64_T_LONG and
_GLIBCXX_HAVE_INT64_T_LONG_LONG.
Currently the type of streamoff is determined at libstdc++ configure
time, chosen by the definitions of _GLIBCXX_HAVE_INT64_T_L
On Wed, 6 Jan 2021, David Edelsohn via Gcc-patches wrote:
Currently the type of streamoff is determined at libstdc++ configure
time, chosen by the definitions of _GLIBCXX_HAVE_INT64_T_LONG and
_GLIBCXX_HAVE_INT64_T_LONG_LONG. For a multilib configuration, the
difference is encoded in the differ
On Wed, Jan 6, 2021 at 1:55 PM Marc Glisse wrote:
>
> On Wed, 6 Jan 2021, David Edelsohn via Gcc-patches wrote:
>
> > Currently the type of streamoff is determined at libstdc++ configure
> > time, chosen by the definitions of _GLIBCXX_HAVE_INT64_T_LONG and
> > _GLIBCXX_HAVE_INT64_T_LONG_LONG. For
On Wed, Jan 06, 2021 at 01:38:25PM -0500, David Edelsohn via Gcc-patches wrote:
> Is this an acceptable solution to determine the value at compile-time?
This looks wrong to me. The fact that long is 64-bit doesn't imply that
int64_t as defined by stdint.h must be long, it could be long long too.
On Tue, 5 Jan 2021 at 20:24, Jeff Law wrote:
>
>
> On 1/5/21 10:54 AM, Rainer Orth wrote:
> >
> > I fear I'm a bit lost here myself. I do have a little experience
> > running various builders:
> >
> > * I inherited a Golang one on Solaris/amd64 (based on their own builder
> > infrastructure).
Hi
Where possible (i.e. where that doesn't alter the intent of a test) we
use a suspend_always as the final suspend and a test that the coroutine
was 'done' to check that the state machine had terminated correctly.
Sometimes, filed PRs have 'suspend_never' as the final suspend expression
and tha
On Wed, Jan 6, 2021 at 2:37 PM Jakub Jelinek wrote:
>
> On Wed, Jan 06, 2021 at 01:38:25PM -0500, David Edelsohn via Gcc-patches
> wrote:
> > Is this an acceptable solution to determine the value at compile-time?
>
> This looks wrong to me. The fact that long is 64-bit doesn't imply that
> int64
On Wed, Jan 06, 2021 at 04:20:22PM -0500, David Edelsohn wrote:
> Your response doesn't correspond to the patch nor to what I described.
>
> Nowhere did I say that int64_t must correspond to "long". The patch
> specifically chooses "long" or "long long" based on the
> __SIZEOF_LONG__ *and* __SIZE
The following fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978
The patch was successfully bootstrapped on x86-64.
commit fbf9b2b634e376516cd21d7aa92ef3fd5778aa10 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Wed Jan 6 14:48:53 2021 -0500
[PR97978] LRA: Permit temporary all
On Wed, Jan 6, 2021 at 4:42 PM Jakub Jelinek wrote:
>
> On Wed, Jan 06, 2021 at 04:20:22PM -0500, David Edelsohn wrote:
> > Your response doesn't correspond to the patch nor to what I described.
> >
> > Nowhere did I say that int64_t must correspond to "long". The patch
> > specifically chooses "
On Wed, Jan 06, 2021 at 06:01:23PM -0500, David Edelsohn wrote:
> You continue to not respond to the actual patch and to raise issues
> that don't exist in the actual patch.
We are talking past each other.
Consider an OS that has in stdint.h
typedef long long int64_t;
supports 32-bit and 64-bit m
On Thu, Jan 07, 2021 at 12:39:39AM +0100, Jakub Jelinek wrote:
> We are talking past each other.
>
> Consider an OS that has in stdint.h
> typedef long long int64_t;
And, from grepping INT64_TYPE in config/* config/*/*
it isn't just theoretic, Darwin and OpenBSD behave that way.
Jakub
Thanks for clarifying the issue.
As you implicitly point out, GCC knows the type of INT64 and defines
the macro __INT64_TYPE__ . The revised code can use that directly,
such as:
#if defined(_GLIBCXX_HAVE_INT64_T_LONG) \
|| defined(_GLIBCXX_HAVE_INT64_T_LONG_LONG)
typedef __INT64_TYPE__
--snip--
On Wed, Jan 6, 2021, at 9:05 AM, Richard Earnshaw wrote:
>
> Thanks for working on this, Daniel.
>
> This is clearly stage1 material, so we've got time for a couple of
> iterations to sort things out.
I appreciate your feedback. I had been hoping that with no regressions
this might s
Fix verified using valgrind.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-6512-gcffe6dd2ce358c2cb550c9fb3c57cec65eee1c93.
gcc/analyzer/ChangeLog:
PR analyzer/98564
* engine.cc (exploded_path::feasible_p): Add missing call to
bitmap_
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-6513-gbe6c485b24f2b47ac85380dd2bea025d353f1f91.
gcc/analyzer/ChangeLog:
PR analyzer/97074
* store.cc (binding_cluster::can_merge_p): Add "out_store" param
and pass to calls to binding_clu
Hi Philipp:
Could you add zihintpause to -march parser and guard that on the
pattern and builtin like zifencei[1-2]?
And could you sent a PR to
https://github.com/riscv/riscv-c-api-doc/blob/master/riscv-c-api.md to
mention __builtin_riscv_pause?
Thanks!
[1] march parser change:
https://github.c
I've got a contrary opinion:
Since HINTs are guaranteed to execute as no-ops--e.g., this one is
just a FENCE instruction, which is already a mandatory part of the
base ISA--they don't _need_ to be called out as separate extensions in
the toolchain.
Although there's nothing fundamentally wrong wit
On Wed, Jan 6, 2021 at 10:39 PM Jakub Jelinek wrote:
>
> On Wed, Jan 06, 2021 at 02:49:13PM +0800, Hongtao Liu wrote:
> > ix86_expand_fp_vec_cmp/ix86_expand_int_vec_cmp are used by vec_cmpmn
> > for vector comparison to vector mask, but ix86_expand_sse_cmp(which is
> > called in upper 2 function
Hi Andrew:
It's safe to execute on old machine, but it is still a new extension not
included on baseline ISA, so I still prefer having -march to guard that,
and then we can track that in the ELF attribute to see what extensions and
which version are used in the executable / object files.
On Thu,
On Tue, Dec 29, 2020 at 3:01 PM sunil.k.pandey via Gcc-regression
wrote:
>
> On Linux/x86_64,
>
> 12ae2bc70846a2be8255eaa41322cd1a5a7b7350 is the first bad commit
> commit 12ae2bc70846a2be8255eaa41322cd1a5a7b7350
> Author: Hongyu Wang
> Date: Fri Dec 25 09:25:39 2020 +0800
>
> Fix standard
Kito:
We had originally considered to guard this with a -march, but decided
against it
eventually: this instruction will be (among other cases) used in the
cpu_relax() of
the Linux kernel. For cases like that, we should consider this the
baseline (i.e.
either there's no pause—in which case, the e
On Wed, 6 Jan 2021, Jakub Jelinek wrote:
> On Wed, Jan 06, 2021 at 08:50:43AM +0100, Richard Biener wrote:
> > > Theoretically we could exclude the range of the no-loc function
> > > from the .debug_ranges, then gdb would not even step into the function.
> >
> > I'd argue we're failing to emit a
On Wed, 6 Jan 2021, Richard Sandiford wrote:
> PR98560 is about a case in which the vectoriser initially generates:
>
> mask_1 = a < 0;
> mask_2 = mask_1 & ...;
> res = VEC_COND_EXPR ;
>
> The vectoriser thus expects res to be calculated using vcond_mask.
> However, we later manage to fold
50 matches
Mail list logo
