This is a revised version of the patch I posted on March 23rd. The changes are
to update the comments and improve the ChangeLog.
There were no regressions when I did the bootstrap and make check steps. I
verified that -mcpu=future does turn on -mprecl if you are targeting a Linux
ELF v2 system
On Sat, 28 Mar 2020, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> After we report various errors about array size, we set for error-recovery
> the size to be 1, but because size_int_const is false, it still means we
> pretend the array is a VLA, can emit a second diagnostics in that case etc.
Hi!
After we report various errors about array size, we set for error-recovery
the size to be 1, but because size_int_const is false, it still means we
pretend the array is a VLA, can emit a second diagnostics in that case etc.
E.g.
$ ./cc1.unpatched -quiet a.c
a.c:1:5: error: size of array ‘f’
Hi!
The following testcase FAILs with -fcompare-debug, because reassociate_bb
mishandles the case when the last stmt in a bb has zero uses. In that case
reassoc_remove_stmt (like gsi_remove) moves the iterator to the next stmt,
i.e. gsi_end_p is true, which means the code sets the iterator back
On 27/03/20 23:29 +, Jonathan Wakely wrote:
@@ -403,6 +428,49 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
operator>=(const reverse_iterator<_IteratorL>& __x,
const reverse_iterator<_IteratorR>& __y)
{ return !(__x < __y); }
+#else // C++20
+ template
+constexpr auto
+
On Fri, Mar 6, 2020 at 6:18 PM Steve Kargl
wrote:
[...]
> TL;DR version.
>
> Fix the simplification and handling of the degree trigonometric functions.
> This includes fixing a number of ICEs. See PR 93871.
An updated version of the patch is attached. Regression tests (and new
test cases)
Define the feature test macro now that ranges support is complete.
This also changes the preprocessor checks for the __cpp_concepts macro
so that library components depending on concepts are only enabled when
C++20 concepts are supported, and not just for the Concepts TS (which
uses different
This adds the missing parts of P0896R4 to reverse_iterator and
move_iterator, so that they meet the C++20 requirements. This should be
the last piece of P0896R4, meaning ranges support is now complete.
The PR 94354 bug with reverse_iterator's comparisons is fixed for C++20
only, but that change
std::insert_iterator and std::inserter need to be adjusted for C++20, so
that they use ranges::iterator_t. That alias template requires
ranges::begin to be defined. Rather than moving the whole of
ranges::begin (and related details like ranges::enable_borrowed_range)
into , this defines a new,
Peter Bergner writes:
> Ian, do you remember why we don't just decompose all wide types and instead
> require a pseudo to pseudo copy to exist?
No, sorry, I don't remember this at all.
Ian
This moves __is_array_convertible so it's not between
__is_nothrow_convertible and its helper, since it isn't related to
those.
* include/std/type_traits (__is_array_convertible): Move definition
to immediately after is_convertible.
Tested powerpc64le-linux, committed to master.
-mlongcall -mno-pltseq is supposed to emit long calls by using
indirect calls. It differs from -mlongcall -mpltseq in that the
function addresses are not placed in the PLT and thus lazy PLT
resolution is not available, affecting programs that dlopen shared
libraries.
In the case of -mcpu=future
The pr87507.c test case regressed due to Segher's commit that added
-fsplit-wide-types-early. The issue is that the lower-subreg pass only
decomposes the TImode code in the example if there is a pseudo reg to pseudo
reg copy. When the lower-subreg pass is called late (its old location),
then
This patch is for an AIX problem, but the only robust solution is in
common code: calls.c:precompute_register_parameters().
AIX, like other platforms, needs to call a function to obtain the
pointer to thread-local storage. If the thread local variable is
referenced as a parameter to a function
On 3/26/20 6:52 PM, Jason Merrill wrote:
On 3/26/20 4:57 PM, Martin Sebor wrote:
On 3/25/20 3:56 PM, Jason Merrill wrote:
On 3/16/20 4:41 PM, Martin Sebor wrote:
The recent fix to avoid modifying in place the type argument in
handle_access_attribute (PR 92721) was incomplete and didn't fully
On 3/27/20 3:55 AM, Jakub Jelinek wrote:
On Thu, Mar 26, 2020 at 07:55:39PM -0600, Martin Sebor via Gcc-patches wrote:
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -2526,17 +2526,21 @@ handle_copy_attribute (tree *node, tree name, tree args,
&&
On March 27, 2020 4:32:58 PM GMT+01:00, Jakub Jelinek wrote:
>On Fri, Mar 27, 2020 at 10:57:05AM +0100, Richard Biener wrote:
>> > That would just mean it ICEs at -g0 too, this PR isn't a
>-fcompare-debug
>> > issue but a bug where we try to gimplify the same STATEMENT_LIST
>multiple
>> > times
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file,
We were pushing the variable 'e' into the cleanup pseudo-binding left by
the try/catch block, but seeing past that for the implicit type decl for
the structure 'e'. this bug seems to happen as far back as I can try --
gcc 6 at least. Fixed by looking through the cleanup binding in both cases.
On 3/27/20 12:20 AM, Patrick Palka wrote:
On Mon, 9 Mar 2020, Patrick Palka wrote:
The first patch tries to avoid changing our current default diagnostics. But
for the sake of consistency we arguably should also respect
current_constraint_diagnosis_depth in diagnose_compound_requirement()
On 3/27/20 12:17 AM, Patrick Palka wrote:
On Mon, 16 Mar 2020, Patrick Palka wrote:
Hi Martin,
On Sun, 15 Mar 2020, Martin Sebor wrote:
On 3/11/20 4:18 PM, Patrick Palka via Gcc-patches wrote:
...
Hmm, like this? This version introduces a new static member function
On 3/27/20 11:28 AM, Patrick Palka wrote:
On Thu, 26 Mar 2020, Patrick Palka wrote:
On Thu, 26 Mar 2020, Jason Merrill wrote:
On 3/26/20 5:24 PM, Patrick Palka wrote:
On Wed, 25 Mar 2020, Jason Merrill wrote:
On 3/25/20 12:17 PM, Patrick Palka wrote:
This PR reports that the
On Wed, Mar 25, 2020 at 11:07:04AM -0500, will schmidt wrote:
> Hi,
> Comments inline.
>
> > Is this patch acceptable to be committed to the master branch. I have done
> > various tests with this patch, including most recently bootstraping and
> > running
> > make check. I have built the Spec
On Sat, Mar 28, 2020 at 02:06:56AM +0800, Kito Cheng wrote:
> PR target/90811
> * ipa-increase-alignment.cc (increase_alignment_local_var): New.
> (increase_alignment_global_var): New.
> (pass_ipa_increase_alignment::gate): Remove.
I'm afraid this is too early,
On Fri, Mar 27, 2020 at 11:07 AM Kito Cheng wrote:
>
> - The alignment for local variable was adjust during
> estimate_stack_frame_size,
>however it seems wrong spot to adjust that, expand phase will adjust that
>but it little too late to some gimple optimization, which rely on certain
- The alignment for local variable was adjust during estimate_stack_frame_size,
however it seems wrong spot to adjust that, expand phase will adjust that
but it little too late to some gimple optimization, which rely on certain
target hooks need to check alignment, forwprop is an example
- This patch is prepare for add more logic into increase_alignment
pass, which is not related to vectorization.
gcc/ChangeLog
* Makefile.in (OBJS): Add ipa-increase-alignment.o.
* tree-vectorizer.c (get_vec_alignment_for_type): Moved to
ipa-increase-alignment.cc.
The iterative addition of 8 and 16 bit vectors has left the mode
iterators in a bit of a mess. Also, the original names were rather
verbose leading to formatting difficulties.
This patch renames all the vector modes such that they are shorter and
tidier. It does not change the output machine
Hi,
On Fri, 20 Mar 2020 at 11:56, Roman Zhuykov via Gcc-patches
wrote:
>
> Hi all!
>
> 12.03.2020 6:17, Jeff Law wrote:
> >> Current modulo-sched implementation is a bit faulty from -fcompile-debug
> >> perspective.
> >>
> >> But right now I see that when I enable -fmodulo-sched by default,
>
On 3/26/20 6:51 PM, Martin Sebor wrote:
On 3/26/20 4:16 PM, Jason Merrill wrote:
On 3/26/20 2:58 PM, Martin Sebor wrote:
On 3/25/20 11:36 PM, Jason Merrill wrote:
On 3/23/20 12:50 PM, Martin Sebor wrote:
On 3/23/20 8:49 AM, Jason Merrill wrote:
On 3/21/20 5:59 PM, Martin Sebor wrote:
+
Hi!
On Fri, Mar 27, 2020 at 09:34:00AM +0800, luoxhu wrote:
> On 2020/3/27 07:59, Segher Boessenkool wrote:
> > On Wed, Mar 25, 2020 at 11:15:22PM -0500, luo...@linux.ibm.com wrote:
> >> frame_pointer_needed is set to true in reload pass setup_can_eliminate,
> >> but regs_ever_live[31] is false,
On 11/19/19 3:48 PM, Richard Biener wrote:
Sure. As said in the if-to-switch pass "review" all these (now three)
passes should share an intermediate representation and costing they
then generate code from (either switch-converted lookups, switches
or optimized if-chains). There's no reason to
On Fri, Mar 27, 2020 at 10:57:05AM +0100, Richard Biener wrote:
> > That would just mean it ICEs at -g0 too, this PR isn't a -fcompare-debug
> > issue but a bug where we try to gimplify the same STATEMENT_LIST multiple
> > times and second time ICE on it as it has been voidified and emptied.
>
>
On Thu, 26 Mar 2020, Patrick Palka wrote:
> On Thu, 26 Mar 2020, Jason Merrill wrote:
>
> > On 3/26/20 5:24 PM, Patrick Palka wrote:
> > > On Wed, 25 Mar 2020, Jason Merrill wrote:
> > >
> > > > On 3/25/20 12:17 PM, Patrick Palka wrote:
> > > > > This PR reports that the requires-expression in
>
On 3/27/20 3:21 PM, Jeff Law wrote:
On Fri, 2020-03-27 at 10:10 +0100, Martin Liška wrote:
On 3/26/20 5:54 PM, Jeff Law wrote:
On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Following DR2061, 'namespace F', looks for 'F's inside inline
namespaces. That can result in ambiguous lookups that we failed to
diagnose early enough, leading us to push a new namespace and ICE later.
Diagnose the ambiguity earlier, and then pick one.
applied to master.
nathan
--
Nathan
Hi!
On Thu, Mar 26, 2020 at 05:06:43AM -0500, luo...@linux.ibm.com wrote:
> Remove split code from add3 to allow a later pass to split.
> This allows later logic to hoist out constant load in add instructions.
> In loop, lis+ori could be hoisted out to improve performance compared with
> previous
On Thu, 2020-03-26 at 17:03 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Mar 24, 2020 at 01:26:25PM -0500, will schmidt wrote:
> > Update existing testcase powerpc/bswap64-4.c to
> > reflect that we generate ldbrx and stdbrx instructions
> > for newer cpu targets. This is in contrast to
Hi Richard:
> I do think that local variable layout probably doesn't belong in that IPA pass
> but elsewhere (way earlier). But my main complaint was that the diff
> doesn't show changes you made to the pass because it first and foremost
> shows moving all the code. That makes reviewing the
On Fri, 2020-03-27 at 10:10 +0100, Martin Liška wrote:
> On 3/26/20 5:54 PM, Jeff Law wrote:
> > On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
> > > On 3/9/20 4:36 PM, H.J. Lu wrote:
> > > > We nee to support different variables, like TLS, data and bss variables.
> > >
> > > Why do we
Fixes to exploded_path::feasible_p exposed a pre-existing bug
with pointer NULL-ness for pointers to symbolic_region.
symbolic_region has an "m_possibly_null" flag which if set means
that a region_svalue pointing to that region is treated as possibly
NULL. Adding a constraint of "!= NULL" on an
This patch extends -fdump-analyzer-supergraph so that rather than just
dumping a DUMP_BASE_NAME.supergraph.dot at the start of analysis, it
also dumps a DUMP_BASE_NAME.supergraph-eg.dot at the end.
The new dump file contains a concise dump of the exploded_graph,
organized with respect to the
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 8f02357571a858f7ff5ca7734e5344d989a7fd0c.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (dedupe_winners::add): Show the
exploded_node index in the log messages.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 4d661bb7a2e1fdfd856140f1b86266ca524df9e2.
gcc/analyzer/ChangeLog:
* supergraph.cc (superedge::dump): Add space before description;
move newline to non-pretty_printer overload.
---
On Fri, Mar 27, 2020 at 2:54 PM Richard Biener
wrote:
>
> On Fri, Mar 27, 2020 at 2:04 PM Kito Cheng wrote:
> >
> > Hi Richard:
> >
> > The local variable alignment adjustment was removed at this commit:
> > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=26d7a5e690169ac04acde90070b0092c41b71c7e
On Fri, Mar 27, 2020 at 2:04 PM Kito Cheng wrote:
>
> Hi Richard:
>
> The local variable alignment adjustment was removed at this commit:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=26d7a5e690169ac04acde90070b0092c41b71c7e
>
> And it's a little bit indirectly, it called from
>
Hi Richard:
The local variable alignment adjustment was removed at this commit:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=26d7a5e690169ac04acde90070b0092c41b71c7e
And it's a little bit indirectly, it called from
estimate_stack_frame_size, call stack like:
estimate_stack_frame_size ->
This avoids completing types for DINFO_LEVEL_TERSE by using
the should_emit_struct_debug machinery.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2020-03-27 Richard Biener
PR debug/94273
* dwarf2out.c (should_emit_struct_debug): Return false for
This fixes a (harmless) use of a not re-initialized curr_order.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2020-03-27 Richard Biener
PR tree-optimization/94352
* tree-ssa-propagate.c (ssa_prop_init): Move seeding of the
worklist ...
On Fri, Mar 27, 2020 at 1:28 PM Kito Cheng wrote:
>
> - The alignment for local variable was adjust during
> estimate_stack_frame_size,
>however it seems wrong spot to adjust that.
>
> - So we must adjust at some point, and here is already a pass to adjust
>alignment, which is
- The alignment for local variable was adjust during estimate_stack_frame_size,
however it seems wrong spot to adjust that.
- So we must adjust at some point, and here is already a pass to adjust
alignment, which is ipa-increase-alignment, used for tree vectorization.
- We move out the
Another patch – the last non-Solaris '[10 Regression]'
gfortran regression, which is in Bugzilla.
The patch is obvious: assumed-rank arrays may be also
nonallocatable, nonpointer variables. They are handled
fine by this routine as it has an early exit for
dummy variables (after doing the minimal
Hi all,
here, the reject_statement cleanup and the freeing of the
namespace both remove the symbol. Solution: Remove it first,
then clean the namespace – then the reject_statement has no
(deleted) statement to cleanup.
As select rank is new, that's again a GCC-10 only
regression (of invalid
On Fri, 27 Mar 2020, Jakub Jelinek wrote:
> On Fri, Mar 27, 2020 at 09:32:40AM +0100, Richard Biener wrote:
> > On Fri, 27 Mar 2020, Jakub Jelinek wrote:
> >
> > > On Thu, Mar 26, 2020 at 08:41:41PM -0300, Alexandre Oliva wrote:
> > > > On Mar 26, 2020, Jakub Jelinek wrote:
> > > >
> > > > >
On Thu, Mar 26, 2020 at 07:55:39PM -0600, Martin Sebor via Gcc-patches wrote:
> --- a/gcc/c-family/c-attribs.c
> +++ b/gcc/c-family/c-attribs.c
> @@ -2526,17 +2526,21 @@ handle_copy_attribute (tree *node, tree name, tree
> args,
>&& !FUNCTION_POINTER_TYPE_P (TREE_TYPE (ref)))
> ref =
Hi Tobias,
Thanks for the patch. I had flagged it up as one that I should be dealing with.
OK indeed!
Cheers
Paul
On Fri, 27 Mar 2020 at 08:05, Tobias Burnus wrote:
>
> Using "associate (y => procedure_name)" and
> "associate (y => derived_type_name)" failed with an ICE
> when converting to
On 3/26/20 5:54 PM, Jeff Law wrote:
On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
About BSS and DATA I
On Fri, Mar 27, 2020 at 09:32:40AM +0100, Richard Biener wrote:
> On Fri, 27 Mar 2020, Jakub Jelinek wrote:
>
> > On Thu, Mar 26, 2020 at 08:41:41PM -0300, Alexandre Oliva wrote:
> > > On Mar 26, 2020, Jakub Jelinek wrote:
> > >
> > > > Or disable -gstatement-frontiers by default and declare it
On Fri, 27 Mar 2020, Jakub Jelinek wrote:
> On Thu, Mar 26, 2020 at 08:41:41PM -0300, Alexandre Oliva wrote:
> > On Mar 26, 2020, Jakub Jelinek wrote:
> >
> > > Or disable -gstatement-frontiers by default and declare it -fcompare-debug
> > > incompatible.
> >
> > I don't get what makes debug
Using "associate (y => procedure_name)" and
"associate (y => derived_type_name)" failed with an ICE
when converting to a tree. This patch rejects those now.
(This is a GCC 10 regression; before there was no ICE but
the code was silently accepted.)
OK?
Tobias
-
Mentor Graphics
gcc.target/arm/fp16-aapcs-3.c is failing on one of our targets, and I'm
puzzled as to the reason for the failure and to the proper fix.
The test fails because, despite the dg-add-options in the subject,
-mfp16-format=alternative is not passed to the compiler, so type __fp16
is not recognized.
Hi Thomas,
Thomas Schwinge writes:
> On 2020-03-25T18:09:25+0100, I wrote:
>> On 2018-02-22T12:23:25+0100, Tom de Vries wrote:
>>> when using cuda 9 nvprof with an openacc executable, the executable hangs.
>
>> What Frederik has discovered today in the hard way... [...]
>> -- the hang was
62 matches
Mail list logo
