libstdc++-v3: Check for TLS support on mingw
2018-02-16 Hugo Beauzée-Luyssen
* crossconfig.m4: Check for TLS support on mignw
* configure: regenerate
Index: libstdc++-v3/crossconfig.m4
===
--- libstdc++-v3/crossconfig.m4
Hi.
Sorry that it took me quite some time. The patch puts sancov pass before switch
lowering on -O0.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
The test-case now works on aarch64.
Ready to be installed?
Martin
gcc/ChangeLog:
2018-02-16 Martin Liska
P
Hi.
This fixes two typos in documentation and description of a param.
Installed as obvious.
Thanks,
Martin
gcc/ChangeLog:
2018-02-19 Martin Liska
* doc/invoke.texi: Fix typo.
* params.def (PARAM_MAX_LOOP_HEADER_INSNS): Likewise.
---
gcc/doc/invoke.texi | 2 +-
gcc/params.de
Hi,
I think there's a typo in gcc/Makefile.in, where lto-wrapper is linked
using $(ALL_COMPILERFLAGS) while it should be $(ALL_LINKERFLAGS).
I noticed this while playing with linker flags, and not seeing them
when linking lto-wrapper.
It seems obvious, but maybe I'm missing something?
OK for tru
Ping.
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00649.html
CC'ing Eric and Jeff as the patch contains a simplify-rtx.c component that I'll
need midend approval on.
Thanks everyone for your comments so far.
Kyrill
On 12/02/18 15:18, Kyrill Tkachov wrote:
Hi Richard,
On 08/02/18 20:29, Ri
Hi Thomas,
I have tested this with the new version of the patch for PR83344 - it
is OK for trunk.
Thanks
Paul
On 18 February 2018 at 16:17, Thomas Koenig wrote:
> Hello world,
>
> after Paul's fix for PR80945, the code in frontend-passes.c meant
> to circumvent this bug is no longer needed. T
Hi.
The patch was suggested by Richard Biener and then Richard Sandiford helped me
to
rewrite it using poly-int. It prevents ubsan in gimple-fold.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
And it does not trigger ubsan in the test-case in gimple-fold.c.
Ready to
Hi Janne,
Please find attached a revised version of the patch that fixes all the
issues that I know of.
Regtests on FC27/x86_64 - OK for trunk?
I have also attached a test of all the failing cases in PR83975.
However, I believe that they are all included in other associate*.f*.
Cheers
Paul
20
On Sun, Feb 18, 2018 at 8:46 PM, Jeff Law wrote:
> On 02/18/2018 11:52 AM, Yuri Gribov wrote:
>> Hi all,
>>
>> This is a second iteration of patch which gets rid of float casts in
>> comparisons when all values of casted integral type are exactly
>> representable by the float type
>> (https://gcc.
Siddhesh Poyarekar wrote:
> On Thursday 15 February 2018 07:50 PM, Wilco Dijkstra wrote:
>> So it seems to me using existing cost mechanisms is always preferable, even
>> if you
>> currently can't differentiate between loads and stores.
>
> Luis is working on address cost adjustments among other t
On Mon, Feb 19, 2018 at 2:39 PM, Paul Richard Thomas
wrote:
> Hi Janne,
>
> Please find attached a revised version of the patch that fixes all the
> issues that I know of.
>
> Regtests on FC27/x86_64 - OK for trunk?
1. The resolve.c part of the patch seems to have incorrect indentation?
2. Inste
Hi.
This changes code to be consistent:
if (!decNumberIsNegative(lhs) & decNumberIsNegative(rhs)) {
...
else if (decNumberIsQNaN(lhs) && decNumberIsSNaN(rhs)) result=+1;
That's fixed in the patch.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to
On 16/02/18 08:15, Richard Biener wrote:
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-02-16 Richard Biener
PR tree-optimization/84399
* graphite-scop-detection.c (scop_detection::stmt_simple_for_scop_p):
For operands we can analyze at
Hi,
This is fix for PR84460.
gcc/testsuite
PR target/84460
* gcc.target/i386/pr57193.c (dg-options): Add -mtune=generic.
Is it ok for trunk?
Thanks,
Sebastian
PR84460.patch
Description: PR84460.patch
On 17/02/18 00:04, Steve Ellcey wrote:
> On Thu, 2018-02-15 at 14:01 +, Richard Earnshaw (lists) wrote:
>>
>> Wouldn't it be better to call output_operand_lossage() with a suitable
>> diagnostic message? If the operand isn't in Pmode assembly will
>> (should) fail anyway.
>>
>> R.
>
> How a
On 2/15/18 3:56 PM, Will Schmidt wrote:
> -/* { dg-options "-mcpu=power8" } */
> +/* { dg-options "-maltivec -mcpu=power8" } */
Why did you add -maltivec? That flag is enabled implicitly by -mcpu=power8
which we're already using?
Peter
The C++ frontend generates a break that results in the fallthrough
warning misfiring in nested switch blocks where cases in the inner
switch block return, rendering the break pointless. The fallthrough
detection in finish_break_stmt does not work either because the
condition is encoded as an IF_ST
On 02/19/2018 08:20 AM, Peryt, Sebastian wrote:
> Hi,
>
> This is fix for PR84460.
>
> gcc/testsuite
>PR target/84460
>* gcc.target/i386/pr57193.c (dg-options): Add -mtune=generic.
>
> Is it ok for trunk?
OK. I went ahead and installed.
jeff
On 02/19/2018 06:43 AM, Martin Liška wrote:
> Hi.
>
> This changes code to be consistent:
>
> if (!decNumberIsNegative(lhs) & decNumberIsNegative(rhs)) {
> ...
>else if (decNumberIsQNaN(lhs) && decNumberIsSNaN(rhs)) result=+1;
>
> That's fixed in the patch.
> Patch can bootstrap on
On 02/19/2018 05:38 AM, Martin Liška wrote:
> Hi.
>
> The patch was suggested by Richard Biener and then Richard Sandiford helped
> me to
> rewrite it using poly-int. It prevents ubsan in gimple-fold.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> And it does no
On 02/19/2018 02:11 AM, Martin Liška wrote:
> Hi.
>
> Sorry that it took me quite some time. The patch puts sancov pass before
> switch
> lowering on -O0.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> The test-case now works on aarch64.
>
> Ready to be install
Hi Carl,
On Fri, Feb 16, 2018 at 11:53:53AM -0800, Carl Love wrote:
> The following patch fixes a GCC internal compiler error on the test
> files:
>
> gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p8.c
> gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p9.c
>
> when compiled w
Hi all,
no objections received therefore committed as r257813. Thanks for fast review
Jerry.
- Andre
On Sun, 18 Feb 2018 18:33:07 +0100
Andre Vehreschild wrote:
> Well, after discussing on IRC whether RM should be bothered, I was asked to
> simplify release managers lives and propose, that if
On 02/14/2018 07:22 AM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping these patches:
>
> PR84146 fix -fcompare-debug issues with -mcet -fcf-protection=full
> http://gcc.gnu.org/ml/gcc-patches/2018-02/msg00390.html
OK. And FWIW, I like this much more than having it be an insn note.
jeff
Hi!
The testcase that has been committed for this PR doesn't work on ilp32
targets, because both 0u - 1 and 0u - 1l are there 0xu.
The testcase originally filed had proper 0u - 1ll in the second case, which
works on all targets where long long is wider than int (not aware of any
target we
Hi!
The simd clones IPA pass is gated on
targetm.simd_clone.compute_vecsize_and_simdlen != NULL
so when we are calling expand_simd_clones later, we shouldn't call it
if it is NULL.
Bootstrapped/regtested on x86_64-linux and i686-linux, tested with
powerpc64le-linux cross on the testcase, committe
Hi!
In this case, because the corresponding variable is errorneous, we end up
with error_mark_node in LAMBDA_TYPE_EXTRA_SCOPE. This patch just makes sure
we won't crash on it. Not 100% sure if this is the best fix though.
Bootstrapped/regtested on x86_64-linux and i686-linux.
2018-02-19 Jakub
Hi!
For internal functions, we use the whole u.bits of the CALL_EXPR
for the internal function number (in this case IFN_LAUNDER), so using
the lang flags on it doesn't work. In a couple of other places
I've checked that test or set lang flags on CALL_EXPR I saw internal fns
special cased early, b
Hi,
On 19/02/2018 20:05, Jakub Jelinek wrote:
Hi!
In this case, because the corresponding variable is errorneous, we end up
with error_mark_node in LAMBDA_TYPE_EXTRA_SCOPE. This patch just makes sure
we won't crash on it. Not 100% sure if this is the best fix though.
IMHO something like the b
Hi!
At least for now, unless OpenMP 5.0 will say something different,
#pragma omp simd is not usable in constexpr, but was forgotten in this spot.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2018-02-19 Jakub Jelinek
PR c++/84430
*
On 02/19/2018 12:11 PM, Jakub Jelinek wrote:
> Hi!
>
> Many years ago Jason has added call to get_callee_fndecl, which does the
> right thing for internal functions as well as handles ADDR_EXPR and also
> casts and constant function pointers with a usable DECL_INITIAL, so while
> to fix this PR I
Yuri Gribov writes:
> Hi all,
>
> This is a second iteration of patch which gets rid of float casts in
> comparisons when all values of casted integral type are exactly
> representable by the float type
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81376). The new version
> addresses Richard's r
Hi!
Honza, do you think you could have a look at this P1 fix?
Thanks.
On Wed, Jan 31, 2018 at 10:03:51AM +, Bin Cheng wrote:
> Hi,
> This patch fixes invalid profile count information in vectorization peeling.
> Current implementation is a bit confusing for me since it tries to compute
> an
Hi!
build_cplus_new can return error_mark_node e.g. when calling a deleted
ctor or dtor, but bot_manip was assuming it will always return
AGGR_INIT_EXPR. As it is generally unsafe to set subexpressions to
error_mark_node, e.g. cp_fold ICEs if binary expression has one of its
operand error_mark_no
Hi!
While cp_parser_lambda_body which is the other finish_lambda_function
caller next to tsubst_lambda_expr temporarily increments function_depth
around that call (if not nested) to avoid GC during expand_or_defer_fn from
finish_lambda_function, tsubst_lambda_expr doesn't, and on the
lambda-ice14.
Hi!
Many years ago Jason has added call to get_callee_fndecl, which does the
right thing for internal functions as well as handles ADDR_EXPR and also
casts and constant function pointers with a usable DECL_INITIAL, so while
to fix this PR I could have added || CALL_EXPR_FN (t)) == NULL_TREE before
This testcase continues to fail for -m32 on powerpc64-linux-gnu and on AIX.
Excess errors:
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:14:10:
error: call of overloaded 'f<0>(char (*)[1])' is ambiguous
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:15:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01247.html
=== g++ tests ===
Running target unix/-m32
...
FAIL: g++.dg/template/overload15.C -std=c++11 (test for excess errors)
FAIL: g++.dg/template/overload15.C -std=c++14 (test for excess errors)
FAIL: g++.dg/template/overload15.C -std=c++
>> First, do you or your company have a copyright assignment on file with FSF?
>
> I do not. What is the process for that? I don't need a company
> assignment, an individual contributor for me will be fine.
>
> If I sign that for this project, would it also cover GCC, or do I need
> one for each?
On Mon, Feb 19, 2018 at 3:35 PM, Jakub Jelinek wrote:
> On Mon, Feb 19, 2018 at 03:31:13PM -0500, David Edelsohn wrote:
>> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01247.html
>>
>> === g++ tests ===
>>
>>
>> Running target unix/-m32
>> ...
>> FAIL: g++.dg/template/overload15.C -std=c++11
On Mon, Feb 19, 2018 at 03:20:25PM -0500, David Edelsohn wrote:
> This testcase continues to fail for -m32 on powerpc64-linux-gnu and on AIX.
>
> Excess errors:
> /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/template/overload15.C:14:10:
> error: call of overloaded 'f<0>(char (*)[1])' is ambiguou
Hi!
When cp_parser_binary_expression is called with no_toplevel_fold_p
(only for OpenMP parsing), it might create a binary op tree with
error_mark_node as one of the operands, which the rest of the FE
isn't prepared to handle.
This arranges to return error_mark_node instead.
Bootstrapped/regtest
On Mon, Feb 19, 2018 at 12:39:47PM -0800, Cary Coutant wrote:
> I've added config-patches to the conversation, so I'm hoping that
> was sufficient to get that going. Once added in the GCC tree, I
> think one can either wait for an automatic sync, or go ahead and
> submit a patch to do the sync (bu
ping
they're good patches. ask questions. I have more.
Committed as revision 257827.
> 1. The resolve.c part of the patch seems to have incorrect indentation?
I can't see what you are referring to. I'll correct it if needs be
>
> 2. Instead of gfc_index_zero_node would it be better to use
> build_zero_cst (gfc_charlen_type_node)? Or is the same
Hello world,
when putting in a seemingly innocent simplification for PR 56342,
I caused a regression in PR 82823, in PACK. The root cause of
this one turned out to be PR 48890, in which structure
constructors containing characters were not handled correctly
if the lengths did not match.
The atta
On Mon, Feb 19, 2018 at 08:12:48PM +0100, Paolo Carlini wrote:
> On 19/02/2018 20:05, Jakub Jelinek wrote:
> > Hi!
> >
> > In this case, because the corresponding variable is errorneous, we end up
> > with error_mark_node in LAMBDA_TYPE_EXTRA_SCOPE. This patch just makes sure
> > we won't crash o
On Mon, Feb 19, 2018 at 03:31:13PM -0500, David Edelsohn wrote:
> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01247.html
>
> === g++ tests ===
>
>
> Running target unix/-m32
> ...
> FAIL: g++.dg/template/overload15.C -std=c++11 (test for excess errors)
> FAIL: g++.dg/template/overload15.C
On Mon, Feb 19, 2018 at 11:41:30PM +0100, Thomas Koenig wrote:
>
> Regression-tested. OK for trunk?
>
OK with the fix suggested below.
> Index: primary.c
> ===
> --- primary.c (Revision 257788)
> +++ primary.c (Arbeitskopie)
> @@
Hi Richard,
On 16 February 2018 at 22:56, Richard Biener wrote:
> On Thu, Feb 15, 2018 at 11:30 PM, Kugan Vivekanandarajah
> wrote:
>> Hi Wilko,
>>
>> Thanks for your comments.
>>
>> On 14 February 2018 at 00:05, Wilco Dijkstra wrote:
>>> Hi Kugan,
>>>
Based on the previous discussions, I
Please see this patch posted to the binutils list:
https://sourceware.org/ml/binutils/2018-02/msg00260.html
where Joshua proposes to add the ax_pthread.m4 script, from the
autoconf macro archive, to the config/ directory in order to improve
gold's configure-time detection of thread support.
I
> config-patches has nothing to do with the GCC config/ directory. It is
> the place to send patches for config.{guess,sub}. Taking if off the
> cc: line.
Sorry, Ben. I've started a new thread on gcc-patches for the config/
part of this patch.
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01138.h
Hi!
While I've over-simplified the testcase and so this patch doesn't help
the 628.pop2_s miscompare, I still believe it is beneficial to defer this
folding until late for these reasons:
1) if we propagate a constant into the second pow argument too, it will
be likely more precise than going th
PR 84468 points out a false positive in -Wstringop-truncation
in code like this:
struct A { char a[4]; };
void f (struct A *p, const struct A *q)
{
if (p->a)
strncpy (p->a, q->a, sizeof p->a - 1); // warning here
p->a[3] = '\0';
}
The warning is due to the code checking
OK.
On Mon, Feb 19, 2018 at 2:12 PM, Paolo Carlini wrote:
> Hi,
>
> On 19/02/2018 20:05, Jakub Jelinek wrote:
>>
>> Hi!
>>
>> In this case, because the corresponding variable is errorneous, we end up
>> with error_mark_node in LAMBDA_TYPE_EXTRA_SCOPE. This patch just makes
>> sure
>> we won't cr
OK.
On Mon, Feb 19, 2018 at 1:56 PM, Jakub Jelinek wrote:
> Hi!
>
> While cp_parser_lambda_body which is the other finish_lambda_function
> caller next to tsubst_lambda_expr temporarily increments function_depth
> around that call (if not nested) to avoid GC during expand_or_defer_fn from
> finis
OK.
On Mon, Feb 19, 2018 at 2:04 PM, Jakub Jelinek wrote:
> Hi!
>
> build_cplus_new can return error_mark_node e.g. when calling a deleted
> ctor or dtor, but bot_manip was assuming it will always return
> AGGR_INIT_EXPR. As it is generally unsafe to set subexpressions to
> error_mark_node, e.g.
OK.
On Mon, Feb 19, 2018 at 2:08 PM, Jakub Jelinek wrote:
> Hi!
>
> For internal functions, we use the whole u.bits of the CALL_EXPR
> for the internal function number (in this case IFN_LAUNDER), so using
> the lang flags on it doesn't work. In a couple of other places
> I've checked that test o
We already handle stripping dereferences for non-VLA captures, just
need to do the same thing for VLAs in the case of a nested capture.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 95a82187a0986740f6357f74ba6d03814ba7fc1c
Author: Jason Merrill
Date: Sun Feb 18 23:57:57 2018 -0500
On Tue, Feb 20, 2018 at 12:41 AM, Thomas Koenig wrote:
> Hello world,
>
> when putting in a seemingly innocent simplification for PR 56342,
> I caused a regression in PR 82823, in PACK. The root cause of
> this one turned out to be PR 48890, in which structure
> constructors containing characters
60 matches
Mail list logo
