One of the nice features of the ELFv2 ABI is that stack frames are
smaller compared to ELFv1. We don't allocate a parameter save area
unless we actually use it. However, for variable argument lists, we
kept the simple va_list type which is a pointer to the memory location
of the next parameter.
On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
> On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
>> On 07/11/2011 05:54 PM, H.J. Lu wrote:
>>>
>>> The key is the
>>> >
>>> > XEXP (x, 1) == convert_memory_address_addr_space
>>> >(to_mode, XEXP (x, 1), as)
>>> >
>>> >
On 05/28/2014 02:54 PM, Jeff Law wrote:
> On 05/28/14 15:52, Jakub Jelinek wrote:
>> On Wed, May 28, 2014 at 05:28:31PM -0400, Kai Tietz wrote:
>>> Yes, I missed the plus-part.
>>>
>>> I am just running bootstrap with regression testing for altering predicate
>>> to:
>>>
>>> (define_predicate "sib
On 05/28/2014 10:00 PM, Paolo Carlini wrote:
Hi again,
On 05/28/2014 07:06 PM, Paolo Carlini wrote:
(In case I would have also to double check something weird I was
seeing if the injection happens for all method types...)
In the meanwhile I investigated the reason of all those regressions I
wa
This patch from Peter Collingbourne tweaks libgo to work around a
deficiency in the LLVM split-stack implementation: it doesn't support
varargs functions. This is a step toward making it possible to compile
libgo with LLVM. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed
On 28/05/2014 11:56 PM, Pedro Alves wrote:
> On 05/28/2014 09:38 PM, Andrew Burgess wrote:
>>
>> diff --git a/libiberty/testsuite/demangle-expected
>> b/libiberty/testsuite/demangle-expected
>> index 453f9a3..0e2bb12 100644
>> --- a/libiberty/testsuite/demangle-expected
>> +++ b/libiberty/testsui
> Richard Sandiford wrote the original section anchors implementation,
> so he would be a good person to comment about the interaction between
> aliases and section anchors.
Thanks! Richard, does this patch seem sane? AIX gcc now builds for me, so I
will test it on x86_64-linux it and commit if i
This patch to libgo, from Peter Collingbourne, changes some of the C
code to make it easier to compile libgo with a compiler other than GCC.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r d73f07d002ef libgo/runtime/go-cdiv.c
--- a/libgo/runtime/g
/ChangeLog:
* gcc.c-torture/compile/20140528-1.c: New testcase.
commit d2a89a0b21f13e676a863eeb3ac1f9ad927e65ac
Author: Andrew Pinski
Date: Wed May 28 15:44:05 2014 -0700
Fix kernel.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c2f6c4f..32c5fcb 100644
--- a
On 05/28/2014 09:38 PM, Andrew Burgess wrote:
> In two places when a struct demangle_component is of type
> DEMANGLE_COMPONENT_FIXED_TYPE we fall back to accessing the default
> s_binary member of the union rather than the s_fixed member. This is
> incorrect and can cause the demangler to crash.
>
On Wed, May 28, 2014 at 6:31 PM, Jan Hubicka wrote:
>> Honza,
>>
>> I'm glad that you're making progress.
>>
>> > David, this looks like a bug in the AIX target output macros. I get:
>> > .set
>> > _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11c
Tom, the final version of this patch that you committed breaks bootstrap
on powerpc64le-linux-gnu. The problem is that all uses of the variable
i are guarded by #ifdef STACK_REGS, but the declaration of i is
unconditional. We get an unused variable warning that becomes an error
during stage 3.
T
On 05/27/2014 12:57 PM, Pedro Alves wrote:
> +dmgl_opts = (DMGL_VERBOSE
> + | DMGL_ANSI
> + | DMGL_GNU_V3
> + | DMGL_RET_POSTFIX
> + | DMGL_PARAMS);
Hmm, don't know why I had put DMGL_RET_POSTFIX there in the
first place. That's unintended.
On Thu, May 29, 2014 at 12:14:45AM +0200, Jakub Jelinek wrote:
> > +#pragma omp target update from(a, b, b) /* { dg-error "'b' appears more
> > than once in motion clauses" } */
> > +#pragma omp target update to(a) to(b, b) /* { dg-error "'b' appears more
> > than once in motion clauses" } */
> >
> Honza,
>
> I'm glad that you're making progress.
>
> > David, this looks like a bug in the AIX target output macros. I get:
> > .set
> > _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
>
> > (this is correct since localalia
+gdb-patches
On 05/27/2014 02:56 PM, Ian Lance Taylor wrote:
> On Tue, May 27, 2014 at 4:57 AM, Pedro Alves wrote:
>>
>> libiberty/
>> 2014-05-26 Pedro Alves
>>
>> * cp-demangle.c (d_dump): Handle DEMANGLE_COMPONENT_FUNCTION_PARAM
>> and DEMANGLE_COMPONENT_NUMBER.
>
> This is
On Wed, May 28, 2014 at 10:51:10PM +0100, Andrew Pinski wrote:
> On Thu, Mar 27, 2014 at 10:33 AM, James Greenhalgh
> wrote:
> > Hi,
> >
> > Next, comparisons, flag setting operations and IF_THEN_ELSE.
> >
> > Tested on aarch64-none-elf.
> >
> > Ok for stage 1?
>
> This broke building the Linux k
>
> Thanks !
>
> Unfortunately this is not the only bug at the time.
>
> see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61331
>
> which is even more painful...
>
> I can currently only build anything if I do this:
>
> svn diff -r210963:210965 | patch -p0 -R
thanks!
I will regtest and go ah
On 05/22/2014 12:57 PM, Thomas Schwinge wrote:
> On Wed, 14 May 2014 15:20:16 +0100, Gary Benson wrote:
>> Andrew Burgess wrote:
>>> On 14/05/2014 10:01 AM, Gary Benson wrote:
Ian Lance Taylor wrote:
> This patch is OK.
Andrew, would you like me to commit this?
>>>
>>> Yes pleas
- Original Message -
> On Wed, May 28, 2014 at 03:54:58PM -0600, Jeff Law wrote:
> > >Why not get rid of all the above 4 lines and just keep:
> > >
> > >> return CONSTANT_P (op);
> > >
> > >? CONST matches CONSTANT_P, and what is inside of CONST should be
> > >fine, and (plus (symbol_ref
On Wed, May 28, 2014 at 10:38:55PM +0200, Thomas Schwinge wrote:
> --- gcc/c/c-parser.c
> +++ gcc/c/c-parser.c
> @@ -13530,7 +13530,7 @@ c_parser_omp_target_update (location_t loc, c_parser
> *parser,
>&& find_omp_clause (clauses, OMP_CLAUSE_FROM) == NULL_TREE)
> {
>error_at (
Hi,
On Wed, 28 May 2014 22:36:17, Jan Hubicka wrote:
>
> On the other hand, the alias created ought to inherit properties form its
> target, so yes, we probably want to copy flags that matters, including
> DECL_THREAD_LOCAL_P. We however should not copy DECL_INITIAL - we never have
> constructors
2014-05-28 Pedro Alves
* MAINTAINERS (Write After Approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0c0062b..a710ccb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -312,6 +312,7 @@ from other maintainers or reviewe
On Wed, May 28, 2014 at 03:54:58PM -0600, Jeff Law wrote:
> >Why not get rid of all the above 4 lines and just keep:
> >
> >> return CONSTANT_P (op);
> >
> >? CONST matches CONSTANT_P, and what is inside of CONST should be
> >fine, and (plus (symbol_ref) (const_int)) not surrounded by CONST
> >i
> Any update?
>
> I've managed to generate a simple test case from
> libstdc++-v3/src/c++98/strstream.cc which reproduces the issue on
> ARM that Ramana has reported previously:
>
>
> template struct char_traits;
>
> template
> class basic_ios
> {
> };
>
> template >
> class basic_istream : v
> Hi!
>
> On Mon, 26 May 2014 02:16:35 -0700, Andrew Pinski wrote:
> > On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres
> > wrote:
> > > r210901 breaks bootstrap on targets not supporting strnlen, e.g.,
> > > darwin10.
> > >
> > > ../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was
On 05/28/14 15:52, Jakub Jelinek wrote:
On Wed, May 28, 2014 at 05:28:31PM -0400, Kai Tietz wrote:
Yes, I missed the plus-part.
I am just running bootstrap with regression testing for altering predicate to:
(define_predicate "sibcall_memory_operand"
(match_operand 0 "memory_operand")
{
o
On Wed, May 28, 2014 at 05:28:31PM -0400, Kai Tietz wrote:
> Yes, I missed the plus-part.
>
> I am just running bootstrap with regression testing for altering predicate to:
>
> (define_predicate "sibcall_memory_operand"
> (match_operand 0 "memory_operand")
> {
> op = XEXP (op, 0);
>
> if (
On Thu, Mar 27, 2014 at 10:33 AM, James Greenhalgh
wrote:
> Hi,
>
> Next, comparisons, flag setting operations and IF_THEN_ELSE.
>
> Tested on aarch64-none-elf.
>
> Ok for stage 1?
This broke building the Linux kernel.
A simple testcase:
unsigned grab_cache_page_write_begin(unsigned flags, unsign
Richard Biener writes:
> The following changes the configury to insist on [u]int64_t being
> available and removes the very old __int64 case. Autoconf doesn't
> check for it, support came in via a big merge in Dec 2002, r60174,
> and it was never used on the libcpp side until I fixed that with
>
Honza,
I'm glad that you're making progress.
> David, this looks like a bug in the AIX target output macros. I get:
> .set
> _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
> (this is correct since localalias is really an ali
- Original Message -
> On 05/28/14 11:22, Richard Henderson wrote:
> > On 05/28/2014 01:43 AM, Kai Tietz wrote:
> >> + if (GET_CODE (op) == CONST)
> >> +op = XEXP (op, 0);
> >> + return (GET_CODE (op) == SYMBOL_REF || CONSTANT_P (op));
> >
> > Surely all this boils down to just CONS
Hi!
Does that look appropriate (for trunk)?
gcc/c/c-parser.c | 2 +-
gcc/c/c-typeck.c | 2 ++
gcc/cp/parser.c | 2 +-
gcc/cp/semantics.c| 2 ++
gcc/testsuite/c-
In two places when a struct demangle_component is of type
DEMANGLE_COMPONENT_FIXED_TYPE we fall back to accessing the default
s_binary member of the union rather than the s_fixed member. This is
incorrect and can cause the demangler to crash.
In d_dump I've changed the code to only access the s_f
>
> When I debug and set a breakpoint in varasm.c line 314 it looks as if
> the flag SECTION_RELRO is different. This flag is set in
I see, it is the same message, but different reason from AIX.
> categorize_decl_for_section where it depends on
> TREE_CODE(decl), and if it is a VAR_DECL also on
While working on patches to speed up the handling of constraints,
I hit some behaviour in ira_get_dup_out_num that looked unintentional:
- the check for output operands was part of the !ignored_p condition
so would be skipped if the first alternative is disabled/excluded.
- the first disabled/e
Honza,
I try to build this configuration:
../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64
--target=arm-linux-gnueabihf --enable-languages=c,c++,fortran,ada
--with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
but make fails:
libtool: compil
Hi again,
On 05/28/2014 07:06 PM, Paolo Carlini wrote:
(In case I would have also to double check something weird I was
seeing if the injection happens for all method types...)
In the meanwhile I investigated the reason of all those regressions I
was seeing when injecting in all METHOD_TYPEs: w
> On 05/27/14 23:20, Jan Hubicka wrote:
> >>
> >>here we have decl and its local alias:
> >>(gdb) p debug_tree (sect->named.decl)
> >> >> type >> type >> 700f57e0>
> >> unsigned SI
> >> size
> >> unit size
> >> align 32 symtab 45 alias s
Thanks for the review.
Jeff Law writes:
> On 05/26/14 13:21, Richard Sandiford wrote:
>>> If we're going to change it, then clearly the docs need to change and
>>> ideally we'd statically check the port's constraints during the build
>>> process to ensure they meet the tighter definition.
>>
>> O
On 05/28/14 11:22, Richard Henderson wrote:
On 05/28/2014 01:43 AM, Kai Tietz wrote:
+ if (GET_CODE (op) == CONST)
+op = XEXP (op, 0);
+ return (GET_CODE (op) == SYMBOL_REF || CONSTANT_P (op));
Surely all this boils down to just CONSTANT_P (op),
without having to look through the CONST a
Sandra Loosemore writes:
> On 05/19/2014 01:38 PM, Sandra Loosemore wrote:
>>
>> 2014-05-19 Iain Sandoe
>> Catherine Moore
>> Sandra Loosemore
>>
>> gcc/
>> * config/mips/mips.c (mips_set_current_function): Choose
>> function alignment once the current mode
On Wed, May 28, 2014 at 5:33 PM, Marat Zakirov wrote:
> Hi all,
>
> Here's a patch for optional Asan instrumentation of inline assembly.
>
> This version scans gimple for GIMPLE_ASMs and performs usual instrumentation
> of arguments with memory constraints ("m", "o", etc.) with fixed size.
>
> Ins
On May 28, 2014, at 7:27 AM, Richard Earnshaw wrote:
>
> Speed of implementation. We're gradually replacing these with proper
> builtins, but that takes a lot more work.
As an owner of a port with more builtins that yours, I can offer a
technological solution to reduce the cost of builtins to:
On 05/27/14 23:20, Jan Hubicka wrote:
here we have decl and its local alias:
(gdb) p debug_tree (sect->named.decl)
unsigned SI
size
unit size
align 32 symtab 45 alias set 3 canonical type 700f5840
pointer_to_this>
BLK
On 05/28/2014 01:43 AM, Kai Tietz wrote:
> + if (GET_CODE (op) == CONST)
> +op = XEXP (op, 0);
> + return (GET_CODE (op) == SYMBOL_REF || CONSTANT_P (op));
Surely all this boils down to just CONSTANT_P (op),
without having to look through the CONST at all.
Otherwise this looks ok.
r~
Hi,
On 05/28/2014 06:33 PM, Jason Merrill wrote:
On 05/28/2014 11:59 AM, Paolo Carlini wrote:
I see. Even not considering this issue, there are many regression if I
inject for all method types. I'm afraid the issue turns out to be much
more tricky than I hoped, I guess I'm going to unassign mys
On 05/28/2014 11:59 AM, Paolo Carlini wrote:
I see. Even not considering this issue, there are many regression if I
inject for all method types. I'm afraid the issue turns out to be much
more tricky than I hoped, I guess I'm going to unassign myself, for now,
and work on some other pending issues
Daveed from EDG pointed out this bug to me.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 912eae71d30adf6c07dbdf1b4741fd7ffd5a05ff
Author: Jason Merrill
Date: Wed May 28 11:50:50 2014 -0400
* pt.c (tsubst) [ARRAY_TYPE]: Check for array of array of unknown
bound.
diff --git
On 05/19/2014 01:38 PM, Sandra Loosemore wrote:
2014-05-19 Iain Sandoe
Catherine Moore
Sandra Loosemore
gcc/
* config/mips/mips.c (mips_set_current_function): Choose
function alignment once the current mode is known.
gcc/testsuite/
* gcc.target
Hi,
On 05/28/2014 05:49 PM, Jason Merrill wrote:
On 05/28/2014 11:38 AM, Paolo Carlini wrote:
But unconditionally doesn't work, without doing something more. For
example for the first test, as reported: when current_class_type is set
and equal to "struct X", class_of_this_parm is "struct X<
>"
Hi,
This patch keeps instrumented and original versions together and preserve
tranparent alias chain during symbol name privatization.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2013-05-28 Ilya Enkovich
* lto/lto-partition.c (add_symbol_to_partition_1): Keep orig
We were getting confused by applying LOOKUP_NO_TEMP_BIND to the nested
list-initializations, which is wrong; in aggregate initialization the
elements are copy-initialized without regard to the enclosing context.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 916172d3d6e115b94f1a902aebca4
On Wed, May 28, 2014 at 1:43 AM, Kai Tietz wrote:
> Hi,
>
> I modified prior patch so that it uses the new predicate
> sibcall_memory_operand to extend sibcall_insn_operand.
> Just one change in i386.c remains about x86_output_mi_thunk. Later one isn't
> pretty much essential. Nevertheless it
On 05/28/2014 11:38 AM, Paolo Carlini wrote:
But unconditionally doesn't work, without doing something more. For
example for the first test, as reported: when current_class_type is set
and equal to "struct X", class_of_this_parm is "struct X<
>".
Right, it needs to be the substituted this para
Hi,
On 05/28/2014 05:14 PM, Jason Merrill wrote:
On 05/28/2014 06:15 AM, Paolo Carlini wrote:
+ bool do_inject = (!current_class_ref
+&& TREE_CODE (t) == METHOD_TYPE
+&& TREE_CODE (TREE_TYPE (t)) == DECLTYPE_TYPE);
Let's do this for any METHOD_TYPE; the decltype could
On Wed, May 28, 2014 at 8:36 AM, Konstantin Serebryany
wrote:
> Dmitry,
> You've introduced atomic_uint64_t stats_[AllocatorStatCount]; in
> http://llvm.org/viewvc/llvm-project?view=revision&revision=173332
> Do you mind to change it to atomic_uintptr_t?
> There is of course a chance of overflow
> After lengthy IRC discussions, what Richard and I can live with is
> && !defined(__clang__) in this particular case that uses longlong.h
> in GCC sources, with a comment why.
> If we get too many of these workarounds, we should reconsider.
Committed as revision 211023, after bootstrap on x86_64-
On 05/28/2014 06:15 AM, Paolo Carlini wrote:
+ bool do_inject = (!current_class_ref
+ && TREE_CODE (t) == METHOD_TYPE
+ && TREE_CODE (TREE_TYPE (t)) == DECLTYPE_TYPE);
Let's do this for any METHOD_TYPE; the decltype could be nested as a
template argument.
On 27/05/14 17:31, Richard Sandiford wrote:
> Richard Earnshaw writes:
>> On 27/05/14 17:09, Richard Sandiford wrote:
>>> Richard Earnshaw writes:
On 27/05/14 16:27, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
>> On 27/05/14 15:08, Richard
On 28 May 2014, at 16:25 , Gopalasubramanian, Ganesh
wrote:
> Hi Philipp,
>
>> These changes look good to me.
>> We'll try them out on the benchmarks that caused us to add prefetching in
>> the first place.
>
> If you are OK, I would like to get these changes upstreamed.
Sorry for the delay
On 28/05/14 09:03, Matthew Fortune wrote:
>> You shouldn't need to declare __builtin_* functions anyway. And if a
>> function can be represented directly with GNU C vector extensions, it's
>> preferred to implement it that way inline in the header rather than having
>> built-in functions duplicati
Hi Philipp,
> These changes look good to me.
> We'll try them out on the benchmarks that caused us to add prefetching in the
> first place.
If you are OK, I would like to get these changes upstreamed.
-Ganesh
-Original Message-
From: Dr. Philipp Tomsich [mailto:philipp.toms...@theobrom
> I suppose casting the result of CWI_ELT () to uint64_t fixes this. Do
> similar errors happen elsewhere?
I don’t think you can cast to uint64_t, as host wide int might be some other
type, no?
There are others:
../../trunk/gcc/print-rtl.c: In function ‘void print_rtx(const_rtx)’:
../../trunk/
On Tue, 27 May 2014, Mike Stump wrote:
> So, I read the doc bits, and they look fine. I’m not a doc reviewer,
> but, the changes are usual and customary for a port, and trivial.
Yes, and I'd like to emphasize this point: Just because a file
matches *.texi doesn't mean that ports, middle, front,
I have reverted the following for now.
Richard.
2014-05-28 Richard Biener
Revert
2014-05-28 Richard Biener
* hwint.h (HOST_WIDE_INT_PRINT_*): Define in terms of PRI*64.
Index: gcc/hwint.h
===
*** gcc
On Wed, May 28, 2014 at 04:00:32PM +0200, Jakub Jelinek wrote:
> Defining HOST_WIDE_INT to long long or long based on whether long is 64-bit
> or not, but using PRIx64 etc. unconditionally is just wrong, either
> HOST_WIDE_INT should be uint64_t and then you should use PRI*64, or it is
> not, and t
The patch also fixes the arm-none-eabi build failures I've seen.
Thanks,
Yufeng
On 05/27/14 16:07, Richard Sandiford wrote:
Richard Sandiford writes:
Richard Sandiford writes:
Does the following patch help?
Bah, it won't of course: %i1 needs to be the operator.
Here's v2. I tested that
On Wed, May 28, 2014 at 03:47:52PM +0200, Richard Biener wrote:
> On Wed, May 28, 2014 at 3:15 PM, FX wrote:
> >> After lengthy IRC discussions, what Richard and I can live with is
> >> && !defined(__clang__) in this particular case that uses longlong.h
> >> in GCC sources, with a comment why.
> >
On Wed, May 28, 2014 at 3:15 PM, FX wrote:
>> After lengthy IRC discussions, what Richard and I can live with is
>> && !defined(__clang__) in this particular case that uses longlong.h
>> in GCC sources, with a comment why.
>
> I’ll test this patch and commit if there is no problem. But right now,
Hi all,
Here's a patch for optional Asan instrumentation of inline assembly.
This version scans gimple for GIMPLE_ASMs and performs usual instrumentation
of arguments with memory constraints ("m", "o", etc.) with fixed size.
Instrumentation is turned off by default.
This was successfully bootst
Ping.
Test is modified according to the fix in the test for loads.
diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-st.c
b/gcc/testsuite/gcc.dg/vect/pr52252-st.c
new file mode 100644
index 000..e7161f7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr52252-st.c
@@ -0,0 +1,21 @@
+/* { dg-do compil
> After lengthy IRC discussions, what Richard and I can live with is
> && !defined(__clang__) in this particular case that uses longlong.h
> in GCC sources, with a comment why.
I’ll test this patch and commit if there is no problem. But right now, current
trunk doesn’t build on x86_64-apple-darwi
Hi,
The patch introduces alternative way of permutations for load groups
of size 2 and 3 which should be faster on architectures with low
parallelism.
The patch gives 2 times gain on Silvermont to the test from PR52252
(in addition to already committed 3 times gain).
Patch passes bootstrap on x86
The following patch makes the VRP dump less vertical space noisy.
It also makes handling of the two forms of copies,
a_1 = b_2;
and
a_1 = PHI
behave more similar by also copying VR_UNDEFINED ranges in the
first case and by creating a [b_2, b_2] symbolic range in
the second case (if b_2 ha
Mike Stump writes:
> On May 27, 2014, at 1:04 AM, Rainer Orth
> wrote:
>> It's been a week since I've submitted the patch, so far having received
>> approval for the testsuite parts only.
>
> So, I read the doc bits, and they look fine. I’m not a doc reviewer, but,
> the changes are usual and
The following fixes bogus folding (introducing signed overflow)
for the X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 transform
where we let through a sign-change of the remaining constant operand.
Fixed as follows, bootstrap and regtest running on
x86_64-unknown-linux-gnu.
Richard.
2014-05-28 R
On Wed, May 28, 2014 at 03:33:15PM +0400, Evgeny Stupachenko wrote:
> Ok. Fixed. Test still passes on x86:
Ok.
> --- a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
> +++ b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
> @@ -1,6 +1,5 @@
> /* { dg-do compile } */
> -/* { dg-options "-O2 -g -ftree-vectorize -ms
Ok. Fixed. Test still passes on x86:
diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
index 6e3cb52..e37b177 100644
--- a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
+++ b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
@@ -1,6 +1,5 @@
/* { dg-do compile } */
-/* { d
On Wed, May 28, 2014 at 12:18:13PM +0200, Richard Biener wrote:
> > ATM we get the testing coverage for i686 and ppc32 hosts. So TBH I'd
> > prefer to keep it simple and just bump the version number.
>
> Works for me (though see Jakubs idea on the other thread, so please
> wait until we settled o
On 27/05/14 04:03, Jan Hubicka wrote:
Jan,
The IPA patch broke bootstrap on AIX with multiple failures.
The tail of the build log is attached.
Thanks,
I will give it a try at gcc111, good to have reproducible testcase.
FWIW, I'm seeing the same error when building arm-none-linux-gnueabihf
missed some line tails. Correct patch below:
diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
index 6e3cb52..57e8468 100644
--- a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
+++ b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
On Wed, May 28, 2014 at 02:51:57PM +0400, Evgeny Stupachenko wrote:
> Does the following fix ok?
>
> 2014-05-28 Evgeny Stupachenko
>
>* gcc.dg/vect/pr52252-ld.c: Fix target and options for the test.
>
> diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
> b/gcc/testsuite/gcc.dg/vect/
Does the following fix ok?
2014-05-28 Evgeny Stupachenko
* gcc.dg/vect/pr52252-ld.c: Fix target and options for the test.
diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
index 6e3cb52..57e8468 100644
--- a/gcc/testsuite/gcc.dg/vect/pr52252-l
On Wed, May 28, 2014 at 12:23 PM, Eric Botcazou wrote:
>> Well, a wrong-code bug plus a very obvious fix certainly qualifies.
>
> Fine with me, onto which branch(es) do you want me to put it?
Where you have tested it already, no need to spend extra cycles.
Richard.
> --
> Eric Botcazou
> Well, a wrong-code bug plus a very obvious fix certainly qualifies.
Fine with me, onto which branch(es) do you want me to put it?
--
Eric Botcazou
On Wed, May 28, 2014 at 12:03:39PM +0200, Richard Biener wrote:
> > Any other compilers that define __GNUC__?
>
> Every one I guess. ICC 9 has it defined to 4, __GNUC_MINOR__ to 0.
For ICC it seems to depend on the ICC version, newer ICC versions
report newer __GNUC_MINOR__.
That said, ICC doesn
On Wed, May 28, 2014 at 12:17 PM, Eric Botcazou wrote:
>> I suppose you also install on branches?
>
> No plan to do so since this isn't a regression, unless you insist. :-)
Well, a wrong-code bug plus a very obvious fix certainly qualifies.
Richard.
> --
> Eric Botcazou
On Wed, May 28, 2014 at 12:00 PM, Bernd Schmidt wrote:
> On 05/27/2014 04:57 PM, Richard Biener wrote:
>>
>> On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt
>> wrote:
>>>
>>> I noticed that string constants built by the Fortran frontend don't set
>>> TREE_READONLY for STRING_CST (and subsequently
... turns out, I can avoid fiddling with in_decl (which, I realized, is
meant to be used for diagnostics). The below version also passes testing.
Thanks,
Paolo.
/
Index: cp/pt.c
===
--- cp/pt.c (revision 211
On Wed, May 28, 2014 at 11:49 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
>> wrote:
>>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek
> I suppose you also install on branches?
No plan to do so since this isn't a regression, unless you insist. :-)
--
Eric Botcazou
On Wed, May 28, 2014 at 12:07:41PM +0200, Richard Biener wrote:
> >> #ifndef GCC_VERSION
> >> +/* Some compilers pretend to be GCC, even when they are not. */
> >> +#if defined(__clang__) || defined(__INTEL_COMPILER)
> >> +#define GCC_VERSION 0
> >> +#else
> >> #define GCC_VERSION (__GNUC__ * 10
On Wed, May 28, 2014 at 12:03 PM, Richard Biener
wrote:
> On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek wrote:
>> On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
>>> On Wed, May 28, 2014 at 10:24 AM, FX wrote:
>>> >> Yeah, a portable (C and C++) static assert would be nice. An
On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek wrote:
> On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
>> On Wed, May 28, 2014 at 10:24 AM, FX wrote:
>> >> Yeah, a portable (C and C++) static assert would be nice. And also
>> >> pushing
>> >> this to gmp then.
>> >>
>> >> In t
On 05/27/2014 04:57 PM, Richard Biener wrote:
On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt wrote:
I noticed that string constants built by the Fortran frontend don't set
TREE_READONLY for STRING_CST (and subsequently noticed that nothing seems to
set it for COMPLEX_CST). That was confusing th
On May 27, 2014, at 5:27 PM, Nathan Sidwell wrote:
> ok
Great! Committed as rev 211011.
Thanks Nathan :-)
Olivier
On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
> On Wed, May 28, 2014 at 10:24 AM, FX wrote:
> >> Yeah, a portable (C and C++) static assert would be nice. And also pushing
> >> this to gmp then.
> >>
> >> In the meantime I see nothing wrong in "merging" from GMP.
> >
> > One que
Richard Biener writes:
> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
> wrote:
>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump w
On Wed, May 28, 2014 at 11:02 AM, Bernd Edlinger
wrote:
> Hi,
>
>
>> But the coment previously read
>>
>> /* A constant address in TO_RTX can have VOIDmode, we must not try
>> to call force_reg for that case. Avoid that case. */
>>
>> and you are removing that check. So I guess you want to retain
1 - 100 of 123 matches
Mail list logo
