On 2017.01.27 at 08:41 +0100, Rainer Orth wrote:
> Hi Martin,
>
> > On 01/24/2017 02:37 AM, Markus Trippelsdorf wrote:
> >> MPFR_RNDx was introduced in MPFR 3.0.0. Since the minimal version that
> >> gcc checks for is 2.4.0, this leads to a build failure.
> >>
> >> The fix is straightforward.
> >>
On 01/26/2017 05:08 PM, Dominik Vogt wrote:
> The attached patch reactivates the setmem_long_and* patterns on
> S/390 that have not been generated for a while. Regression tested
> and bootstrapped on s390x biarch and s390.
>
> Ciao
>
> Dominik ^_^ ^_^
>
Applied. Thanks!
-Andreas-
On Fri, Jan 27, 2017 at 08:41:59AM +0100, Rainer Orth wrote:
> > On 01/24/2017 02:37 AM, Markus Trippelsdorf wrote:
> >> MPFR_RNDx was introduced in MPFR 3.0.0. Since the minimal version that
> >> gcc checks for is 2.4.0, this leads to a build failure.
> >>
> >> The fix is straightforward.
> >>
> >
Hi Jakub and Matthias,
New overall patch attached. My commit access is pending so I'm relying on Martin
or someone else to get this committed for now.
Added replies inline:
On Thu, Jan 26, 2017 at 2:04 PM, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Jan 26, 2017 at 01:30:21PM +0200, Pekka Jääskeläin
On Thu, 26 Jan 2017, Richard Biener wrote:
I also notice we dont' handle 1 - A CMP A anywhere.
Hmm, what are we supposed to transform that into? For ==, that would be
false (parity), but for < it is false for 0, true for 1, false for 2, then
true again after MAX/2... Nothing obvious.
--
Ma
On Thu, 26 Jan 2017, Jeff Law wrote:
I assume this causes a regression for code like
unsigned f(unsigned a){
unsigned b=a+1;
if(bYes. The transformation ruins the conversion into ADD_OVERFLOW for the +- 1
case. However, ISTM that we could potentially recover the ADD_OVERFLOW in
phi-opt.
On 27 January 2017 at 03:49, Martin Sebor wrote:
> I committed the patch below to clean up the "mess."
>
> Thanks
> Martin
>
> Index: gcc/gimple-ssa-sprintf.c
> ===
> --- gcc/gimple-ssa-sprintf.c(revision 244957)
> +++ gcc/gimple-
Hi!
During development, I had been changing the libgomp plugin API, which
should have caused build failures in unmodified plugins -- but it didn't.
Here is patch to address that. OK for trunk? Should this also go into
release branches?
commit 01828b7ec25f2087548b5c75568b545aa0d16c3b
Author: Tho
On Fri, Jan 27, 2017 at 10:19:18AM +0100, Thomas Schwinge wrote:
> During development, I had been changing the libgomp plugin API, which
> should have caused build failures in unmodified plugins -- but it didn't.
> Here is patch to address that. OK for trunk? Should this also go into
> release br
David Edelsohn writes:
> I'm receiving the following error message for the new testcase:
>
> FAIL: c-c++-common/Wduplicated-branches-13.c -std=gnu++98 (test for
> excess errors)
> Excess errors:
> /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/Wduplicated-branches-13.c:11:7:
> warning: thi
Martin Sebor writes:
> The improvements to the handling of flexible array members in
> C++ in GCC 6 inadvertently removed the pedantic warnings GCC
> used to issue for their declarations. The attached patch
> restores it.
After this patch, I get
FAIL: obj-c++.dg/property/at-property-23.mm -fgn
On 01/26/2017 06:12 PM, Gerald Pfeifer wrote:
> Hi Martin,
>
> On Wed, 25 Jan 2017, Martin Liška wrote:
>> Following patch documents DO loop changes which were done for upcoming
>> GCC 7.1.
>
> thanks for putting this together.
>
> Index: htdocs/gcc-7/changes.html
>
Hi Jakub,
> On Fri, Jan 27, 2017 at 08:41:59AM +0100, Rainer Orth wrote:
>> > On 01/24/2017 02:37 AM, Markus Trippelsdorf wrote:
>> >> MPFR_RNDx was introduced in MPFR 3.0.0. Since the minimal version that
>> >> gcc checks for is 2.4.0, this leads to a build failure.
>> >>
>> >> The fix is straigh
On Fri, 27 Jan 2017, Jakub Jelinek wrote:
> On Fri, Jan 27, 2017 at 08:41:59AM +0100, Rainer Orth wrote:
> > > On 01/24/2017 02:37 AM, Markus Trippelsdorf wrote:
> > >> MPFR_RNDx was introduced in MPFR 3.0.0. Since the minimal version that
> > >> gcc checks for is 2.4.0, this leads to a build fail
Hi all,
This fixes (PR78142) by only creating one vector in the char case.
r241590 is causing more registers to be used and so
the SP registered happens to be picked and used.
This test I believe was checking explicitly that the
SP is not used if not needed. By creating a single vector then less
On 26/01/17 20:56, Andrew Pinski wrote:
Hi,
This patch enables -fprefetch-loop-arrays for -mcpu=thunderxt88 and
-mcpu=thunderxt88p1. I filled out the tuning structures for both
thunderx and thunderx2t99. No other core current enables software
prefetching so I set them to 0 which does not ch
On Fri, Jan 27, 2017 at 10:30 AM, Tamar Christina
wrote:
> Hi all,
>
> This fixes (PR78142) by only creating one vector in the char case.
> r241590 is causing more registers to be used and so
> the SP registered happens to be picked and used.
>
> This test I believe was checking explicitly that th
On 01/26/2017 07:29 AM, Richard Biener wrote:
On Thu, Jan 26, 2017 at 1:04 PM, Aldy Hernandez wrote:
On 01/24/2017 07:23 AM, Richard Biener wrote:
Your initial on-demand approach is fine to catch some of the cases but it
will not handle those for which we'd need post-dominance.
I guess we c
On Fri, Jan 27, 2017 at 1:27 AM, Andrew Pinski wrote:
> On Thu, Jan 26, 2017 at 5:19 PM, Segher Boessenkool
> wrote:
>> On Thu, Jan 26, 2017 at 05:00:44PM -0800, Andrew Pinski wrote:
>>> On Thu, Jan 26, 2017 at 4:38 PM, Segher Boessenkool
>>> wrote:
>>> > Scheduling should never move very expens
The following restores forceful propagation of assert-exprs from SSA
names which we know will restore valid IL even if the source is
abnormal.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2017-01-27 Richard Biener
PR tree-optimization/79244
* tree-
The following fixes a reported slowdown in 171.swim due to "better"
loop distribution dependence analysis. We really should apply
the (weak) costing model also to builtin partitions.
(and work on a better one so we can enable loop distribution by
default at -O3)
Bootstrapped on x86_64-unknown-l
Hi!
Richard reported too many resources required for this test, on a fast
8c16ht box I get for
time make check-g++ RUNTESTFLAGS=cilk-plus.exp=fib-opr*
real0m17.801s
user2m8.345s
sys 0m0.734s
With the following patch that I've installed after IRC discussions I get:
real0m3.953s
user
A slightly adjusted testcase of the PR shows my lame attempt at
fixing the issue easily breaks down. So the following implements
the full solution to sinking common asserts.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2017-01-27 Richard Biener
PR tree-op
Hi,
this is the regression introduced on 32-bit SPARC by this change:
2016-11-18 Dominik Vogt
Re-apply after PR bootstrap/77359 is fixed:
2016-08-23 Dominik Vogt
* explow.c (get_dynamic_stack_size): Take known alignment of stack
pointer + STACK_DYNAMIC_OFFS
On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse wrote:
> On Thu, 26 Jan 2017, Jeff Law wrote:
>
>>> I assume this causes a regression for code like
>>>
>>> unsigned f(unsigned a){
>>> unsigned b=a+1;
>>> if(b>> return b;
>>> }
>>
>> Yes. The transformation ruins the conversion into ADD_OVERFL
On Thu, Jan 26, 2017 at 9:56 PM, Andrew Pinski wrote:
> Hi,
> This patch enables -fprefetch-loop-arrays for -mcpu=thunderxt88 and
> -mcpu=thunderxt88p1. I filled out the tuning structures for both
> thunderx and thunderx2t99. No other core current enables software
> prefetching so I set them t
On Fri, Jan 27, 2017 at 1:10 PM, Richard Biener
wrote:
> On Thu, Jan 26, 2017 at 9:56 PM, Andrew Pinski wrote:
>> Hi,
>> This patch enables -fprefetch-loop-arrays for -mcpu=thunderxt88 and
>> -mcpu=thunderxt88p1. I filled out the tuning structures for both
>> thunderx and thunderx2t99. No oth
On Thu, Jan 26, 2017 at 3:56 PM, Andre Vieira (lists)
wrote:
> On 20/01/17 14:08, Ramana Radhakrishnan wrote:
>> On Wed, Dec 28, 2016 at 9:58 AM, Andre Vieira (lists)
>> wrote:
>>> On 29/11/16 09:45, Andre Vieira (lists) wrote:
On 17/11/16 10:00, Ramana Radhakrishnan wrote:
> On Thu, Oct
On Fri, Jan 27, 2017 at 1:38 AM, Segher Boessenkool
wrote:
> Scheduling should never move very expensive instructions to places they
> are executed more frequently. This patch fixes that, reducing the
> execution time of c-ray by over 40% (I tested on a BE Power7 system).
>
> Is there some existi
On Thu, Jan 26, 2017 at 5:52 PM, David Malcolm wrote:
> The "internals" documentation has a "Testsuites" chapter; this patch
> adds some notes to it, describing the __GIMPLE and __RTL extensions
> to the C frontend.
>
> Builds; passed visual inspection of .info, .html, .pdf. and .dvi.
>
> OK for t
On Fri, Jan 27, 2017 at 01:15:27PM +0100, Richard Biener wrote:
> As both SQRT and DIV may trap I wonder how we can end up speculating
> them at all?
The testcase uses -ffast-math.
> Ok, maybe with -fno-trapping-math we don't consider that case but even
> then generating
> a NaN is usually dreadf
On Fri, Jan 27, 2017 at 11:32:32AM +, Ramana Radhakrishnan wrote:
> >>> Seems like it should be checking the insn cost and compare that
> >>> against some parameter. That is possibly set by the target if needed.
> >>
> >> But what is "insn cost"? Latency is no good at all -- we *want* insns
>
On 01/27/2017 02:19 AM, Segher Boessenkool wrote:
But what is "insn cost"? Latency is no good at all -- we *want* insns
with higher latency to be earlier. fsqrt is not pipelined, and that is
what makes it so costly. (This isn't modeled in the scheduling
description btw: that would make the au
Jason,
I happened to be working on 67273, noticed a problem with my 77585 fix,
and coincidentally 79253 got filed, which this also fixes.
In 67253, Wshadow checking was getting confused when determining the
return type of an instantiated lambda.
template void Foo (T &&lambda) {
int ARG =
On 01/25/2017 05:09 PM, Jason Merrill wrote:
Something smaller would be moving the call to deduce_inheriting_ctor
to build_over_call; we can get away with that because calling is the
only way to refer to a constructor. What do you think of this
approach?
LGTM, thanks!
nathan
--
Nathan Sidwel
This PR seems to be curable by fixing up the CFG a little earlier.
Bootstrapped and tested on x86_64-linux, and it seems to cure the
testcase with a ppc cross. I'd appreciate if someone ran full ppc tests
with this though. Ok?
Bernd
PR rtl-optimization/79194
* cprop.c (one_cprop_pass): Move
FAIL: c-c++-common/Wduplicated-branches-13.c -std=gnu++98 (test for excess
errors)
Excess errors:
/daten/aranym/gcc/gcc-20170127/gcc/testsuite/c-c++-common/Wduplicated-branches-13.c:11:7:
warning: this decimal constant is unsigned only in ISO C90
/daten/aranym/gcc/gcc-20170127/gcc/testsuite/c-c
On Fri, Jan 27, 2017 at 02:18:10PM +0100, Andreas Schwab wrote:
> FAIL: c-c++-common/Wduplicated-branches-13.c -std=gnu++98 (test for excess
> errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20170127/gcc/testsuite/c-c++-common/Wduplicated-branches-13.c:11:7:
> warning: this deci
On Fri, Jan 27, 2017 at 1:38 PM, Segher Boessenkool
wrote:
> On Fri, Jan 27, 2017 at 01:15:27PM +0100, Richard Biener wrote:
>> As both SQRT and DIV may trap I wonder how we can end up speculating
>> them at all?
>
> The testcase uses -ffast-math.
>
>> Ok, maybe with -fno-trapping-math we don't co
On 01/27/2017 01:02 PM, Eric Botcazou wrote:
The attached
patch is a middle ground between the previously working and currently broken
situations: if the back-end defines STACK_DYNAMIC_OFFSET, then the middle-end
assumes that STACK_DYNAMIC_OFFSET maintains the alignment; if it doesn't,
which mean
On Fri, Jan 27, 2017 at 01:43:30PM +0100, Bernd Schmidt wrote:
> On 01/27/2017 02:19 AM, Segher Boessenkool wrote:
>
> >But what is "insn cost"? Latency is no good at all -- we *want* insns
> >with higher latency to be earlier. fsqrt is not pipelined, and that is
> >what makes it so costly. (Th
On Fri, Jan 27, 2017 at 02:30:49PM +0100, Richard Biener wrote:
> >> Ok, maybe with -fno-trapping-math we don't consider that case but even
> >> then generating
> >> a NaN is usually dreadfully slow so avoiding speculation of such insns
> >> looks good in
> >> any case (w/o considering its cost).
>
Hi,
I have just committed the patch, as it is, except that a couple of
two-spaces-after Pekka's name in Changelogs had already been corrected
(sorry for that mistake) and I have also
On Fri, Jan 27, 2017 at 10:31:34AM +0200, Pekka Jääskeläinen wrote:
> --- a/gcc/brig/ChangeLog
> +++ b/gcc/brig/Ch
On Fri, 2017-01-27 at 13:20 +0100, Richard Biener wrote:
> On Thu, Jan 26, 2017 at 5:52 PM, David Malcolm
> wrote:
> > The "internals" documentation has a "Testsuites" chapter; this
> > patch
> > adds some notes to it, describing the __GIMPLE and __RTL extensions
> > to the C frontend.
> >
> > Bu
On Wed, Jan 25, 2017 at 4:25 PM, Segher Boessenkool
wrote:
> On Wed, Jan 25, 2017 at 04:08:54PM +, Bin.Cheng wrote:
>> > I was worried this patch would prevent too many other optimisations,
>> > so I looked into better options. I didn't find any. I tested the
>> > effects of the patch on 31
This patch to libgo updates to the go1.8rc3 release (release candidate
3 for the Go 1.8 release). Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: libgo/MERGE
===
--- libgo/MERGE (revision
While experimenting with some new OpenACC benchmarks, I noticed that
gfortran errors when the user explicitly marks loop induction variables
as private. I applied this patch to gomp-4_0-branch to resolve that problem.
Cesar
2017-01-26 Cesar Philippidis
gcc/fortran/
* openmp.c (gfc_resolve_oa
In libgo the runtime.dbgvars initializer looks like
var dbgvars = []dbgVar{
{"allocfreetrace", &debug.allocfreetrace},
}
Because the field address was not recognized as valid for a static
initializer, the variable was initialized at runtime. Normally that
would be fine, but for the runtime p
The fsel define_insn uses fpr_reg_operand for its predicates. This
won't work because passes can put a hard register in the operands: in
the testcase, combine likes to forward the parameter registers to what
then is still an smin, and then split1 uses "*s3_fpr"
(which has gpc_reg_operand). And th
On Fri, Jan 27, 2017 at 07:02:45AM -0800, Cesar Philippidis wrote:
> While experimenting with some new OpenACC benchmarks, I noticed that
> gfortran errors when the user explicitly marks loop induction variables
> as private. I applied this patch to gomp-4_0-branch to resolve that problem.
>
> Ces
On 01/27/2017 07:07 AM, Jakub Jelinek wrote:
> On Fri, Jan 27, 2017 at 07:02:45AM -0800, Cesar Philippidis wrote:
>> diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
>> index 61940d7..2782a8d 100644
>> --- a/gcc/fortran/openmp.c
>> +++ b/gcc/fortran/openmp.c
>> @@ -5192,7 +5192,8 @@ gfc_re
On 01/27/2017 06:55 AM, Bernd Schmidt wrote:
> I'd appreciate if someone ran full ppc tests with this though.
I've started testing it on PowerPC, will post results when I have them.
-Pat
On 01/27/2017 12:44 AM, Markus Trippelsdorf wrote:
On 2017.01.22 at 16:53 -0700, Martin Sebor wrote:
This is the last patch in the series. It adds logic to handle
non-constant width and precision with range information to help
reduce both false positives false negatives. The patch replaces
the
This patch does the following two things:
1) Enable GOMP_MAP_FIRSTPRIVATE_INT in OpenaCC.
2) Extends the 'INT' values to handle floats and doubles via type
casting.
OpenACC handles OMP_CLAUSE_FIRSTPRIVATE slightly different to OpenMP;
lower_omp_target changes it to a data map clause. Conseq
On Fri, Jan 27, 2017 at 4:11 AM, Richard Biener
wrote:
> On Fri, Jan 27, 2017 at 1:10 PM, Richard Biener
> wrote:
>> On Thu, Jan 26, 2017 at 9:56 PM, Andrew Pinski wrote:
>>> Hi,
>>> This patch enables -fprefetch-loop-arrays for -mcpu=thunderxt88 and
>>> -mcpu=thunderxt88p1. I filled out the
On 2017.01.27 at 08:45 -0700, Martin Sebor wrote:
> On 01/27/2017 12:44 AM, Markus Trippelsdorf wrote:
> > On 2017.01.22 at 16:53 -0700, Martin Sebor wrote:
> > > This is the last patch in the series. It adds logic to handle
> > > non-constant width and precision with range information to help
> >
> On Jan 26, 2017, at 6:40 PM, Segher Boessenkool
> wrote:
>
> On Thu, Jan 26, 2017 at 05:31:16PM -0600, Bill Schmidt wrote:
>>> So for older targets it used to run the final, but not after the patch; and
>>> for newer targets it used to not run it, but it does after the patch? So
>>> it is me
This patch optimizes GOMP_MAP_TO_PSET in libgomp by installing the
remapped pointer to the array data directly in the PSET, instead of
uploading it separately with GOMP_MAP_POINTER. Effectively this
eliminates the GOMP_MAP_POINTER that is associated with the PSET,
thereby eliminating an additional
The following patch to the website adds -fdiagnostics-generate-patch to
gcc 7's changes.html.
It consolidates the documentation with that for -fdiagnostics-parseable
-fixits, so that they can share an example.
Successfully validated.
OK to commit?Index: htdocs/gcc-7/changes.html
This patch adds a description for the following warnings:
-Wimplicit-fallthrough
-Wpointer-compare
-Wduplicated-branches
-Wrestrict
-Wmemset-elt-size
-Wint-in-bool-context
-Wswitch-unreachable
-Wexpansion-to-defined
-Wregister
-Wvla-larger-than=N
-Wduplicate-decl-specifier
-Waligned-new
-Wdangling
This implements the strong exception-safety guarantee that is required
by [string.require] p2, which the new string can fail to meet when
propagate_on_container_copy_assignment (POCCA) is true.
The solution is to define a helper that takes ownership of the
string's memory (and also the associated
Hi!
This patch attempts to document some new features (without warnings,
those are partially covered by Marek's patch, C++ FE (would be nice
to document -faligned-new, -fnew-inheriting-ctors, -fnew-ttp-matching,
-fstrong-eval-order and what from C++ is supported) and the BRIG FE).
Ok for wwwdocs?
Hi Jakub,
On 27/01/17 16:30, Jakub Jelinek wrote:
Hi!
This patch attempts to document some new features (without warnings,
those are partially covered by Marek's patch, C++ FE (would be nice
to document -faligned-new, -fnew-inheriting-ctors, -fnew-ttp-matching,
-fstrong-eval-order and what from
On Fri, Jan 27, 2017 at 05:13:22PM +0100, Marek Polacek wrote:
> +-Wregister warns about uses of register storage
> specifier.
> +
For -Wregister I think it would be better to write more:
-Wregister warns about uses of register
storage
specifier. In C++17 this keyword
On Fri, Jan 27, 2017 at 04:34:53PM +, Kyrill Tkachov wrote:
> > +
> > PowerPC / PowerPC64 / RS6000
> >
> > The PowerPC port now uses LRA by default.
> > GCC now diagnoses inline assembly that clobbers register r2.
> > This has always been invalid code, and is no longer quietl
On 01/27/2017 06:43 AM, Bernd Schmidt wrote:
On 01/27/2017 01:02 PM, Eric Botcazou wrote:
The attached
patch is a middle ground between the previously working and currently
broken
situations: if the back-end defines STACK_DYNAMIC_OFFSET, then the
middle-end
assumes that STACK_DYNAMIC_OFFSET main
On Thu, Jan 26, 2017 at 9:11 PM, Alexandre Oliva wrote:
> - introduced, new_friend can be called after the befriended class is
> + introduced, new_friend can be called after the befriending class is
s/new/add/ in the comment, too.
> +/* Build a template-dependent template type id (e.g., T).
The following patch permits to compile last 3 test cases on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 244989.
Index: ChangeLog
===
--- Chang
On 01/27/2017 02:45 AM, Rainer Orth wrote:
Martin Sebor writes:
The improvements to the handling of flexible array members in
C++ in GCC 6 inadvertently removed the pedantic warnings GCC
used to issue for their declarations. The attached patch
restores it.
After this patch, I get
FAIL: obj
On Fri, Jan 27, 2017 at 05:36:48PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 27, 2017 at 05:13:22PM +0100, Marek Polacek wrote:
> > +-Wregister warns about uses of register storage
> > specifier.
> > +
>
> For -Wregister I think it would be better to write more:
> -Wregister warns
This patch partially enables GOMP_MAP_FIRSTPRIVATE_POINTER in gfortran.
gfortran still falls back to GOMP_MAP_POINTER for arrays with
descriptors and derived types. The limitation on derived types is there
because we don't have much test coverage for it, and this patch series
was more exploratory f
On Jan 27 2017, Martin Sebor wrote:
> FWIW, I could avoid this awkward setup if I had just one repo for all
> my changes, shared across my various machines. Unfortunately, for it
> to really work I would also need to be able to commit using Git rather
> than Subversion which doesn't work. At le
On 01/27/2017 09:40 AM, Pat Haugen wrote:
> On 01/27/2017 06:55 AM, Bernd Schmidt wrote:
>> I'd appreciate if someone ran full ppc tests with this though.
> I've started testing it on PowerPC, will post results when I have them.
Bootstrap/regtest on PowerPC was fine.
-Pat
On 01/27/2017 07:19 AM, Segher Boessenkool wrote:
On Fri, Jan 27, 2017 at 02:30:49PM +0100, Richard Biener wrote:
Ok, maybe with -fno-trapping-math we don't consider that case but even
then generating
a NaN is usually dreadfully slow so avoiding speculation of such insns
looks good in
any case (
On 01/27/2017 04:32 AM, Ramana Radhakrishnan wrote:
On Fri, Jan 27, 2017 at 1:27 AM, Andrew Pinski wrote:
On Thu, Jan 26, 2017 at 5:19 PM, Segher Boessenkool
wrote:
On Thu, Jan 26, 2017 at 05:00:44PM -0800, Andrew Pinski wrote:
On Thu, Jan 26, 2017 at 4:38 PM, Segher Boessenkool
wrote:
Sch
This patch changes the generated sequence for builtin expansion of
memcmp to one that is actually correct. The old sequence did not work
right if the subf overflowed subtracting two 64-bit chunks, or if extsw
overflowed after subtraction of two 32-bit chunks. Included is an
expansion of the memcmp-
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71374
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 244991.
Index: ChangeLog
===
--- ChangeLog (revision 244990)
+++ Change
On 01/27/2017 05:43 AM, Bernd Schmidt wrote:
On 01/27/2017 02:19 AM, Segher Boessenkool wrote:
But what is "insn cost"? Latency is no good at all -- we *want* insns
with higher latency to be earlier. fsqrt is not pipelined, and that is
what makes it so costly. (This isn't modeled in the sche
On Fri, Jan 27, 2017 at 11:56 AM, Martin Sebor wrote:
> FWIW, I could avoid this awkward setup if I had just one repo for all
> my changes, shared across my various machines. Unfortunately, for it
> to really work I would also need to be able to commit using Git rather
> than Subversion which doe
On 01/27/2017 05:08 AM, Richard Biener wrote:
On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse wrote:
On Thu, 26 Jan 2017, Jeff Law wrote:
I assume this causes a regression for code like
unsigned f(unsigned a){
unsigned b=a+1;
if(b
Yes. The transformation ruins the conversion into ADD_OVE
On Fri, Jan 27, 2017 at 10:02:41AM -0600, Bill Schmidt wrote:
> > For the record: approved for trunk. Thanks!
> >
> Would it be all right to back port this to GCC 5 and 6 after some burn-in?
> I see now that the bug was reported against GCC 5.
Sure. It only fixes a testcase so it won't really h
On 01/27/2017 10:47 AM, Pat Haugen wrote:
On 01/27/2017 09:40 AM, Pat Haugen wrote:
On 01/27/2017 06:55 AM, Bernd Schmidt wrote:
I'd appreciate if someone ran full ppc tests with this though.
I've started testing it on PowerPC, will post results when I have them.
Bootstrap/regtest on PowerPC
On 01/27/2017 11:20 AM, Jason Merrill wrote:
On Fri, Jan 27, 2017 at 11:56 AM, Martin Sebor wrote:
FWIW, I could avoid this awkward setup if I had just one repo for all
my changes, shared across my various machines. Unfortunately, for it
to really work I would also need to be able to commit us
On Fri, Jan 27, 2017 at 05:38:17PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 27, 2017 at 04:34:53PM +, Kyrill Tkachov wrote:
> > > +
> > > PowerPC / PowerPC64 / RS6000
> > >
> > > The PowerPC port now uses LRA by default.
> > > GCC now diagnoses inline assembly that clobbers regist
On Fri, 27 Jan 2017, Jakub Jelinek wrote:
> For -Wregister I think it would be better to write more:
> -Wregister warns about uses of register
> storage
> specifier. In C++17 this keyword has been removed and for C++17
> this is a pedantic warning enabled by default. The
On Fri, 27 Jan 2017, David Malcolm wrote:
> The following patch to the website adds -fdiagnostics-generate-patch
> to gcc 7's changes.html.
>
> It consolidates the documentation with that for -fdiagnostics-parseable
> -fixits, so that they can share an example.
This looks fine, thank you, David!
On Fri, Jan 27, 2017 at 09:32:05PM +0100, Gerald Pfeifer wrote:
> On Fri, 27 Jan 2017, Jakub Jelinek wrote:
> > For -Wregister I think it would be better to write more:
> > -Wregister warns about uses of register
> > storage
> > specifier. In C++17 this keyword has been removed and
On 01/26/2017 03:39 AM, Jan Hubicka wrote:
On Thu, Jan 26, 2017 at 11:04 AM, Jan Hubicka wrote:
+ if (!contains_hot_bb && speed_p)
+ contains_hot_bb |= optimize_bb_for_speed_p (bb);
+
Hmm, but you are also counting the destination of the threading here
which we will
not duplicate.
On 01/25/2017 02:12 PM, Martin Sebor wrote:
While putting together examples for the GCC 7 changes document
I noticed that a few of the buffer overflow warnings issued by
-Wstringop-overflow are defeated by Glibc's macros for string
manipulation functions like strncat and strncpy.
While testing m
Applied.
Gerald
Index: cli.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cli.html,v
retrieving revision 1.28
diff -u -r1.28 cli.html
--- cli.html28 May 2016 12:53:29 - 1.28
+++ cli.html27 Jan 2017 21:08:14 -000
On Fri, Jan 27, 2017 at 02:05:40PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 27, 2017 at 05:38:17PM +0100, Jakub Jelinek wrote:
> > On Fri, Jan 27, 2017 at 04:34:53PM +, Kyrill Tkachov wrote:
> > > > +
> > > > PowerPC / PowerPC64 / RS6000
> > > >
> > > > The PowerPC port now uses
On 01/27/2017 11:20 AM, Jason Merrill wrote:
On Fri, Jan 27, 2017 at 11:56 AM, Martin Sebor wrote:
FWIW, I could avoid this awkward setup if I had just one repo for all
my changes, shared across my various machines. Unfortunately, for it
to really work I would also need to be able to commit us
On January 27, 2017 7:30:07 PM GMT+01:00, Jeff Law wrote:
>On 01/27/2017 05:08 AM, Richard Biener wrote:
>> On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse
>wrote:
>>> On Thu, 26 Jan 2017, Jeff Law wrote:
>>>
> I assume this causes a regression for code like
>
> unsigned f(unsigned a){
On Fri, Jan 27, 2017 at 11:04:42AM -0700, Jeff Law wrote:
> >Well, the only thing from the pipeline description that is used here is
> >the insn latency, which isn't all that much higher than "normal" FP insns.
> >And simply "not decribed properly" won't do much good -- if we could
> >(without blow
On 01/27/2017 02:35 PM, Richard Biener wrote:
On January 27, 2017 7:30:07 PM GMT+01:00, Jeff Law wrote:
On 01/27/2017 05:08 AM, Richard Biener wrote:
On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse
wrote:
On Thu, 26 Jan 2017, Jeff Law wrote:
I assume this causes a regression for code like
On Fri, Jan 27, 2017 at 10:15:37PM +0100, Jakub Jelinek wrote:
> > > > AArch64 also implements these hooks and so benefits from the
> > > > optimisation as well.
> > > > Perhaps move this to the general optimizer improvements section and
> > > > mention it's only
> > > > enabled for powerpc and a
On 01/27/2017 03:01 PM, Segher Boessenkool wrote:
On Fri, Jan 27, 2017 at 11:04:42AM -0700, Jeff Law wrote:
Well, the only thing from the pipeline description that is used here is
the insn latency, which isn't all that much higher than "normal" FP insns.
And simply "not decribed properly" won't
On 01/27/2017 02:35 PM, Richard Biener wrote:
On January 27, 2017 7:30:07 PM GMT+01:00, Jeff Law wrote:
On 01/27/2017 05:08 AM, Richard Biener wrote:
On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse
wrote:
On Thu, 26 Jan 2017, Jeff Law wrote:
I assume this causes a regression for code like
On Fri, Jan 27, 2017 at 10:30 AM, Jeff Law wrote:
> On 01/27/2017 05:08 AM, Richard Biener wrote:
>>
>> On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse
>> wrote:
>>>
>>> On Thu, 26 Jan 2017, Jeff Law wrote:
>>>
> I assume this causes a regression for code like
>
> unsigned f(unsigned a)
On Fri, Jan 27, 2017 at 03:17:42PM -0700, Jeff Law wrote:
> >>My preference would be somehow either mark those insns as not fully
> >>modeled and avoid speculating on them. Or invent a target hook to allow
> >>the scheduler to query the backend.
> >
> >This is my preference -- have it in one locat
1 - 100 of 107 matches
Mail list logo
