On Thu, Mar 21, 2019 at 8:24 PM Richard Biener
wrote:
>
> On Mon, Dec 18, 2017 at 1:37 PM Richard Biener
> wrote:
> >
> > On Fri, Dec 15, 2017 at 7:39 PM, Bin.Cheng wrote:
> > > On Fri, Dec 15, 2017 at 1:19 PM, Richard Biener
> > > wrote:
> > >> On Fri, Dec 15, 2017 at 1:35 PM, Bin.Cheng wrote
Ping.
On Fri, 22 Feb 2019 18:11:44 -0700
Kevin Buettner wrote:
> For debugging purposes, I need to be able to find the master thread
> in the thread pool.
>
> Without this patch, I see over 20 failures in the tests that I've
> written for GDB.
>
> I've also tested this in the gcc tree - no reg
On 3/21/19 5:05 PM, Martin Sebor wrote:
On 3/21/19 4:25 PM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 04:19:37PM -0600, Martin Sebor wrote:
Say that the argument is either a type or an expression that is
either an identifier (for C++ id-expression) to cover 1) and
a postfix expression with .
On Thu, Mar 21, 2019 at 04:15:09PM -0500, Bill Schmidt wrote:
> It was recently pointed out that there's a pasto in mmintrin.h for the
> _mm_sub_pi32 function, so that it performs an addition rather than a
> subtraction. This won't do.
>
> This patch corrects the problem, and adds a test case to
On 21/03/19 23:56 +, Jonathan Wakely wrote:
On 21/03/19 22:32 +, Jonathan Wakely wrote:
On 21/03/19 15:19 -0700, Thomas Rodgers wrote:
Fixed up change log.
Thanks, this version seems to have addressed everything.
As this was one of our big ticket features for stage 1 (but was
delaye
On 21/03/19 22:32 +, Jonathan Wakely wrote:
On 21/03/19 15:19 -0700, Thomas Rodgers wrote:
Fixed up change log.
Thanks, this version seems to have addressed everything.
As this was one of our big ticket features for stage 1 (but was
delayed due to the necessary legal steps that Intel too
On Thu, Mar 21, 2019 at 07:27:03PM -0400, Jason Merrill wrote:
> On 3/15/19 4:07 PM, Jakub Jelinek wrote:
> > +/* Number of cxx_eval_constant_expression calls (except skipped ones,
> > + on simple constants or location wrappers) encountered during current
> > + cxx_eval_outermost_constant_expr
On 3/21/19 4:55 PM, Marek Polacek wrote:
On Thu, Mar 21, 2019 at 04:13:29PM -0400, Jason Merrill wrote:
On 3/16/19 4:53 PM, Marek Polacek wrote:
Here we have code like
struct X { operator const int(); };
int&& rri = X();
which I think is invalid, because [dcl.init.ref] says that if ty
On 3/21/19 6:55 PM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 05:03:11PM -0400, Jason Merrill wrote:
--- gcc/cp/semantics.c.jj 2019-03-14 09:14:16.718012031 +0100
+++ gcc/cp/semantics.c 2019-03-15 16:53:14.270384477 +0100
@@ -2135,6 +2135,17 @@ finish_qualified_id_expr (tree qualifyin
On 3/15/19 4:07 PM, Jakub Jelinek wrote:
+/* Number of cxx_eval_constant_expression calls (except skipped ones,
+ on simple constants or location wrappers) encountered during current
+ cxx_eval_outermost_constant_expr call. */
+static HOST_WIDE_INT constexpr_ops_count;
Hmm, a global static
On 3/21/19 4:25 PM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 04:19:37PM -0600, Martin Sebor wrote:
Say that the argument is either a type or an expression that is
either an identifier (for C++ id-expression) to cover 1) and
a postfix expression with . or -> operator (to cover COMPONENT_REF)?
On Thu, Mar 21, 2019 at 05:03:11PM -0400, Jason Merrill wrote:
> > --- gcc/cp/semantics.c.jj 2019-03-14 09:14:16.718012031 +0100
> > +++ gcc/cp/semantics.c 2019-03-15 16:53:14.270384477 +0100
> > @@ -2135,6 +2135,17 @@ finish_qualified_id_expr (tree qualifyin
> > expr = build_qualified_n
On 21/03/19 15:19 -0700, Thomas Rodgers wrote:
Fixed up change log.
Thanks, this version seems to have addressed everything.
As this was one of our big ticket features for stage 1 (but was
delayed due to the necessary legal steps that Intel took to kindly
transfer this to the LLVM project) we
On Thu, Mar 21, 2019 at 04:19:37PM -0600, Martin Sebor wrote:
> > Say that the argument is either a type or an expression that is
> > either an identifier (for C++ id-expression) to cover 1) and
> > a postfix expression with . or -> operator (to cover COMPONENT_REF)?
>
> That doesn't look easy to
Fixed up change log.
20190321-1-pstl-integration.patch.bz2
Description: pstl integration patch
Thomas Rodgers writes:
> Jonathan Wakely writes:
>
>> On 20/03/19 14:05 -0700, Thomas Rodgers wrote:
>>
>>>
>>>Fixed a failing test.
>>
>> Thanks. A
On 3/21/19 4:13 PM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 03:59:55PM -0600, Martin Sebor wrote:
1) either an identifier naming a function or variable, or
2) some other expression like a member reference via . or ->,
an array subscript, or the indirection expression *.
But GCC disting
On Thu, Mar 21, 2019 at 03:59:55PM -0600, Martin Sebor wrote:
> 1) either an identifier naming a function or variable, or
> 2) some other expression like a member reference via . or ->,
>an array subscript, or the indirection expression *.
>
> But GCC distinguishes three kinds of arguments:
>
20190321-pstl-integration.patch.bz2
Description: pstl integration patch
Jonathan Wakely writes:
> On 20/03/19 14:05 -0700, Thomas Rodgers wrote:
>
>>
>>Fixed a failing test.
>
> Thanks. Apart from the changelog issue I mentioned on IRC, the only
> other required
On 3/19/19 9:33 PM, Jeff Law wrote:
On 3/19/19 8:22 PM, Joseph Myers wrote:
On Tue, 19 Mar 2019, Jeff Law wrote:
I'll note that our documentation clearly states that attributes can be
applied to functions, variables, labels, enums, statements and types.
A key thing here is that they can be a
Hi,
It was recently pointed out that there's a pasto in mmintrin.h for the
_mm_sub_pi32 function, so that it performs an addition rather than a
subtraction. This won't do.
This patch corrects the problem, and adds a test case to verify it.
Installed and tested on powerpc64le-unknown-linux-gnu wi
On Thu, Mar 21, 2019 at 09:04:21PM +0100, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 20 Mar 2019 11:07:31 +0100, I wrote:
> > On Fri, 26 Aug 2016 08:16:43 -0700, Cesar Philippidis
> > wrote:
> > > While working on [...], I noticed
> >
> > If only all such issues would end up in their own PRs, ins
On 3/15/19 4:53 PM, Jakub Jelinek wrote:
Hi!
As the testcase shows, we replace TLS vars that need initialization
in finish_id_expression_1 and in tsubst_copy_and_build of a VAR_DECL
with a _ZTW* call, but miss it in other cases where finish_id_expression
is not actually called. In particular bu
On Thu, Mar 21, 2019 at 04:13:29PM -0400, Jason Merrill wrote:
> On 3/16/19 4:53 PM, Marek Polacek wrote:
> > Here we have code like
> >
> >struct X { operator const int(); };
> >int&& rri = X();
> >
> > which I think is invalid, because [dcl.init.ref] says that if types T1 and
> > T2
>
This is a crash in digest_init_r -- we encounter
/* "If T is a class type and the initializer list has a single
element of type cv U, where U is T or a class derived from T,
the object is initialized from that element." */
if (flag_checking
&& cxx_dialect >= cxx11
&& BRA
Hi Thomas,
Are there any further questions, or am I good to commit my patch as
posted?
Problem is, I have never looked into module writing / reading in any
detail, so it will take a few days for me to get up to speed so I can
really review your patch.
If, in the meantime, maybe somebody else
Hi!
On Fri, 26 Aug 2016 08:16:43 -0700, Cesar Philippidis
wrote:
> This patch
(..., variants of which got re-submitted a few times, later on...)
> teaches the fortran FE how to verify that there is sufficient
> parallelism when calling acc routines inside acc loop. E.g. the fortran
> FE will n
On 3/16/19 4:53 PM, Marek Polacek wrote:
Here we have code like
struct X { operator const int(); };
int&& rri = X();
which I think is invalid, because [dcl.init.ref] says that if types T1 and T2
are reference-related, no qualifiers can be dropped, and if the reference is an
rvalue referen
Hi!
On Wed, 20 Mar 2019 11:07:31 +0100, I wrote:
> On Fri, 26 Aug 2016 08:16:43 -0700, Cesar Philippidis
> wrote:
> > While working on [...], I noticed
>
> If only all such issues would end up in their own PRs, instead of mixing
> them with other changes...
>
> > that the fortran FE wasn't per
On 3/19/19 11:45 AM, Marek Polacek wrote:
On Thu, Mar 14, 2019 at 04:22:41PM -0400, Jason Merrill wrote:
On 3/7/19 4:52 PM, Marek Polacek wrote:
This was one of those PRs where the more you poke, the more ICEs turn up.
This patch fixes the ones I could find. The original problem was that
maybe
Hi!
On Thu, 28 Feb 2019 21:37:21 +0100, I wrote:
> On Mon, 15 Aug 2016 18:54:49 -0700, Cesar Philippidis
> wrote:
> > [...]
> >
> > Note that besides for checking for multiple acc routine directives, this
> > patch also handles the case where the optional name argument in 'acc
> > routine (NAME
Hi!
On Wed, 13 Mar 2019 18:50:38 +0100, I wrote:
> On Thu, 28 Feb 2019 22:17:01 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 28, 2019 at 10:12:00PM +0100, Thomas Schwinge wrote:
> > > On Wed, 15 Jun 2016 20:12:15 -0700, Cesar Philippidis
> > > wrote:
> > > The code changes now are actually very
Hi!
On Mon, 15 Sep 2014 18:13:47 +0200, Jakub Jelinek wrote:
> --- gcc/testsuite/gfortran.dg/dg.exp.jj 2014-07-04 10:20:35.0
> +0200
> +++ gcc/testsuite/gfortran.dg/dg.exp 2014-09-15 17:05:04.038126245 +0200
> +proc dg-compile-aux-modules { args } {
> +global gfortran_test_pa
Hi!
On Thu, 28 Feb 2019 18:02:32 +0100, Thomas Schwinge
wrote:
> On Fri, 02 Jan 2015 12:28:10 +0100, Tobias Burnus wrote:
> > [...]
> >
> > I additionally propagated the dg-compile-aux-modules support to caf.dg
>
> That got committed in r219143:
>
> > --- a/gcc/testsuite/gfortran.dg/coarray
Hi!
On Thu, 28 Feb 2019 20:22:08 +0100, I wrote:
> While looking for something else -- isn't that always how it happens ;-)
> -- I noticed one thing here:
>
> On Wed, 25 Jun 2014 01:41:02 +0200, FX wrote:
> > I’ll wait a few more days to commit, so others can comment/review and I am
> > sure to
On 3/20/19 6:06 PM, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
On Mar 20, 2019, Marek Polacek wrote:
This test fails with
On 3/21/19 9:43 AM, Richard Biener wrote:
On Thu, 21 Mar 2019, Richard Biener wrote:
This also avoids the ICE in PR89779 but IMHO is not a real fix.
Still it restores a previously active check against released SSA names
which now have error_mark_node type rather than NULL. The new way
opens
On 3/21/19 1:48 PM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 10:25:25AM -0400, Jason Merrill wrote:
Attached (so far without changelog, selftest additions and only tested with
make -j32 -k check-c++-all RUNTESTFLAGS="dg.exp='pr89767.C *lambda* *desig*'"
) is
1) hash_{table,set} implementati
On Thu, Mar 21, 2019 at 10:25:25AM -0400, Jason Merrill wrote:
> > Attached (so far without changelog, selftest additions and only tested with
> > make -j32 -k check-c++-all RUNTESTFLAGS="dg.exp='pr89767.C *lambda*
> > *desig*'"
> > ) is
> > 1) hash_{table,set} implementation for lazy allocation
This Go frontend patch by Cherry Zhang fixes the type debug dump code
to add a newline after the function receiver type. Bootstrapped and
ran Go tests on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
Hello, I have found a minor diagnostic issue.
Since r262910 we got a little odd error messages in cases like this:
$ gcc -flto-compression-level=2-O2 -c empty.c
gcc: error: argument to '-flto-compression-level=' is not between 0 and 9
$ g++ -fabi-version=2-O2 -c empty.cpp
cc1plus: error: '-fabi-ve
On 3/21/19 5:03 AM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 09:28:06AM +0100, Richard Biener wrote:
Well, this is surely more costly in that it allocates both the hash_table
structure and the memory pointed by it from GC.
You could use
char constexpr_fundef_table[sizeof(hash-table)];
IS 29124 8.2 [sf.mathh] says that should add the names of the
special functions to the global namespace. However, C++17 Annex D
[depr.c.headers] excludes those functions explicitly, so they should not
be placed in the global namespace unconditionally for C++17.
Only add them to the global names
On Thu, 21 Mar 2019, Richard Biener wrote:
>
> This also avoids the ICE in PR89779 but IMHO is not a real fix.
>
> Still it restores a previously active check against released SSA names
> which now have error_mark_node type rather than NULL. The new way
> opens up consolidation so I've adjusted
On Thu, Mar 21, 2019 at 1:38 PM Otto, Thomas wrote:
>
> > > > > > > "ggc_collect() discarding/reusing remap_debug_filename() output,
> > > > > > > thus producing invalid objects"
> > > > > >
> > > > > > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd ()
> > > > > > result survives.
On Thu, Mar 21, 2019 at 2:04 PM Richard Sandiford
wrote:
>
> The handling of -Wstrict-aliasing=1 applied COMPLETE_TYPE_P to the
> pointer type rather than the pointer target, so missed the warnings
> for "struct incomplete" in the testcase.
>
> I couldn't find any existing C tests for -Wstrict-ali
The handling of -Wstrict-aliasing=1 applied COMPLETE_TYPE_P to the
pointer type rather than the pointer target, so missed the warnings
for "struct incomplete" in the testcase.
I couldn't find any existing C tests for -Wstrict-aliasing=1,
so I added a few extra tests besides the ones fixed by the p
> > > > > > "ggc_collect() discarding/reusing remap_debug_filename() output,
> > > > > > thus producing invalid objects"
> > > > >
> > > > > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd ()
> > > > > result survives. I vaguely remember GC being happy with heap
> > > > > strings (d
On 26.02.19 15:06, Richard Biener wrote:
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
> sofar.
That was backported to the gcc-8 branch, and now Richard approved the backport
the gcc-7 branch.
Matthias
On Mon, Dec 18, 2017 at 1:37 PM Richard Biener
wrote:
>
> On Fri, Dec 15, 2017 at 7:39 PM, Bin.Cheng wrote:
> > On Fri, Dec 15, 2017 at 1:19 PM, Richard Biener
> > wrote:
> >> On Fri, Dec 15, 2017 at 1:35 PM, Bin.Cheng wrote:
> >>> On Fri, Dec 15, 2017 at 12:09 PM, Bin.Cheng wrote:
> On F
These headers were missed in the previous commit for this bug.
There are also several "" includes in the profile mode headers, but
because they're deprecated I'm not fixing them.
* include/backward/hash_map: Use <> for includes not "".
* include/backward/hash_set: Likewise.
Hi Ian,
Attached is a proposed patch to fix PR 89394, which contains an
artificial mangled name that triggers excessive recursion in
d_count_templates_scopes. The patch uses the same recursion limit
that is already in place for d_print_comp, which I hope will be
acceptable.
There is
On 21/03/19 11:37 +, Jonathan Wakely wrote:
Exporting something like this from libstdc++.so would work, but is
disgusting (and presumably "tbb::interface7" changes from release to
release?"):
extern "C" [[__gnu__::__weak__]]
int
_ZN3tbb10interface78internal15task_arena_base21internal_current
On 20/03/19 14:05 -0700, Thomas Rodgers wrote:
Fixed a failing test.
Thanks. Apart from the changelog issue I mentioned on IRC, the only
other required change I see is in include/Makefile.am:
@@ -1480,7 +1512,9 @@ install-headers:
$(mkinstalldirs) $(DESTDIR)${host_installdir}/../ext
Fix PR jit/87808, the embedded driver still needing the external gcc driver to
find the gcc_lib_dir. This can happen in a packaging context when libgccjit
doesn't depend on the gcc package, but just on binutils and libgcc-dev packages.
libgccjit probably could use /proc/self/maps to find the gcc_li
On Sun, 10 Mar 2019, Bernd Edlinger wrote:
> Hi,
>
> This patch is an update to the previous patch, which takes into account that
> the middle-end is not supposed to use the unaligned DI value directly which
> was passed in an unaligned stack slot due to the AAPCS parameter passing
> rules.
>
>
On Thu, 21 Mar 2019, Jakub Jelinek wrote:
> On Thu, Mar 21, 2019 at 11:25:38AM +0100, Richard Biener wrote:
> > On Thu, 21 Mar 2019, Jakub Jelinek wrote:
> >
> > > On Thu, Mar 21, 2019 at 11:13:41AM +0100, Richard Biener wrote:
> > > > > Would you prefer to have say add_tree_to_fld_list that does
On Thu, Mar 21, 2019 at 11:25:38AM +0100, Richard Biener wrote:
> On Thu, 21 Mar 2019, Jakub Jelinek wrote:
>
> > On Thu, Mar 21, 2019 at 11:13:41AM +0100, Richard Biener wrote:
> > > > Would you prefer to have say add_tree_to_fld_list that does what it
> > > > does now
> > > > and has just 2 cal
On Thu, 21 Mar 2019, Jakub Jelinek wrote:
> On Thu, Mar 21, 2019 at 11:13:41AM +0100, Richard Biener wrote:
> > > Would you prefer to have say add_tree_to_fld_list that does what it does
> > > now
> > > and has just 2 callers in find_decls_types_r and a new
> > > maybe_add_tree_to_fld_list that w
On Thu, Mar 21, 2019 at 11:13:41AM +0100, Richard Biener wrote:
> > Would you prefer to have say add_tree_to_fld_list that does what it does now
> > and has just 2 callers in find_decls_types_r and a new
> > maybe_add_tree_to_fld_list that would do
> > if (!fld->pset.add (t))
> > add_tree_to_
On Thu, 21 Mar 2019, Jakub Jelinek wrote:
> On Thu, Mar 21, 2019 at 10:11:00AM +0100, Richard Biener wrote:
> > On Thu, 21 Mar 2019, Jakub Jelinek wrote:
> >
> > > On Thu, Mar 21, 2019 at 09:35:07AM +0100, Richard Biener wrote:
> > > > LGTM - any reason you only sometimes conditionalize add_tree_
[Sorry for responding to such an old patch]
Jakub Jelinek writes:
> +/* For two FIELD_DECLs in the same chain, return -1 if field1
> + comes before field2, 1 if field1 comes after field2 and
> + 0 if field1 == field2. */
> +
> +static int
> +field_decl_cmp (tree field1, tree field2)
> +{
> +
This also avoids the ICE in PR89779 but IMHO is not a real fix.
Still it restores a previously active check against released SSA names
which now have error_mark_node type rather than NULL. The new way
opens up consolidation so I've adjusted tree_nop_conversion plus
operand_equal_p which got a d
The testcase in this PR shows that IVOPTs ends up using cached
control IV information of IVs that have been elimiated by it.
IVOPTs fails to properly release that information as scev_reset
just resets ->nb_iterations but not control-IVs.
A proper fix is to avoid doing the above for each loop and
Hi all,
Vectorise __builtin_signbit (v4sf) with unsigned shift right vector
instruction.
Bootstrapped and tested on aarch64-none-linux-gnu.
Assembly output for:
$ aarch64-elf-gcc -S -O3 signbitv4sf.c -dp
Before patch:
foo:
adrpx3, in // 37 [c=4 l=4] *movdi_aarch64/12
ad
On Thu, Mar 21, 2019 at 10:11:00AM +0100, Richard Biener wrote:
> On Thu, 21 Mar 2019, Jakub Jelinek wrote:
>
> > On Thu, Mar 21, 2019 at 09:35:07AM +0100, Richard Biener wrote:
> > > LGTM - any reason you only sometimes conditionalize add_tree_to_fld_list
> > > on the fld->pset.add () result? IM
On Thu, 21 Mar 2019, Jakub Jelinek wrote:
> On Thu, Mar 21, 2019 at 09:35:07AM +0100, Richard Biener wrote:
> > LGTM - any reason you only sometimes conditionalize add_tree_to_fld_list
> > on the fld->pset.add () result? IMHO consistency should win over
> > micro-optimizing the case you know the
On Thu, Mar 21, 2019 at 09:28:06AM +0100, Richard Biener wrote:
> > Well, this is surely more costly in that it allocates both the hash_table
> > structure and the memory pointed by it from GC.
>
> You could use
>
> char constexpr_fundef_table[sizeof(hash-table)];
> bool constexpr_fundef_tabl
On Thu, Mar 21, 2019 at 09:35:07AM +0100, Richard Biener wrote:
> LGTM - any reason you only sometimes conditionalize add_tree_to_fld_list
> on the fld->pset.add () result? IMHO consistency should win over
> micro-optimizing the case you know the type will not be in the set.
Yeah, it was a optimi
On Thu, 21 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, if e.g. build_aligned_type creates some specially
> aligned variant of some TYPE_MAIN_VARIANT, that type doesn't appear in the
> IL during free_lang_data and later on we call build_aligned_type with the
> same arguments a
On Wed, 20 Mar 2019, Jakub Jelinek wrote:
> On Wed, Mar 20, 2019 at 05:32:16PM -0400, Jason Merrill wrote:
> > > Does this look reasonable, or do you have other proposals?
> >
> > IMO if you need to guard usage with
> >
> > + if (some_type_hash_table.size () == 0)
> > + some_type_hash_tab
On Wed, Mar 20, 2019 at 7:36 PM Otto, Thomas wrote:
>
> > > > > "ggc_collect() discarding/reusing remap_debug_filename() output,
> > > > > thus producing invalid objects"
> > > >
> > > > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd ()
> > > > result survives. I vaguely remember
71 matches
Mail list logo
