Could you please elaborate.
Dominique
> Le 7 avr. 2016 à 07:48, Steve Kargl a
> écrit :
>
> On Wed, Apr 06, 2016 at 05:44:55PM +0200, Dominique d'Humières wrote:
>> Is the following patch OK (regtested on x86_64-apple-darwin15)? Should it be
>> back ported
On Wed, Apr 06, 2016 at 05:44:55PM +0200, Dominique d'Humières wrote:
> Is the following patch OK (regtested on x86_64-apple-darwin15)? Should it be
> back ported to the gcc-5 branch?
No and No.
--
Steve
On Wed, 6 Apr 2016, Patrick Palka wrote:
> On Wed, Apr 6, 2016 at 1:17 PM, Richard Biener
> wrote:
> > On April 6, 2016 6:51:40 PM GMT+02:00, Patrick Palka
> > wrote:
> >>During constexpr evaluation we unconditionally call unshare_expr in a
>
here?
That's a good idea. I went ahead and combined this patch with the data
map reduction fix for PR70289 that I posted on Monday,
<https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00202.html>, because I'm
already scanning for parallel reduction data clauses in there. As you
suggeste
On Wed, Apr 6, 2016 at 5:55 PM, H.J. Lu wrote:
> On Wed, Apr 6, 2016 at 8:11 AM, Uros Bizjak wrote:
>> ... so there is no unresolved attributes in insn-output.c.
>>
>> 2016-04-06 Uros Bizjak
>>
>> * config/i386/sse.md
Kaushik Phatak writes:
> 2016-04-06 Kaushik Phatak
>
> * config/rl78/bit-count.S: Use clrw/clrb where possible.
> * config/rl78/cmpsi2.S: Likewise.
> * config/rl78/divmodhi.S Likewise.
> * config/rl78/divmodsi.S
On Wed, Apr 6, 2016 at 1:17 PM, Richard Biener
wrote:
> On April 6, 2016 6:51:40 PM GMT+02:00, Patrick Palka
> wrote:
>>During constexpr evaluation we unconditionally call unshare_expr in a
>>bunch of places to ensure that CONSTRUCTORs (and
On April 6, 2016 6:51:40 PM GMT+02:00, Patrick Palka
wrote:
>During constexpr evaluation we unconditionally call unshare_expr in a
>bunch of places to ensure that CONSTRUCTORs (and their
>CONSTRUCTOR_ELTS)
>don't get shared. But as far as I can tell, we don't have any
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70398
The patch was successfully tested and bootstrapped on x86_64 and aarch64.
Committed as rev. 234792
Index: ChangeLog
===
--- ChangeLog (revision
During constexpr evaluation we unconditionally call unshare_expr in a
bunch of places to ensure that CONSTRUCTORs (and their CONSTRUCTOR_ELTS)
don't get shared. But as far as I can tell, we don't have any reason to
call unshare_expr on non-CONSTRUCTORs, and a CONSTRUCTOR will never be
an operand
We were incorrectly omitting the ABI tag on the instantiation of this
member function because we were setting the tags on the instantiation
and looking for them on the temploid.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 32a5b18940f37dd97c2735f24a8353d1db457d86
Author: Jason Merrill
On Wed, Apr 6, 2016 at 8:11 AM, Uros Bizjak wrote:
> ... so there is no unresolved attributes in insn-output.c.
>
> 2016-04-06 Uros Bizjak
>
> * config/i386/sse.md (shuffletype): Add V32HI and V4TI modes.
> (ssescalarsize): Add V8SF, V4SF, V4DF and
Is the following patch OK (regtested on x86_64-apple-darwin15)? Should it be
back ported to the gcc-5 branch?
TIA
Dominique
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (revision 234788)
+++
On 6 April 2016 at 17:24, Pedro Alves wrote:
> On 04/06/2016 04:13 PM, Yvan Roux wrote:
>> On 6 April 2016 at 17:09, Pedro Alves wrote:
>>> On 04/06/2016 03:53 PM, Yvan Roux wrote:
Dejagnu cleanup mechanism needs to be enhanced, but I think that it
I don't understand how this one slipped through the cracks last year, but the
test needs to be disabled on Visium as on a bunch of other architectures.
Tested on visium-elf, applied on the mainline and 5 branch.
2016-04-06 Eric Botcazou
*
On 04/06/2016 04:13 PM, Yvan Roux wrote:
> On 6 April 2016 at 17:09, Pedro Alves wrote:
>> On 04/06/2016 03:53 PM, Yvan Roux wrote:
>>> Dejagnu cleanup mechanism needs to be enhanced, but I think that it
>>> would also be better if guality tests don't get stuck and/or can be
On 6 April 2016 at 17:09, Pedro Alves wrote:
> On 04/06/2016 03:53 PM, Yvan Roux wrote:
>> Dejagnu cleanup mechanism needs to be enhanced, but I think that it
>> would also be better if guality tests don't get stuck and/or can be
>> killed easily. This patch changes GDB
... so there is no unresolved attributes in insn-output.c.
2016-04-06 Uros Bizjak
* config/i386/sse.md (shuffletype): Add V32HI and V4TI modes.
(ssescalarsize): Add V8SF, V4SF, V4DF and V2DF modes.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
> OK, I have no objection to the original patch then.
Thanks, applied. FWIW I verified that the library still builds after the
change with an empty port_specific_symbol_files variable.
--
Eric Botcazou
On 04/06/16 07:49, Jason Merrill wrote:
On 04/05/2016 05:21 PM, Nathan Sidwell wrote:
On 04/05/16 12:40, Jason Merrill wrote:
It's not clear to me that we really need a TARGET_EXPR for vector values. Since
one element of a vector can't refer to another, we don't need the ctx->ctor
handling.
On Wed, Apr 06, 2016 at 04:53:47PM +0200, Yvan Roux wrote:
> 2016-04-06 Yvan Roux
> Pedro Alves
>
> * gcc.dg/guality/guality.h (main): Avoid GDB being blocked on signals.
Ok.
> diff --git a/gcc/testsuite/gcc.dg/guality/guality.h
Hi,
we are confronted to a deadlock situation when doing native validation
on armv8l target.
When gcc/testsuite/gcc.dg/guality/example.c is executed it spawns gdb,
and makes it attach to his parent, but during the test execution, gdb
receives a SIGSEGV, which is handled as a stop signal. Then
On 04/05/2016 05:21 PM, Nathan Sidwell wrote:
On 04/05/16 12:40, Jason Merrill wrote:
It's not clear to me that we really need a TARGET_EXPR for vector values. Since
one element of a vector can't refer to another, we don't need the ctx->ctor
handling. Perhaps we should handle vectors like we
On Tue, Apr 05, 2016 at 09:22:37AM -0700, Richard Henderson wrote:
> These two related PRs are all about remembering where a macro is expanded.
> Worse, we've got two competing goals -- the real location of the expansion,
> for __LINE__, and the virtual location of the expansion, for diagnostics.
OK.
Jason
On Tue, Apr 05, 2016 at 06:53:47PM -0700, Cesar Philippidis wrote:
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -309,6 +309,25 @@ is_oacc_kernels (omp_context *ctx)
> == GF_OMP_TARGET_KIND_OACC_KERNELS));
> }
>
> +/* Return true if CTX corresponds to an oacc parallel region and
On 04/04/2016 06:22 AM, Jonathan Wakely wrote:
I plan to commit this to wwwdocs CVS. Have I missed anything that
should be listed?
I'd mention that TM requires the -fgnu-tm flag.
Jason
Hi!
As we already have some declare simd ABI changes in GCC 6 (mangling of
the various linear clause kinds), and as glibc uses the AVX512F stuff in,
I've decided to commit following ABI changes right now rather than waiting
for GCC 7.
The changes are:
1) for AVX2, functions with {{un,}signed
On Wed, Apr 06, 2016 at 12:27:36PM +0200, Andreas Schwab wrote:
> Alan Modra writes:
>
> > diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > new file mode 100644
> > index 000..99e6f19
> > --- /dev/null
> > +++
On Wed, Apr 6, 2016 at 12:03 PM, Thomas Preudhomme
wrote:
> Hi,
>
> Testcase in gcc.target/arm/pr70496.c uses an .arm directive so assumes the
> target has an ARM execution state. This patch adds a dg-skip-if directive to
> skip that test on Cortex-M targets since
I've finally gotten around to analyzing this testsuite failure on 32-bit
Solaris/x86:
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O1 -fcilkplus execution test
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O3 -fcilkplus execution test
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -g -O2 -fcilkplus execution
Hi Thomas,
On 06/04/16 12:03, Thomas Preudhomme wrote:
Hi,
Testcase in gcc.target/arm/pr70496.c uses an .arm directive so assumes the
target has an ARM execution state. This patch adds a dg-skip-if directive to
skip that test on Cortex-M targets since they don't have such an execution
state.
Hi,
Testcase in gcc.target/arm/pr70496.c uses an .arm directive so assumes the
target has an ARM execution state. This patch adds a dg-skip-if directive to
skip that test on Cortex-M targets since they don't have such an execution
state.
ChangeLog entry is as follows:
***
The following patch has remainded unreviewed for a week:
[testsuite, sparcv9] Fix gcc.dg/ifcvt-4.c on 64-bit SPARC (PR
rtl-optimization/68749)
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01631.html
Although it's testsuite-only, I'm quite reluctant to make potential
semantic
On Tue, Feb 16, 2016 at 5:50 AM, Hurugalawadi, Naveen
wrote:
> Hi,
>
>>> I'm also failing to see why you can't enhance the existing
>
> Please find attached the patch that enhances the existing pattern.
> Please review the patch and let me know if any
Alan Modra writes:
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c
> b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> new file mode 100644
> index 000..99e6f19
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> @@ -0,0 +1,22 @@
> +/* { dg-do run {
Hi,
Having updated the way we parse and output extension strings, now we just
need to wire up the native detection to use these new features.
In doing some cleanup and rename I ended up fixing 8-spaces to tabs in
about half the file. I've done the rest while I'm here to save us from
some a
Hi,
This patch aims to ensure that when we say:
-march=armv8-a+nosimd
We communicate that to the assembler in a way it understands.
On trunk, we'll put out a directive that says
.march armv8-a+fp
Which has two issues; it is not enough to disable the simd extensions, and
it adds a +fp
Hi,
This patch set fixes PR70133, which is a bug in the way we handle extension
strings after using -march or -mcpu=native. In investigating this, I found
other bugs in the way we communicate architceture intention between the
compiler and the assembler.
This patch set cleans this up somewhat.
Hi,
This change reflects binutils support for CRC, where it is always enabled
for armv8.1-a.
OK?
Thanks,
James
---
2016-04-06 James Greenhalgh
* config/aarch64/aarch64.h (AARCH64_FL_FOR_ARCH8_1): Also add
AARCH64_FL_CRC.
diff --git
On Wed, Apr 06, 2016 at 10:46:48AM +0200, Richard Biener wrote:
> On Wed, Apr 6, 2016 at 10:31 AM, Alan Modra wrote:
> > On Tue, Apr 05, 2016 at 11:29:30AM +0200, Richard Biener wrote:
> >> In general the patch looks like a good approach to me but can we
> >> hide that
> >>
> >>
On Wed, Apr 06, 2016 at 10:12:18AM +0100, Jonathan Wakely wrote:
> >As it is a make variable, can't make be used to test this?
> >So perhaps
> > chmod +w $@.tmp
> >ifneq ($(port_specific_symbol_files),)
> > if grep '^# Appended to version file.' \
> >
On 06/04/16 11:01 +0200, Jakub Jelinek wrote:
On Wed, Apr 06, 2016 at 09:50:48AM +0100, Jonathan Wakely wrote:
On 06/04/16 09:39 +0200, Eric Botcazou wrote:
>we recently ran into build failures on Windows systems using a somewhat old
>grep, coming from a syntax error in the
On Wed, 6 Apr 2016, Prathamesh Kulkarni wrote:
> On 6 April 2016 at 13:44, Richard Biener wrote:
> > On Wed, 6 Apr 2016, Prathamesh Kulkarni wrote:
> >
> >> On 5 April 2016 at 18:28, Richard Biener wrote:
> >> > On Tue, 5 Apr 2016, Prathamesh Kulkarni
On Wed, Apr 06, 2016 at 09:50:48AM +0100, Jonathan Wakely wrote:
> On 06/04/16 09:39 +0200, Eric Botcazou wrote:
> >we recently ran into build failures on Windows systems using a somewhat old
> >grep, coming from a syntax error in the libstdc++-symbols.ver version file:
> >
> ># Symbol versioning
On 6 April 2016 at 13:44, Richard Biener wrote:
> On Wed, 6 Apr 2016, Prathamesh Kulkarni wrote:
>
>> On 5 April 2016 at 18:28, Richard Biener wrote:
>> > On Tue, 5 Apr 2016, Prathamesh Kulkarni wrote:
>> >
>> >> On 5 April 2016 at 16:58, Richard Biener
On 06/04/16 09:39 +0200, Eric Botcazou wrote:
Hi,
we recently ran into build failures on Windows systems using a somewhat old
grep, coming from a syntax error in the libstdc++-symbols.ver version file:
# Symbol versioning for shared libraries.
if ENABLE_SYMVERS
libstdc++-symbols.ver:
On Wed, Apr 6, 2016 at 10:31 AM, Alan Modra wrote:
> On Tue, Apr 05, 2016 at 11:29:30AM +0200, Richard Biener wrote:
>> In general the patch looks like a good approach to me but can we
>> hide that
>>
>> > + const struct real_format *fmt = FLOAT_MODE_FORMAT (mode);
>> > + bool
This is similar to what Jason reported last week for the main
cxxstatus.html page.
Things already improved by virtue of the global styles I introduced,
this now completes things, simplifying the page (removing all those
align="center"s and s) and using the global CSS sheet, so any
changes
On Tue, Apr 05, 2016 at 11:29:30AM +0200, Richard Biener wrote:
> In general the patch looks like a good approach to me but can we
> hide that
>
> > + const struct real_format *fmt = FLOAT_MODE_FORMAT (mode);
> > + bool is_ibm_extended = fmt->pnan < fmt->p;
>
> in a function somewhere in
On Wed, 6 Apr 2016, Prathamesh Kulkarni wrote:
> On 5 April 2016 at 18:28, Richard Biener wrote:
> > On Tue, 5 Apr 2016, Prathamesh Kulkarni wrote:
> >
> >> On 5 April 2016 at 16:58, Richard Biener wrote:
> >> > On Tue, 5 Apr 2016, Prathamesh Kulkarni
On 5 April 2016 at 18:28, Richard Biener wrote:
> On Tue, 5 Apr 2016, Prathamesh Kulkarni wrote:
>
>> On 5 April 2016 at 16:58, Richard Biener wrote:
>> > On Tue, 5 Apr 2016, Prathamesh Kulkarni wrote:
>> >
>> >> On 4 April 2016 at 19:44, Jan Hubicka
Hi,
we recently ran into build failures on Windows systems using a somewhat old
grep, coming from a syntax error in the libstdc++-symbols.ver version file:
# Symbol versioning for shared libraries.
if ENABLE_SYMVERS
libstdc++-symbols.ver: ${glibcxx_srcdir}/$(SYMVER_FILE) \
53 matches
Mail list logo