[ 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 a
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, I've been running into this failure while run
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 here (
> https://gcc.gnu.o
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 slp-red
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 couldn'
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 h
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 middle-end/69780
> 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, w
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
> > impr
> 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 so
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
>
> 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 mes
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
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 second time.
>>
>>
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 thes
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 clu
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
im
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
it
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
=
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:
* common/config/s3
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 availability issues on
>>> certain platfo
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
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
> +int
> +foo (unsigned x)
Usua
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',
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 availability issues on
>>> certain platfo
25 matches
Mail list logo
