In addition to a PR this is 1/2 of a C=+17 feature. (The other half -
really a separate thing - is attributes on namespaces).
I wonder if we should pedwarn for < C++17?
Or it could be just an extension for < C++17 - I guess that would match
with clang.
if (SCOPED_ENUM_P (newtag))
diff --g
This is a problem I found while bootstrapping on ppc64-linux, but is a
problem we will run into sooner or later.
As I've mentioned before, the fact that we call
debug_hooks->late_global_decl() on symbols from the symbol table means
that we miss out on symbols that were removed from the symbol
ge.
https://people.freebsd.org/~adrian/gcc/20150506-gcc-trunk-libgomp-1.diff
I'd appreciate feedback/review.
Thanks!
-adrian
On 05/06/2015 08:24 AM, Christian Bruel wrote:
diff '--exclude=.svn' -ruN gnu_trunk.p3/gcc/gcc/doc/extend.texi
gnu_trunk.p4/gcc/gcc/doc/extend.texi
--- gnu_trunk.p3/gcc/gcc/doc/extend.texi2015-05-06 09:00:31.232943164
+0200
+++ gnu_trunk.p4/gcc/gcc/doc/extend.texi2015-05-06 14:5
Currently GCC does not put mergeable read-only data in a per-function
section, so the -gc-sections linker option does not do much for such
data. Fix that.
Bootstrapped and tested on powerpc64-linux; no regressions.
Is this okay for trunk?
Segher
2015-05-06 Segher Boessenkool
PR m
This patch from Chris Manghane improves escape analysis for interface
parameters. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r aaa6df965e1f go/escape.cc
--- a/go/escape.cc Tue May 05 13:56:24 2015 -0700
+++ b/go/escape.cc Wed May 06
On 05/06/2015 06:41 PM, Sandra Loosemore wrote:
On 05/06/2015 03:22 PM, Andrew MacLeod wrote:
gcc
* c-family/c-common.c (const struct attribute_spec c_common_att):
Add "atomic" attribute.
(handle_atomic_attribute): New. Deal with __attribute__((atomic)).
(resolve_overloaded
On 05/06/2015 03:22 PM, Andrew MacLeod wrote:
gcc
* c-family/c-common.c (const struct attribute_spec c_common_att):
Add "atomic" attribute.
(handle_atomic_attribute): New. Deal with __attribute__((atomic)).
(resolve_overloaded_builtin): If an atomic objec
On Wed, May 06, 2015 at 11:14:08PM +0200, Marek Polacek wrote:
> On Wed, Apr 29, 2015 at 05:13:11PM +0200, Marek Polacek wrote:
> > This patch adds the -fsanitize=bounds-strict option Martin U. wanted; it is
> > actually based on his earlier patch, I did only some small adjustments.
> >
> > Bootst
This patch resurrects the __attribute__((atomic)) bits from the old C11
atomic branch that were never included in trunk.
Motivation was for C++ to be able to use the attribute in the atomic
templates giving c++ exact compatibility with C11 _Atomic. Alignment has
been an issue, and jwakley had
Ping.
On Wed, Apr 29, 2015 at 05:13:11PM +0200, Marek Polacek wrote:
> This patch adds the -fsanitize=bounds-strict option Martin U. wanted; it is
> actually based on his earlier patch, I did only some small adjustments.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2015-04-29 M
On Wed, May 06, 2015 at 03:27:48PM +, Joseph Myers wrote:
> On Tue, 5 May 2015, Michael Meissner wrote:
>
> > The problem is the PowerPC will have 2 128-bit floating point types, one
> > using
> > the IBM double-double format (a pair of doubles to give the user more
> > mantissa
> > bits, bu
Hi Mikael,
thanks for the review. I have committed the following, which took
your remarks into account (plus an additional test case, as obvious).
Regards
Thomas
2015-05-06 Thomas Koenig
PR fortran/37131
* gfortran.h (gfc_isym_id): Add GFC_ISYM_FE_RUNTIME_ERROR.
Add a simple benchmark to the jit testsuite: measuring the wallclock
time of:
* building a simple function (sum of squares from 0..n-1)
* compiling it in-memory
* running it (with n=100)
doing this combined test 100 times, at each optimization level.
On this machine I get this output:
PASSED
Hi
Following Marc Glisse comment #4
on:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65641 I would like to
propose this enhancement to the hash functor for pointers. It simply
gets rid of the irrelevant bits on pointers hash code based on memory
alignment of the pointed type. The only draw
On Wed, May 6, 2015 at 12:17 PM, Rich Felker wrote:
> On Wed, May 06, 2015 at 12:05:20PM -0700, H.J. Lu wrote:
>> >> -Bsymbolic will bind all references to local definitions in shared
>> >> libraries,
>> >> with and without visibility, weak or non-weak. Compiler can use it
>> >> in binds_tls_loc
On Wed, May 06, 2015 at 12:05:20PM -0700, H.J. Lu wrote:
> >> -Bsymbolic will bind all references to local definitions in shared
> >> libraries,
> >> with and without visibility, weak or non-weak. Compiler can use it
> >> in binds_tls_local_p and we can generate much better codes in shared
> >> l
On Wed, May 6, 2015 at 12:01 PM, Rich Felker wrote:
> On Wed, May 06, 2015 at 11:44:57AM -0700, H.J. Lu wrote:
>> On Wed, May 6, 2015 at 11:37 AM, Rich Felker wrote:
>> > On Wed, May 06, 2015 at 11:26:29AM -0700, H.J. Lu wrote:
>> >> On Wed, May 6, 2015 at 10:35 AM, Rich Felker wrote:
>> >> > On
On Wed, May 06, 2015 at 11:44:57AM -0700, H.J. Lu wrote:
> On Wed, May 6, 2015 at 11:37 AM, Rich Felker wrote:
> > On Wed, May 06, 2015 at 11:26:29AM -0700, H.J. Lu wrote:
> >> On Wed, May 6, 2015 at 10:35 AM, Rich Felker wrote:
> >> > On Wed, May 06, 2015 at 07:43:58PM +0300, Alexander Monakov w
On 2015-04-27 9:16 AM, John David Anglin wrote:
Hi Dave,
Would it be possible for you to test this patch on a 64-bit hppa
or at least bootstrap it?
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01288.html
I started a build and test with your patch on hppa64-hp-hpux11.11 this
morning.
The patc
On Wed, May 6, 2015 at 11:37 AM, Rich Felker wrote:
> On Wed, May 06, 2015 at 11:26:29AM -0700, H.J. Lu wrote:
>> On Wed, May 6, 2015 at 10:35 AM, Rich Felker wrote:
>> > On Wed, May 06, 2015 at 07:43:58PM +0300, Alexander Monakov wrote:
>> >> On Wed, 6 May 2015, Jakub Jelinek wrote:
>> >> > The
On Wed, May 06, 2015 at 04:13:05PM +, Joseph Myers wrote:
> On Wed, 6 May 2015, Marek Polacek wrote:
>
> > 2015-05-06 Marek Polacek
> >
> > PR c/47043
> > * c-common.c (handle_deprecated_attribute): Allow CONST_DECL.
>
> Do all other attributes already reject CONST_DECL? I don't
On Wed, May 06, 2015 at 11:26:29AM -0700, H.J. Lu wrote:
> On Wed, May 6, 2015 at 10:35 AM, Rich Felker wrote:
> > On Wed, May 06, 2015 at 07:43:58PM +0300, Alexander Monakov wrote:
> >> On Wed, 6 May 2015, Jakub Jelinek wrote:
> >> > The linker would know very well what kind of relocations are us
On Wed, May 6, 2015 at 10:35 AM, Rich Felker wrote:
> On Wed, May 06, 2015 at 07:43:58PM +0300, Alexander Monakov wrote:
>> On Wed, 6 May 2015, Jakub Jelinek wrote:
>> > The linker would know very well what kind of relocations are used for
>> > particular PLT slot, and for the new relocations whic
On Wed, May 06, 2015 at 07:43:58PM +0300, Alexander Monakov wrote:
> On Wed, 6 May 2015, Jakub Jelinek wrote:
> > The linker would know very well what kind of relocations are used for
> > particular PLT slot, and for the new relocations which would resolve to the
> > address of the .got.plt slot it
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 easily miss the != VOIDmode terminator, or not know when to
> > use GET_MODE_WIDER_SPECIAL.
> >
> > We can certainly
On 05/06/2015 12:06 AM, Gerald Pfeifer wrote:
I started working on this over the weekend, and then Jason
wondered about it yesterday, so I completed and committed the
following skeleton for the GCC 6 release notes yesterday.
+GCC 6 Release SeriesChanges, New Features, and Fixes
+
+
+Caveats
+
On Wed, 6 May 2015, Jakub Jelinek wrote:
> The linker would know very well what kind of relocations are used for
> particular PLT slot, and for the new relocations which would resolve to the
> address of the .got.plt slot it could just tweak corresponding 3rd insn
> in the slot, to not jump to firs
On Wed, May 06, 2015 at 06:18:23PM +0200, Marek Polacek wrote:
> On Wed, May 06, 2015 at 04:58:03PM +0200, Jakub Jelinek wrote:
> > Also, it would be nice to figure why gcc doesn't warn (for both meaningful
> > changes, in the first snippet I believe gcc just determines the static
> > function is n
Thanks! Updated patch.
2015-05-06 Aditya Kumar
* gcov-tool.c (do_merge): Refactored to remove int ret.
* ipa-icf.c (sem_item::hash_referenced_symbol_properties): Changed
(!type == FUNC) to (type != FUNC).
* reload.h (struct target_reload): Changed to type of
x_spill_
On 05/05/2015 04:33 PM, Aldy Hernandez wrote:
On 05/05/2015 02:08 PM, Jason Merrill wrote:
On 05/04/2015 09:29 PM, Aldy Hernandez wrote:
The code handling parameter DIEs needed a little tweaking for variable
length template arguments. I've relaxed the original assert, but this
may require twea
On Wed, May 06, 2015 at 04:22:13PM +, Aditya K wrote:
> Thanks Richard, Jakub and Trevor for the feedback. I have reformatted the
> changelog, and modified the patch addressing your comments.
>
> -Aditya
>
>
> 2015-05-06 Aditya Kumar
>
> * gcov-tool.c (do_merge):
> * ipa
On Wed, May 06, 2015 at 06:18:23PM +0200, Marek Polacek wrote:
> On Wed, May 06, 2015 at 04:58:03PM +0200, Jakub Jelinek wrote:
> > Also, it would be nice to figure why gcc doesn't warn (for both meaningful
> > changes, in the first snippet I believe gcc just determines the static
> > function is n
On Wed, May 06, 2015 at 04:58:03PM +0200, Jakub Jelinek wrote:
> Also, it would be nice to figure why gcc doesn't warn (for both meaningful
> changes, in the first snippet I believe gcc just determines the static
> function is noreturn and that is why it correctly doesn't warn).
> I thought Marek h
On Wed, 6 May 2015, Marek Polacek wrote:
> 2015-05-06 Marek Polacek
>
> PR c/47043
> * c-common.c (handle_deprecated_attribute): Allow CONST_DECL.
Do all other attributes already reject CONST_DECL? I don't see any tests
for unsupported attributes on enum values being properly di
On Wed, 6 May 2015, Michael Haubenwallner wrote:
> Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
>
> Patch for top-level files.
I don't think this top-level patch is a good idea. These are *not*
generated files,
On 05/06/2015 09:45 AM, Jakub Jelinek wrote:
As for hoisting the load of the call address before the loop, with lazy
binding that has the obvious disadvantage that you'd resolve the slot again
and again, if you are unlucky enough that the function hasn't been resolved
yet. Unless the shared PLT
Jakub Jelinek writes:
> Hi!
>
> See Trevor's comments on ChangeLog.
>
> diff --git a/gcc/reload.h b/gcc/reload.h
> index c777e54..ae86150 100644
> --- a/gcc/reload.h
> +++ b/gcc/reload.h
> @@ -168,7 +168,7 @@ struct target_reload {
> value indicates the level of indirect addressing supported
This patch implements a feature quite a lot of people wanted: allow using
__attribute__ ((deprecated)) on an enumerator. Implementing it was quite
straightforward: parse the attributes and apply them to the CONST_DECL.
I hit an issue in the C++ FE though: since r217677 we produce the deprecated
d
On Wed, May 06, 2015 at 06:24:58PM +0300, Alexander Monakov wrote:
> If the same PLT stubs as today are to be used, it constrains the compiler on
> 32-bit x86 and possibly other arches where PLT stubs need GOT pointer in a
> specific register. It's possible to imagine more complex PLT stubs that
>
On 6 May 2015 at 09:27, Renlin Li wrote:
> Hi Jonathan,
>
>
> On 22/04/15 13:58, Jonathan Wakely wrote:
>>
>> 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 Ok
Hi,
I'm sitting on this since quite some time already and always missed stage
1. This implements support for vectorizing strided stores with unknown
but loop invariant stride, like:
sumit (float * __restrict dest,
float * __restrict src, float * __restrict src2,
int stride, int n
On Tue, 5 May 2015, Michael Meissner wrote:
> The problem is the PowerPC will have 2 128-bit floating point types, one using
> the IBM double-double format (a pair of doubles to give the user more mantissa
> bits, but no greater exponent range), and IEEE 128-bit floating point. I
> don't
> want
On Mon, 4 May 2015, Jeff Law wrote:
> On 05/04/2015 11:39 AM, Jakub Jelinek wrote:
> > On Mon, May 04, 2015 at 11:34:05AM -0600, Jeff Law wrote:
> > > On 05/04/2015 10:37 AM, Alexander Monakov wrote:
> > > > This patch introduces option -fno-plt that allows to expand calls that
> > > > would
> > >
On Wed, May 6, 2015 at 9:36 AM, Segher Boessenkool
wrote:
> This patch makes cstore expand all comparisons against a constant
> (that aren't already handled by a subfc;subfe sequence) as an
> addi ; [n]{and,or}[c] ; sr[wd]i sequence. It expands all the
> possible inversions separately (as well a
Hi!
See Trevor's comments on ChangeLog.
diff --git a/gcc/reload.h b/gcc/reload.h
index c777e54..ae86150 100644
--- a/gcc/reload.h
+++ b/gcc/reload.h
@@ -168,7 +168,7 @@ struct target_reload {
value indicates the level of indirect addressing supported, e.g., two
means that (MEM (MEM (R
Jeff Law writes:
> On 05/05/2015 05:54 PM, Michael Meissner wrote:
>> This patch contains the machine independent changes that I will need to add
>> IEEE 128-bit floating point to the GCC compiler for PowerPC.
>>
>> It adds a new mode defintion macro: SPECIAL_FLOAT_MODE that is similar to
>> FLOAT
2015-05-06 Gleb Fotengauer-Malinovskiy
PR libitm/61164
* local_atomic (__always_inline): Rename to...
(__libitm_always_inline): ... this.
---
libitm/local_atomic | 299 ++--
1 file changed, 149 insertions(+), 150 deletions
On Wed, May 06, 2015 at 01:47:38PM +, Aditya K wrote:
> I recently compiled gcc with clang and found few useful warnings
> (https://gcc.gnu.org/ml/gcc/2015-05/msg00015.html,
> https://gcc.gnu.org/ml/gcc/2015-05/msg00041.html).
> I have a patch to fix some of those, it passes bootstrap, please
Hi all,
Here is an implementation of std::initializer_list objects that properly own
the underlying sequence. This will allow list-initialization for containers
like std::vector< std::unique_ptr< T > >, but such library support will come in
a subsequent patch if this one is supported.
To summa
Implement the -mflip-thump option. Undocumented for internal testing
only. This option artificially inserts alternative attribute thumb/modes
on functions.
This close the patch set. Thanks for your review,
Christian
2014-09-23 Christian Bruel
* config/arm/arm.c (add_attribute, arm_insert_att
Implements the hooks for #pragma GCC target
A test included to check that macros were correctly defined/undefined on
pragma regions.
Thanks
Christian
2014-09-23 Christian Bruel
* config/arm/arm.h (REGISTER_TARGET_PRAGMAS):
Call arm_register_target_pragmas.
* config/arm/arm-protos.h (arm_
On 05/05/2015 05:54 PM, Michael Meissner wrote:
This patch contains the machine independent changes that I will need to add
IEEE 128-bit floating point to the GCC compiler for PowerPC.
It adds a new mode defintion macro: SPECIAL_FLOAT_MODE that is similar to
FLOAT_MODE. The difference is the co
Implements and document the hooks to support target_attributes.
The emission of blx is handled directly for armv5 to overcome a bug with
the current binutils that fails with calls to a static symbol in a
different section. (e.g .text -> .text.startup) in different modes.
(ref https://sourceware.o
Re-implement ARM_DECLARE_FUNCTION_NAME as a function. That will make
changed related to unified/divided and mode directives easier to insert.
Thanks
Christian
2014-09-23 Christian Bruel
* config/arm/arm-protos.h (arm_declare_function_name): Declare.
(is_called_in_ARM_mode): Remove.
* conf
In preparation of the pragma target
reorganize ÂTARGET_CPU_CPP_BUILTINSÂ to redefine mode dependent macros
based on current thumb_p.
Thanks,
Christian
2014-09-23 Christian Bruel
* config/arm/arm-c.c (cpp_def_or_undef): New functions.
(arm_cpp_builtins): Likewise.
* config/arm/arm.h (TARG
In preparation of the target attribute,
reorganize Âarm_option_override into 3 entities:
arm_option_override_internal_p
arm_option_check_internal
arm_option_param_internal
Also define and use TREE_TARGET macros instead of file-scope variables
in the machine description.
Thanks,
Christian
2014-
On 6 May 2015 at 11:50, Ramana Radhakrishnan wrote:
> On Thu, Apr 30, 2015 at 6:49 PM, Yvan Roux wrote:
>> Hi,
>>
>> On 23 March 2015 at 18:47, Yvan Roux wrote:
>>> Hi,
>>>
>>> On 23 March 2015 at 17:08, Ramana Radhakrishnan
>>> wrote:
On Wed, Mar 18, 2015 at 10:19 AM, Yvan Roux wrote:
>>
> A general note, please reply to each of the patches with a rebased
> patch as a separate email. Further more all your patches appear to
> have dos line endings so they don't seem to apply cleanly. Please
> don't have spurious headers in your patch submission - it then makes
> it hard to , please
On 05/05/2015 10:03 AM, Michael Haubenwallner wrote:
Hello build machinery maintainers,
following up
http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462
http://thread.gmane.org/gmane.comp.gcc.patches/332160
[ ... snip ... ]
Even if I probably need to split this change into one
Hi All,
Here is a patch which gives us significant speed-up on HASWELL for
test containing masked stores. The main goal of that patch is attempt
to avoid HW hazard for maskmove instructions through inserting
additional check on zero mask and putting all masked store statements
into separate block
On 05/05/15 19:07, Richard Biener wrote:
> On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw
> wrote:
>> On 05/05/15 15:33, Richard Earnshaw wrote:
>>> On 05/05/15 15:29, Jakub Jelinek wrote:
On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
> On 05/05/15 14:06, Jakub
I recently compiled gcc with clang and found few useful warnings
(https://gcc.gnu.org/ml/gcc/2015-05/msg00015.html,
https://gcc.gnu.org/ml/gcc/2015-05/msg00041.html).
I have a patch to fix some of those, it passes bootstrap, please apply these if
it is useful.
Thanks,
-Aditya
This patch makes cstore expand all comparisons against a constant
(that aren't already handled by a subfc;subfe sequence) as an
addi ; [n]{and,or}[c] ; sr[wd]i sequence. It expands all the
possible inversions separately (as well as add to zero); combine
and friends will take care of all that.
Th
On 01/05/15 13:51, Marcus Shawcroft wrote:
On 23 March 2015 at 17:06, Szabolcs Nagy wrote:
GCC can be compiled for aarch64 target with busybox sed except for
the geniterators.sh script which uses nonstandard basic regex.
I explicitly set LC_ALL=C too because the regex depends on collation
ord
Hi,
On Tue, 5 May 2015 18:03:15, Michael Haubenwallner wrote:
>
> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
>
> BTW, the actual commands I use to re-run automake for everything (I found) is:
> $ export AUTOMAKE='automake-1.11 --add-missing --copy --force-missing'
> $
On Wed, May 6, 2015 at 8:22 AM, Alan Modra wrote:
> Using a plain [(const_int 0)] for a nop pattern apparently no longer
> survives optimization. rtl_dce deletes these nops. This patch uses
> an unspec so that explicitly inserted nops are kept.
> Fixing that revealed a number of patterns and spl
On Wed, May 6, 2015 at 5:50 AM, Alan Modra wrote:
> -mprofile-kernel changed recently to not save lr on the stack before
> calling _mcount. This means a change is required in the _mcount
> used by one of the powerpc64 tests to grab function parameter
> registers. While fixing that, I noticed tha
Tobias,
First, thank you for taking the time to review the patch.
Second, thank you for providing the comments. It appears
all of the comments need to be acted upon in some manner.
Thanks!
On 05/05/2015 05:01 AM, Tobias Burnus wrote:
Thomas Schwinge wrote:
In follow-up messages, I'll be post
Yes, it's documented that there is still some work to do for cross builds,
however a cross build for gotools currently fails.
The toplevel make always passes the GOC variable in the environment, overwriting
anything configured in gotools own configure.ac. Fixed by explictly using @GOC@
for GOCOMPI
On Wed, May 06, 2015 at 08:32:13AM +0100, Richard Sandiford wrote:
> > Alternately, you could find a way to accurately track if we're inside a
> > MEM, where we want to canonicalize things slightly differently. Once we
> > can accurately track if we're inside a MEM, then we no longer have to
>
Using a plain [(const_int 0)] for a nop pattern apparently no longer
survives optimization. rtl_dce deletes these nops. This patch uses
an unspec so that explicitly inserted nops are kept.
Fixing that revealed a number of patterns and splitters that
accidentally inserted [(const_int 0)] insns int
Vectorization is now possible even for targets that don't
support unaligned loads. Committed.
Richard.
2015-05-06 Richard Biener
PR tree-optimization/62283
* gcc.dg/vect/bb-slp-32.c: Remove XFAIL.
Index: gcc/testsuite/gcc.dg/vect/bb-slp-32.c
===
Hi!
On Tue, 5 May 2015 15:38:03 -0400, David Malcolm wrote:
> On Wed, 2015-04-29 at 14:10 +0200, Mikael Morin wrote:
> > Le 29/04/2015 02:02, David Malcolm a écrit :
> > > diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> > > index 2c7c554..30e4eab 100644
> > > --- a/gcc/fortran/parse.c
>
On Wed, Apr 29, 2015 at 10:54:58PM +, Joseph Myers wrote:
> On Mon, 27 Apr 2015, Marek Polacek wrote:
>
> > trigger by default. One change is that we reject programs that use shift
> > with
> > undefined behavior in a context where a constant expression is required,
> > thus
> > e.g. enum E
On 30/04/15 00:18, Joseph Myers wrote:
> On Wed, 29 Apr 2015, Szabolcs Nagy wrote:
>> only affects [u]int_fastN_t types
>> (on 64bit systems for N=16,32 musl uses int but glibc uses long)
>>
>> i can fix glibc-stdint.h, but it's yet another way in which the
>> compiler is tied to a particular libc
On 29/04/15 14:51, Szabolcs Nagy wrote:
> On 29/04/15 14:17, Michael Eager wrote:
>> On 04/27/2015 07:35 AM, Szabolcs Nagy wrote:
>>> On 20/04/15 19:54, Szabolcs Nagy wrote:
Set up dynamic linker name for microblaze.
>>>
>>> Patch v2.
>>> (undef MUSL_DYNAMIC_LINKER that comes from confi
On 29/04/15 00:30, Joseph Myers wrote:
> On Mon, 20 Apr 2015, Szabolcs Nagy wrote:
>
>> * config/linux.opt (mmusl): New option.
>
> New -m options need documenting in invoke.texi.
>
Patch v3.
Now with documentation in invoke.texi.
Based on previous discussion I assume it is
OK to commit
On 05/05/2015 02:42 PM, Marcus Shawcroft wrote:
> On 5 May 2015 at 12:07, Christian Bruel wrote:
>> This fixes PR target/66015 and a latent issue revealed by
>> gcc.dg/ipa/iinline-attr.c since
>> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01609.html
>>
>> Regtested on aarch64-linux-gnu by Lin
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 condition.
>
> While the original test case shown here seems t
Well - only those with no gaps in the groups with this patch. More
as followup.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-05-06 Richard Biener
* tree-vect-slp.c (vect_supported_load_permutation_p): Use
vect_transform_slp_perm_load to check
of course I forgot one to attach...
Am 2015-05-06 um 12:13 schrieb Michael Haubenwallner:
>
> Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
>> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
>
> Patch for liboffloadmic.
>
2015-05-06 Michael Haubenwallner
* Ma
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
Patch for zlib.
2015-05-06 Michael Haubenwallner
* Makefile.in: Regenerated with automake-1.11.6.
* aclocal.m4: Likewise.
* configure: Likewise.
Index: zlib/Makef
Patch for lto-plugin.
Removing "by automake version number" from Makefile.am to
avoid false positives when hunting for "by automake 1.11.[^6]".
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Hello build machinery maintainers,
>
> following up
> http://thread.gmane.org/gmane.comp.gcc.patc
Patch for libvtv, also recreated (apparently) unused
testsuite/other-tests/Makefile.in
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Hello build machinery maintainers,
>
> following up
> http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462
> http://thread.gmane.org/gmane.c
Patch for libstdc++-v3.
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Hello build machinery maintainers,
>
> following up
> http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462
> http://thread.gmane.org/gmane.comp.gcc.patches/332160
>
> On 01/25/2015 08:42 PM, Jan-Benedic
> On 2015–05–04, at 12:00 AM, David Krauss wrote:
>
> Besides that, are some machines overloaded? If I need to use POWER, will
> there be a learning curve or brittleness as on Darwin? To avoid trial and
> error whilst wading into the process, I’m just asking for some personal
> confirmation o
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
Patch for libssp.
2015-05-06 Michael Haubenwallner
* Makefile.in: Regenerated with automake-1.11.6.
* aclocal.m4: Likewise.
* configure: Likewise.
Index: libssp/M
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
Patch for libsanitizer.
2015-05-06 Michael Haubenwallner
* Makefile.in: Regenerated with automake-1.11.6.
* aclocal.m4: Likewise.
* asan/Makefile.in: Likewise.
*
Hi DJ,
OK to apply ?
Ok, but...
Thanks - committed.
- if (regno == FRAME_POINTER_REGNUM && frame_pointer_needed)
+ if (regno == FRAME_POINTER_REGNUM
+ && (frame_pointer_needed || df_regs_ever_live_p (regno)))
Do we want regs_ever_live or regs_ever_written_to ? I seem to recall
Patch for libquadmath.
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Hello build machinery maintainers,
>
> following up
> http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462
> http://thread.gmane.org/gmane.comp.gcc.patches/332160
>
> On 01/25/2015 08:42 PM, Jan-Benedict
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
Patch for libjava/libltdl, need to gzip for recipients gcc.gnu.org.
libjava.libltdl.patch.gz
Description: application/gzip
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
Patch for liboffloadmic.
Patch for libobjc.
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Hello build machinery maintainers,
>
> following up
> http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462
> http://thread.gmane.org/gmane.comp.gcc.patches/332160
>
> On 01/25/2015 08:42 PM, Jan-Benedict Gla
Patch for libmpx.
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Hello build machinery maintainers,
>
> following up
> http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462
> http://thread.gmane.org/gmane.comp.gcc.patches/332160
>
> On 01/25/2015 08:42 PM, Jan-Benedict Glaw
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6?
Patch for libjava, without classpath and libltdl.
2015-05-06 Michael Haubenwallner
* Makefile.in: Regenerated with automake-1.11.6.
* aclocal.m4: Likewise.
* confi
Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01004.html
Thanks,
Kyrill
On 20/04/15 11:16, Kyrill 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
Hi Gerald,
as maintainer of the port you do not need anyone else's approval.
Thanks - have checked the (editted) patch in.
That said, I am always happy to provide a second pair of eyes, so
here are some comments:
Thanks for those too. I have made the appropriate changes following
your su
-mprofile-kernel changed recently to not save lr on the stack before
calling _mcount. This means a change is required in the _mcount
used by one of the powerpc64 tests to grab function parameter
registers. While fixing that, I noticed that the asm defined the
_mcount label, which is a bit rude;
On Thu, Apr 30, 2015 at 6:49 PM, Yvan Roux wrote:
> Hi,
>
> On 23 March 2015 at 18:47, Yvan Roux wrote:
>> Hi,
>>
>> On 23 March 2015 at 17:08, Ramana Radhakrishnan
>> wrote:
>>> On Wed, Mar 18, 2015 at 10:19 AM, Yvan Roux wrote:
Hi,
This is a fix for PR64208 where LRA loops when
1 - 100 of 128 matches
Mail list logo
