Hi,
Please find attached the patch that adds AES and CMP_BRANCH
fusion for Thunderx2t99.
Bootstrapped and Regression tested on aarch64-thunderx2t99.
Please review the patch and let us know if its okay?
2017-1-25 Naveen H.S
gcc
* config/aarch64/aarch64.c (thunderx2t99_tunings):
This patch to the gofrontend improves the recently added type alias
handling, and lets the compiler pass the tests on the dev.typealias
branch of the gc compiler.
We now give an error for an attempt to define a method on an imported type.
We now give an error for each attempt to define a method o
In implementing the -Wstringop-overflow warning I missed stpcpy.
The attached patch adds the required checking. Given how simple
it is, does it qualify for GCC 7 despite stage 4?
Martin
PR middle-end/79222 - missing -Wstringop-overflow= on a stpcpy overflow
gcc/ChangeLog:
PR middle-end/79222
The __NPS400__ define is currently created in CPP_SPEC unlike the other
target defines, which are created in arc-c.def. Further, the current
__NPS400__ define is (currently) only created when -mcpu=nps400 is
passed, which is fine, except that if GCC is configured using
--with-cpu=nps400 then the -
I noticed that the __NPS400__ define was not being created properly,
when the toolchain is configured with --with-cpu=nps400 then the
define will not be created (unless --mcpu=nps400 is also used).
I thought the fix would be easy, __NPS400__ was being created in the
CPP_SPEC, in contrast to simila
Currently we only make the base_architecture globally available, this
means we can tell if we have selected arc700/archs/etc but it's not
possible to tell if the user has selected a specific cpu variant, for
example nps400.
One problem this causes is, for example, in arc-c.def, if we want to add
a
Hi!
Apparently the configury of this library has been copied over before the
PR79046 changes were done, the following patch updates it. Ok for trunk?
Though, I wonder why configure.ac/Makefile.am have been based on one of the
only 2 that aren't GPL licensed, there are over dozen other libraries
Hi!
r215070 moved -Winvalid-offsetof pedwarn from build_class_member_access_expr
(where it warned even about offsetof-like hand-written constructs) to
finish_offsetof. That is fine, the problem is that while
build_class_member_access_expr saw the original first argument to
__builtin_offsetof (the
On Tue, 24 Jan 2017, Pekka Jääskeläinen wrote:
> Hi,
>
> On Tue, Jan 24, 2017 at 7:26 PM, Joseph Myers wrote:
> > Since front ends can't be enabled or disabled on a per-multilib basis, if
> > you want to support any x86/x86_64 GNU/Linux configuration you need to
> > support all of them here (and
On Tue, Jan 24, 2017 at 3:43 PM, Alexandre Oliva wrote:
> On Jan 24, 2017, Jason Merrill wrote:
>> On Mon, Jan 23, 2017 at 7:21 PM, Alexandre Oliva wrote:
>>> On Jan 23, 2017, Jason Merrill wrote:
>>>
>>> + If the newly-created namespace is to be an inline namespace, after
>>> + pus
Hi!
The following testcase ICEd because genericization handled
an is_invisiref_parm PARM_DECL in DECL_INITIAL of the decomposition
artificial variable twice. Fixed by making sure we don't walk
the INDIRECT_REFs added by convert_from_reference for is_invisiref_parm
PARM_DECLs.
Bootstrapped/regtes
On Jan 24, 2017, at 6:16 AM, Kyrill Tkachov wrote:
>
> The tests in this patch fail for me on aarch64-none-elf with:
> relocation R_AARCH64_ADR_PREL_PG_HI21 against external symbol `_impure_ptr'
> can not be used when making a shared object; recompile with -fPIC
>
> I believe since the tests pa
On Jan 24, 2017, Jason Merrill wrote:
> On Mon, Jan 23, 2017 at 7:21 PM, Alexandre Oliva wrote:
>> On Jan 23, 2017, Jason Merrill wrote:
>>
>> + If the newly-created namespace is to be an inline namespace, after
>> + push_namespace, get the nested namespace decl with
>> + get
On Tue, Jan 24, 2017 at 10:09:23AM -0800, Carl E. Love wrote:
> > Do we need a separate testcase to check for this? Or do those specific
> > builtins need better testcases? Or was the bug obvious already?
[ ... ]
> Once the bug for the ALTIVEC_BUILTIN_VEC_PACKS built-in was found, I
> wrote a p
On Tue, 2017-01-24 at 15:30 -0500, David Malcolm wrote:
> On Tue, 2017-01-24 at 13:52 +0100, Martin Jambor wrote:
> > Hi,
> >
> > On Mon, Jan 23, 2017 at 02:11:37PM +0100, Richard Biener wrote:
> > > On Mon, Jan 23, 2017 at 1:02 PM, Martin Jambor
> > > wrote:
> > > > Hi,
> > > >
> > > >
> > > >
On Tue, 2017-01-24 at 13:52 +0100, Martin Jambor wrote:
> Hi,
>
> On Mon, Jan 23, 2017 at 02:11:37PM +0100, Richard Biener wrote:
> > On Mon, Jan 23, 2017 at 1:02 PM, Martin Jambor
> > wrote:
> > > Hi,
> > >
> > >
> > > On Mon, Jan 23, 2017 at 12:56:13PM +0100, Richard Biener wrote:
> > > > On
On Fri, Jan 20, 2017 at 10:53 PM, Richard Henderson wrote:
> On 01/11/2017 06:30 PM, Palmer Dabbelt wrote:
>>
>> +__riscv_save_12:
>> + addi sp, sp, -112
>> + li t1, 0
>> + sd s11, 8(sp)
>> + j .Ls10
>> +
>> +__riscv_save_11:
>> +__riscv_save_10:
>> + addi sp, sp, -112
>> + li t1, -16
>
>
>
Attached is an update documenting a number of options new or updated
in GCC 7. Aldy, if/when you have a minute can you please quickly look
over the -Waloca text to make sure I didn't miss something?
-Walloca
-Walloca-larger-than
-Walloc-size-larger-than
-Walloc-zero
-Wformat-overflow
On Mon, Jan 23, 2017 at 7:21 PM, Alexandre Oliva wrote:
> On Jan 23, 2017, Jason Merrill wrote:
>
> + If the newly-created namespace is to be an inline namespace, after
> + push_namespace, get the nested namespace decl with
> + get_current_binding_level, pop back to the enclosin
OK.
On Tue, Jan 24, 2017 at 2:17 PM, Nathan Sidwell wrote:
> On 01/24/2017 11:36 AM, Jason Merrill wrote:
>
>> This is the wrong place for this; we don't know at this point whether
>> we're in a new-expression or actually creating a temporary. I think we
>> want to add this flag in the call to b
OK.
On Tue, Jan 24, 2017 at 1:53 PM, Nathan Sidwell wrote:
> On 01/24/2017 01:41 PM, Jason Merrill wrote:
>>
>> On Tue, Jan 24, 2017 at 1:31 PM, Nathan Sidwell wrote:
>>>
>>> On 01/23/2017 04:06 PM, Jason Merrill wrote:
>>>
> In this particular case we've also made the base object the contai
On 01/24/2017 11:36 AM, Jason Merrill wrote:
This is the wrong place for this; we don't know at this point whether
we're in a new-expression or actually creating a temporary. I think we
want to add this flag in the call to build_value_init from build_new_1.
And look at other calls to build_valu
On 01/24/2017 01:41 PM, Jason Merrill wrote:
On Tue, Jan 24, 2017 at 1:31 PM, Nathan Sidwell wrote:
On 01/23/2017 04:06 PM, Jason Merrill wrote:
In this particular case we've also made the base object the containing
class, not the unnamed struct member. That means we're looking in the
wrong
Woo!
On Tue, Jan 24, 2017 at 8:05 AM, Nathan Sidwell wrote:
> As some have already noticed, I created a c++-modules branch yesterday.
> Don't get too excited, that doesn't mean I have an implementation to commit
> there.
>
> I expect several false starts, and don't intend to post patches here.
>
On Tue, Jan 24, 2017 at 1:31 PM, Nathan Sidwell wrote:
> On 01/23/2017 04:06 PM, Jason Merrill wrote:
>
>>> In this particular case we've also made the base object the containing
>>> class, not the unnamed struct member. That means we're looking in the
>>> wrong
>>> CONSTRUCTOR and see CONSTRUCTO
This provides a definition of aligned_alloc for targets which have
none of aligned_alloc, posix_memalign, memalign or _aligned_alloc.
The code is based on gcc/config/i386/gmm_malloc.h but modified to only
use sizeof(void*) not 2*sizeof(void*), because I don't understand why
that's used in gmm_mal
Hi,
On Tue, Jan 24, 2017 at 7:26 PM, Joseph Myers wrote:
> Since front ends can't be enabled or disabled on a per-multilib basis, if
> you want to support any x86/x86_64 GNU/Linux configuration you need to
> support all of them here (and possibly disable runtime libraries for
> particular multili
On 01/23/2017 04:06 PM, Jason Merrill wrote:
In this particular case we've also made the base object the containing
class, not the unnamed struct member. That means we're looking in the wrong
CONSTRUCTOR and see CONSTRUCTOR_NO_IMPLICIT_ZERO is true. Whereas for the
subobj's CONSTRUCTOR it is f
On Tue, 2017-01-24 at 11:08 -0600, Segher Boessenkool wrote:
> On Tue, Jan 24, 2017 at 08:28:37AM -0800, Carl E. Love wrote:
> > The following patch fixes an issue with the entries in the table of
> > built-in functions. All of the entries for a given built-in, must occur
> > in the table as a sin
On 03/01/2017 13:13, Wilco Dijkstra wrote:
> Adhemerval Zanella wrote:
>
> Sorry for the late reply - but I think it's getting there. A few more
> comments:
No worries.
>
> + /* If function uses stacked arguments save the old stack value so morestack
> + can return it. */
> + reg11
On Tue, 24 Jan 2017, David Malcolm wrote:
> /* { dg-do run { x86_64-*-* } } */
That's never correct, since x86_64-*-* can have -m32 multilibs and
i?86-*-* can have 64-bit multilibs. You always need to cover all relevant
triplets and then restrict with effective-target selectors to relevant
On Fri, 2017-01-20 at 16:16 +0100, Richard Biener wrote:
[...]
> > Richi: if that patch is approved, are you OK with patch 9 in early
> > stage 4?
>
> Yes.
Thanks.
All of the various parts of patch 9 have now been approved.
I've rebased it, and merged the fixes identified in review.
Testing o
Hi,
I have a patch to fix the following openmp issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79212
Writing openmp directives in a certain way in fortran programs can lead to
the following assert:
internal compiler error: in maybe_lookup_decl_in_outer_ctx, at omp-low.c:4134
0xa941e6 maybe_
On Tue, 24 Jan 2017, Matthias Klose wrote:
> the toplevel configure.ac has:
>
> # Disable the BRIG frontend and libhsail-rt on untested or known
> # broken systems. Currently it has been tested only on x86_64 Linux
> # of the upstream gcc targets. More targets shall be added after testing.
> case
Hi,
Test gcc.dg/vect/vect-24.c starts passing after my vectorizer changes, but not
on all targets. For x86_64, looks like other passes still mess up the IR and
prevent it from being vectorized. This patch removes xfail for ARM targets.
Test result checked. Is it OK?
Thanks,
bin
gcc/testsuite
On 01/24/2017 06:03 PM, Christophe Lyon wrote:
Ha... the regression occurred between r 244818 and r 244816,
and I read r 244816 ChangeLog too quickly and did not notice
it was modifying ifcvt.c in addition to x86-only files.
So it's likely that it's your other patch for pr78634
that caused the
On Tue, Jan 24, 2017 at 08:28:37AM -0800, Carl E. Love wrote:
> The following patch fixes an issue with the entries in the table of
> built-in functions. All of the entries for a given built-in, must occur
> in the table as a single block of entries. Otherwise the code that
> searches the table f
On 24 January 2017 at 17:55, Bernd Schmidt wrote:
> On 01/24/2017 05:50 PM, Kyrill Tkachov wrote:
>>
>>
>> Actually trying it out with an explicit -mcpu=cortex-a5 (so -O2 -S
>> -mfpu=fp-armv8 -mcpu=cortex-a57 -mfloat-abi=hard) I get
>> the test failing before and after the patch. The code generate
On 01/24/2017 05:50 PM, Kyrill Tkachov wrote:
Actually trying it out with an explicit -mcpu=cortex-a5 (so -O2 -S
-mfpu=fp-armv8 -mcpu=cortex-a57 -mfloat-abi=hard) I get
the test failing before and after the patch. The code generated is
vcmp.f64d0, d1
vmrsAPSR_nzcv, FP
On 24/01/17 16:36, Bernd Schmidt wrote:
On 01/24/2017 05:30 PM, Kyrill Tkachov wrote:
The -mfpu is overridden in the testcase to add the ARMv8 instructions.
So to reproduce the compilation in that testcase you'd want
-mfpu=fp-armv8 or
something equivalent rather than vfpv3-d16-fp16.
Exact st
On Tue, 24 Jan 2017, Jakub Jelinek wrote:
> The following patch fixes the warnings (all the 5 fallthrus are intentional)
> for me on x86_64-linux. But I assume it needs to go into glibc first,
> right?
>
> 2017-01-24 Jakub Jelinek
>
> * soft-fp/op-common.h (_FP_MUL, _FP_FMA, _FP_DIV):
On 01/24/2017 09:13 AM, Nathan Sidwell wrote:
On 01/23/2017 05:01 PM, Jason Merrill wrote:
I suppose adding a tsubst flag isn't too horrible. But then we also
need to audit other uses of build_value_init to decide whether they
should build a cleanup or not.
@@ -8055,7 +8055,8 @@ build_over_
GCC maintainers:
The following patch fixes an issue with the entries in the table of
built-in functions. All of the entries for a given built-in, must occur
in the table as a single block of entries. Otherwise the code that
searches the table for a given built-in definition will stop looking
onc
On 01/24/2017 05:30 PM, Kyrill Tkachov wrote:
The -mfpu is overridden in the testcase to add the ARMv8 instructions.
So to reproduce the compilation in that testcase you'd want
-mfpu=fp-armv8 or
something equivalent rather than vfpv3-d16-fp16.
Exact steps please. No one who's not well-versed i
On 24/01/17 16:28, Christophe Lyon wrote:
On 24 January 2017 at 17:02, Kyrill Tkachov wrote:
On 24/01/17 15:21, Segher Boessenkool wrote:
On Tue, Jan 24, 2017 at 01:40:46PM +0100, Bernd Schmidt wrote:
On 01/24/2017 09:38 AM, Christophe Lyon wrote:
It seems that Bernd's patch causes regressi
On January 24, 2017 5:02:39 PM GMT+01:00, Marc Glisse
wrote:
>On Tue, 24 Jan 2017, Jeff Law wrote:
>
>> But that would assume that match.pd is relying on range information
>and could
>> thus use the improved range information. *If* match.pd is using the
>range
>> information generated by VRP,
On 24 January 2017 at 17:02, Kyrill Tkachov wrote:
>
> On 24/01/17 15:21, Segher Boessenkool wrote:
>>
>> On Tue, Jan 24, 2017 at 01:40:46PM +0100, Bernd Schmidt wrote:
>>>
>>> On 01/24/2017 09:38 AM, Christophe Lyon wrote:
It seems that Bernd's patch causes regressions on arm-linux-gnue
On 24/01/17 15:21, Segher Boessenkool wrote:
On Tue, Jan 24, 2017 at 01:40:46PM +0100, Bernd Schmidt wrote:
On 01/24/2017 09:38 AM, Christophe Lyon wrote:
It seems that Bernd's patch causes regressions on arm-linux-gnueabihf
--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:
gcc.target/arm/vse
On Tue, 24 Jan 2017, Jeff Law wrote:
But that would assume that match.pd is relying on range information and could
thus use the improved range information. *If* match.pd is using the range
information generated by VRP, it's not terribly pervasive.
Oh, I thought we already had some explicit c
On 01/24/2017 02:37 AM, Markus Trippelsdorf wrote:
MPFR_RNDx was introduced in MPFR 3.0.0. Since the minimal version that
gcc checks for is 2.4.0, this leads to a build failure.
The fix is straightforward.
Tested on x86_64-pc-linux-gnu. Committed to trunk as obvious.
* gimple-ssa-sprin
This was found building config-list.mk last night using the trunk
compiler. The buffer can clearly overflow for large label numbers.
Confirmed that the microblaze target builds, and installed.
Jeff
commit 5b9382fcd400c8587667d7125f240ebec4ae2c81
Author: law
Date: Tue Jan 24 15:49:32 2017
On 24 January 2017 at 16:46, Ville Voutilainen
wrote:
> On 24 January 2017 at 16:16, Jonathan Wakely wrote:
>>> We do want it for basic_string as well, I think. And while I doubt
>>> your interpretation
>>> of the standard is pedantically correct, I also think that the
>>> standard is broken if i
On 01/24/2017 03:15 AM, Richard Biener wrote:
The more I look at our SCCVN implementation, the more I want to explore
trying to re-use that infrastructure to simplify DOM.
Certainly having a single way to hash/record stmts/expressions on GIMPLE would
be nice. Not sure if the SCCVN one is perf
On Tue, Jan 24, 2017 at 01:40:46PM +0100, Bernd Schmidt wrote:
> On 01/24/2017 09:38 AM, Christophe Lyon wrote:
> >It seems that Bernd's patch causes regressions on arm-linux-gnueabihf
> >--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:
> >
> > gcc.target/arm/vselvcdf.c scan-assembler-times vselvs.
On 01/24/2017 07:29 AM, Marc Glisse wrote:
On Tue, 24 Jan 2017, Richard Biener wrote:
That was my thought as well, but AFAICT we only call into match.pd
from VRP if we changed the insn.
Yes - there was thoughts to change that (but it comes at an expense).
Basically we'd like to re-fold stmts
On Tue, 24 Jan 2017, Jonathan Wakely wrote:
I've just committed this, and then noticed that we don't do the same
optimization for basic_string unless the char_type is char.
Note the "see also" field in that PR ;-)
--
Marc Glisse
On 24 January 2017 at 16:16, Jonathan Wakely wrote:
>> We do want it for basic_string as well, I think. And while I doubt
>> your interpretation
>> of the standard is pedantically correct, I also think that the
>> standard is broken if it
>> doesn't allow this optimization, and the standard should
On Tue, 24 Jan 2017, Richard Biener wrote:
That was my thought as well, but AFAICT we only call into match.pd
from VRP if we changed the insn.
Yes - there was thoughts to change that (but it comes at an expense).
Basically we'd like to re-fold stmts that indirectly use stmts we
changed. We ce
Hi Martin,
>> this broke bootstrap on i386-pc-solaris2.12, sparc-sun-solaris2.12, and
>> i686-pc-linux-gnu (probably every 32-bit host), as confirmed by an
>> i386-pc-solaris2.10 reghunt.
>>
>> E.g. in the Linux/i686 bootstrap, compiling tree-ssa-math-opts.o fails
>> with
>>
>> virtual memory ex
On 24/01/17 14:54 +0200, Ville Voutilainen wrote:
On 24 January 2017 at 14:05, Jonathan Wakely wrote:
I've just committed this, and then noticed that we don't do the same
optimization for basic_string unless the char_type is char. Presumably
this is so that we do call basic_string::compare() an
Hi all,
The tests in this patch fail for me on aarch64-none-elf with:
relocation R_AARCH64_ADR_PREL_PG_HI21 against external symbol `_impure_ptr' can
not be used when making a shared object; recompile with -fPIC
I believe since the tests pass -shared to the linker they should be gated on
the '
On 01/23/2017 05:01 PM, Jason Merrill wrote:
I suppose adding a tsubst flag isn't too horrible. But then we also
need to audit other uses of build_value_init to decide whether they
should build a cleanup or not.
Not too ugly, I guess. Looking at the other calls that end up at
build_target_e
On 16.05.2016 19:25, Pekka Jääskeläinen wrote:
> The configuration file changes and misc. updates required
> by the BRIG frontend.
>
> Also, added include/hsa-interface.h which is hsa.h taken from libgomp
> and will be shared by it (agreed with Martin Liška / SUSE).
>
the toplevel configure.ac h
On 23/01/17 16:45, Gerald Pfeifer wrote:
> Hi Kyrill,
>
> On Mon, 23 Jan 2017, Kyrill Tkachov wrote:
>> This patch adds a short entry for the store merging pass in GCC 7 to the
>> "General Optimizer Improvements" section.
>
> + A new store merging pass has been added. It will attempt to merge
>
As some have already noticed, I created a c++-modules branch yesterday.
Don't get too excited, that doesn't mean I have an implementation to
commit there.
I expect several false starts, and don't intend to post patches here.
Wiki page is https://gcc.gnu.org/wiki/cxx-modules
nathan
--
Nathan S
On 24 January 2017 at 14:05, Jonathan Wakely wrote:
> I've just committed this, and then noticed that we don't do the same
> optimization for basic_string unless the char_type is char. Presumably
> this is so that we do call basic_string::compare() and so call any
> user-defined traits_type::eq()
Hi,
On Mon, Jan 23, 2017 at 02:11:37PM +0100, Richard Biener wrote:
> On Mon, Jan 23, 2017 at 1:02 PM, Martin Jambor wrote:
> > Hi,
> >
> >
> > On Mon, Jan 23, 2017 at 12:56:13PM +0100, Richard Biener wrote:
> >> On Fri, Jan 20, 2017 at 6:25 PM, Pekka Jääskeläinen
> >> wrote:
> >> > Hi Richard,
On 01/24/2017 09:38 AM, Christophe Lyon wrote:
It seems that Bernd's patch causes regressions on arm-linux-gnueabihf
--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:
gcc.target/arm/vselvcdf.c scan-assembler-times vselvs.f64\td[0-9]+ 1
gcc.target/arm/vselvcsf.c scan-assembler-times vselvs.f32\
Committed as obvious.
Richard.
2017-01-24 Richard Biener
PR translation/79208
* ipa-devirt.c (odr_types_equivalent_p): Fix typo in diagnostic.
Index: gcc/ipa-devirt.c
===
--- gcc/ipa-devirt.c(revision 244865
On Tue, Jan 24, 2017 at 07:01:45AM -0500, Nathan Sidwell wrote:
> On 01/24/2017 05:49 AM, Jakub Jelinek wrote:
>
> > ((BIT_FIELD_REF ^ BIT_FIELD_REF ) & 110) == 0
> > out of that. So unless we DTRT (i.e. save constexpr bodies before
> > cp_fold for constexpr evaluation purposes), the workaround
On Mon, Jan 23, 2017 at 6:26 PM, Aldy Hernandez wrote:
> On 01/18/2017 10:10 AM, Richard Biener wrote:
>>
>> On Fri, Jan 13, 2017 at 7:48 PM, Aldy Hernandez wrote:
>
>
> Hi Richard.
>
> I'd be happy to provide a patch, but could you please elaborate, as I'm
> afraid I'm not following.
>
>>> We co
I've just committed this, and then noticed that we don't do the same
optimization for basic_string unless the char_type is char. Presumably
this is so that we do call basic_string::compare() and so call any
user-defined traits_type::eq() function (which is observable). I don't
think that's necessa
On 01/24/2017 05:49 AM, Jakub Jelinek wrote:
((BIT_FIELD_REF ^ BIT_FIELD_REF ) & 110) == 0
out of that. So unless we DTRT (i.e. save constexpr bodies before
cp_fold for constexpr evaluation purposes), the workaround would need
to handle this properly (basically pattern recognize whatever the
Hi,
I committed this patch to the embedded-6-branch to update this branch's
version of the Coprocessor Intrinsics implementation. The code
committed earlier to implement the Coprocessor Intrinsics was based on a
version of the mainline patch that had not been upstreamed yet and that
patch changed
On Tue, Jan 24, 2017 at 11:54:09AM +0100, Richard Biener wrote:
> > Please note that say for:
> > struct S { int : 1; int a : 3; int : 1; int b : 2; };
> >
> > int
> > foo (S a, S b)
> > {
> > return a.a == b.a && a.b == b.b;
> > }
> >
> > (haven't tried to turn that into a constexpr testcase, bu
On Tue, Jan 24, 2017 at 11:49 AM, Jakub Jelinek wrote:
> On Mon, Jan 23, 2017 at 08:49:43AM -0500, Nathan Sidwell wrote:
>> This patch addresses 79118, where we ICE on a constexpr involving bitfields
>> in an unnamed struct (unnamed struct members are a g++ extension).
>>
>> This is really a band-
On Tue, Jan 24, 2017 at 11:12 AM, Bin Cheng wrote:
> Hi,
> Given test as reported in PR79159:
>
> void foo(float tmpCorr[9][9]);
> float bar;
>
> void finalDigits(int& n)
> {
> float tmpCorr[9][9] = {{0}};
>
> foo(tmpCorr);
> for (int i = 0; i < n; i++) {
> for (int j = i+1; j < n; j++)
On Mon, Jan 23, 2017 at 08:49:43AM -0500, Nathan Sidwell wrote:
> This patch addresses 79118, where we ICE on a constexpr involving bitfields
> in an unnamed struct (unnamed struct members are a g++ extension).
>
> This is really a band-aid, because our internal representation BITFIELD_REF
> and t
On Tue, Jan 24, 2017 at 1:03 AM, Jeff Law wrote:
> On 01/21/2017 01:00 AM, Marc Glisse wrote:
>>
>> On Fri, 20 Jan 2017, Jeff Law wrote:
>>
>>> On 01/20/2017 04:30 PM, Jeff Law wrote:
Going to work from the self-contained test...
>
> Here's a test case that's closer to
Hi!
On Tue, Jan 24, 2017 at 10:59:38AM +0100, Sebastian Huber wrote:
...
> mulkf3-sw.c:48:3: note: in expansion of macro ‘FP_MUL_Q’
>FP_MUL_Q (R, A, B);
>^~~~
> /home/sh/gcc-git/libgcc/soft-fp/op-common.h:913:10: warning: this statement
> may fall through [-Wimplicit-fallthrough=]
>
On Tue, Jan 24, 2017 at 01:10:46PM +0300, Maxim Ostapenko wrote:
> gcc/fortran/ChangeLog:
>
> 2017-01-24 Maxim Ostapenko
>
> * f95-lang.c (gfc_create_decls): Include stringpool.h.
> Pass main_input_filename to build_translation_unit_decl.
>
> gcc/ada/ChangeLog:
>
> 2017-01-24 Ma
On Tue, 24 Jan 2017, Maxim Ostapenko wrote:
> Hi,
>
> as Richard pointed out in previous mail, v1 patch regresses compile-time by
> 100% on some fortran cases (PR 79165).
> Doing the linemap operation in build_translation_unit_decl confuses the
> linemap code too much, thus we propagate main_inpu
On Mon, Jan 23, 2017 at 5:07 PM, Jeff Law wrote:
> On 01/23/2017 02:50 AM, Richard Biener wrote:
So ideally DOM and EVRP would merge and CCP, copyprop and VRP
would merge. It's probably not possible (or wise) to merge their
lattices
(maybe to some extent)
>>>
>>>
>>>
Hi,
Given test as reported in PR79159:
void foo(float tmpCorr[9][9]);
float bar;
void finalDigits(int& n)
{
float tmpCorr[9][9] = {{0}};
foo(tmpCorr);
for (int i = 0; i < n; i++) {
for (int j = i+1; j < n; j++) {
bar = tmpCorr[i][j];
}
}
}
Pass cunrolli unrolls the inner lo
On Mon, Jan 23, 2017 at 4:55 PM, Martin Sebor wrote:
>>> Yes, I see that. But when I change size_t to unsigned int (in LP64)
>>> like so:
>>>
>>> void g (int *p, int *q)
>>> {
>>> unsigned n = (unsigned)(p - q);
>>>
>>> if (n < 10)
>>> f (__builtin_alloca (n));
>>> }
>>>
>>> -
Hi,
as Richard pointed out in previous mail, v1 patch regresses compile-time
by 100% on some fortran cases (PR 79165).
Doing the linemap operation in build_translation_unit_decl confuses the
linemap code too much, thus we propagate main_input_filename through
DECL_NAME of TRANSLATION_UNIT_DECL
Hi,
On Mon, Jan 23, 2017 at 11:05:03PM +0100, Rainer Orth wrote:
> Hi Martin,
>
> > when I fixed PR 78365 by streaming types of parameters that might not
> > have been anywhere else, I forgot that I was holding them in non-GC
> > memory and so I caused PR 79108. The following patch fixes it by
>
Hi,
the first of the following two patches fixes PR 79198. The issue is
that early inliner creates ipa_node_params_sum then and calls
ipa_free_all_node_params to release it many times (I guess for each
function) and because I forgot to call the destructor in the function,
we ended up with multitu
MPFR_RNDx was introduced in MPFR 3.0.0. Since the minimal version that
gcc checks for is 2.4.0, this leads to a build failure.
The fix is straightforward.
Tested on x86_64-pc-linux-gnu. Committed to trunk as obvious.
* gimple-ssa-sprintf.c (format_floating): Change MPFR_RNDx to
On 20 January 2017 at 20:24, Segher Boessenkool
wrote:
> Hi Bernd,
>
> On Fri, Jan 20, 2017 at 01:33:59PM +0100, Bernd Schmidt wrote:
>> So, when looking for situations where we have only one condition, we can
>> try to undo the conversion of a plain REG into a condition, on the
>> grounds that th
Hi!
The target requirement in the test was meant to prevent running the test
on x86 without sse2 support, but unfortunately disabled the test also on
non-x86. The following test fixes that, regtested on
{aarch64,x86_64,powerpc64,powerpc64le,i686,s390x}-linux, committed to trunk
as obvious.
The te
91 matches
Mail list logo
