Committed as obvious after regression testing.
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:e2947cfa2d1d4da13bb298b4f36cd745b007d88d
commit r10-6060-ge2947cfa2d1d4da13bb298b4f36cd745b007d88d
Author: Jerry DeLisle
Date: Fri Jan 17 19:36:03 2020 -0800
PR9323
update_version_svn has been replaced by update_version_git. The
scripts directory in ~gccadmin is now a symlink into a gcc-checkout
directory. Various commands using SVN are replaced by git commands
and instructions for updating the old git mirror are removed.
Instructions for adding a new basepo
From: Andrew Pinski
On MIPS, .set noreorder/reorder needs to emitted around
the nop. The template for the nop instruction uses %(/%) to
do that. But default_print_patchable_function_entry uses
fprintf rather than output_asm_insn to output the instruction.
This fixes the problem by using output
Pushed.
Gerald
---
htdocs/snapshots.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/snapshots.html b/htdocs/snapshots.html
index 3c491b00..80d61e27 100644
--- a/htdocs/snapshots.html
+++ b/htdocs/snapshots.html
@@ -11,7 +11,7 @@
GCC Snapshots
-We recommend tha
On Fri, 2020-01-17 at 20:15 +0100, Jakub Jelinek wrote:
> Hi!
>
> As reported in PR93312, the:
> > > > > > > * config/arm/arm.c (clear_operation_p): New function.
> change broke RTL checking bootstrap.
>
> On the testcase from the PR (which is distilled from libgcc2.c, so I think
> we don
On Thu, 2020-01-16 at 20:43 +0100, Martin Liška wrote:
> Hi.
>
> The patch is fixes a regression in libgcrypt package where
> we incorrectly forget to stream out a definition of a no-reorder symbol.
> It's caused by LTO balanced map reversion, where we do not revert
> also best_noreorder_pos.
>
>
On Thu, 2020-01-16 at 18:01 +0100, Jakub Jelinek wrote:
> Hi!
>
> The PR87488 changes include:
> * lib/prune.exp (TEST_ALWAYS_FLAGS): Add -fdiagnostics-urls=never.
> Unfortunately, this broke all the compat.exp etc. compatibility testing with
> alternate compilers, because those compilers (l
From: Andrew Pinski
The problem here was g:23b88fda665d2f995c was not a complete fix
for supporting tranditional TLS on ILP32.
So the problem here is a couple of things, first __tls_get_addr
call will return a C pointer value so we need to use ptr_mode
when we are creating the call. Then we nee
> > On Mon, 2020-01-13 at 11:23 +0800, luoxhu wrote:
> > On 2020/1/10 19:08, Jan Hubicka wrote:
> > > OK. You will need to do the obvious updates for Martin's patch
> > > which turned some member functions into static functions.
> > >
> > > Honza
> >
> > Thanks a lot! Rebased & updated, will com
On Fri, Jan 17, 2020 at 11:20:06PM +0100, Thomas Koenig wrote:
> Am 17.01.20 um 15:42 schrieb Steve Kargl:
> > Gfortran probably should not try to guess what the user
> > thought s/he wanted. The generic "Syntax error" would
> > seem to apply here. To me, foo(1)%a looks much more like
> > an arra
Am 17.01.20 um 15:42 schrieb Steve Kargl:
Gfortran probably should not try to guess what the user
thought s/he wanted. The generic "Syntax error" would
seem to apply here. To me, foo(1)%a looks much more like
an array reference rather than a function reference.
OK, so here's a patch which doe
On Fri, Jan 17, 2020 at 05:01:24PM -0500, David Malcolm wrote:
> Is there a way to force the use of this optimization at -O2, or is it
> always going to be target dependent?
You could try --param logical-op-non-short-circuit=0 ,
--param logical-op-non-short-circuit=1 and/or -mbranch-cost= (the las
I ran into difficulties with the Graphviz format changing from under
me during an upgrade, where the new version of "dot" would reject .dot
files generated by the analyzer.
The analyzer testsuite has a dot-output.c test that attempts to check
that the generated .dot can be handled by dot, with a d
Amongst the inputs to the analyzer state machines that can lead to state
transitions are conditions on CFG edges, such as a test for a pointer
being non-NULL.
These conditionals can be non-trivial to determine in the face of
optimization. For example, at -O2:
if (p == NULL || q == NULL)
is op
PR analyzer/93307 reports that in an LTO bootstrap, there are ODR
violations between:
- the "region" type:
gcc/analyzer/region-model.h:792
vs:
gcc/sched-int.h:1443
- the "constraint" type:
gcc/analyzer/constraint-manager.h:121
vs:
gcc/tree-ssa-structalias.c:533
This patches sol
PR analyzer/93290 reports an ICE on calls to isnan().
The root cause is that an UNORDERED_EXPR is passed
to region_model::eval_condition_without_cm, and there's
a stray gcc_unreachable () in the case where we're comparing
an svalue against itself.
I attempted a more involved patch that properly ha
Pushed.
Gerald
---
htdocs/fortran/index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/fortran/index.html b/htdocs/fortran/index.html
index 42012ddc..7b6aa805 100644
--- a/htdocs/fortran/index.html
+++ b/htdocs/fortran/index.html
@@ -30,7 +30,7 @@ this to attract
DejaGnu test directives such as dg-warning support an optional
"comment" argument for disambiguating multiple tests on the same line.
Jeff noticed various name collisions of test names in the analyzer
testsuite, due to me using empty comment strings when using line
offsets in test directives.
Thi
Remove a section that only applies to SVN and some specifics on
encoding patches in mails that are rarely relevant.
Shorten the initial statement, the note on copyright disclaimers,
and trim some further overly picky/explicit statements.
Use active voice and improve markup in one case each.
I s
This patch adds a new function to logically decrement the "dynamic
reference counter" for a mapped OpenACC variable, and handles some cases
in which that counter drops to zero inside a structured data
block. Previously, it's likely that at least in some cases, ending a
dynamic data lifetime in this
This patch series provides fixes for some cases of mixing static and
dynamic data lifetimes in OpenACC, hopefully addressing some of Thomas's
concerns in PR92843 -- in particular that an "exit data"-type operation on
a given variable inside a structured block (also mapping that variable)
should be
This patch prevents "exit data" directives from copying back data that
was mapped with an acc_map_data API call. This matches the behaviour
expected by the pr92843-1.c test, and together with the previous patch
in this series, allows that test to pass (with no other regressions).
Tested alongside
This patch provides a way to distinguish target_mem_descs that arise from
"enter data" operations from those that arise from structured OpenACC
data blocks. In that way, we can implement the equivalent of the "no-op"
behaviour of decrementing a dynamic reference count that is already zero
for some
Since e4511ca2e9ecdb51d41b64452398f8e2df575668 force_paren_expr can create
a VIEW_CONVERT_EXPR so that we have something to set REF_PARENTHESIZED_P
on, while not making the expression dependent. But tsubst_copy can't cope
with such a VIEW_CONVERT_EXPR, because it's not location_wrapper_p, or
a TEM
One step^Wfile at a time; next in line: svn.html.
Pushed.
Gerald
---
htdocs/contribute.html | 4 +-
htdocs/svnwrite.html | 432 -
2 files changed, 2 insertions(+), 434 deletions(-)
delete mode 100644 htdocs/svnwrite.html
diff --git a/htdocs/contribu
> Hi Honza,
>
> This change seems to have cost a 0.2% regression in SPEC2017 vs a codesize
> reduction of 0.02%.
>
> Only leela seems to have made any noticable difference at 2.64% codesize
> reduction.
>
> Is there anyway to keep the performance at -O3 where the codesize doesn't
> matter muc
Hi!
As reported in PR93312, the:
> > > > > > * config/arm/arm.c (clear_operation_p): New function.
change broke RTL checking bootstrap.
On the testcase from the PR (which is distilled from libgcc2.c, so I think
we don't need to add it into testsuite) we ICE because SET_DEST (elt) is
not a
On Fri, Jan 17, 2020 at 11:12:08AM +, Mihail Ionescu wrote:
> On 01/17/2020 08:37 AM, Jakub Jelinek wrote:
> > On Wed, Dec 18, 2019 at 05:00:01PM +, Mihail Ionescu wrote:
> > > 2019-12-18 Mihail Ionescu
> > > 2019-12-18 Andre Vieira
> > >
> > > * config/arm/arm-cpus.in (mve, mve_fl
I've committed this patch, pre-approved by Thomas. It's basically just a
search and replace.
I had originally invented acc_device_gcn for the device number, but as
Thomas pointed out the OpenACC documentation already uses
acc_device_radeon for AMD devices. Presumably this is what any existing
This is not directly related to our move to Git, though I noticed
it in the context of working to update the web pages.
Most of our downloads are now happening via http, and Chrome will
soon even remove support for the ftp protocol.
Pushed.
Gerald
---
htdocs/gcc-2.95/branch.html | 2 +-
htdocs/
On 1/17/20 11:01 AM, Jonathan Wakely wrote:
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
std::deque is supposed to be like a double-queue that you can
attack from front and back. But currrently its implementation makes
it behave differently when starting from a fresh deque. If push_ba
In a freestanding library we don't install the
header, so don't try to include it unless it exists.
Explicitly declare aligned alloc functions for freestanding, because
doesn't declare them.
PR libstdc++/92376
* include/bits/c++config: Only do PSTL config when the header is
Hi Kyrill & Richard,
> I was leaving this to others in case it was obvious to them. On the
> basis that silence suggests it wasn't, :-) could you go into more details?
> Is it expected on first principles that jump alignment doesn't matter
> for Neoverse N1, or is this purely based on experimenta
Hi all,
This patch is part of a series adding support for Armv8.6-A features.
It depends on Arm BFMode patch
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html
This patch implements intrinsics to convert between bfloat16 and float32
formats.
ACLE documents are at https://developer.arm.com
On Tue, Jan 14, 2020 at 11:29 PM Prathamesh Kulkarni
wrote:
>
> On Wed, 8 Jan 2020 at 15:50, Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 5 Nov 2019 at 17:38, Richard Biener
> > wrote:
> > >
> > > On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah
> > > wrote:
> > > >
> > > > Hi,
> > > > T
Hi Honza,
This change seems to have cost a 0.2% regression in SPEC2017 vs a codesize
reduction of 0.02%.
Only leela seems to have made any noticable difference at 2.64% codesize
reduction.
Is there anyway to keep the performance at -O3 where the codesize doesn't
matter much?
Thanks,
Tamar
>
On 1/17/20 9:22 AM, Joseph Myers wrote:
On Fri, 17 Jan 2020, Joel Brobecker wrote:
The main goal of the limit is really to avoid accidents where someone
pushes something he shouldn't or something he didn't realize would
push so many commits. If the GCC repository is such that merges of
100 comm
On Fri, Jan 17, 2020 at 09:29:33AM +0100, Tobias Burnus wrote:
> On 1/17/20 4:49 AM, Steve Kargl wrote:
> > On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:
> >> +type(t) :: foo
> >> +print *, foo(1)%a ! { dg-error "Function call can not contain a
> >> reference" }
> > I do not under
Hi Richard,
> If you're able to say for the record which cores you tested, then that'd
> be good.
I've mostly checked it on Cortex-A57 - if there is any affect, it would be on
older cores.
> OK, thanks. I agree there doesn't seem to be an obvious reason why this
> would pessimise any cores sign
Ok, after personal discussion with Honza that I had,
we should be more conservative and prune only
a run-time TOP N counters before we merge them.
The patch does that. Can you please Honza test me the patch of Firefox?
Thanks,
Martin
>From 7fe1e6a59139ae00cefd1f5edf082d428952203e Mon Sep 17 00:00
On Fri, 17 Jan 2020, Richard Biener wrote:
> We also make sure (?) to not make them show up in bugzilla, right?
That's already done; the email-to-bugzilla-filtered script only passes
commits to master and release branches (i.e., pushes that update those
refs) to Bugzilla.
--
Joseph S. Myers
j
On January 17, 2020 3:22:11 PM GMT+01:00, Joseph Myers
wrote:
>On Fri, 17 Jan 2020, Joel Brobecker wrote:
>
>> The main goal of the limit is really to avoid accidents where someone
>> pushes something he shouldn't or something he didn't realize would
>> push so many commits. If the GCC repository
This was failing because uses_template_parms didn't recognize LAMBDA_EXPR as
a kind of expression. Instead of trying to enumerate all the different
varieties of expression and then aborting if what's left isn't
error_mark_node, let's handle error_mark_node and then assume anything else
is an expre
On Fri, 17 Jan 2020, Joel Brobecker wrote:
> The main goal of the limit is really to avoid accidents where someone
> pushes something he shouldn't or something he didn't realize would
> push so many commits. If the GCC repository is such that merges of
> 100 commits or more is going to be, if not
On 1/10/20 3:28 PM, Jakub Jelinek wrote:
Hi!
As the following testcase shows, when deprecated attribute is on a template,
we'd never print the message if any, because the attribute is not
present on the TEMPLATE_DECL with which warn_deprecated_use is called,
but on its DECL_TEMPLATE_RESULT or it
On Fri, Jan 17, 2020 at 09:07:01AM -0500, Jason Merrill wrote:
> On 12/30/19 3:51 PM, Kerem Kat wrote:
> > +/* { dg-message "expected" "expected" { target *-*-* } .3 } */
>
> Dejagnu doesn't like this:
>
> ERROR: c-c++-common/pr92833-4.c -std=c++98: expected integer but got ".3"
> for " dg-messa
On 12/30/19 3:51 PM, Kerem Kat wrote:
+/* { dg-message "expected" "expected" { target *-*-* } .3 } */
Dejagnu doesn't like this:
ERROR: c-c++-common/pr92833-4.c -std=c++98: expected integer but got
".3" for " dg-message 4 "expected" "expected" { target *-*-* } .3 "
Jason
As Jonathan discovered,
#if FALSE_THING && has_include
still goes look for foo.
This patch makes the has_include evaluator check skip_eval before
looking for foo -- but after parsing the has_include to diagnose
ill-formedness.
Sadly, no testcase, because it's pretty much only observable via
Hi!
I'd like to ping following patch. Thanks.
On Fri, Jan 10, 2020 at 09:28:20PM +0100, Jakub Jelinek wrote:
> 2020-01-10 Jakub Jelinek
>
> PR c++/93228
> * parser.c (cp_parser_template_name): Look up deprecated attribute
> in DECL_TEMPLATE_RESULT or its type's attributes.
AIUI, the main purpose of REVERSE_CONDITION is to take advantage of
any integer vs. FP information encoded in the CC mode, particularly
when handling LT, LE, GE and GT. For integer comparisons we can
safely map LT->GE, LE->GT, GE->LT and GT->LE, but for float comparisons
this would usually be inva
PR91323 was fixed for x86 and sparc in target code, but aarch64
instead relies on the target-independent comparison splitters.
Since LTGT is an unordered-signalling operation, we should split
it into unordered-signalling operations for any input that could
be NaN, not just inputs that could be sign
On 16/01/2020 15:00, Jakub Jelinek wrote:
On Wed, Jan 15, 2020 at 10:48:23PM +, Joseph Myers wrote:
A reasonable replacement for those push rules might be command aliases
(e.g. "git upush " to push the user branch ).
Would we have then separate aliases for pushing to one vendor branch and
On 16/01/2020 14:49, Andreas Schwab wrote:
On Jan 16 2020, Richard Earnshaw (lists) wrote:
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index dae2c35bb57..1cde6fd8224 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -11,
The initial structure for vendor and personal branches makes use of the
default remote (normally origin) for the upstream repository).
Unfortunately, this causes some confusion, especially for personal
branches because a push will not push to the correct upstream location.
This can be 'fixed' b
It is already ported :)
https://github.com/gcc-mirror/gcc/commit/555e4a053951a0ae24835a266e71819336d7f637#diff-5b8bd26eec6c2b9f560870c205416edc
Cheers,
Claudiu
On Wed, Jan 15, 2020 at 1:49 AM Vineet Gupta wrote:
>
> On 12/9/19 1:52 AM, Claudiu Zissulescu wrote:
> > Although the FDCMP (the double
Hi Jakub,
On 01/17/2020 08:37 AM, Jakub Jelinek wrote:
On Wed, Dec 18, 2019 at 05:00:01PM +, Mihail Ionescu wrote:
2019-12-18 Mihail Ionescu
2019-12-18 Andre Vieira
* config/arm/arm-cpus.in (mve, mve_float): New features.
(dsp, mve, mve.fp): New options.
Note, the a
On 12/18/19 1:23 PM, Mihail Ionescu wrote:
Hi Kyrill,
On 12/11/2019 05:50 PM, Kyrill Tkachov wrote:
> Hi Mihail,
>
> On 11/14/19 1:54 PM, Mihail Ionescu wrote:
>> Hi,
>>
>> This patch adds the new scalar shift instructions for Armv8.1-M
>> Mainline to the arm backend.
>> This patch is adding
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
std::deque is supposed to be like a double-queue that you can attack
from front and back. But currrently its implementation makes it behave
differently when starting from a fresh deque. If push_back then all
goes well, it is copy/move to th
Hi Richard, Wilco,
On 1/17/20 8:43 AM, Richard Sandiford wrote:
Wilco Dijkstra writes:
> Testing shows the setting of 32:16 for jump alignment has a
significant codesize
> cost, however it doesn't make a difference in performance. So set
jump-align
> to 4 to get 1.6% codesize improvement.
I
Hi.
The patch removes need to have a gnu_indirect_function global
symbol. That aligns the code with what ppc64 target does.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-01-17 Martin Liska
PR target
Wilco Dijkstra writes:
> Enable the most basic form of compare-branch fusion since various CPUs
> support it. This has no measurable effect on cores which don't support
> branch fusion, but increases fusion opportunities on cores which do.
If you're able to say for the record which cores you test
Thank you for reviewing and committing it.
Kerem
On Fri, Jan 17, 2020 at 1:04 AM Jeff Law wrote:
> On Thu, 2020-01-16 at 23:43 +, Joseph Myers wrote:
> > Thanks, patch committed.
> Beat me to it :-) I spun it yesterday, but didn't get around to
> committing it.
> jeff
>
>
Wilco Dijkstra writes:
> Testing shows the setting of 32:16 for jump alignment has a significant
> codesize
> cost, however it doesn't make a difference in performance. So set jump-align
> to 4 to get 1.6% codesize improvement.
I was leaving this to others in case it was obvious to them. On the
On Wed, Dec 18, 2019 at 05:00:01PM +, Mihail Ionescu wrote:
> 2019-12-18 Mihail Ionescu
> 2019-12-18 Andre Vieira
>
> * config/arm/arm-cpus.in (mve, mve_float): New features.
> (dsp, mve, mve.fp): New options.
Note, the above is not the right ChangeLog formatting when you ha
Hi Ian,
> As I noted, 100 commits to master is a small number, so I expect this problem
> to fire almost every time someone does a merge of master to a devel or user
> branch (unless they have the habit of doing that almost daily, which I doubt
> for
> most).
The main goal of the limit is really
On 1/17/20 4:49 AM, Steve Kargl wrote:
On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:
+type(t) :: foo
+print *, foo(1)%a ! { dg-error "Function call can not contain a reference" }
I do not understand this error message, and find it to be confusing.
foo(1)%a looks like an invalid
On Thu, Jan 16, 2020 at 1:10 PM Richard Sandiford
wrote:
>
> If a TARGET_EXPR has poly-int size, the gimplifier would treat it
> like a VLA and use gimplify_vla_decl. gimplify_vla_decl in turn
> would use an alloca and expect all references to be gimplified
> via the DECL_VALUE_EXPR. This caused
Hello Thomas, hi all,
On 1/16/20 11:34 PM, Thomas Koenig wrote:
Anyway, the fix is rather straightforward. We cannot have a reference
on a function. If this slipped through on parsing, let's issue the
error during resolution.
Regression-tested. OK for trunk?
I think I am fine with the check it
Hi Folks,
Joel Brobecker wrote:
You should include Joel on such questions as the expert on the hooks.
I don't know whether there's something to put in the commit message to say
"allow this merge of more than 100 commits". I don't think a squashed
merge is the right workaround, supposing you
69 matches
Mail list logo
