[PING][PATCH] Don't mark offload symbols with force_output in ltrans

[ was: [PING][PATCH] Mark symbols in offload tables with force_output in read_offload_tables ] On 08/02/16 14:20, Tom de Vries wrote: On 26/01/16 14:01, Ilya Verbin wrote: On Tue, Jan 26, 2016 at 13:21:57 +0100, Tom de Vries wrote: On 25/01/16 14:27, Ilya Verbin wrote: On Tue, Jan 05, 2016

Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

If we are talking about pr 68580, then I would try: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c2 first. On Mon, Feb 15, 2016 at 8:18 AM, Dmitry Vyukov wrote: > On Mon, Feb 15, 2016 at 7:00 AM, Tom de Vries wrote: >> Hi, >> >> Occasionally,

Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

On Mon, Feb 15, 2016 at 7:00 AM, Tom de Vries wrote: > Hi, > > Occasionally, I've been running into this failure while running the tsan > testsuite: > ... > FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test > ... > > I've also observed a potential similar occurrence

Re: [ARM] Use vector wide add for mixed-mode adds

Hi Kyrill, I made the following changes based on your comments: 1. I rebased the patch so that it applies cleanly on trunk 2. Fixed the dg-add-options as requested to my new test cases 3. Fixed the GNU style issues identified by ./contrib/check_GNU_style.sh The failure you are seeing on

[RFC, PR68580] Handle pthread_create error in tsan testsuite

Hi, Occasionally, I've been running into this failure while running the tsan testsuite: ... FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test ... I've also observed a potential similar occurrence here ( https://gcc.gnu.org/ml/gcc-regression/2015-08/msg00147.html ). Initially, I

Re: bswap PRs 69714, 67781

Hi Bernd, First of all, my apologize for the late reply. I was in holidays the past week to celebrate Chinese new year. On Friday, February 12, 2016 05:28:43 PM Bernd Schmidt wrote: > PR69714 is an issue where the bswap pass makes an incorrect > transformation on big-endian targets. The source

[PATCH] 69780 - [4.9/5/6 Regression] ICE on __builtin_alloca_with_align, with small alignment

The attached patch adds argument validation for __builtin_alloca_with_align to reject arguments the middle end isn't prepared to handle or that aren't meaningful for the API (constant integers that aren't powers of 2 greater than or equal to 8). Tested on x86_64-linux. Martin PR

Re: [PATCH] Avoid bugs like PR68273 to trigger

On Sun, Feb 14, 2016 at 10:35:17PM +0100, Eric Botcazou wrote: > > How does that help? Testcases have been posted multiple times that show > > that if targets look at type alignment of non-aggregate types, they have > > just broken argument passing, so conditionally reverting the tree-sra > >

Re: [PATCH] Avoid bugs like PR68273 to trigger

> No, it is a major deficiency in the backends. Back-ends were obviously written with the natural alignment of types in mind and were not prepared for overaligned non-aggregate types. Fixing MIPS will not fix the other dozen and one can wonder, as was already mentioned by a few other people,

Re: [PATCH] Avoid bugs like PR68273 to trigger

> No, but if there is none left why would you want to "fix" SRA? As expected, it seems that the make_ssa_name_fn kludge is not sufficient, so I'm proposing to disable the PR65310 one-liner for selected targets, using the function_arg_boundary hook, until after we have a clear way out of this

Re: [PATCH] Avoid bugs like PR68273 to trigger

On Sun, Feb 14, 2016 at 09:39:56PM +0100, Eric Botcazou wrote: > > No, but if there is none left why would you want to "fix" SRA? > > As expected, it seems that the make_ssa_name_fn kludge is not sufficient, so > I'm proposing to disable the PR65310 one-liner for selected targets, using > the

Re: [PATCH] Avoid bugs like PR68273 to trigger

> How does that help? Testcases have been posted multiple times that show > that if targets look at type alignment of non-aggregate types, they have > just broken argument passing, so conditionally reverting the tree-sra > improvements can't help. Well, that has been the case for 2 decades for

Re: [RFC] [P2] [PR tree-optimization/33562] Lowering more complex assignments.

On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law wrote: >On 02/12/2016 10:21 AM, Jeff Law wrote: >>> But really we simply need a better DSE algorithm. >> So the way to fix DSE is to keep the existing algorithm and track the >> hunks of Complex/aggregates that have been set a

[patch, fortran] Two associate fixes in dump-parse-tree.c

Hello world, the two fixes in the patch - show ASSOCIATE lists if present, to complete the AST dump - fix an ICE where an EXEC_END_BLOCK survived. This can only happen if the END ASSOCIATE or END BLOCK statement had a statement label. If the preference is to use some other format for the

[committed] Add new bswap and abs patterns to PA

The recent investigation of wrong code for the bswap tree optimization showed that we were not generating optical bswap sequences on PA. The PA 2.0 architecture manual shows optimized sequences for half-word, word and double word variables. The attached change implements insn patterns for

Re: [wwwdocs] New bits to porting_to

Hi Marek, On Wed, 10 Feb 2016, Marek Polacek wrote: > +The additional overloads can cause the compiler to reject invalid code that > +was accepted before. An example of such code is the below: which additional overloads does this refer to? > +#include stdlib.h > +int > +foo (unsigned x)

Re: [patch, Fortran] Fix PR 60526, variable name has already been declared as a type

On Sat, Feb 13, 2016 at 3:56 AM, Thomas Koenig wrote: > Am 12.02.2016 um 11:42 schrieb Janne Blomqvist: >> >> On Fri, Feb 12, 2016 at 12:16 PM, Andre Vehreschild wrote: > > >>> The proposed alloca() call >>> has according to the documentation of libc some

[wwwdocs] Trim the navigation bar

Trim the navigation bar, by - removing "Testing" from the "Documentation" section, - renaming "Further Readings" to "Pointers", - renaming "Mirror Sites" to "Mirrors" under "Download", - renaming ""Live" Sources" to just "Sources", - moving the Git link past both SVN links, - renaming "Rsync

[PATCH] s390: Add -fsplit-stack support

libgcc/ChangeLog: * config.host: Use t-stack and t-stack-s390 for s390*-*-linux. * config/s390/morestack.S: New file. * config/s390/t-stack-s390: New file. * generic-morestack.c (__splitstack_find): Add s390-specific code. gcc/ChangeLog: *

[committed] Xfail gfortran.dg/read_dir.f90 on hppa*-*-hpux*

The "call system" call doesn't work on hppa-hpux, so xfailing. Dave -- John David Anglin dave.ang...@bell.net 2016-02-14 John David Anglin PR fortran/68746 * gfortran.dg/read_dir.f90: Xfail on hppa*-*-hpux*. Index: gfortran.dg/read_dir.f90

Re: [RFC] [P2] [PR tree-optimization/33562] Lowering more complex assignments.

On 02/12/2016 10:21 AM, Jeff Law wrote: But really we simply need a better DSE algorithm. So the way to fix DSE is to keep the existing algorithm and track the hunks of Complex/aggregates that have been set a second time. My first thought was to implement this as an inverted bitmap. ie, set

Re: [patch, Fortran] Fix PR 60526, variable name has already been declared as a type

Am 14.02.2016 um 15:38 schrieb H.J. Lu: It breaks bootstrap on x86: ../../../src-trunk/libgfortran/intrinsics/selected_int_kind.f90:28:40: integer :: _gfortran_selected_int_kind I have fixed this in two parts: a) reverted the patch (r233411). I still managed to catch the revision

Re: [wwwdocs] New bits to porting_to

On 14/02/16 14:14 +0100, Gerald Pfeifer wrote: Hi Marek, On Wed, 10 Feb 2016, Marek Polacek wrote: +The additional overloads can cause the compiler to reject invalid code that +was accepted before. An example of such code is the below: which additional overloads does this refer to? The

Re: [patch, Fortran] Fix PR 60526, variable name has already been declared as a type

On Sat, Feb 13, 2016 at 1:56 PM, Thomas Koenig wrote: > Am 12.02.2016 um 11:42 schrieb Janne Blomqvist: >> >> On Fri, Feb 12, 2016 at 12:16 PM, Andre Vehreschild wrote: > > >>> The proposed alloca() call >>> has according to the documentation of libc some

New Swedish PO file for 'gcc' (version 6.1-b20160131)

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 Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-6.1-b20160131.sv.po',