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
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
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
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
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
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
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
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:
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
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
--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
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__
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
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
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
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
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*
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
>
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
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).
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 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.
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
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
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
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).
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
*
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
"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.
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
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 =
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
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
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
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
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
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
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
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
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:
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
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
> 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
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
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 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
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:
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
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
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
50 matches
Mail list logo
