Ping!
Regards
Senthil
On Fri, Apr 10, 2015 at 12:19:36PM +0530, Senthil Kumar Selvaraj wrote:
> Hi,
>
> This (rather big) patch is an attempt to generate per function DWARF
> information for functions that go into their own sections (through
> -ffunction-section or otherwise). This is so th
Richard,
this is my attempt to make sense of TYPE_CANONICAL at LTO. My undrestanding is
that gimple_canonical_types_compatible_p needs to return true for all pairs of
types that are considered compatible across compilation unit for any of
languages we support (and in a sane way for cross language,
2015-05-20 Max Filippov
gcc/
* config/xtensa/xtensa.c (init_alignment_context): Replace MULT
by BITS_PER_UNIT with ASHIFT by exact_log2 (BITS_PER_UNIT).
---
gcc/config/xtensa/xtensa.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/config/xtensa/xten
On 07/05/15 17:24, James Greenhalgh wrote:
> On Wed, May 06, 2015 at 03:12:33AM +0100, Kugan wrote:
gcc/ChangeLog:
2015-04-24 Kugan Vivekanandarajah
Jim Wilson
* config/arm/aarch-common-protos.h (struct mem_cost_table): Added
new fields loadv
On Tue, May 19, 2015 at 8:03 PM, Sandra Loosemore
wrote:
> On 05/19/2015 05:34 PM, Alan Modra wrote:
>>
>> On Tue, May 19, 2015 at 02:18:23PM -0400, David Edelsohn wrote:
>>>
>>> This seems reasonable to me.
>>>
>>> Alan, any thoughts from you?
>>
>>
>> Looks good.
>
>
> Thanks. I've checked the
Honza pointed out we were leaking some memory in the jump threading
code. There's at least two leaks, this fixes the first.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed on the trunk.
commit f4517a9d2f17b0890d9fe1159a3981985bed5672
Author: Jeff Law
Date: Tue Ma
I've committed this obvious patch for 65954. We failed to issue a diagnostic
for a failed class enum lookup, and returned NULL, rather than error_mark_node,
leading to a seg fault.
booted & tested on x86_64-linux.
nathan
2015-05-19 Nathan sidwell
cp/
PR c++/65954
* typeck.c (finish_cla
On 05/02/2015 04:16 PM, Ed Smith-Rowland wrote:
This extends' static assert to not require a message string.
I elected to make this work also for C++11 and C++14 and warn only
with -pedantic.
I think many people just write
static_assert(thing, "");
.
I took the path of building an empty stri
Thanks for reviewing! Somehow I missed seeing your OK in yesterday's
email. I have far too many emails in my inbox.. Patch series
committed as revisions 223424, 223425, 223426, and 223427. I made a
change to the comment for rs6000_supports_split_stack, instead of
/* -fsplit-stack uses a field
On Mon, May 18, 2015 at 02:05:59PM -0400, David Edelsohn wrote:
> On Sun, May 17, 2015 at 10:54 PM, Alan Modra wrote:
> > This patch changes rs6000_stack_info to keep save areas offsets even
> > when not used. I need lr_save_offset valid for split-stack, and it
> > seemed reasonable to treat the
On Tue, May 19, 2015 at 05:10:11PM -0700, H.J. Lu wrote:
> On Tue, May 19, 2015 at 1:54 PM, Rich Felker wrote:
> > On Tue, May 19, 2015 at 01:27:06PM -0700, H.J. Lu wrote:
> >> On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
> >> > On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
> >>
From: Trevor Saunders
Hi,
This is a straight forward fixup of the hash table descriptor in winnt.c
causing the PR.
Tested a cross to i686-cygwin now builds, and committing to trunk.
Trev
gcc/ChangeLog:
2015-05-19 Trevor Saunders
PR c++/65835
* config/i386/winnt.c (struct
On Tue, May 19, 2015 at 07:40:15AM -0500, Lynn A. Boger wrote:
> Questions on the use of the options for split stack:
>
> - The way this is implemented, split stack is generated if the
> target platform supports split stack, on ppc64/ppc64le as well
> as on x86, and the use of -fno-split-stack doe
On Tue, May 19, 2015 at 1:54 PM, Rich Felker wrote:
> On Tue, May 19, 2015 at 01:27:06PM -0700, H.J. Lu wrote:
>> On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
>> > On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
>> >> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson
>> >> wro
On 05/19/2015 05:34 PM, Alan Modra wrote:
On Tue, May 19, 2015 at 02:18:23PM -0400, David Edelsohn wrote:
This seems reasonable to me.
Alan, any thoughts from you?
Looks good.
Thanks. I've checked the patch into mainline (r223418). I assume this
is also a candidate for backporting to the
On Tue, May 19, 2015 at 02:18:23PM -0400, David Edelsohn wrote:
> This seems reasonable to me.
>
> Alan, any thoughts from you?
Looks good.
--
Alan Modra
Australia Development Lab, IBM
Hi,
The SH testcase pr64366 would fail on SH2A because -m4 -ml is specified
in dg-options of the test case. Target options such as CPU and
endianness are usually not specified in the test cases directly, but
when invoking the test suite. Fixed with the attached patch. Committed
as r223417.
Che
On Mon, 2015-05-18 at 23:27 -0400, Nuno Diegues wrote:
> On Mon, May 18, 2015 at 5:29 PM, Torvald Riegel wrote:
> >
> > Are there better options for the utility function, or can we tune it to
> > be less affected by varying txn length and likelihood of txnal vs.
> > nontxnal code? What are the th
> On 05/19/2015 01:33 PM, Jan Hubicka wrote:
> >I tracked down that those are implicit typedef created by
> >create_implicit_typedef.
> >My patch made them no longer anonymous that in turn triggers the bogus
> >diagnostics.
> >I do not think it is fully correct though - those types are not anonym
On 05/19/2015 01:33 PM, Jan Hubicka wrote:
I tracked down that those are implicit typedef created by
create_implicit_typedef.
My patch made them no longer anonymous that in turn triggers the bogus
diagnostics.
I do not think it is fully correct though - those types are not anonymous.
Hmm? Th
On 19 May 2015 at 14:34, Richard Biener wrote:
> On Tue, 19 May 2015, Prathamesh Kulkarni wrote:
>
>> On 18 May 2015 at 20:17, Prathamesh Kulkarni
>> wrote:
>> > On 18 May 2015 at 14:12, Richard Biener wrote:
>> >> On Sat, 16 May 2015, Prathamesh Kulkarni wrote:
>> >>
>> >>> Hi,
>> >>> genmatch
On 05/18/2015 11:07 PM, Mikhail Maltsev wrote:
It seems rather weird to me: I have definitely sent this message, but
now I realized that it did not get to the mailing list archive (and it
was not bounced either). Thus, resending.
I got the original, not sure why it didn't show up in the archives
On Tue, May 19, 2015 at 01:27:06PM -0700, H.J. Lu wrote:
> On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
> > On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
> >> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson
> >> wrote:
> >> > On 05/19/2015 12:06 PM, H.J. Lu wrote:
> >> >> O
Hello
Is it ok ?
François
On 04/05/2015 22:31, François Dumont wrote:
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/i
On 03/05/2015 22:19, François Dumont wrote:
On 30/04/2015 13:18, Jonathan Wakely wrote:
On 30/04/15 10:40 +0200, François Dumont wrote:
On 27/04/2015 13:55, Jonathan Wakely wrote:
(Alternatively, could the same simplification be made for
__miter_base? Do we need _Miter_base<> or just two overl
On Tue, May 19, 2015 at 1:15 PM, Rich Felker wrote:
> On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
>> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson wrote:
>> > On 05/19/2015 12:06 PM, H.J. Lu wrote:
>> >> On Tue, May 19, 2015 at 11:59 AM, Richard Henderson
>> >> wrote:
>> >>>
On Tue, May 19, 2015 at 12:17:18PM -0700, H.J. Lu wrote:
> On Tue, May 19, 2015 at 12:11 PM, Richard Henderson wrote:
> > On 05/19/2015 12:06 PM, H.J. Lu wrote:
> >> On Tue, May 19, 2015 at 11:59 AM, Richard Henderson
> >> wrote:
> >>> On 05/19/2015 11:06 AM, Rich Felker wrote:
> I'm still
On 05/19/2015 12:35 PM, Rich Felker wrote:
> Why would you recompute it (this requires a fairly expensive call that
> reads or pops its own return address) rather than simply spilling the
> already-computed value and reloading it from the stack?
>
> The only example I can think of where it might m
On 05/19/2015 12:17 PM, H.J. Lu wrote:
>> But my point is that the only time the compiler should present you with the
>> form of indirect branch you're looking for is when there's no place to hoist
>> the load.
>>
>> At which point, is it really worth adding a new relocation to the ABI? Is it
>> r
On Tue, May 19, 2015 at 11:59:00AM -0700, Richard Henderson wrote:
> On 05/19/2015 11:06 AM, Rich Felker wrote:
> > I'm still mildly worried that concerns for supporting
> > relaxation might lead to decisions not to optimize code in ways that
> > would be difficult to relax (e.g. certain types of a
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2015-05-19 Marek Polacek
* c-typeck.c (start_init): Use AGGREGATE_TYPE_P.
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 7f54490..cf5322f 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -7126,10 +7126,7 @@ start_init (
On Tue, May 19, 2015 at 8:33 AM, Joseph Myers wrote:
> On Tue, 19 May 2015, H.J. Lu wrote:
>
>> > I think the whole thing should be posted as one patch, with both the
>> > target-independent changes and the target-specific changes for all
>> > targets.
>> >
>>
>> That is what makes me concerned.
On Mon, 2015-05-18 at 17:36 +0100, Matthew Wahab wrote:
> Hello,
>
> On 15/05/15 17:22, Torvald Riegel wrote:
> > This patch improves the documentation of the built-ins for atomic
> > operations.
>
> The "memory model" to "memory order" change does improve things but I think
> that
> the patch h
On Tue, May 19, 2015 at 12:11 PM, Richard Henderson wrote:
> On 05/19/2015 12:06 PM, H.J. Lu wrote:
>> On Tue, May 19, 2015 at 11:59 AM, Richard Henderson wrote:
>>> On 05/19/2015 11:06 AM, Rich Felker wrote:
I'm still mildly worried that concerns for supporting
relaxation might lead to
On 05/19/2015 12:06 PM, H.J. Lu wrote:
> On Tue, May 19, 2015 at 11:59 AM, Richard Henderson wrote:
>> On 05/19/2015 11:06 AM, Rich Felker wrote:
>>> I'm still mildly worried that concerns for supporting
>>> relaxation might lead to decisions not to optimize code in ways that
>>> would be difficul
On Tue, May 19, 2015 at 06:01:07PM +0200, Michael Matz wrote:
> Hi,
>
> On Tue, 19 May 2015, Jeff Law wrote:
>
> > > > Forget lazy binding. It's dead anyway because serious distros want
> > > > PIE+relro+bindnow+...
> > >
> > > You keep saying this, but I can't help the feeling it's mostly beca
On Tue, May 19, 2015 at 11:59 AM, Richard Henderson wrote:
> On 05/19/2015 11:06 AM, Rich Felker wrote:
>> I'm still mildly worried that concerns for supporting
>> relaxation might lead to decisions not to optimize code in ways that
>> would be difficult to relax (e.g. certain types of address loa
Probably a misapplied patch: the dependency of the shared libgcc on the shared
libunwind is in a wrong place in Makefile. The patch also removes a useless
endif/ifneq pair.
Tested on x86_64-suse-linux and ia64-suse-linux, applied as obvious.
2015-05-19 Eric Botcazou
* Makefile.in
On 05/19/2015 11:06 AM, Rich Felker wrote:
> I'm still mildly worried that concerns for supporting
> relaxation might lead to decisions not to optimize code in ways that
> would be difficult to relax (e.g. certain types of address load
> reordering or hoisting) but I don't understand GCC internals
Hi,
The original patch had a missing declaration of micromips_globals in mips.h
that appears to be the cause of segmentation faults when building
mips-mti-linux-gnu.
I didn't get any failures just before the submission neither on
mips-img-linux-gnu
nor mips64el-linux-gnu and the test case is to
This seems reasonable to me.
Alan, any thoughts from you?
Thanks, David
On Mon, May 18, 2015 at 12:22 PM, Sandra Loosemore
wrote:
> We've found that configuring a powerpc-linux-gnu cross toolchain with
> --enable-targets=all no longer enables -m64 support in GCC 5, due to the
> patch for PR ta
On 05/11/2015 03:23 PM, Andreas Krebbel wrote:
> With this patch .gnu_attribute is used to mark binaries with a vector
> ABI tag. This is required since the z13 vector support breaks the ABI
> of existing vector_size attribute generated vector types:
>
> 1. vector_size(16) and bigger vectors are
On Tue, May 19, 2015 at 10:22 AM, Yury Gribov wrote:
> On 05/19/2015 09:16 AM, Sriraman Tallam wrote:
>>
>> We have the following problem with selectively compiling modules with
>> -m options and I have provided a solution to solve this. I would
>> like to hear what you think.
>>
>> Multi version
On Tue, May 19, 2015 at 11:08 AM, Yunlian Jiang wrote:
>
> I could do that and it make the compilation of libiberty passes.
> However, I have some other problem when using clang to build gdb
> because of libiberty.
>
> Some c file from other component may include 'libiberty.h' which contains
> th
> If the other c file only includes libiberty.h and does not include the
> libiberty/config.h and
In general, such "other c files" should have their own config.h that
does the same test and has its own HAVE_DECL_ASPRINTF.
That way, the config.h matches the compiler options being used, and
not th
I could do that and it make the compilation of libiberty passes.
However, I have some other problem when using clang to build gdb
because of libiberty.
Some c file from other component may include 'libiberty.h' which contains
the following
#if !HAVE_DECL_ASPRINTF
/* Like sprintf but provides a p
On Tue, May 19, 2015 at 04:43:53PM +0200, Michael Matz wrote:
> Hi,
>
> On Fri, 15 May 2015, Rich Felker wrote:
>
> > Forget lazy binding. It's dead anyway because serious distros want
> > PIE+relro+bindnow+...
>
> You keep saying this, but I can't help the feeling it's mostly because
> musl do
Self-explanatory, tested on x86_64-suse-linux, applied as obvious.
2015-05-19 Eric Botcazou
* stor-layout.c (finalize_type_size): Use AGGREGATE_TYPE_P.
(layout_type): Use RECORD_OR_UNION_TYPE_P.
--
Eric BotcazouIndex: stor-layout.c
==
On 2015.05.19 at 19:33 +0200, Jan Hubicka wrote:
>
> Jason,
> I just noticed that there are bogus ODR violation warnings during
> LTO-bootstrap
> (that breaks -Werror builds). It was caused by my work-around for
> type_in_anonymous_namespace
> for the issue discussed in:
> https://gcc.gnu.org/m
On 05/18/2015 02:16 AM, David Sherwood wrote:
Hi Jeff,
Thanks for the suggestion. I did a bootstrap x86_64 build before and after my
patch and looked for differences in the last stage object files and there were
plenty of them. I chose a nice simple function (check_callers) from
ipa-inline-analy
Jason,
I just noticed that there are bogus ODR violation warnings during LTO-bootstrap
(that breaks -Werror builds). It was caused by my work-around for
type_in_anonymous_namespace
for the issue discussed in:
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01245.html
(i.e. the TYPE_STUB_DECL disuc
On Fri, May 08, 2015 at 01:05:59PM -0600, Jeff Law wrote:
> On 05/06/2015 11:29 AM, Michael Meissner wrote:
> >On Wed, May 06, 2015 at 04:03:00PM +0100, Richard Sandiford wrote:
> >>Jeff Law writes:
> >>>So my worry here is that folks writing these loops to iterate over modes
> >>>are going to eas
On 05/16/2015 07:55 PM, Hans-Peter Nilsson wrote:
On Sat, 16 May 2015, Segher Boessenkool wrote:
On Sat, May 16, 2015 at 12:36:38PM -0400, Hans-Peter Nilsson wrote:
On Sat, 16 May 2015, Segher Boessenkool wrote:
On Fri, May 15, 2015 at 10:40:48PM -0400, Hans-Peter Nilsson wrote:
I confess the
On 05/19/2015 09:16 AM, Sriraman Tallam wrote:
We have the following problem with selectively compiling modules with
-m options and I have provided a solution to solve this. I would
like to hear what you think.
Multi versioning at module granularity is done by compiling a subset
of modules with
On Tue, May 19, 2015 at 2:39 AM, Richard Biener
wrote:
> On Tue, May 19, 2015 at 8:16 AM, Sriraman Tallam wrote:
>> We have the following problem with selectively compiling modules with
>> -m options and I have provided a solution to solve this. I would
>> like to hear what you think.
>>
>> Mult
Hi!
When working on taskloop, I've noticed various issues in the OpenMP 4.0
handling of the linear/lastprivate (explicit as well as implicit) clauses.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
plan to backport to 5/4.9 after a while.
2015-05-19 Jakub Jelinek
Re-pinging a patch from last year that never got reviewed:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00511.html
This problem still exists in GCC 5.1 and the above patch still fixes it.
I haven't tried mainline head yet, but it doesn't look like anything
else has touched this since we bran
> Date: Tue, 19 May 2015 11:33:16 +0200
> Subject: Re: Refactor gimple_expr_type
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tbsau...@tbsaunde.org; gcc-patches@gcc.gnu.org
>
> On Tue, May 19, 2015 at 12:04 AM, Aditya K wrote:
>>
>>
>>
w.r.t. the PR48052, here is the patch which finds out if scev would wrap or not.
The patch symbolically evaluates if valid_niter>= loop->nb_iterations is true.
In that case the scev would not wrap (??).
Currently, we only look for two special 'patterns', which are sufficient to
analyze the simple
>
> Hm. But which options are unsafe? Also wouldn't it be better to simply
> _not_ have unsafe options produce comdats but always make local clones
> for them (thus emit the comdat with "unsafe" flags dropped)?
Always localize comdat functions may lead to text size increase. It
does not work if
On 19 May 2015 at 15:32, James Greenhalgh wrote:
> On Tue, May 12, 2015 at 09:30:48PM +0100, Christophe Lyon wrote:
>> This patch series is a follow-up to the tests I already contributed,
>> converted from my original testsuite.
>>
>> This series consists in 13 new files, which can be committed
>>
On Tue, May 19, 2015 at 4:54 PM, wrote:
>
>
>
>
>> On May 19, 2015, at 5:54 AM, Ramana Radhakrishnan
>> wrote:
>>
>> Hi,
>>
>> Like the ARM port, the AArch64 ports needs to set glibc_integral_traps to
>> false as integer divide instructions do not trap.
>>
>> Bootstrapped and regression tested
Hi,
On Tue, 19 May 2015, Jeff Law wrote:
> > > Forget lazy binding. It's dead anyway because serious distros want
> > > PIE+relro+bindnow+...
> >
> > You keep saying this, but I can't help the feeling it's mostly because
> > musl doesn't support it ;-)
>
> FWIW, Red Hat is pushing PIE & parti
> On May 19, 2015, at 5:54 AM, Ramana Radhakrishnan
> wrote:
>
> Hi,
>
> Like the ARM port, the AArch64 ports needs to set glibc_integral_traps to
> false as integer divide instructions do not trap.
>
> Bootstrapped and regression tested on aarch64-none-linux-gnu
>
> Ok to apply ?
Not r
Hans-Peter Nilsson writes:
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -f
Hi Maintainers,
Please find the attached patch, that fixes add/extend gcc test suite failures
in Aarch64 target.
Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049
These tests started to fail after we prevented combiner from converting shift
RTX to mult RTX, when the RTX is not inside a
Hi Venkat,
On 19/05/15 16:37, Kumar, Venkataramanan wrote:
Hi Maintainers,
Please find the attached patch, that fixes add/extend gcc test suite failures
in Aarch64 target.
Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049
These tests started to fail after we prevented combiner from conv
On Tue, May 19, 2015 at 8:33 AM, wrote:
>
>
> From: gcc-patches-ow...@gcc.gnu.org [gcc-patches-ow...@gcc.gnu.org] on behalf
> of H.J. Lu [hjl.to...@gmail.com]
> Sent: Tuesday, May 19, 2015 11:27 AM
> To: Joseph Myers
> Cc: Magnus Granberg; GCC Patches
> S
From: gcc-patches-ow...@gcc.gnu.org [gcc-patches-ow...@gcc.gnu.org] on behalf
of H.J. Lu [hjl.to...@gmail.com]
Sent: Tuesday, May 19, 2015 11:27 AM
To: Joseph Myers
Cc: Magnus Granberg; GCC Patches
Subject: Re: PING^3: [PATCH]: New configure options that m
On Tue, 19 May 2015, H.J. Lu wrote:
> > I think the whole thing should be posted as one patch, with both the
> > target-independent changes and the target-specific changes for all
> > targets.
> >
>
> That is what makes me concerned. I have some simple target-specified
> patches which weren't re
On Tue, May 19, 2015 at 8:21 AM, Joseph Myers wrote:
> On Mon, 18 May 2015, H.J. Lu wrote:
>
>> > Have updates for all affected specs for all targets been posted? I just
>> > saw a small and apparently arbitrary subset of targets with patches, and
>> > no explanation of how those targets were ide
On Mon, 18 May 2015, H.J. Lu wrote:
> > Have updates for all affected specs for all targets been posted? I just
> > saw a small and apparently arbitrary subset of targets with patches, and
> > no explanation of how those targets were identified or why the other
> > targets with specs mentioning t
> From: Richard Sandiford
> Date: Mon, 18 May 2015 20:09:19 +0200
> While looking at a profile of gcc, I noticed one thing fairly high
> up the list was a loop iterating over all the registers in a REG,
> apparently due to the delay in computing the index for hard_regno_nregs
> and then loading t
On Tue, May 19, 2015 at 5:10 PM, Uros Bizjak wrote:
> No functional changes.
>
> 2015-05-18 Uros Bizjak
>
> * config/alpha/alpha.c (alpha_legitimize_reload_address)
> (alpha_preferred_reload_class, alpha_legitimate_constant_p): Use
> CONST_INT_P, CONST_SCALAR_INT_P and CONST_DOUBLE_
No functional changes.
2015-05-18 Uros Bizjak
* config/alpha/alpha.c (alpha_legitimize_reload_address)
(alpha_preferred_reload_class, alpha_legitimate_constant_p): Use
CONST_INT_P, CONST_SCALAR_INT_P and CONST_DOUBLE_P predicates.
(alpha_split_reload_pair) :
Use CASE_CONST_
On 05/19/2015 08:43 AM, Michael Matz wrote:
Hi,
On Fri, 15 May 2015, Rich Felker wrote:
Forget lazy binding. It's dead anyway because serious distros want
PIE+relro+bindnow+...
You keep saying this, but I can't help the feeling it's mostly because
musl doesn't support it ;-)
FWIW, Red Hat is
On 05/19/2015 01:41 AM, Andreas Krebbel wrote:
> On 05/18/2015 07:35 PM, Richard Henderson wrote:
>> On 05/11/2015 06:23 AM, Andreas Krebbel wrote:
>>> @@ -6784,14 +6784,18 @@ expand_vec_perm (machine_mode mode, rtx v0, rtx v1,
>>> rtx sel, rtx target)
>>> {
>>>/* Multiply each elemen
Hi,
On Fri, 15 May 2015, Rich Felker wrote:
> Forget lazy binding. It's dead anyway because serious distros want
> PIE+relro+bindnow+...
You keep saying this, but I can't help the feeling it's mostly because
musl doesn't support it ;-)
No, you don't have to use bindnow to get the effects of re
This small refinement to the -fsplit-stack prologue arg pointer
initialization improves code generation. Compare the -O2
gcc/testsuite/gcc.dg/split-3.c code for down() below.
beforeafter
mflr 0mflr 0
std 31,-8(1)std 31,-8(1)
std 0,16(1)mr 12,1
On Sun, May 17, 2015 at 10:54 PM, Alan Modra wrote:
> This patch tidies the prologue and epilogue altivec code a little.
> A number of places using info->altivec_size unnecessarily also test
> TARGET_ALTIVEC_ABI, when rs6000_stack_info() guarantees that
> info->altivec_size is zero if !TARGET_ALTI
On 17/05/15 22:21 +0200, François Dumont wrote:
Ok, I just commit fixing some other lines length except those having a
long hyperlink, I didn't want to break those.
Yep, thanks. I think we should backport Nathan's patch and your one to
the gcc-5-branch too.
I'll make a note to do that before t
This PR points out that we output same -Wformat warning twice when using
__attribute__ ((format)). The problem was that attribute_value_equal
(called when processing merge_attributes) got two lists:
"format printf, 1, 2" and "__format__ __printf__, 1, 2", these should be
equal. But since attribut
This fixes some missed optimizations I should have made when adding
the new std::__cxx11::list, making use of the O(1) list::size() when
it saves work.
In the equality comparisons two lists can't be equal if their sizes
differ.
When resizing a list we don't need to walk the list to find whether
Le 19/05/2015 10:50, Andre Vehreschild a écrit :
> Hi all,
>
> find attached latest version to fix 65548.
>
> Bootstraps and regtests ok on x86_64-linux-gnu/f21.
>
OK. Thanks.
Mikael
Hi,
attached is the most recent version of the patch for 58586. It adapts to
recent trunk and addresses the caveats so far, i.e. the testcases in the
comments now compile and run again w/o errors.
Bootstraps and regtests fine on x86_64-linux-gnu/f21.
Comments?
- Andre
On Fri, 8 May 2015 16:11:
On Tue, May 12, 2015 at 09:30:48PM +0100, Christophe Lyon wrote:
> This patch series is a follow-up to the tests I already contributed,
> converted from my original testsuite.
>
> This series consists in 13 new files, which can be committed
> independently.
>
> Another series (hopefully final) wi
Test gcc.c-torture/execute/memcpy-bi.c (-O2) failed for attiny40 device.
Cause seems to be in "load from memory" as it is not restoring base
register after load instructions generated.
Function avr_out_load_psi_reg_no_disp_tiny in avr.c:
It returns just after emitting instructions to load from mem
Hi,
Like the ARM port, the AArch64 ports needs to set glibc_integral_traps
to false as integer divide instructions do not trap.
Bootstrapped and regression tested on aarch64-none-linux-gnu
Ok to apply ?
regards
Ramana
2015-05-17 Ramana Radhakrishnan
* configure.host: Define cpu
Hardware Integer divide instructions do not trap. Define this to be so
for the ARM port.
Applied to trunk after a build and test across architecture ranges and a
bootstrap and regression run on a Cortex-A15 - a v7ve core that has
hardware divide instructions.
A patch for AArch64 follows.
re
2015-05-18 16:51 GMT-03:00 :
> Hi, this patch adds two new plugin events PLUGIN_START_PARSE_FUNCTION and
> PLUGIN_FINISH_PARSE_FUNCTION. These events are invoked at start_function and
> finish_function in gcc/c/c-decl.c and gcc/cp/decl.c respectively in the C and
> C++ frontends.
> PLUGIN_START
Hi,
so here is the update on pr 64674. Besides adapting to current trunk nothing
has changed from the previous version. The links for getting the patches this
one depends on are:
PR65548 v5: https://gcc.gnu.org/ml/fortran/2015-05/msg00123.html and
PR44672 v6: https://gcc.gnu.org/ml/fortran/2015-0
Hi Guys,
I am applying the patch below to enhance the zero_extendhisi2 pattern
in the MSP430 backend so that it can cope with separate source and
destination registers. This makes zero extending into another
register more efficient and it also helps to work around a reload bug
reported
On Tue, 19 May 2015, Rainer Orth wrote:
> Richard Biener writes:
>
> > Well, not really - but at least don't fail vectorization because of that
> > but allow it to proceed the "build up from scalar pieces" path.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
>
On Tue, May 19, 2015 at 12:17 PM, Thomas Preud'homme wrote:
> 2015-05-18 Thomas Preud'homme
>
> PR rtl-optimization/66168
> * loop-invariant.c (move_invariant_reg): Set inv->reg to destination
> of inv->insn when moving an invariant without introducing a temporary
>
On Mon, Apr 20, 2015 at 11:16:02AM +0100, Kyrylo Tkachov wrote:
> Hi all,
>
> The ICE in the PR happens when we pass a 1x(128-bit float) vector as an
> argument.
> The aarch64 backend erroneously classifies it as a composite type when in
> fact it
> is a short vector according to AAPCS64
> (sectio
Richard Biener writes:
> Well, not really - but at least don't fail vectorization because of that
> but allow it to proceed the "build up from scalar pieces" path.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
The testcase FAILs on Solaris/SPARC:
FAIL: gcc.dg/vect/b
On Wed, May 6, 2015 at 7:02 PM, Richard Biener
wrote:
> On Mon, May 4, 2015 at 9:47 PM, Abderrazek Zaafrani
> wrote:
>> This is an old thread and we are still running into similar issues:
>> Code is not being vectorized on 64-bit target due to scev not being
>> able to optimally analyze overflow
On Tue, May 19, 2015 at 11:36:58AM +0100, Julian Brown wrote:
> This patch fixes an oversight whereby if the CUDA libraries are
> available for some reason on a system that doesn't actually contain an
> nVidia card, an OpenACC program will raise an error if the NVPTX
> backend is picked as a defaul
Hi,
This patch fixes an oversight whereby if the CUDA libraries are
available for some reason on a system that doesn't actually contain an
nVidia card, an OpenACC program will raise an error if the NVPTX
backend is picked as a default instead of falling back to some other
device instead.
OK for g
Hi,
This patch adds several tests of vector-single/vector-partitioned mode,
as part of work implementing the OpenACC execution model.
Pre-approved for gomp4 branch. I will apply there shortly.
Thanks,
Julian
ChangeLog
libgomp/
* testsuite/libgomp.oacc-c-c++-common/vec-single-{1,2,3,4,
1 - 100 of 125 matches
Mail list logo
