On Thu, Apr 23, 2015 at 04:27:59AM +0100, James Greenhalgh wrote:
> On Tue, Apr 21, 2015 at 04:24:44PM +0100, Trevor Saunders wrote:
> > On Tue, Apr 21, 2015 at 04:14:01PM +0200, Richard Biener wrote:
> > > On Tue, Apr 21, 2015 at 3:24 PM, wrote:
> > > > From: Trevor Saunders
> > > >
> > > > gcc
On Tue, Apr 21, 2015 at 04:24:44PM +0100, Trevor Saunders wrote:
> On Tue, Apr 21, 2015 at 04:14:01PM +0200, Richard Biener wrote:
> > On Tue, Apr 21, 2015 at 3:24 PM, wrote:
> > > From: Trevor Saunders
> > >
> > > gcc/ChangeLog:
> > >
> > > 2015-04-21 Trevor Saunders
> > >
> > > * co
On Wed, 2015-04-22 at 20:55 -0500, Segher Boessenkool wrote:
> Using a hard reg in the RTL like this has a few problems:
> a) It might hinder register allocation. Maybe it doesn't, not sure;
> b) It does hinder scheduling;
> c) It can make things ICE, maybe with register asm.
Ahh, I see what you
Hi there,
This patch is to correct options in arm test case pr65710.c. I reused
some existing test case as template to produce this case, but forgot
to update the options. Is it OK to trunk?
BR,
Terry
2015-04-23 Terry Guo
* gcc.target/arm/pr65710.c: Update the options.
diff --git a/gcc/te
On Wed, Apr 22, 2015 at 06:08:26PM -0500, Peter Bergner wrote:
> > > > > + case HTM_BUILTIN_TTEST: /* Alias for: tabortwci. 0,r0,0 */
> > > > > + op[nopnds++] = GEN_INT (0);
> > > > > + op[nopnds++] = gen_rtx_REG (SImode, 0);
> > > > > + op[nopnds++] = GEN_INT (0);
>
Hi,
this patch strenghtens ipa-icf to allow merging non-inline function to
inline function. This is safe because inline flag does not affect function
itself. It only affects way the function is used, so we need to compare the
flag only when comparing references. (inline flag mismatch is one of com
On 23/04/15 09:48, H.J. Lu wrote:
> On Wed, Apr 22, 2015 at 3:15 PM, Kugan
> wrote:
>> On 17/01/15 13:11, Kugan wrote:
>>>
>>> Re-enable zero/sign extension elimination using value range that
>>> includes wrapped attribute.
>>>
>>
>> Now that stage-1 is open, rebased it and regression tested on
The attached patch fixes
gcc/testsuite/g++.dg/debug/dwarf2/template-func-params-7.C.
The problem is that DW_TAG_GNU_formal_parameter_pack DIEs are generated
multiple times (once for early dwarf and once for late dwarf). Fixed by
only outputting in early dwarf.
Tested with GCC and GDB testsu
On Wed, Apr 22, 2015 at 3:15 PM, Kugan
wrote:
> On 17/01/15 13:11, Kugan wrote:
>>
>> Re-enable zero/sign extension elimination using value range that
>> includes wrapped attribute.
>>
>
> Now that stage-1 is open, rebased it and regression tested on
> x86-64-none-linux-gnu with no new regressions
On Tue, Apr 07, 2015 at 12:59:20PM -0700, Steve Kargl wrote:
> On Tue, Mar 31, 2015 at 10:17:14AM -0700, Jerry DeLisle wrote:
> > On 03/29/2015 09:25 AM, Steve Kargl wrote:
> > > On Sat, Mar 28, 2015 at 01:01:57AM +0100, Dominique Dhumieres wrote:
> > >>
> > >> AFAICT your test succeeds without you
On Wed, 2015-04-22 at 17:16 -0500, Segher Boessenkool wrote:
> On Wed, Apr 22, 2015 at 08:43:10AM -0500, Peter Bergner wrote:
> > > Maybe you can fold tabortdc with tabortwc now? Use one UNSPEC name
> > > for both, :GPR and ?
> >
> > Wouldn't that change the tabortwc pattern to use DImode rather
On Wed, Apr 22, 2015 at 3:15 PM, Ramana Radhakrishnan
wrote:
> On Wed, Apr 22, 2015 at 5:34 PM, H.J. Lu wrote:
>> Normally, with PIE, GCC accesses globals that are extern to the module
>> using GOT. This is two instructions, one to get the address of the global
>> from GOT and the other to get t
On Wed, Apr 22, 2015 at 08:43:10AM -0500, Peter Bergner wrote:
> > Maybe you can fold tabortdc with tabortwc now? Use one UNSPEC name
> > for both, :GPR and ?
>
> Wouldn't that change the tabortwc pattern to use DImode rather
> than SImode when compiled with -m64 or -m32 -mpowerpc64?
> I'm not su
On Wed, Apr 22, 2015 at 5:34 PM, H.J. Lu wrote:
> Normally, with PIE, GCC accesses globals that are extern to the module
> using GOT. This is two instructions, one to get the address of the global
> from GOT and the other to get the value. Examples:
>
> ---
> extern int a_glob;
> int
> main ()
>
On 17/01/15 13:11, Kugan wrote:
>
> Re-enable zero/sign extension elimination using value range that
> includes wrapped attribute.
>
Now that stage-1 is open, rebased it and regression tested on
x86-64-none-linux-gnu with no new regressions.
Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
On 17/01/15 13:06, Kugan wrote:
> Freeing a spare-bit to store wrapped attribute by going back to
> representing VR_ANTI_RANGE as [max + 1, min - 1] in SSA_NAME.
>
Now that stage-1 is open, rebased it and regression tested on
x86-64-none-linux-gnu with no new regressions.
Is this OK for trunk?
On 19/01/15 22:28, Richard Biener wrote:
> On Sat, 17 Jan 2015, Kugan wrote:
>
>>
>> This patch propagate value range wrapps attribute and save this to
>> SSA_NAME.
>
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index 9b7695d..832c35d 100644
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@
Hi Kirill,
On 21.04.15 10:28, Kirill Yukhin wrote:
On 19 Apr 21:56, Andreas Tobler wrote:
Done so and tested on FreeBSD amd64-unknown-freebsd11.0 and CentOS7.1.
Ok for trunk?
The patch is OK for trunk and for gcc-5 branch (when it is open).
Thanks for fixing this!
Done on trunk and gcc-5.
On 04/22/2015 02:46 PM, Trevor Saunders wrote:
yeah, its irritated me on a number of occasions too. I'd really like it
if building config-list.mk could be faster, but that's a much bigger
project, but at least if everything is target hooks maybe ccache can
kick in some.
I don't see ccache kickin
On Wed, Apr 22, 2015 at 12:36:58PM -0600, Jeff Law wrote:
> On 04/22/2015 12:13 PM, David Malcolm wrote:
>
> >
> >Conditional compilation was a major PITA when doing the rtx->rtx_insn *
> >work last year, so I'm very pleased to see these cleanups go in.
> Yup. It also got in Andrew's way last yea
On Wed, Apr 22, 2015 at 09:39:48PM +0200, François Dumont wrote:
> Hello
>
> Here is a rather trivial patch, just code cleanup. Since we export
> _Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
>
> * include/bits/hashtable_policy.h (_Prime_rehash_policy::_S_n_primes
With the patch this time.
On 22/04/2015 21:39, François Dumont wrote:
Hello
Here is a rather trivial patch, just code cleanup. Since we export
_Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
* include/bits/hashtable_policy.h
(_Prime_rehash_policy::_S_n_primes
Hello
I don't know if I am missing something but I think __niter_base
could be simplified to remove usage of _Iter_base. Additionally I
overload it to also remove __normal_iterator layer even if behind a
reverse_iterator or move_iterator, might help compiler to optimize code,
no ? If not,
On April 13, 2015 3:12:48 PM GMT+02:00, Jeff Law wrote:
>On 04/11/2015 04:27 PM, Bernhard Reutner-Fischer wrote:
>> Hi,
>>
>> I'd like to ask an RM or global reviewer to kindly consider the
>> following patches preventing one or the other target in
>config-list.mk
>> to build:
>>
>> [PATCH, bfin]
Hello
Here is a rather trivial patch, just code cleanup. Since we export
_Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
* include/bits/hashtable_policy.h (_Prime_rehash_policy::_S_n_primes):
Delete.
* src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy::_
This patch adjusts the testcase to work with the now slightly different
ordering of DIEs in the branch.
Brought to you by the letter "N" for "nightmare".
Committed to branch.
Aldy
commit 7996af2f984f42a9694c466ee05d5067696503cc
Author: Aldy Hernandez
Date: Wed Apr 22 12:20:10 2015 -0700
Hi,
This patch is an attempt to fix some potential race conditions with
accesses to shared data structures from multiple concurrent threads in
libgomp's OpenACC entry points. The main change is to move locking out
of lookup_host and lookup_dev in oacc-mem.c and into their callers
(which can then h
On 04/22/2015 12:13 PM, David Malcolm wrote:
Conditional compilation was a major PITA when doing the rtx->rtx_insn *
work last year, so I'm very pleased to see these cleanups go in.
Yup. It also got in Andrew's way last year and we regularly see cases
where small patches which work fine on th
Currently, we warn if the right operand of a shift expression is negative,
or greater than or equal to the length in bits of the promoted left operand.
But we don't warn when we see a left shift of a negative value. That is
undefined behavior since C99 and I believe C++11, so this patch implement
On 9 April 2015 at 13:20, Bernhard Reutner-Fischer
wrote:
> essentially s/[[:space:]]*[[:space:]];/;/g
>
> ChangeLog (attn: to src, IIRC no write-access, ask someone to commit)
>
> Ok for trunk now?
Jeff OKed this, applied as r222334.
Please holler if i broke something..
thanks,
>
> 2015-04-01
On Tue, 2015-04-21 at 11:29 -0400, Trevor Saunders wrote:
> On Tue, Apr 21, 2015 at 07:57:19AM -0600, Jeff Law wrote:
> > On 04/21/2015 07:24 AM, tbsaunde+...@tbsaunde.org wrote:
> > >From: Trevor Saunders
> > >
> > >Hi,
> > >
> > >This is a first round of patches to reduce the amount of code with
Alan Lawrence wrote:
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_split_simd_combine): Add V4HFmode.
* config/aarch64/aarch64-builtins.c (VAR13, VAR14): New.
(aarch64_scalar_builtin_types, aarch64_init_simd_builtin_scalar_types):
Add __builtin_aarch64_simd_h
This adds a test of vcvt_f32_f16 and vcvt_f16_f32, also vcvt_high_f32_f16 and
vcvt_high_f16_f32.
On ARM, we pass additional option -mfpu=neon-fp16 to the compiler (possible
following patch 2/3). The compiler is already receiving an option such as
-mfpu=neon or -mfpu=crypto-neon-fp-armv8, but p
In the first revision of Christophe Lyon's advsimd-intrinsics tests,
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00532.html , both gcc-dg-runtest
(to assemble only) and c-torture-execute were used. In review the gcc-dg-runtest
part was then dropped, and execution tests continued using c-tortur
This is a fairly straightforward addition of a new type: I've added it in on
equal status to the other types, because the various
vector-load/store/element-manipulating intrinsics, are *not* conditional on HW
support. (They just involve moving 16-bit chunks around, just like s16/u16/p16).
Thus
native_interpret_real in fold_const.c has an assumption that floats are at least
32-bits (on bigendian targets with UNITS_PER_WORD >= 4). This patch relaxes that
assumption (allowing e.g. 16-bit HFmode values).
On aarch64_be-none-elf, this fixes the float16x4_t variant of
gcc.target/aarch64/ad
This adds the two remaining widening intrinsics, first adding patterns in
aarch64-simd.md, then entries in aarch64-simd-builtins.def, and finally
intrinsics in arm_neon.h .
Note this changes the vector indices present in the RTL on bigendian for float
vec_unpacks, to be the same as for integer
gcc/ChangeLog:
* config/aarch64/arm_neon.h (vreinterpretq_p8_f16,
vreinterpretq_p16_f16, vreinterpretq_f32_f16, vreinterpretq_f64_f16,
vreinterpretq_s64_f16, vreinterpretq_s8_f16, vreinterpretq_s16_f16,
vreinterpretq_s32_f16, vreinterpretq_u8_f16, vreinterpretq_u16
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (aarch64_float_truncate_lo_v2sf):
Reparameterize to...
(aarch64_float_truncate_lo_): ...this, for both V2SF and V4HF.
(aarch64_float_truncate_hi_v4sf): Reparameterize to...
(aarch64_float_truncate_hi_): ...thi
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_split_simd_combine): Add V4HFmode.
* config/aarch64/aarch64-builtins.c (VAR13, VAR14): New.
(aarch64_scalar_builtin_types, aarch64_init_simd_builtin_scalar_types):
Add __builtin_aarch64_simd_hf.
* config/aa
This adds some basic intrinsics - vget_lane, vset_lane, vld1_lane, vld1, vst1 -
for float16 types, and the necessary support in the builtin generator, basic
patterns for moving values around, etc. Other intrinsics will follow in later
patches.
I've extended the existing testcases in aarch64/,
[Resending with correct in-reply-to header]
This adds basic support for moving __fp16 values around, passing and returning,
and operating on them by promoting to 32-bit floats. Also a few scalar testcases.
Note I've not got an fmov (immediate) variant, because there is no 'fmov h,
...' - the
This adds basic support for moving __fp16 values around, passing and returning,
and operating on them by promoting to 32-bit floats. Also a few scalar testcases.
Note I've not got an fmov (immediate) variant, because there is no 'fmov h,
...' - the only way to load a 16-bit immediate is to rein
This is a respin of https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01440.html ;
changes are to add in several missing vst... intrinsics, and fix a missing
iterator V_uf_sclr used in vec_extract.
These intrinsics are all made from patterns in neon.md, and are all tied
together by iterators - I'v
This is a respin of https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01439.html ,
again fixing a wrong 'lane index out of bounds' error for vgetq_lane_f16 and
vsetq_lane-f16 at -O0, and dropping vdupq_n_f16 and vdupq_lane_f16 as these are
not in the ACLE spec.
The vld1, vldN, vldN_lane and corres
This is a respin of https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01437.html ,
but fixes a wrong 'lane index out of bounds' error on vget_lane_f16 and
vset_lane_f16, and drops vdup_n_f16 and vdup_lane_f16, as these are not in the
ACLE spec. As previously, these use GCC vector extensions to maxim
Identical to https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01438.html .
Bootstrapped on arm-none-linux-gnueabihf.
commit bc582bd6a0ed7c7c91fc834603fc573ed745b1a7
Author: Alan Lawrence
Date: Mon Dec 8 18:40:24 2014 +
Add float16x8_t + V8HFmode support (regardless of -mfp16-format)
dif
Ping (https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01436.html).
These are required for float16 patches posted at
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01332.html
Bootstrapped + check-gcc on arm-none-linux-gnueabihf.
Alan Lawrence wrote:
This parallels the present form of __builtin_aa
Ping (https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01422.html).
These are required for float16 patches posted at
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01332.html .
Bootstrapped + check-gcc on arm-none-linux-gnueabihf.
Alan Lawrence wrote:
This is based loosely upon svn r217440, "[AAr
This patch series adds support for ARM Neon float16x4_t and float16x8_t vector
types and intrinsics, and the __fp16 type, on both ARM and AArch64, and extends
the tests in Christophe Lyon's advsimd-intrinsics testsuite to cover these. (I
chose to extend the existing tests rather than add new one
Normally, with PIE, GCC accesses globals that are extern to the module
using GOT. This is two instructions, one to get the address of the global
from GOT and the other to get the value. Examples:
---
extern int a_glob;
int
main ()
{
return a_glob;
}
---
With PIE, the generated code accesses g
Hi all,
This hunk that slightly reduces the cost of immediate moves doesn't actually
have any effect.
In the whole of SPEC2006 it didn't make a difference. In any case, I'd like to
move to a point
where we use COSTS_N_INSNS units for our costs and not increment decrement them
by one.
This pat
Hi all,
In rtx costs we do not handle the FP abs (minus (a b)) case which maps down
to a FABD instruction.
This patch fixes that. FABD behaves similarly to the FADD class of
instructions unlike simple FABS
which is closer to FNEG.
Tested aarch64-none-elf.
Ok for trunk?
Thanks,
Kyrill
2015-04-22
-Original Message-
From: Maciej W. Rozycki [mailto:ma...@linux-mips.org]
Sent: Tuesday, April 21, 2015 8:52 PM
To: Petar Jovanovic
Cc: gcc-patches@gcc.gnu.org; catherine_mo...@mentor.com;
matthew.fort...@imgtec.com
Subject: Re: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
> I think
On 22/04/15 16:36, Kyrylo Tkachov wrote:
> On 22/04/15 16:26, Ilya Verbin wrote:
>> On Wed, Apr 22, 2015 at 15:34:51 +0100, Kyrill Tkachov wrote:
>>> On 22/04/15 14:16, Jeff Law wrote:
On 04/20/2015 12:52 PM, Szabolcs Nagy wrote:
> Add musl libc support to gcc and the command line option
On 22/04/15 16:26, Ilya Verbin wrote:
> On Wed, Apr 22, 2015 at 15:34:51 +0100, Kyrill Tkachov wrote:
>> On 22/04/15 14:16, Jeff Law wrote:
>>> On 04/20/2015 12:52 PM, Szabolcs Nagy wrote:
Add musl libc support to gcc and the command line option -mmusl
following other
libc support code.
On Wed, Apr 22, 2015 at 15:34:51 +0100, Kyrill Tkachov wrote:
>
> On 22/04/15 14:16, Jeff Law wrote:
> >On 04/20/2015 12:52 PM, Szabolcs Nagy wrote:
> >>Add musl libc support to gcc and the command line option -mmusl following
> >>other
> >>libc support code.
> >>
> >>Note that -m cannot be entir
handle_cache_entry in tm_clone_hasher looks wrong: the condition
if (e != HTAB_EMPTY_ENTRY || e != HTAB_DELETED_ENTRY) is always true. While
it could be fixed by just changing || into &&, I decided to follow suit and
do what we do in handle_cache_entry's elsewhere in the codebase. I've fixed
a fo
On 04/21/2015 05:58 PM, Jakub Jelinek wrote:
suggests that while it is nice that when building nvptx accel compiler
we build libgcc.a, libc.a, libm.a, libgfortran.a (and in the future hopefully
libgomp.a),
nothing attempts to link those in :(.
I have that fixed; I expect I'll get around to po
On 22/04/15 12:46, Kyrill Tkachov wrote:
[Sorry for resending twice. My mail client glitched]
On 20/04/15 16:47, Kyrill Tkachov wrote:
Hi all,
This is an attempt to add native CPU detection to AArch64 GNU/Linux targets.
Similar to other ports we use SPEC rewriting to rewrite -m{cpu,tune,arch}
On 20/04/15 21:38, Jeff Law wrote:
On 04/20/2015 12:58 PM, Szabolcs Nagy wrote:
No fixincludes are needed for musl.
fixincludes/Changelog:
2015-04-16 Gregor Richards
* mkfixinc.sh: Add *-musl* with no fixes.
OK.
jeff
I've committed this on Szabolcs' behalf with r222327.
Kyril
On 22/04/15 14:17, Jeff Law wrote:
On 04/20/2015 12:59 PM, Szabolcs Nagy wrote:
libgcc/gthr-posix.h uses weak reference logic to determine if libpthread
is linked into the application or not. This is broken unless there is
special workaround with libc internal knowledge and even then static
li
On 22/04/15 14:20, Jeff Law wrote:
On 04/20/2015 12:58 PM, Szabolcs Nagy wrote:
dl_iterate_phdr depends on USE_PT_GNU_EH_FRAME.
I think USE_PT_GNU_EH_FRAME could be enabled more generally (whenever
libc provides dl_iterate_phdr), but I only made a conservative change.
libgcc/Changelog:
2015
On 22/04/15 14:16, Jeff Law wrote:
On 04/20/2015 12:52 PM, Szabolcs Nagy wrote:
Add musl libc support to gcc and the command line option -mmusl following other
libc support code.
Note that -m cannot be entirely correct: there are build time decisions
based on the default libc.
gcc/Changelog:
On 20/04/15 21:41, Jeff Law wrote:
On 04/20/2015 12:51 PM, Szabolcs Nagy wrote:
This are minor correctness fixes required for musl.
(fcntl.h is the standard header and always available on Linux,
sys/fcntl.h is just a legacy alias, so use the standard one.)
libitm/Changelog:
2015-04-16 Grego
This pushes a bunch of changes from my dev tree to trunk.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2015-04-22 Richard Biener
* cfgexpand.c (expand_gimple_stmt_1): Use ops.code.
* cfgloop.c (verify_loop_structure): Verify the root loop node.
This patch stifles -Wlogical-op a bit: don't warn if either operand comes from
a macro expansion. As the comment says, it doesn't fix the bug completely, but
it's a simple improvement. I did this by introducing a new macro.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
(Bootstrap with -W
On Wed, Apr 22, 2015 at 3:38 PM, Tom de Vries wrote:
> On 22-04-15 10:06, Richard Biener wrote:
>>
>> On Wed, Apr 22, 2015 at 9:41 AM, Tom de Vries
>> wrote:
>>>
>>> Hi,
>>>
>>> this patch fixes PR65823.
>>>
>
>
>
>>>
>>> The patches fixes the problem by using operand_equal_p to do the equality
On 04/22/2015 08:33 AM, Jeff Law wrote:
On 04/22/2015 06:28 AM, Andrew MacLeod wrote:
On 04/22/2015 08:19 AM, Jakub Jelinek wrote:
On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
Is anyone else seeing comparison problems on trunk?
I was having problems testing a patch on a 4/1
On Tue, 2015-04-21 at 21:17 -0500, Segher Boessenkool wrote:
> On Tue, Apr 21, 2015 at 03:56:18PM -0500, Peter Bergner wrote:
> > This patch also fixes some issues I hit with the tabortdc[i] and
> > htm_m[ft]spr_ patterns when used with -m32 -mpowerpc64.
>
> Running the testsuite, or did you actua
On 22-04-15 10:06, Richard Biener wrote:
On Wed, Apr 22, 2015 at 9:41 AM, Tom de Vries wrote:
Hi,
this patch fixes PR65823.
The patches fixes the problem by using operand_equal_p to do the equality
test.
Bootstrapped and reg-tested on x86_64.
Did minimal non-bootstrap build on arm an
On Wed, Apr 22, 2015 at 06:16:24AM -0700, H.J. Lu wrote:
> > I admit I have not tried, but am certainly not seeing Peter's fix
> > in https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.19.5
> > has it been fixed differently? Not seeing anything in the Fedora kernel
> > package %changelog eit
Hi Alex,
On 22/04/15 14:12, Alex Velenko wrote:
> Hi,
>
> This patch adds arm rtl patterns to generate bics instructions with shift.
>
> Done full regression run on arm-none-eabi.
A bootstrap on arm-none-linux-gnueabihf would be nice too.
>
>
> Is patch ok?
>
> gcc/config
>
> 2015-04-22 Alex Ve
On 04/20/2015 12:58 PM, Szabolcs Nagy wrote:
dl_iterate_phdr depends on USE_PT_GNU_EH_FRAME.
I think USE_PT_GNU_EH_FRAME could be enabled more generally (whenever
libc provides dl_iterate_phdr), but I only made a conservative change.
libgcc/Changelog:
2015-04-16 Gregor Richards
On 04/20/2015 12:59 PM, Szabolcs Nagy wrote:
libgcc/gthr-posix.h uses weak reference logic to determine if libpthread
is linked into the application or not. This is broken unless there is
special workaround with libc internal knowledge and even then static
linking needs further manual link time
On Wed, Apr 22, 2015 at 6:10 AM, Jakub Jelinek wrote:
> On Wed, Apr 22, 2015 at 05:40:07AM -0700, H.J. Lu wrote:
>> On Wed, Apr 22, 2015 at 5:19 AM, Jakub Jelinek wrote:
>> > On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
>> >> Is anyone else seeing comparison problems on trunk?
On 04/20/2015 12:52 PM, Szabolcs Nagy wrote:
Add musl libc support to gcc and the command line option -mmusl following other
libc support code.
Note that -m cannot be entirely correct: there are build time decisions
based on the default libc.
gcc/Changelog:
2015-04-16 Gregor Richards
On 04/21/2015 03:41 PM, Jan Kratochvil wrote:
Hi,
the next [patch 3/5] will change the libcc1.so API. I am not sure if the API
change gets approved that way but for such case:
(1) We really need to change GCC_FE_VERSION_0 -> GCC_FE_VERSION_1, this
feature is there for this purpose. That i
On 04/21/2015 03:41 PM, Jan Kratochvil wrote:
Hi,
see [patch 1/5], particularly:
(3) Currently there is no backward or forward compatibility although there
could be one implemented. Personally I think the 'compile' feature is
still in experimental stage so that it is OK to require las
Hi,
This patch adds arm rtl patterns to generate bics instructions with shift.
Done full regression run on arm-none-eabi.
Is patch ok?
gcc/config
2015-04-22 Alex Velenko
* arm/arm.md (andsi_not_shiftsi_si_scc): New pattern.
* (andsi_not_shiftsi_si_scc_no_reuse): New pattern.
gcc/tests
On 04/21/2015 03:41 PM, Jan Kratochvil wrote:
Hi,
as discussed in
How to use compile & execute function in GDB
https://sourceware.org/ml/gdb/2015-04/msg00026.html
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but it does not
display which one. It cannot, GCC m
On Wed, Apr 22, 2015 at 05:40:07AM -0700, H.J. Lu wrote:
> On Wed, Apr 22, 2015 at 5:19 AM, Jakub Jelinek wrote:
> > On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
> >> Is anyone else seeing comparison problems on trunk?
> >>
> >> I was having problems testing a patch on a 4/16 ex
On 04/21/2015 03:41 PM, Jan Kratochvil wrote:
as discussed in
How to use compile & execute function in GDB
https://sourceware.org/ml/gdb/2015-04/msg00026.html
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but one cannot
override which one. GDB would provide new
On 04/21/2015 03:41 PM, Jan Kratochvil wrote:
Hi,
with the patches so far after
(gdb) set debug compile 1
one would get:
searching for compiler matching regex
^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-gcc$
found compiler x86_64-unknown-linux-gnu-gcc
But I believe it is more r
On 22 April 2015 at 12:25, Renlin Li wrote:
> Hi Jonathan,
>
> Thank you for the suggestion. I have just attached the updated the patch. It
> works as before.
> Is this Okay to commit?
OK, thanks.
On Wed, Apr 22, 2015 at 5:19 AM, Jakub Jelinek wrote:
> On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
>> Is anyone else seeing comparison problems on trunk?
>>
>> I was having problems testing a patch on a 4/16 extraction, so last night I
>> checked out a fresh trunk, built it, r
On 04/22/2015 06:28 AM, Andrew MacLeod wrote:
On 04/22/2015 08:19 AM, Jakub Jelinek wrote:
On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
Is anyone else seeing comparison problems on trunk?
I was having problems testing a patch on a 4/16 extraction, so last
night I
checked out
On 04/22/2015 08:19 AM, Jakub Jelinek wrote:
On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
Is anyone else seeing comparison problems on trunk?
I was having problems testing a patch on a 4/16 extraction, so last night I
checked out a fresh trunk, built it, ran make check... the
On Wed, 22 Apr 2015, Jan Hubicka wrote:
> > > @@ -42,6 +42,6 @@ bool f(I a, I b, I c, I d) {
> > > // This works only if everything is inlined into 'f'.
> > >
> > > // { dg-final { scan-tree-dump-times ";; Function" 1 "fre2" } }
> > > -// { dg-final { scan-tree-dump-times "free" 19 "fre2" } }
>
On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
> Is anyone else seeing comparison problems on trunk?
>
> I was having problems testing a patch on a 4/16 extraction, so last night I
> checked out a fresh trunk, built it, ran make check... then removed the
> build directory, re-buil
> > @@ -42,6 +42,6 @@ bool f(I a, I b, I c, I d) {
> > // This works only if everything is inlined into 'f'.
> >
> > // { dg-final { scan-tree-dump-times ";; Function" 1 "fre2" } }
> > -// { dg-final { scan-tree-dump-times "free" 19 "fre2" } }
> > +// { dg-final { scan-tree-dump-times "free" 18 "
On Mon, Apr 13, 2015 at 3:01 AM, Jan Hubicka wrote:
> Hi,
> this patch adds DSE to early optimizations and handles testuiste fallout.
> As discussed in PR 65076 this reduces number of CLOBBER statements in tramp3d
> to 50% (and those accounts 29% of all code previously). The pass also quite
> ofte
Is anyone else seeing comparison problems on trunk?
I was having problems testing a patch on a 4/16 extraction, so last
night I checked out a fresh trunk, built it, ran make check... then
removed the build directory, re-built it from scratch again. make
check.. and get a bunch of different re
On 21/04/15 18:33, Kyrill Tkachov wrote:
On 21/04/15 15:09, Jeff Law wrote:
On 04/21/2015 02:30 AM, Kyrill Tkachov wrote:
From reading config/stormy16/stormy-abi it seems to me that we don't
pass arguments partially in stormy16, so this code would never be called
there. That leaves pa as th
[Sorry for resending twice. My mail client glitched]
On 20/04/15 16:47, Kyrill Tkachov wrote:
Hi all,
This is an attempt to add native CPU detection to AArch64 GNU/Linux targets.
Similar to other ports we use SPEC rewriting to rewrite -m{cpu,tune,arch}=native
options into the appropriate CPU/ar
Hi Jonathan,
Thank you for the suggestion. I have just attached the updated the
patch. It works as before.
Is this Okay to commit?
Regards,
Renlin Li
On 22/04/15 11:19, Jonathan Wakely wrote:
On 21/04/15 15:29 +0100, Renlin Li wrote:
Hi all,
This patch defines a new dg-require-thread-fence
On Wed, Apr 22, 2015 at 11:50:17AM +0200, Manuel López-Ibáñez wrote:
> So, I think your proposal is an improvement, however, it does not
> fully fix the problem. For that, we need to have locations for the
> operands of expressions (PR43486), so we can check if they are also
> come from macro expan
Hello!
Attached patch moves CRT_GET_RFIB_DATA from gcc to libgcc in the same
way as was recently done for x86 targets [1].
The second patch is needed to successfully compile frv-elf libgcc,
otherwise libgcc build fails in defaults.h, line 499 with "Unknown
BITS_PER_UNIT" error.
libgcc/ChangeLog:
On 21/04/15 15:29 +0100, Renlin Li wrote:
Hi all,
This patch defines a new dg-require-thread-fence directive. And three
test cases are updated to use it.
The new directive are used to check whether the target support thread
fence either by the target back-end or external library function cal
Hi!
Committed to gomp-4_0-branch in r222320:
commit d9af23c3cb81d769ce6ca32c26b147ebafe9628c
Merge: 7109b39 5622376
Author: tschwinge
Date: Wed Apr 22 10:07:47 2015 +
svn merge -r 221363:221638 svn+ssh://gcc.gnu.org/svn/gcc/trunk
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc
1 - 100 of 128 matches
Mail list logo
