On Tue, 7 Feb 2017, Jeff Law wrote:
* tree-vrp.c (extract_range_from_binary_expr_1): For EXACT_DIV_EXPR,
if the numerator has the range ~[0,0] make the resultant range ~[0,0].
If I understand correctly, for x /[ex] 4 with x!=0, we currently split
~[0,0] into [INT_MIN,-1] and [1,INT_MAX], then
On Sun, 12 Feb 2017, Marc Glisse wrote:
On Tue, 7 Feb 2017, Jakub Jelinek wrote:
* tree-vrp.c (simplify_div_or_mod_using_ranges): If op1 is not
constant, but SSA_NAME with a known integer range, use the minimum
of that range instead of op1 to determine if modulo can be
On Tue, 7 Feb 2017, Jakub Jelinek wrote:
* tree-vrp.c (simplify_div_or_mod_using_ranges): If op1 is not
constant, but SSA_NAME with a known integer range, use the minimum
of that range instead of op1 to determine if modulo can be replaced
with its first operand.
I noticed a bunch of copy-editing issues in the "ARC Options" section of
invoke.texi. I'm willing to take a stab at fixing them, but I need some
technical assistance since I'm not familiar with the details of this
architecture myself.
* In e.g. "Compile for ARC 600 cpu with norm instruction e
Hi Matthew,
Please find attached updated patch as per our offline discussion.
I have disabled return in registers for all vector float types, and updated the
test case accordingly.
Ok for trunk?
- Thanks and regards,
Sameera D.
From: Sameera Deshpande
There were two problems with this testcase:
1) In a template non-dependent context, we try to do full semantic
processing and then roll back and build an expression with the
original operands and the computed type. This was failing with a
CONSTRUCTOR operand, since digest_init changes the content
This patch fixes an issue I spotted while trying to spell-check the GCC
manual sources. The preprocessor documentation was mostly using
"stringify" (verb) and "stringification" (noun) to document the #
operator, instead of the C standard's "stringize"/"stringizing",
respectively. Using made-u
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:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-7.1-b20170101.de.po', h
Running a spell check on the GCC manual sources turns up too many false
positives to be useful for exhaustive correctness checking, but I did
spot some obvious mistakes in the output. I've got a list of a few
things that need more extensive rewriting, but this patch takes care of
the easy case
Dear all,
please find in attachment a new patch following the discussion at
https://gcc.gnu.org/ml/fortran/2017-01/msg00054.html.
Suggestions on how to fix potential issues are more than welcome.
Regards,
Alessandro
commit e2dad3cc56447daea85c147f08b3f58a8e70617f
Author: Alessandro Fanfarillo
Da
With the alloca.h header fixed, the skip is no longer needed on hppa*-*-*.
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2017-02-11 John David Anglin
* testsuite/libgomp.oacc-c-c++-common/loop-dim-default.c: Remove
h
The alloca.h header on hppa-hpux needs to include sys/stdsyms.h to define
_PROTOTYPES, etc.
It was assumed that stddef.h would include sys/stdsyms.h. However, the HP
version of stddef.h is
now replaced by a GCC version and it doesn't include sys/stdsyms.h.
The attached change modifies alloca.h
These new static assertions fail if the deleter insists on lvalues (I
don't know why somebody would do that, but it caused a build failure
for fuse-encfs). Since the deleter is invoked as an lvalue and passed
an lvalue, this makes the assertion check the right thing.
PR libstdc++/79467
Whitespace fixes.
* include/bits/atomic_base.h: Re-indent.
Tested powerpc64le-linux, committed to trunk.
commit 05bfff4c39fcceeea9aa8b44db0972020626bea0
Author: Jonathan Wakely
Date: Sat Feb 11 20:15:14 2017 +
Adjust whitespace in
* include/bits/atomic_base.h:
Hi!
In order to have fast unwinding (which doesn't use unwind info)
work properly on s390{,x}, -mbackchain is needed (similarly to
-fno-omit-frame-pointer needed everywhere and -mno-omit-leaf-frame-pointer
on x86). Committed to trunk:
2017-02-11 Jakub Jelinek
PR sanitizer/79341
Hi!
We got a report that man gcc refers to too old version of OpenMP.
Fixed thusly, committed to trunk.
2017-02-11 Jakub Jelinek
* doc/invoke.texi (fopenmp): Bump OpenMP version from 4.0 to
4.5.
--- gcc/doc/invoke.texi.jj 2017-02-07 16:40:43.0 +0100
+++ gcc/doc/i
Hi,
this patch prevents tail recurisve optimization for functions recursing over
interposable symbol with an alias.
Bootstrapped/regtested x86_64-linux, comitted.
PR tree-ssa/56727
* gcc.dg/tree-ssa/pr56727.c: New testcase.
* ipa-utils.c (recursive_call_p): Be more careful
We were complaining about a function with deduced return type in C++11
mode, but leaving it alone and then assuming it couldn't have happened
later. Fixed by removing that assumption.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 94709718a2b25596677385adbf8a298c621ff8d0
Author: Jason Merr
On Wed, Feb 08, 2017 at 04:00:35PM +, Paul Richard Thomas wrote:
>
> The attached rework of the patch functions in the same way as
> yesterday's but is based in resolve.c rather than trans-decl.c. It
> looks to me to be by far cleaner.
>
> Bootstraps and regtests on FC23/x86_64 - OK for trunk
On Wed, Feb 08, 2017 at 10:17:10PM +0100, Thomas Koenig wrote:
> + && !gfc_notify_std (GFC_STD_F2003, "Transformational function
> %qs "
> + "invalid as initialization expression is
> at %L",
> + name, &expr->where))
OK after you fi
Hi,
c-ray has regressed somewhat. This is largely caused by bad luck - better
early optimizations results in different inling order which makes big_speedup
hint to barely not match.
This patch decreases big_speedup threshold and slightly improves the estimation
of speedups by considering loop str
Ping!
On 8 February 2017 at 16:00, Paul Richard Thomas
wrote:
> Dear All,
>
> The attached rework of the patch functions in the same way as
> yesterday's but is based in resolve.c rather than trans-decl.c. It
> looks to me to be by far cleaner.
>
> Bootstraps and regtests on FC23/x86_64 - OK for
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 French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-7.1-b20170101.fr.po', h
This broke when cvsweb.cgi was removed for gcc.gnu.org / sourcware.org;
apparently there is no replacement in place to access CVS repositories,
so I had to remove the link.
Applied (revision 245355).
Gerald
2017-02-11 Gerald Pfeifer
* doc/contrib.texi (Contributors): Remove broken li
24 matches
Mail list logo
