Two things that had poor location info: we weren't giving the TARGET_EXPR
for a lambda object any location, and the call to a conversion function was
getting whatever input_location happened to be.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* call.c (perform_implici
The implicit constexpr patch revealed that our checks for constexpr
constructors that could possibly produce a constant value (which
otherwise are IFNDR) was failing to look at most of the function body.
Fixing that required some library tweaks.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/
Compiling coroutines/pr95736.C with the implicit constexpr patch broke
because is_this_parameter didn't recognize the coroutines proxy for 'this'.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* semantics.c (is_this_parameter): Check DECL_HAS_VALUE_EXPR_P
inste
The implicit constexpr patch revealed that marking the constructor in the
PR70690 testcase as constexpr made the bug reappear, because build_vec_init
assumed that a constexpr default constructor initialized the whole object,
so it was equivalent to value-initialization. But this is no longer true
The implicit constexpr patch revealed that we were doing constant evaluation
of arbitrary expressions in unevaluated contexts, leading to failure when we
tried to evaluate e.g. a call to declval. This is wrong more generally;
only manifestly-constant-evaluated expressions should be evaluated withi
C++20 allows virtual functions to be constexpr. I don't think that calling
through a pointer to a vbase subobject is supposed to work in a constant
expression, since an object with virtual bases can't be constant, but the
call shouldn't ICE.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/
On Sat, Nov 13, 2021 at 10:43 AM Maxim Blinov wrote:
>
> The two target hooks responsible for informing GCC about stack
> parameter alignment are `TARGET_FUNCTION_ARG_BOUNDARY` and
> `TARGET_FUNCTION_ARG_ROUND_BOUNDARY`, which currently only consider
> the tree and machine_mode of a specific given
On Sun, 14 Nov 2021 at 02:07, David Malcolm via Gcc-patches
wrote:
>
> This patch adds two new attributes. The followup patch makes use of
> the attributes in -fanalyzer.
>
> gcc/c-family/ChangeLog:
> * c-attribs.c (attr_noreturn_exclusions): Add
> "returns_zero_on_failure" and "r
The change at r12-4790 should have done the same change for
CRIS as was done for powerpc64*-*-*. (Probably MMIX too but
that may have to wait until the next weekend.)
Committed.
gcc/testsuite:
* gcc.dg/uninit-pred-9_b.c: Correct last adjustment, for CRIS.
---
gcc/testsuite/gcc.dg/uninit
On 15/11/21 12:25 am, Jonathan Wakely wrote:
On Sun, 14 Nov 2021 at 13:31, François Dumont via Libstdc++
wrote:
libstdc++: Unordered containers merge re-use hash code.
When merging between 2 unordered containers with same hasher we can
re-use
the cached hash code if any.
Ins
Add the the `-mlra' command-line option for the VAX target, with the
usual semantics of enabling Local Register Allocation, off by default.
LRA remains unstable with the VAX target, with numerous ICEs throughout
the testsuite and worse code produced overall where successful, however
the presenc
On Mon, Nov 15, 2021 at 9:37 AM Hongtao Liu wrote:
>
> On Sat, Nov 13, 2021 at 2:21 AM H.J. Lu via Gcc-patches
> wrote:
> >
> > On Fri, Nov 12, 2021 at 8:13 AM Jakub Jelinek wrote:
> > >
> > > On Fri, Nov 12, 2021 at 07:55:26AM -0800, H.J. Lu wrote:
> > > > > I have following patch queued for te
On Sat, Nov 13, 2021 at 2:21 AM H.J. Lu via Gcc-patches
wrote:
>
> On Fri, Nov 12, 2021 at 8:13 AM Jakub Jelinek wrote:
> >
> > On Fri, Nov 12, 2021 at 07:55:26AM -0800, H.J. Lu wrote:
> > > > I have following patch queued for testing for this...
> > > >
> > > > 2021-11-12 Jakub Jelinek
> > >
Sorry for taking so long. I hope we can still get this done for GCC 12.
One open question: If we change std::__cxx11::basic_string to
std::string with this feature, should DWARF strings change or not? I.e. should
diagnose_as be conditional on (pp->flags & pp_c_flag_gnu_v3)? If these strings
are
From: Andrew Pinski
For this PR, we have:
if (d_5 < 0)
goto ; [INV]
else
goto ; [INV]
:
v_7 = c_4 | -128;
:
# v_1 = PHI
Which PHI-OPT will try to simplify
"(d_5 < 0) ? (c_4 | -128) : c_4" which is not handled currently.
This adds a few patterns which allows to try to see
From: Andrew Pinski
While writing up some testcases, I noticed some newer testcases
just had "dg-do compile/run" on them with dg-options of either -O1
or -O2. Since it is always better to run them over all optimization
levels I put them in gcc.c-torture/compile or gcc.c-torture/execute.
Committe
On Sun, 14 Nov 2021 at 13:31, François Dumont via Libstdc++
wrote:
>
> libstdc++: Unordered containers merge re-use hash code.
>
> When merging between 2 unordered containers with same hasher we can
> re-use
> the cached hash code if any.
Instead of introducing the _ReuseOrComputeH
Hi,
this patch extends tree-ssa-dse to use modref kill summary to clear
live_bytes. This makes it possible to remove calls that are killed
in parts.
I noticed that DSE duplicates the logic of tree-ssa-alias that is mathing bases
of memory accesses. Here operands_equal_p (base1, base, OEP_ADDRESS
Not committed yet ...
This feature is present in the C++23 draft. The ARM EABI requires that
the type_info::operator== function can be defined out-of-line (and
suggests that should be the default). With this patch, we fail to
conform to that in C++23 mode. I think we might want to move the logic
Hi,
This patch adds tracking of two new flags in ipa-modref: nondeterministic and
calls_interposable. First is set when function does something that is not
guaranteed to be the same if run again (volatile memory access, volatile asm or
external function call). Second is set if function calls some
Hi!
Amend fix for PR88009 to mark all these class components as artificial.
gcc/fortran/ChangeLog:
* class.c (gfc_build_class_symbol, generate_finalization_wrapper,
(gfc_find_derived_vtab, find_intrinsic_vtab): Use stringpool for
names. Mark internal symbols as artificial
From: Philipp Tomsich
The Ventana VT1 core supports quad-issue and instruction fusion.
This implemented TARGET_SCHED_MACRO_FUSION_P to keep fusible sequences
together and adds idiom matcheing for the supported fusion cases.
gcc/ChangeLog:
* config/riscv/riscv.c (enum riscv_fusion_pairs)
From: Philipp Tomsich
The Ventana-VT1 core is compatible with rv64gc and Zb[abcs].
This introduces a placeholder -mcpu=ventana-vt1, so tooling and
scripts don't need to change once full support (pipeline, tuning,
etc.) will become public later.
gcc/ChangeLog:
* config/riscv/riscv-cores.
This series provides support for the Ventana VT1 (a 4-way superscalar
rv64gc_zba_zbb_zbc_zbs core) including support for the supported
instruction fusion patterns.
This includes the addition of the fusion-aware scheduling
infrastructure for RISC-V and implements idiom recognition for the
fusion
David: PING
Le mardi 12 octobre 2021 à 22:09 -0400, Antoni Boucher a écrit :
> David: PING
>
> Le lundi 27 septembre 2021 à 20:53 -0400, Antoni Boucher a écrit :
> > I fixed an issue (it would show an error message when
> > gcc_jit_type_dyncast_function_ptr_type was called on a type
> > different
The MOVC5 machine instruction has `memset' semantics if encoded with a
zero source length[1]:
"4. MOVC5 with a zero source length operand is the preferred way
to fill a block of memory with the fill character."
Use that instruction to implement the `setmemhi' instruction then. Use
the AP r
On Sun, 7 Nov 2021 13:32:34 +0100
Mikael Morin wrote:
> > btw.. Just because it's vagely related.
> > I think f8add009ce300f24b75e9c2e2cc5dd944a020c28 for
> > PR fortran/88009 (ICE in find_intrinsic_vtab, at fortran/class.c:2761)
> > is incomplete in that i think all the internal class helpers sh
> >
> > I think you want get_addr_base_and_unit_offset here. All
> > variable indexed addresses are in separate stmts. That also means
> > you can eventually work with just byte sizes/offsets?
>
> Will do. The access range in modref summary is bit based (since we want
> to disabiguate bitfield
On Sat, 13 Nov 2021 at 13:19, François Dumont via Libstdc++
wrote:
>
> libstdc++: [_GLIBCXX_DEBUG] Remove _Safe_container<>::_M_safe()
>
> Container code cleanup to get rid of _Safe_container<>::_M_safe()
> and just
> _Safe:: calls which use normal inheritance. Also remove several
>
Hi!
On Sun, Nov 14, 2021 at 08:17:41AM -0600, Bill Schmidt wrote:
> On 11/11/21 10:50 AM, Bill Schmidt wrote:
> > On 11/11/21 7:11 AM, Segher Boessenkool wrote:
> >> void f(long x) { __builtin_set_texasr(x); }
> >>
> >> built with -m32 -mpowerpc64 gives (in the expand dump):
> >>
> >> void f (long
Ok, done.
Pushed.
Aldy
On Sun, Nov 14, 2021 at 2:53 PM Martin Liška wrote:
>
> On 11/14/21 14:15, Aldy Hernandez wrote:
> > The code computing ranges in PHIs in the path solver reuses the
> > temporary ssa_global_cache by calling its clear method. Calling it on
> > an empty cache causes us to
On 11/11/21 10:50 AM, Bill Schmidt wrote:
> On 11/11/21 7:11 AM, Segher Boessenkool wrote:
>> void f(long x) { __builtin_set_texasr(x); }
>>
>> built with -m32 -mpowerpc64 gives (in the expand dump):
>>
>> void f (long int x)
>> {
>> long long unsigned int _1;
>>
>> ;; basic block 2, loop dep
On Sat, Nov 13, 2021 at 9:37 PM David Malcolm wrote:
>
> #define __user __attribute__((untrusted))
>
> where my patched GCC treats
> T *
> vs
> T __attribute__((untrusted)) *
> as being different types and thus the C frontend can complain (even without
> -fanalyzer) about e.g.:
This one sou
On 11/14/21 14:15, Aldy Hernandez wrote:
The code computing ranges in PHIs in the path solver reuses the
temporary ssa_global_cache by calling its clear method. Calling it on
an empty cache causes us to call memset with NULL.
[The testcase doesn't fail without the patch. I suppose it needs som
libstdc++: Unordered containers merge re-use hash code.
When merging between 2 unordered containers with same hasher we can
re-use
the cached hash code if any.
Use previous insert iterator as a hint for the next insert in case
of multi container.
* include/bits/
The code computing ranges in PHIs in the path solver reuses the
temporary ssa_global_cache by calling its clear method. Calling it on
an empty cache causes us to call memset with NULL.
[The testcase doesn't fail without the patch. I suppose it needs some
usbsan magic, or to live somewhere else?]
> Tested and pushed to master as obvious.
>
> Martin
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/tsan/free_race.c: Remove unnecessary -ldl.
> * c-c++-common/tsan/free_race2.c: Likewise.
Thank you, I cut&pasted it from the other testcase and forgot to remove
it. Patch is OK.
Ho
Tested and pushed to master as obvious.
Martin
gcc/testsuite/ChangeLog:
* c-c++-common/tsan/free_race.c: Remove unnecessary -ldl.
* c-c++-common/tsan/free_race2.c: Likewise.
---
gcc/testsuite/c-c++-common/tsan/free_race.c | 2 +-
gcc/testsuite/c-c++-common/tsan/free_race2.c |
Hi,
this is variant I comitted. Commonizing the code exposed that I can
drop memory walking when parameter passed is NULL (under assumption of
flag_delete_null_pointer_checks) since it can not point to useful
memory. This was already done in tree-ssa-alias, but not in
tree-ssa-dse. This needed b
> On Linux/x86_64,
>
> 5aa91072e24c1e16a5ec641b48b64c9c9f199f13 is the first bad commit
> commit 5aa91072e24c1e16a5ec641b48b64c9c9f199f13
> Author: Jan Hubicka
> Date: Sat Nov 13 22:25:23 2021 +0100
>
> Implement DSE of dead functions calls storing memory.
>
> caused
>
> FAIL: c-c++-comm
> Most of the time we get away with using the dsymutil that is
> installed with the latest Xcode, however for some cross-compilation
> cases that does not work.
>
> We now have the ability to specify the correct dsymutil to use for
> the toolchain (--with-dsymutil=) and we should use that specifie
Hi,
this patch implements the cleanup suggested by Richard to move code
getting tree op from access_node and stmt to a common place. I also commonized
logic to build ao_ref. While I was on it I also replaced FOR_EACH_* by range
for since they reads better.
Bootstrapped/regtesed x86_64-linux, will
42 matches
Mail list logo
