The following patch fixes a missed optimization caused by niter analysis
returning a complex pointer subtraction expression instead of a constant
for a loop with a pointer IV (it looks like pointer IVs are quite common
in libstdc++).
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Not a reg
As Jakub also pointed out, there are various places where our
BUGURL is defined (not just used).
For libstdc++, Jonathan already filed gcc.gnu.org/PR79422, and
I'll tackle the others one by one, involving the respective
maintainers to see whether there is more to be done than just
updating the st
In my original submission, which Arnaud approved, I failed to copy
gcc-patches, so let me share the committed patch (revision 245297)
here as well.
(Note that there is an extra space after the URL so that copy&paste
or clicking works.)
Gerald
2017-02-09 Gerald Pfeifer
* comperr.adb:
[ Copying libcpp maintainers ]
On Thu, 9 Feb 2017, Gerald Pfeifer wrote:
> As Jakub also pointed out, there are various places where our
> BUGURL is defined (not just used).
This is the patch for libcpp.
Applied for now, though I'm wondering whether there's more than just
updating the URL that
Hi again,
On 14/01/2017 15:43, Jason Merrill wrote:
OK.
As you may or may not have noticed, I had to revert the patch because it
caused the regression of
tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc during error
recovery: an ICE happens in remap_decl when build_variant_type_copy is
c
On Tue, Feb 07, 2017 at 08:01:44AM -0800, Mike Stump wrote:
> On Feb 7, 2017, at 2:20 AM, Rainer Orth wrote:
> > No. In fact, I'd go for something like this:
> >
> > 2017-02-07 Dominik Vogt
> > Rainer Orth
> >
> > * g++.dg/tls/thread_local-order2.C: Only xfail execution on
> >
Hi Dominik,
>> I think that addresses most all known issues. I'll pre-appove
>> any additional targets people find as trivial. For example, if
>> darwin10 doesn't pass, then *-*-darwin10* would be fine to add
>> if that fixes the issue. I don't happen to have one that old to
>> just test on.
>
On Feb 9, 2017, at 1:31 AM, Dominik Vogt wrote:
>
> Here's a case of the test failing now:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427
>
> Powerpc64 BE with glibc-2.17 (2.18 reported to work). I'd be
> inclined to reply "upgrade Glibc to get rid of the FAIL" as that
> is what the t
Hi Mike,
> On Feb 9, 2017, at 1:31 AM, Dominik Vogt wrote:
>>
>> Here's a case of the test failing now:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427
>>
>> Powerpc64 BE with glibc-2.17 (2.18 reported to work). I'd be
>> inclined to reply "upgrade Glibc to get rid of the FAIL" as t
On Wed, Feb 8, 2017 at 9:23 PM, Mikael Morin wrote:
> Le 08/02/2017 à 10:25, FX a écrit :
>>
>> Hi Steve,
>>
>> I see Mikael has okayed the patch, but I did not have any time to comment
>> prior. I wanted to note that:
>>
>> - the choice was deliberate, as the standard allows us to choose which
>
[ Copying libquadmath maintainers ]
On Thu, 9 Feb 2017, Gerald Pfeifer wrote:
> As Jakub also pointed out, there are various places where our
> BUGURL is defined (not just used).
This is the patch for libquadmath.
Applied for now, though I'm wondering whether indeed we do have to
redefine this h
On Thu, Feb 09, 2017 at 11:59:36AM +0100, Gerald Pfeifer wrote:
> [ Copying libquadmath maintainers ]
>
> On Thu, 9 Feb 2017, Gerald Pfeifer wrote:
> > As Jakub also pointed out, there are various places where our
> > BUGURL is defined (not just used).
>
> This is the patch for libquadmath.
>
>
>
> Or make it an alias for -fipa-bit-cp.
I double programs are going on -fno-ipa-alignment for longer term - it would be
very fragile
because inlining and other transformations could do the same.
I would just ignore it and mention that it no longer has effect in
changes.html (in entry decsrib
On Mon, May 16, 2016 at 01:09:28PM +0200, Eric Botcazou wrote:
> This patch cleans up the implementation of packed array types, which is shared
> between the front-end proper and gigi (because the middle-end doesn't support
> bit packing for array types, unlike for record types through bit fields).
On Wed, Feb 08, 2017 at 07:35:09PM -0500, John David Anglin wrote:
> The libgomp.oacc-c-c++-common/loop-dim-default.c test uses asms and needs to
> be skipped on hppa.
This broke the test everywhere, because the dg-skip-if is not in a comment.
I've fixed it (below), but am not sure why you had to
Hi!
Mentioning an automatic variable in #pragma omp declare target
to or link clauses doesn't make any sense, but I can't find anything
in OpenMP that would say it is invalid.
Thus the following patch accepts it and ignores (except for the
diagnostics when a var is mentioned in both to and link o
Hi!
This patch fixes error-recovery on the following testcases.
{push,pop}_omp_privatization_clauses should not be used outside of
functions, fixed by diagnosing it/punting it before we call those.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2017-02-09 Jakub Jelin
Hi!
The following testcase ICEs because we've failed to gimplify the array
bounds. The array size in bytes e.g. is ((sizetype) (1 / 0) * 4) but
is TREE_CONSTANT and thus is_gimple_sizepos said that nothing needs to be
done for it. In reality, the code actually expects INTEGER_CSTs or
VAR_DECLs (
On Sun, 5 Feb 2017, Jonathan Wakely wrote:
> ANSI sells the standard for a much more reasonable price than ISO or
> any of the other national standards bodies. I think many people use
> draft standards now, rather than buying it, but for those who do want
> an official copy ANSI is the cheapest sou
On Thu, 9 Feb 2017, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs because we've failed to gimplify the array
> bounds. The array size in bytes e.g. is ((sizetype) (1 / 0) * 4) but
> is TREE_CONSTANT and thus is_gimple_sizepos said that nothing needs to be
> done for it. In reality,
On Thu, 9 Feb 2017, Gerald Pfeifer wrote:
> As Jakub also pointed out, there are various places where our
> BUGURL is defined (not just used).
So, this one I found particularly interesting.
The same URL is used four times in the same file, which begs for
a little abstraction. ;-) I did that, and
On Wed, Feb 08, 2017 at 06:47:10PM -0500, Jason Merrill wrote:
> On Wed, Feb 8, 2017 at 5:24 PM, Jakub Jelinek wrote:
> > On Wed, Feb 08, 2017 at 04:51:54PM -0500, Jason Merrill wrote:
> >> On Tue, Feb 7, 2017 at 4:30 PM, Jakub Jelinek wrote:
> >> > P0017R1 added in [dcl.init.aggr]/1 that classes
On Tue, Nov 29, 2016 at 08:23:45PM +0800, Chung-Lin Tang wrote:
> Adjusted and re-tested using the way you advised, attached updated patch.
This broke bootstrap on all arches:
../../gcc/omp-offload.c: In function ‘unsigned int
oacc_loop_auto_partitions(oacc_loop*, unsigned int, bool)’:
../../gcc/
As stated in the PR, this test now passes on aarch64, ia64, powerpc,
and s390x. This patch disables the xfails for those targets.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
Segher
2017-02-09 Segher Boessenkool
gcc/testsuite/
PR testsuite/79356
* gcc.dg
This test does not fail with -m32, so we shouldn't xfail it there.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
Segher
2017-02-09 Segher Boessenkool
gcc/testsuite/
* gcc.dg/Wtrampolines.c: Do the xfail for only 64-bit powerpc instead
of all powerpc.
---
-m32 works fine, only 64-bit still fails.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
Segher
2017-02-09 Segher Boessenkool
gcc/testsuite/
PR tree-optimization/66612
* gcc.target/powerpc/20050830-1.c: Don't xfail on 32-bit.
---
gcc/testsuite/gcc.target/
On 32-bit we of course do not generate mulld insns. This patch makes
the testcase only do the scan-assembler on 64-bit targets.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
Segher
2017-02-09 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/fold-vec-mult-lo
This is a runtime testcase so it should test p8vector_hw instead of
powerpc_p8vector_ok, or it will fail with an illegal instruction on older
processors.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
Segher
2017-02-09 Segher Boessenkool
gcc/testsuite/
* gcc.target
As discussed in the PR, this changes a call to c_parser_skip_until_found into
c_parser_skip_to_pragma_eol to avoid crashing on an assert in
c_parser_consume_token (CPP_PRAGMA_EOLs shouldn't be consumed in that way).
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2017-02-09 Marek Polacek
On Thu, Feb 09, 2017 at 05:59:34PM +0100, Marek Polacek wrote:
> As discussed in the PR, this changes a call to c_parser_skip_until_found into
> c_parser_skip_to_pragma_eol to avoid crashing on an assert in
> c_parser_consume_token (CPP_PRAGMA_EOLs shouldn't be consumed in that way).
>
> Bootstrap
For those of you not following the PR, this is a re-post of a patch that
was approved in some form a year+ ago, but was reverted because it
caused an undiagnosed bootstrap problem on AIX:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00421.html
Annoyingly, the AIX problem disappeared with some
The attached patch fixes PR 79241 on s390x. Bootstrapped and
regression tested on s390x biarch (not tested on s390).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/ChangeLog-pr79421
PR target/79421
* config/s390/s390.c
On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote:
>
> That being said, I think even with Steve's patch, it's not guaranteed
> to give you IEEE 754-2008 binary128. E.g. on IBM POWER targets,
> depending on the ABI you may get an IBM extended double (double-double
> or __ibm128) forma
Hi!
This is a big hammer approach for (ab) SSA_NAME issues in reassoc, on
the following testcase we extend the lifetime of (ab) SSA_NAME and ICE
because it can't be coalesced anymore. In theory we could try to be careful
and whenever changing something that could extend (ab) lifetime, instead
ins
On Thu, Feb 9, 2017 at 8:33 PM, Steve Kargl
wrote:
> On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote:
>>
>> That being said, I think even with Steve's patch, it's not guaranteed
>> to give you IEEE 754-2008 binary128. E.g. on IBM POWER targets,
>> depending on the ABI you may get a
79316 observed that we were rejecting default arguments in a deduction
guide, which is required by some of the usage of deduction guides in
the standard library.
79350 observed that we weren't allowing explicit on a deduction guide,
which was added at the last meeting.
This patch fixes these issu
OK.
On Thu, Feb 9, 2017 at 9:16 AM, Jakub Jelinek wrote:
> On Wed, Feb 08, 2017 at 06:47:10PM -0500, Jason Merrill wrote:
>> On Wed, Feb 8, 2017 at 5:24 PM, Jakub Jelinek wrote:
>> > On Wed, Feb 08, 2017 at 04:51:54PM -0500, Jason Merrill wrote:
>> >> On Tue, Feb 7, 2017 at 4:30 PM, Jakub Jeline
On Thu, Feb 9, 2017 at 4:08 AM, Paolo Carlini wrote:
> On 14/01/2017 15:43, Jason Merrill wrote:
>>
>> OK.
>
> As you may or may not have noticed, I had to revert the patch because it
> caused the regression of
> tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc during error recovery:
> an ICE
On 02/08/2017 05:45 AM, Richard Biener wrote:
On Tue, Feb 7, 2017 at 7:31 PM, Jeff Law wrote:
This patch addresses issues Richi raised from V1. Specifically it moves
EXACT_DIV_EXPR handling into extract_range_from_binary_expr_1 and less
aggressively uses ~[0,0] when intersecting ranges -- onl
On 02/08/2017 05:53 AM, Richard Biener wrote:
Bah.
Add a nonnull_p flag to value_range ...
/me runs...
Honestly, the way to go is ditch VR_ANTI_RANGE and make value_range be
// template
struct GTY(()) value_range
{
enum value_range_type type;
// The value range is the union of [ min[0],
On 02/09/2017 12:40 PM, Janne Blomqvist wrote:
On Thu, Feb 9, 2017 at 8:33 PM, Steve Kargl
wrote:
On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote:
That being said, I think even with Steve's patch, it's not guaranteed
to give you IEEE 754-2008 binary128. E.g. on IBM POWER targe
Basic problem is that the runtime check for a 4k boundary crossing was
checking that it didn't happen in the N bytes strncmp was being asked
to look at. But, the code generation after the check assumed it could
generate an 8-byte read and so it could step over the boundary.
The fix is to make sur
On Thu, Feb 09, 2017 at 07:35:11PM -0800, Jerry DeLisle wrote:
> On 02/09/2017 12:40 PM, Janne Blomqvist wrote:
> > On Thu, Feb 9, 2017 at 8:33 PM, Steve Kargl
> > wrote:
> >> On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote:
> >>>
> >>> That being said, I think even with Steve's pa
The bcdadd pattern has the wrong constraints. The change Meissner
supplied in PR79295 fixes the issue.
Successfully bootstrapped on ppc64le, ok for trunk if regtest also
passes?
2017-02-09 Aaron Sawdey
PR target/79295
* config/rs6000/altivec.md (bcd): Fix constraints.
--
Aar
On 02/08/2017 05:28 PM, Bernhard Reutner-Fischer wrote:
On 7 February 2017 19:40:17 CET, Daniel Santos wrote:
+{ "-mmoutline-msabi-xlogues",MASK_OUTLINE_MSABI_XLOGUES }
};
s/mm/m/
+thus reducing function size at the cost of and few extra instructions.
s/and/a/
Thanks for catc
On 8 February 2017 09:41:47 CET, Richard Biener wrote:
>On Tue, 7 Feb 2017, Jakub Jelinek wrote:
>> +/* { dg-final { scan-tree-dump-times "link_error" 0 "optimized"} }
>*/
scan-tree-dump-not would have been more expressive, FWIW.
On Thu, 9 Feb 2017, Jakub Jelinek wrote:
> Hi!
>
> This is a big hammer approach for (ab) SSA_NAME issues in reassoc, on
> the following testcase we extend the lifetime of (ab) SSA_NAME and ICE
> because it can't be coalesced anymore. In theory we could try to be careful
> and whenever changing
47 matches
Mail list logo
