/On Wed, Nov 2, 2016 at 3:54 AM, James Greenhalgh
wrote:
> On Tue, Nov 01, 2016 at 11:08:53AM -0700, Andrew Pinski wrote:
>> On Tue, Nov 17, 2015 at 2:10 PM, Andrew Pinski wrote:
>> > Since ThunderX T88 pass 1 (variant 0) is a ARMv8 part while pass 2
>> > (variant 1)
>> > is an ARMv8.1 part, I
On November 5, 2016 3:40:04 AM GMT+01:00, Jeff Law wrote:
>On 11/02/2016 06:27 AM, Richard Biener wrote:
>> I'm still torn about all the rest of the stuff and question its
>> usability (esp. merging the epilogue with the main vector loop).
>> But it has already been approved ... oh well.
>Note tha
Hello world,
I have committed the attached patch to the regression as obvious and
simple after regression-testing. Will commit to gcc 6 in a
few days.
Regards
Thomas
2016-11-06 Thomas Koenig
PR fortran/78221
* arith.c (gfc_complex2real): Change gfc_warning_now to
The use of an Apple sandbox with denied file access permissions into /usr/local
exposed that cc1 fails on errors of...
cc1: error: /usr/local/include: Operation not permitted
The commonly suggested solution of using --with-local-prefix= set to something
other than /usr/local is undeirable on darw
On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth wrote:
> The use of an Apple sandbox with denied file access permissions into
> /usr/local
> exposed that cc1 fails on errors of...
>
> cc1: error: /usr/local/include: Operation not permitted
>
> The commonly suggested solution of using --with-local-pr
Hi!
This improves the stack usage on the sha512 test case for the case
without hardware fpu and without iwmmxt by splitting all di-mode
patterns right while expanding which is similar to what the shift-pattern
does. It does nothing in the case iwmmxt and fpu=neon or vfp as well as
thumb1.
It red
> On 6 Nov 2016, at 06:04, Jack Howarth wrote:
>
> On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth wrote:
>> The use of an Apple sandbox with denied file access permissions into
>> /usr/local
>> exposed that cc1 fails on errors of...
>>
>> cc1: error: /usr/local/include: Operation not permitted
On Sun, Nov 6, 2016 at 9:45 AM, Iain Sandoe wrote:
>
>> On 6 Nov 2016, at 06:04, Jack Howarth wrote:
>>
>> On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth
>> wrote:
>>> The use of an Apple sandbox with denied file access permissions into
>>> /usr/local
>>> exposed that cc1 fails on errors of...
>
> On 6 Nov 2016, at 06:57, Jack Howarth wrote:
>
> On Sun, Nov 6, 2016 at 9:45 AM, Iain Sandoe wrote:
>>
>>> On 6 Nov 2016, at 06:04, Jack Howarth wrote:
>>>
>>> On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth
>>> wrote:
The use of an Apple sandbox with denied file access permissions int
Hi Steve, hi Paul, hi Dominique, hi all,
thanks for the reviews, Steve and Paul, thanks for the heavy testing, Dominique.
Committed as r241885.
Regards,
Andre
On Sat, 5 Nov 2016 10:46:46 +0100
Paul Richard Thomas wrote:
> Dear Andre,
>
> The patch looks fine to me. OK for trunk.
>
> C
> The problem was that forall could handle substring expressions,
> but not if it had to create a temporary array. I did my best
> to fix this. I left a couple of TODO comments in the code.
Well, I don’t understand why the test needs a temporary for
forall (i1 = nl1:nu1) o(i1:i1) = i(i1:i1)
Hi,
Some platforms, such as Blackfin, have a special prefix for assembly
symbols as opposed to C symbols. For this reason, a function named
"foo()" in C will in fact be visible as a symbol called "_foo" in the
ELF binary.
The current linker version script logic in libgcc doesn't take into
account
Hi,
This commit makes the Blackfin platform use the generic linker version
information, rather than a completely duplicated file, specific for the
Blackfin architecture.
This is made possible using the newly introduced skip_underscore
variable of the mkmap-symver script.
This also allows to get
It appears this got stuck.
Uros, is this okay? I can handle the commit if you approve.
Gerald
On Wed, 6 Jul 2016, Roger Pau Monne wrote:
> At the moment the -m16 option only passes the "--32" parameter to the
> assembler on glibc OSes, while on other OSes the assembler is called without
> any s
Hi Folks,
This might make some configuration modes easier on modern Darwin (although
hitting the problem used to be an unusual circumstance, it will likely become
more common if we need to use build-sysroots - e.g. targeting a minimum OS X
version of 10.6 on later versions).
Earlier Darwin (es
Dominique,
(1) I'm not sure why the 'forall' gets a temporary.
(2) As far as I can tell, we get an ICE because the code that generates
'forall' temporaries doesn't work well with substrings. It's hard to test all
possible combinations, and this one had been missed.
While the original program i
On Sat, 2016-09-10 at 09:51 -0400, Eric Gallager wrote:
> On 9/10/16, Ian Lance Taylor wrote:
> > I'm not sure about the patch to configure.ac/configure. The last I
> > looked -Wshadow would warn if a local variable shadows a global
> > variable. That can cause a pointless build break if some sy
Le 03/11/2016 à 14:16, Andre Vehreschild a écrit :
@Dominique: Would you give it a go on your open patch collection? Maybe it
fixes one PR, but I am not very hopeful, because the patch is merely removing
complexity instead of doing new things.
Hello,
Since you asked:
I think the patch fixes pr
Hi Folks,
Including Jeff on the cc since we were discussing this on Friday (and it’s not
100% clear who’s reviewing configury patches at present).
Including Uros, because there’s one minor change to i386/i386.c
PR71767 is " Endless stream of warnings when using GCC with -Wa,-q and Clang
Integra
Hi Folks,
(in Darwin) If we have a situation like:
global_weak_symbol:
Lnon_weak_local:
ld64 will be unable to split this into two atoms (because the "L" makes
the second symbol 'invisible'). This means that legitimate direct accesses
to the second symbol will appear to be
Hi Folks,
This is an initial patch in a series that converts Darwin's configury to detect
ld64 features, rather than the current process of hard-coding them on target
system version.
This adds an option --with-ld64[=version] that allows the configurer to specify
that the Darwin ld64 linker is
Hi Folks,
(much) Older Darwin linkers needed separate sections marked "coalesce" to
allow for weak symbol coalescing. This has not been needed for some time
and is now deprecated, newer assemblers warn if the old coalesced sections
are used. We need to switch to using the regular sections when a
Hi folks,
As per $SUBJECT.
OK for trunk (after the relevant patches are applied)?
OK for open branches (likewise)?
Iain
gcc/testsuite/
…. Dominique d'Humieres
Iain Sandoe
PR target/71767
* g++.dg/abi/key2.C: Adjust for changed Darwin sections and
linker-visible
Hi Folks,
PR57438 has two manifestations - which arise from the same root cause.
A.
Empty function bodies causes two problems for Darwin's linker (i) zero-length
FDEs and (ii) coincident label addresses that might point to items of differing
weakness.
B.
Trailing local labels can be problemat
On Sun, Nov 6, 2016 at 5:48 PM, Gerald Pfeifer wrote:
> It appears this got stuck.
>
> Uros, is this okay? I can handle the commit if you approve.
Looks good to me, so OK if tested on non-glibc system.
Thanks,
Uros.
> Gerald
>
> On Wed, 6 Jul 2016, Roger Pau Monne wrote:
>> At the moment the -
On Sun, Nov 6, 2016 at 8:40 PM, Iain Sandoe wrote:
> Hi Folks,
>
> (much) Older Darwin linkers needed separate sections marked "coalesce" to
> allow for weak symbol coalescing. This has not been needed for some time
> and is now deprecated, newer assemblers warn if the old coalesced sections
> ar
Hi Folks,
This is an updated solution, but on a patch from Rainer Orth (attached to
pr67710).
A/ Newer versions of ld64 check the min_version command, and newer versions of
the system assembler inserts this in response to "-mmacosx-version-min=" on the
assembler line.
Unless one makes sensible
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 Spanish team of translators. The file is available at:
http://translationproject.org/latest/gcc/es.po
(This file, 'gcc-6.2.0.es.po', has just
Hello world,
I have committed the attached patch as obvious and simple.
No test case because I don't have one :-)
I am planning some more work on the PR tracking these issues,
PR 78226.
Regards
Thomas
2016-11-06 Thomas Koenig
PR fortran/78226
resolve.c (build_loc_c
Hi Iain,
On Sun, Nov 06, 2016 at 12:13:16PM -0800, Iain Sandoe wrote:
> 2016-11-06 Iain Sandoe
>
> PR target/57438
> * config/i386/i386.c (ix86_code_end): Note that we emitted code where
> the
> function might otherwise appear empty for picbase thunks.
> (ix86_output_f
But obviously not all levels of the warning can/should be enabled
with -Wall/-Werror. There are cases which are worth warning by default
(the case where we want to inform the user if you reach this stmt,
you'll get your program killed (will call __chk_fail)) is something
that ought like before be
On 06.11.16 21:38, Uros Bizjak wrote:
On Sun, Nov 6, 2016 at 5:48 PM, Gerald Pfeifer wrote:
It appears this got stuck.
Uros, is this okay? I can handle the commit if you approve.
Looks good to me, so OK if tested on non-glibc system.
Results w/o patch:
https://gcc.gnu.org/ml/gcc-testresu
32 matches
Mail list logo
