Jeff Law writes:
> On 05/18/2015 12:19 PM, Richard Sandiford wrote:
>> This patch replaces the current REG "i0" format with a dedicated structure,
>> so that we can make use of the extra 32 bits in the "i" field.
>>
>> Of the places that iterate on formats and do something for 'i's,
>> most alread
On 05/19/2015 01:00 AM, Richard Sandiford wrote:
Just to confirm, this doesn't change the size of a REG object, right?
If it doesn't change the size, then it's OK.
It doesn't change the size for LP64 hosts. It makes it 32 bits bigger
for ILP32 hosts. See https://gcc.gnu.org/ml/gcc-patches/201
On 05/15/2015 08:38 AM, Martin Liška wrote:
Hello.
Following patch attempts to rewrite memory reports for GCC's internal
allocations
so that it uses a new template type. The type shares parts which are
currently duplicated,
adds support for special 'counters' and introduces new support for
hash-
[ moved to gcc-patches ml ]
On 18-05-15 17:31, Tom de Vries wrote:
Thomas,
In ran into this bootstrap failure with branch gomp-4_0-branch:
...
src/gcc-gomp-4_0-branch/gcc/omp-low.c:2897:1: error: 'omp_context*
enclosing_target_ctx(omp_context*)' defined but not used
[-Werror=unused-function]
Hi,
Since a recent change to the tree optimizers
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00089.html
some related SH patterns stopped working. The attached patch fixes
this.
Tested briefly with 'make all' and with
make -k check-gcc RUNTESTFLAGS="sh.exp=pr54236* --target_board=sh-sim
\{-m2/-
On Mon, 18 May 2015, Prathamesh Kulkarni wrote:
> On 18 May 2015 at 14:12, Richard Biener wrote:
> > On Sat, 16 May 2015, Prathamesh Kulkarni wrote:
> >
> >> Hi,
> >> genmatch generates incorrect code for following (artificial) pattern:
> >>
> >> (for op (plus)
> >> op2 (op)
> >> (simplif
On Tue, May 19, 2015 at 10:33:08AM +0200, Richard Biener wrote:
> > Would that be a good idea ? For symmetry, I thought
> > (for op (list)
> > op2 (op))
> > should be supported too.
>
> Hmm, but is this really a useful extension? To me it just complicates
> the syntax for the occasional rea
On 05/18/2015 04:19 PM, Richard Biener wrote:
> On Mon, May 18, 2015 at 3:41 PM, Andreas Krebbel
> wrote:
>> The new version also changes the type for the alternative_mask to unsigned
>> HOST_WIDE_INT.
>>
>> Bootstrapped without regressions on x86-64.
>>
>> Ok to apply?
>
> Please use uint64_t i
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 element by its byte size. */
>>machine_mode selmode
On Mon, 18 May 2015, Jan Hubicka wrote:
> > > + if (!comp_type_attributes (t1, t2))
> > > + return false;
> > >
> > > Because I think the TBAA does not care about attribute lists. I suppose
> > > this
> > > is kind-of harmless because of:
> >
> > I think that was about attributes like 'pa
Hi all,
find attached latest version to fix 65548.
Bootstraps and regtests ok on x86_64-linux-gnu/f21.
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr65548_5.clog
Description: Binary data
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 814bdde..6d565ae 100
On Mon, 18 May 2015, Jakub Jelinek wrote:
> Hi!
>
> As the testcases show, for signed types we really should use SIGNED rather
> than UNSIGNED as tree_int_cst_min_precision argument, that function doesn't
> really do the desired thing with UNSIGNED for negative values and with
> -fwrapv we just w
> Some pieces of code create a temporary REG or MEM and only fill it
> in later when they're testing the cost of a particular rtx. This patch
> makes sure that even the dummy REG or MEM is valid, rather than force
> the gen_* code to handle garbage values.
>
>
> gcc/
> * caller-save.c (ini
On Tue, 19 May 2015, Prathamesh Kulkarni wrote:
> Hi,
> genmatch segfaults on:
> (define_operator_list op (plus))
>
> The above syntax is invalid, and it segfaults on:
> fatal_error (token, "operator list is empty");
> because token is NULL.
>
> The patch puts a check for CPP_CLOSE_PAREN after p
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 generates incorrect code for following (artificial) patter
I forgot to roll back SLP child state when ending up building vectors
from scalars.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-05-19 Richard Biener
PR tree-optimization/66185
* tree-vect-slp.c (vect_build_slp_tree): Properly roll back
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-05-19 Richard Biener
PR tree-optimization/66165
* tree-vect-slp.c (vect_supported_load_permutation_p): Add guard
for no load permutation.
* gcc.dg/torture/pr66165.c: New testcase.
In
On Tue, May 19, 2015 at 12:04 AM, Aditya K wrote:
>
>
>
>> Date: Mon, 18 May 2015 12:08:58 +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 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.
>
> Multi versioning at module granularity is done by compiling a subse
Ping
2015-05-05 11:05 GMT+03:00 Ilya Enkovich :
> Ping
>
> 2015-04-14 17:35 GMT+03:00 Ilya Enkovich :
>> On 10 Apr 03:27, Jan Hubicka wrote:
>>> >
>>> > + /* We might propagate instrumented function pointer into
>>> > + not instrumented function and vice versa. In such a
>>> > + case we
Ping
2015-05-05 11:06 GMT+03:00 Ilya Enkovich :
> Ping
>
> 2015-04-14 12:14 GMT+03:00 Ilya Enkovich :
>> On 10 Apr 03:15, Jan Hubicka wrote:
>>> >
>>> > References are not streamed out for nodes which are referenced in a
>>> > partition but don't belong to it ('continue' condition in output_refs
>
On Tue, May 19, 2015 at 10:40 AM, Andreas Krebbel
wrote:
> On 05/18/2015 04:19 PM, Richard Biener wrote:
>> On Mon, May 18, 2015 at 3:41 PM, Andreas Krebbel
>> wrote:
>>> The new version also changes the type for the alternative_mask to unsigned
>>> HOST_WIDE_INT.
>>>
>>> Bootstrapped without re
Hi all,
This patch adds a mention of the new native cpu detection feature in aarch64
GNU/Linux.
Gerald, this is a patch against htdocs/gcc-6/changes.html and I thought I had
seen the 'changes' link
in gcc.gnu.org earlier but I don't see it now (there's only a release criteria
link).
Is this a
Hi,
r223113 made it possible for invariant to actually be moved rather than
moving the source to a new pseudoregister. However, when doing so
the inv->reg is not set up properly: in case of a subreg destination it
holds the inner register rather than the subreg expression.
This patch fixes that.
Hi all,
update based on latest 65548 (v5) patch and current trunk. Description and
issue addressed unchanged (see cite below).
Bootstrapped and regtested on x86_64-linux-gnu/f21.
Any volunteers to review? The initial version dates back to March 30. 2015. Not
a single comment so far!
- Andre
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,
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
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
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
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 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
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 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.
>
>
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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 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_
> 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 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
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 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
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, 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
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
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
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
> 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
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 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
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
>>
>
> 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
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
> 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:
>>
>>
>>
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
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
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
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 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 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
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 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
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
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 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
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
> 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
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
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 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
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
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
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
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 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
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 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 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 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 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.
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 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
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 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 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 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:
>> >>>
1 - 100 of 125 matches
Mail list logo
