Hi Mikael,
> To be honest, both patches look fragile to me. Yours because it leaves
> gfc_current_ns to its value, leaving the door open to other problems.
> Mine, well, because it's playing with a global variable, with the
> possible side-effects this could have.
> However, without a better idea
Hi Steve,
Yes this is expected. As Segher pointed out, we need to change .md patterns in
target to be based on shifts instead of mults.
Regards,
Venkat.
-Original Message-
From: Steve Ellcey [mailto:sell...@imgtec.com]
Sent: Monday, May 11, 2015 11:20 PM
To: Kumar, Venkataramanan
Cc:
Joseph Myers writes:
> On Mon, 11 May 2015, Bernhard Reutner-Fischer wrote:
>
>> +TARGETLIB_PIC = $(dir $(TARGETLIB))pic/$(notdir $(TARGETLIB))
>> +TARGETLIB_NOASAN = $(dir $(TARGETLIB))noasan/$(notdir $(TARGETLIB))
>
> Is it OK to use GNU make features in libiberty now? That is, do binutils
>
On Fri, 2015-05-08 at 14:54 -0700, Paul Eggert wrote:
> On 05/08/2015 09:59 AM, Joseph Myers wrote:
> > Paul, although glibc's copy of parts of tzcode is a bit out of date, it
> > looks like the currenthttps://github.com/eggert/tz.git still has the
> > problematic code in private.h, relying on lef
This fixes an RTL checking failure I ran into while working on a change and it
is latent in the pristine compiler. emit_pattern_{after|before}_setloc have:
if (active_insn_p (after) && !INSN_LOCATION (after))
if (active_insn_p (first) && !INSN_LOCATION (first))
Now active_insn_p still has
> >> This won't play well with LTO since fplt will become another global flag
> >> while
> >> it affects codegen.
> >
> > I know Richi explained this to me in the past, but I can't remember the
> > details of why this is bad. Can you walk me through it again?
> >
>
> I have proposed a different a
> On 05/10/2015 12:33 PM, Jan Hubicka wrote:
> >This is properly honored by C++ FE but other FEs are bit random, which in
> >turn
> >confuses type_in_anonymous_namespace_p predicate that leads to flase
> >poistives
> >on type mismatch warnings. I used to be able to get around by checking only
>
> On 05/11/2015 01:05 PM, Jan Hubicka wrote:
> >>On 05/11/2015 12:46 PM, Jan Hubicka wrote:
> >>>Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to
> >>>handle
> >>>enums. But other case I would like to deal with are integer types - i.e.
> >>>preserve
> >>>difference between ch
On Mon, 11 May 2015, Marek Polacek wrote:
> The problem here isn't in the -Wshift-negative-value warning itself; the
> problem is with marking -1 << 0 as a non-constant: later on, we warn in
> a context where a constant expression is needed ("initializer element is
> not a constant expression"), a
On 05/10/2015 12:33 PM, Jan Hubicka wrote:
This is properly honored by C++ FE but other FEs are bit random, which in turn
confuses type_in_anonymous_namespace_p predicate that leads to flase poistives
on type mismatch warnings. I used to be able to get around by checking only
C++ types at LTO ti
On 04/28/2015 06:02 PM, David Malcolm wrote:
This is an updated implementation of the proposed
-Wmisleading-indentation warning.
Changes since last patch:
* I've rewritten it to use Manuel's approach from
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01225.html
I took Manuel's proposed
On Mon, 11 May 2015, Mikhail Maltsev wrote:
> In general, is there a recommended set of targets that cover most
> conditionally compiled code? Also, the GCC Wiki mentions some automated
See contrib/config-list.mk (note that some of those targets may have
pre-existing build failures, and note tha
On 05/11/2015 01:05 PM, Jan Hubicka wrote:
On 05/11/2015 12:46 PM, Jan Hubicka wrote:
Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to handle
enums. But other case I would like to deal with are integer types - i.e.
preserve
difference between char/signed char/unsigned char/
On 05/11/2015 03:11 PM, Segher Boessenkool wrote:
On Mon, May 11, 2015 at 11:23:47AM -0600, Jeff Law wrote:
* combine.c (simplify_set): When generating a CC set, if the
source already is in the correct mode, do not wrap it in a
compare. Simplify the rest of that code.
S
On Mon, May 11, 2015 at 11:23:47AM -0600, Jeff Law wrote:
> > * combine.c (simplify_set): When generating a CC set, if the
> > source already is in the correct mode, do not wrap it in a
> > compare. Simplify the rest of that code.
> Seems reasonable. Might not hurt to do a little test
My proposal should be consider out of any context. We don't know
what std::hash is used for in user code, this is why I am proposing this
patch even if for the moment it doesn't make any difference considering
only our usage of it.
Your remark would make more sens if we were talking ab
On Mon, May 11, 2015 at 1:36 PM, Jeff Law wrote:
> On 05/10/2015 10:59 AM, Jan Hubicka wrote:
>>>
>>> This patch introduces option -fno-plt that allows to expand calls that
>>> would
>>> go via PLT to load the address of the function immediately at call site
>>> (which
>>> introduces a GOT load).
Segher Boessenkool writes:
> On Mon, May 11, 2015 at 08:16:41PM +, Matthew Fortune wrote:
> > Does this patch effectively change the canonicalization rules? The
> > following Still exists in md.texi:
> >
> > @item
> > Within address computations (i.e., inside @code{mem}), a left shift is
> > c
On 05/07/2015 11:52 AM, Steve Ellcey wrote:
I would like to get some feedback on an idea of how to spill registers
that require (or perhaps only prefer for performance reasons) an alignment
greater than that supported by the stack.
If you look at how GCC supports local variables with alignment
On Mon, 11 May 2015, Bernhard Reutner-Fischer wrote:
> +TARGETLIB_PIC = $(dir $(TARGETLIB))pic/$(notdir $(TARGETLIB))
> +TARGETLIB_NOASAN = $(dir $(TARGETLIB))noasan/$(notdir $(TARGETLIB))
Is it OK to use GNU make features in libiberty now? That is, do binutils
and GDB now require GNU make?
--
On 09.05.2015 0:54, Jeff Law wrote:
>
> Both patches are approved. Please install onto the trunk.
>
> jeff
>
Sorry for delay. When I started to work on this task, I wrote that I'll
test the patches on couple of other platforms (not just x86). Probably I
should have done it earlier, because I m
On 05/10/2015 10:59 AM, Jan Hubicka wrote:
This patch introduces option -fno-plt that allows to expand calls that would
go via PLT to load the address of the function immediately at call site (which
introduces a GOT load). Cover letter explains the motivation for this patch.
New option document
On 05/08/2015 06:04 PM, James Bowman wrote:
Are you using LRA or reload? The former is definitely preferred and for
a simple target like this, I'd expect the transition to be very easy.
I'm using reload. Attempting to naively switch on LRA resulted in
internal compiler error: Max. number
All,
this patch adds the ability to build PIE executables for FreeBSD. The
core is since a longer time in the code base of FreeBSD itself and is
working fine.
This patch makes it available for all FreeBSD targets.
Tested on x86_64-*-freebsd11.0 and armv6/hf-*-freebsd11.0,
i386-*-freebsd11.0
On Mon, May 11, 2015 at 08:16:41PM +, Matthew Fortune wrote:
> Does this patch effectively change the canonicalization rules? The following
> Still exists in md.texi:
>
> @item
> Within address computations (i.e., inside @code{mem}), a left shift is
> converted into the appropriate multiplicat
Jeff Law writes:
> On 05/11/2015 01:46 PM, Jeff Law wrote:
> > On 05/11/2015 01:44 PM, Steve Ellcey wrote:
> >> On Mon, 2015-05-11 at 13:22 -0500, Segher Boessenkool wrote:
> >>> Hi Steve,
> >>>
> >>> On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
> This patch broke a number of
On 05/06/2015 03:47 AM, Thomas Preud'homme wrote:
Ping?
Something to consider as future work -- I'm pretty sure PRE sets up the
same kind of problematical pattern with a new pseudo (reaching reg)
holding the result of the redundant expression and the original
evaluations turned into copies fro
> On 05/11/2015 01:46 PM, Uros Bizjak wrote:
> >On Mon, May 11, 2015 at 8:00 PM, Jan Hubicka wrote:
> >>>On Sun, 10 May 2015, Jan Hubicka wrote:
> >>>
> >On i386, peepholes that transform memory load and register-indirect jump
> >into
> >memory-indirect jump are overly restrictive in
On 05/11/2015 01:46 PM, Jeff Law wrote:
On 05/11/2015 01:44 PM, Steve Ellcey wrote:
On Mon, 2015-05-11 at 13:22 -0500, Segher Boessenkool wrote:
Hi Steve,
On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
This patch broke a number of MIPS tests, specifically mips32r6 tests
that lo
On 05/11/2015 01:46 PM, Uros Bizjak wrote:
On Mon, May 11, 2015 at 8:00 PM, Jan Hubicka wrote:
On Sun, 10 May 2015, Jan Hubicka wrote:
On i386, peepholes that transform memory load and register-indirect jump into
memory-indirect jump are overly restrictive in that they don't allow combining
w
On Mon, May 11, 2015 at 8:00 PM, Jan Hubicka wrote:
>> On Sun, 10 May 2015, Jan Hubicka wrote:
>>
>> > > On i386, peepholes that transform memory load and register-indirect jump
>> > > into
>> > > memory-indirect jump are overly restrictive in that they don't allow
>> > > combining
>> > > when t
On 05/11/2015 01:44 PM, Steve Ellcey wrote:
On Mon, 2015-05-11 at 13:22 -0500, Segher Boessenkool wrote:
Hi Steve,
On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
This patch broke a number of MIPS tests, specifically mips32r6 tests
that look for the lsa instruction (load scaled a
On Mon, May 11, 2015 at 4:45 AM, Ramana Radhakrishnan
wrote:
> sorry about the slow response, I was travelling for a bit and missed your
> emails. Trying your patch out gives me failures possibly because my mail
> client munged it when it received this inline.
>
> Can you please rebase if necessa
On Mon, 2015-05-11 at 13:22 -0500, Segher Boessenkool wrote:
> Hi Steve,
>
> On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
> > This patch broke a number of MIPS tests, specifically mips32r6 tests
> > that look for the lsa instruction (load scaled address) which shifts one
> > regis
On 05/08/2015 03:41 PM, David Malcolm wrote:
I want to make the timevar infrastructure be more flexible,
to better serve some JIT use-cases.
The following is a "removal of global state" patch which gathers
together the state within timevar.c into a new "timer" class.
Within the classic cc1/cc1p
On 05/11/2015 03:05 AM, Richard Sandiford wrote:
Thomas pointed out that, while I'd kept the code to validate patterns
for things like missing modes, the code wasn't being used. Fixed with
the patch below.
I ended up reinstating the original code to create a single rtx
pattern for a define_peep
On 05/11/2015 06:02 AM, David Sherwood wrote:
Hi,
This patch fixes a couple of issues I saw during the compilation of shell_lam.f
for 410.bwaves test in spec2006:
* create_new_invariant: We shouldn't bother attempting to calculate the address
cost for something that clearly isn't an address. Us
On 05/11/2015 12:14 PM, Manuel López-Ibáñez wrote:
On 11 May 2015 at 17:54, Marek Polacek wrote:
I'm sorry to sound so "pedantic" but we have faced this same issue in
the past (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19976#c7) and
the solution was to delay folding
(https://gcc.gnu.org/ml/g
> >Bootstrapped/regtested x86_64-linux, OK?
> >
> >Honza
> >
> > * c-decl.c (pushtag): Declare type as public.
> What I'm struggling with here is how do you know the stub decl is
> public? I realize these things are a bit special, but I don't see
> the C++ front-end doing anything similar. Wh
On 05/10/2015 11:33 AM, Jan Hubicka wrote:
Hi,
TREE_PUBLIC of TYPE_DECL is defined to say if the type is public:
/* In a VAR_DECL, FUNCTION_DECL, NAMESPACE_DECL or TYPE_DECL,
nonzero means name is to be accessible from outside this translation unit.
In an IDENTIFIER_NODE, nonzero means an
Hi Steve,
On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
> This patch broke a number of MIPS tests, specifically mips32r6 tests
> that look for the lsa instruction (load scaled address) which shifts one
> register and then adds it to a second register. I am not sure if this
> needs
On Sun, 10 May 2015 21:08:04 +, Paulo Matos wrote:
> Somehow I never added myself to the MAINTAINERS file.
> Apologies for that. OK to commit?
>
> 2015-05-10 Paulo Matos
>
> * MAINTAINERS: Add myself as commit after approval.
>
> diff --git a/MAINTAINERS b/MAINTAI
On Sun, 10 May 2015, Segher Boessenkool wrote:
> > This clearly renames rather than removing the `rlwinm' pattern, please
> > correctly reflect that in ChangeLog. Some other, unnamed patterns are
> > given names rather than deleted as well, just as you've noted at the top.
> > And none of th
On 11 May 2015 at 17:54, Marek Polacek wrote:
> The problem here isn't in the -Wshift-negative-value warning itself; the
> problem is with marking -1 << 0 as a non-constant: later on, we warn in
> a context where a constant expression is needed ("initializer element is
> not a constant expression"
On Sun, 10 May 2015 22:07:53 -0600, Jeff Law wrote:
> On 05/10/2015 03:00 PM, Paulo Matos wrote:
> Yes. This would fall under the obvious rule and can be committed
> without waiting for approvals.
>
> jeff
Thanks. Committed.
--
Paulo Matos
> On 05/11/2015 12:46 PM, Jan Hubicka wrote:
> >Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to handle
> >enums. But other case I would like to deal with are integer types - i.e.
> >preserve
> >difference between char/signed char/unsigned char/short/int/long/wchar in
> >case
On 05/11/2015 12:57 PM, Jason Merrill wrote:
On 05/11/2015 08:03 AM, Manuel López-Ibáñez wrote:
My preference would be to replace the static with a pointer and
placement-new with proper new and delete
Actually, on second thought, there really doesn't seem to be a need for
that. The patch sho
> On Sun, 10 May 2015, Jan Hubicka wrote:
>
> > > On i386, peepholes that transform memory load and register-indirect jump
> > > into
> > > memory-indirect jump are overly restrictive in that they don't allow
> > > combining
> > > when the jump target is loaded into %eax, and the called function
On 05/11/2015 08:03 AM, Manuel López-Ibáñez wrote:
My preference would be to replace the static with a pointer and
placement-new with proper new and delete, but see:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00910.html
Agreed.
Jason
On Sat, 9 May 2015, Bernd Edlinger wrote:
> But maybe you would like it better if we update, for instance, to:
> automake-1.14 _and_ autoconf-2.69 ?
Updating to current automake and autoconf release versions (but still
using git versions of the toplevel scripts, not those from particular
rele
On 05/11/2015 12:46 PM, Jan Hubicka wrote:
Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to handle
enums. But other case I would like to deal with are integer types - i.e.
preserve
difference between char/signed char/unsigned char/short/int/long/wchar in cases
where they str
On Sun, 10 May 2015, Jan Hubicka wrote:
> > On i386, peepholes that transform memory load and register-indirect jump
> > into
> > memory-indirect jump are overly restrictive in that they don't allow
> > combining
> > when the jump target is loaded into %eax, and the called function returns a
> >
On Thu, 2015-05-07 at 11:01 +, Kumar, Venkataramanan wrote:
> Hi Segher,
>
> Thank you I committed as r222874.
> Ref: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222874
>
> Regards,
> Venkat.
Venkat,
This patch broke a number of MIPS tests, specifically mips32r6 tests
that loo
> On 05/11/2015 09:28 AM, Jan Hubicka wrote:
> >We already discussed earlier that type_in_anonymous_namespace_p is not
> >working
> >on compund types, because these do not have TYPE_STUB_DECL. I thought those
> >are
> >!TYPE_NAME types. What is reason for !TYPE_NAME type with no TYPE_STUB_DECL?
On 05/11/2015 07:13 AM, Segher Boessenkool wrote:
There already was code to just use the original reg:CC, but it was
positioned incorrectly: if the original code (that this RTL is
simplified from) did not already start with a COMPARE (or not in
the right mode), it didn't trigger. But it is valid
On 05/11/2015 07:23 AM, Andreas Krebbel wrote:
The current implementation re-uses the location of the selection
pattern to generate a new one. This fails if the pattern resides in a
read-only location. With the patch a new temporary register is
allocated for that purpose.
gcc/
* optabs
On 05/11/2015 06:38 AM, Jan Hubicka wrote:
-TYPE_METHODS (type) = chainon (TYPE_METHODS (type), fn);
+TYPE_METHODS (type) = chainon (TYPE_METHODS (TYPE_MAIN_VARIANT (type)),
fn);
else
{
- DECL_CHAIN (fn) = TYPE_METHODS (type);
- TYPE_METHODS (type) = fn;
+ DECL_C
2015-05-11 9:07 GMT+03:00 Sivanupandi, Pitchumani
:
>> -Original Message-
>> From: Denis Chertykov [mailto:cherty...@gmail.com]
>> Sent: Sunday, May 10, 2015 12:55 PM
>> To: Sivanupandi, Pitchumani
>> Cc: Georg-Johann Lay; GCC Patches
>> Subject: Re: [patch, avr] extend part-clobbered check
On 05/11/2015 09:28 AM, Jan Hubicka wrote:
We already discussed earlier that type_in_anonymous_namespace_p is not working
on compund types, because these do not have TYPE_STUB_DECL. I thought those are
!TYPE_NAME types. What is reason for !TYPE_NAME type with no TYPE_STUB_DECL?
Is it always a c
On 05/11/2015 07:40 AM, Andreas Krebbel wrote:
With this patch GCC implements an Altivec style set of builtins to
make use of vector instructions in C/C++ code. This is provided for
compatibility with the IBM XL compiler.
gcc/
* config.gcc: Add vecintrin.h to extra_headers. Add s390-c.
On 05/11/2015 07:23 AM, Andreas Krebbel wrote:
gcc/testsuite/
* lib/target-supports.exp: Vector do not always have natural
alignment on s390*.
OK.
jeff
On 05/11/2015 07:23 AM, Andreas Krebbel wrote:
gcc/testsuite/
* gcc.dg/tree-ssa/gen-vect-11b.c: Disable vector
instructions on s390*.
* gcc.dg/tree-ssa/gen-vect-11c.c: Likewise.
Fine with me. Seems to me that generally adding a clause like this to a
test ought to fall
On 05/11/2015 07:23 AM, Andreas Krebbel wrote:
With the vector facility support z13 mov patterns have more than 30
alternatives.
gcc/
* recog.h: Increase MAX_RECOG_ALTERNATIVES.
---
gcc/recog.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/recog.h b/gcc/re
> What I was confused about is that the first set isn't valid rtl.
> The SET_SRC and SET_DEST always have to have the same mode
> (or VOIDmode in the case of a CONST_INT, etc., where the mode
> is implicitly the same as the SET_DEST). So wouldn't it have
> to be:
>
> (set (reg:SI 1)
>(
On May 11, 2015, at 4:05 AM, sameera wrote:
>>> +(define_insn "*join2_loadhi"
>>> + [(set (match_operand:SI 0 "register_operand" "=r")
>>> + (any_extend:SI (match_operand:HI 1 "non_volatile_mem_operand" "m")))
>>> + (set (match_operand:SI 2 "register_operand" "=r")
>>> + (any_extend:SI (mat
On Mon, 11 May 2015, Marek Polacek wrote:
> Is the following any better? Thanks,
Yes, this looks fine.
(I admit that "flexible array member-like arrays" confused me a bit,
but that's probably me not fully getting standards language. ;-)
Gerald
Hello!
2015-05-11 Uros Bizjak
* config/i386/i386.c (ix86_loop_unroll_adjust): Use PATTERN (insn)
when looking for memory references.
Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/i386.c
=
Hi!
On Tue, 05 May 2015 10:54:02 +0200, I wrote:
> In follow-up messages, I'll be posting the separated parts (for easier
> review) of a next set of OpenACC changes that we'd like to commit.
> ChangeLog updates not yet written; will do that before commit, obviously.
In order for us to be able to
On Mon, May 11, 2015 at 6:25 PM, Alexander Monakov wrote:
>> >>> LEGACY_REGS, which causes IRA not to consider it separately for register
>> >>> allocation, even when it has lower cost than other classes. This patch
>> >>> is
>> >>> useful to fix code generation problem that appears with no-PLT
On Sun, 10 May 2015, Uros Bizjak wrote:
> On Sun, May 10, 2015 at 7:51 PM, Uros Bizjak wrote:
> > On Sun, May 10, 2015 at 6:44 PM, Jan Hubicka wrote:
> >>> On 32-bit x86, register class CLOBBERED_REGS is a proper subset of
> >>> LEGACY_REGS, which causes IRA not to consider it separately for regi
The runtime/pprof package builds stack traces that skip runtime
functions. When libgo is compiled with -O0, the function profilealloc
appears on the stack trace, but the package doesn't know to skip it.
Rename the function so that it is skipped. This lets the
runtime/pprof test pass when libgo is
On Mon, May 11, 2015 at 06:04:48PM +0200, Gerald Pfeifer wrote:
> Hi Marek,
>
> On Mon, 11 May 2015, Marek Polacek wrote:
> > Ok to commit?
>
> as maintainer I am happy for you to commit documentation/web changes
> without approval, though I am also happy to review.
I was hoping you could glance
On Sun, 10 May 2015, Jan Hubicka wrote:
> You probably need to update comment here. I wonder what happens when we
> optimize
> indirect call to direct call to global function at RTL level? I suppose we are
> safe here, because at RTL level we explicitly represent if we refer to PLT
> entry
> or t
Hi Marek,
On Mon, 11 May 2015, Marek Polacek wrote:
> Ok to commit?
as maintainer I am happy for you to commit documentation/web changes
without approval, though I am also happy to review.
> +General Optimizer Improvements
> +
> +UndefinedBehaviorSanitizer gained a new sanitization option:
> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Monday, May 11, 2015 12:02 PM
> To: gcc-patches@gcc.gnu.org
> Cc: matthew.fort...@imgtec.com; Moore, Catherine
> Subject: [patch, MIPS, testsuite] Fix gcc.target/mips/branch-1.c
>
> The test gcc.target/mips/bra
On 2015.05.11 at 17:54 +0200, Marek Polacek wrote:
> On Mon, May 11, 2015 at 05:09:26PM +0200, Manuel López-Ibáñez wrote:
> > On 11/05/15 16:21, Marek Polacek wrote:
> > >The -Wshift-negative-value patch caused grief since it breaks building
> > >some programs. The following patch should alleviate
The test gcc.target/mips/branch-1.c has started failing because it is trying
to verify that each of 4 functions generates and 'andi' instruction and only
finding 2 of them. With a recent change (fixing PR 65150) GCC determined that
the f1 and f2 functions generate identical code and that the f3 an
Hi,
pinging this...
On 04/30/2015 01:56 AM, Paolo Carlini wrote:
Hi,
this seems pretty straightforward given the grammar. Tested x86_64-linux.
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01948.html
Paolo.
On Mon, May 11, 2015 at 05:09:26PM +0200, Manuel López-Ibáñez wrote:
> On 11/05/15 16:21, Marek Polacek wrote:
> >The -Wshift-negative-value patch caused grief since it breaks building
> >some programs. The following patch should alleviate the pain a bit: mark
> >a left shift of a negative value a
On Sun, May 10, 2015 at 12:13 PM, Segher Boessenkool
wrote:
> The next patch removes the zero_extract insn this splits to. Write
> it as (and (lshiftrt ... instead.
>
> Okay for trunk?
>
>
> Segher
>
>
> 2015-05-10 Segher Boessenkool
>
> * config/rs6000/rs6000.md (define_split for bswa
On Sun, May 10, 2015 at 12:13 PM, Segher Boessenkool
wrote:
> Some cleanups:
>
> * Give every define_insn a name;
> * Add missing conditions for some of the dot forms;
> * Use define_insn_and_split to reduce duplication;
> * Renumber operands so 0,1,2,3 are the actual operands of the machine
> i
On 11/05/15 14:05, Jakub Jelinek wrote:
> On Mon, May 11, 2015 at 01:39:17PM +0100, Szabolcs Nagy wrote:
>> fyi, musl loader loads libstdc++ just fine because it has no
>
> But will it load any shared library that uses any of the 26 (if I count well
> on x86_64) @ symbols from libstdc++.so.6?
i
On Sun, May 10, 2015 at 12:13 PM, Segher Boessenkool
wrote:
> The next patch will rename the "rlwinm" pattern (as well as the other patterns
> that implement rlwinm, now unnamed). The only place that uses gen_rlwinm
> (an expander) is better off expanding the separate operations separately.
> Do
On Sun, May 10, 2015 at 12:13 PM, Segher Boessenkool
wrote:
> After the change to combine, we no longer need all the special-case
> patterns.
>
> Tested on powerpc64-linux, as usual. As mentioned with the combine
> patch, there are no differences to generated code in cc1.
>
> This does not delete
On 11-05-15 09:47, Richard Biener wrote:
Bootstrapped and reg-tested on x86_64, with and without -m32.
>
>OK for trunk?
>
>[ FWIW, I suspect this patch will make life easier for the reimplementation of
>the pass_stdarg optimization using ifn_va_arg. ]
+ if (canon_va_type != NULL)
+{
+
On 11/05/15 16:21, Marek Polacek wrote:
The -Wshift-negative-value patch caused grief since it breaks building
some programs. The following patch should alleviate the pain a bit: mark
a left shift of a negative value as non-const only if pedantic.
Either this is not correct according to the gu
Ok to commit?
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.3
diff -u -r1.3 changes.html
--- changes.html6 May 2015 09:55:29 - 1.3
+++ changes.html11 May
On 05/11/2015 04:01 PM, Segher Boessenkool wrote:
> On Mon, May 11, 2015 at 03:23:29PM +0200, Andreas Krebbel wrote:
>> With the vector facility support z13 mov patterns have more than 30
>> alternatives.
>
> Wow, that is a lot!
>
>> --- a/gcc/recog.h
>> +++ b/gcc/recog.h
>> @@ -23,7 +23,7 @@ alo
Jason,
I got my firefox tree building again and noticed that my patch to enable
ODR merging on non-class types caused false positives:
/aux/hubicka/trunk-install/include/c++/6.0.0/ext/new_allocator.h:66:26:
warning: type ‘(anonymous namespace)::ObservationWithStack const&’ violates one
definitio
The -Wshift-negative-value patch caused grief since it breaks building
some programs. The following patch should alleviate the pain a bit: mark
a left shift of a negative value as non-const only if pedantic.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-05-11 Marek Polacek
On Mon, May 11, 2015 at 01:48:03PM +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 6 May 2015, Rich Felker wrote:
>
> > I don't see how this case is improved unless GCC is failing to consider
> > strong definitions in the same TU as locally-binding.
>
> Interposition of non-static non-inline non-w
On Mon, May 11, 2015 at 12:31:51PM +0200, Jakub Jelinek wrote:
> On Mon, May 11, 2015 at 11:20:15AM +0100, Szabolcs Nagy wrote:
> >
> >
> > On 09/05/15 19:57, Szabolcs Nagy wrote:
> > > * H.J. Lu [2015-05-09 10:41:41 -0700]:
> > >> There are
> > >>
> > >> 4: 2b70 806 FUNCG
> >Would you be OK with a slight variation of your earlier idea, i.e.
> >calling fold_stmt with a specific valueizer from fold_marked_statements
> >instead of the implicit no_follow_ssa_edges in the inliner? Something
> >like:
> >
> >tree
> >follow_anonymous_single_use_edges (tree val)
> >{
> >
>
On Mon, May 11, 2015 at 03:23:29PM +0200, Andreas Krebbel wrote:
> With the vector facility support z13 mov patterns have more than 30
> alternatives.
Wow, that is a lot!
> --- a/gcc/recog.h
> +++ b/gcc/recog.h
> @@ -23,7 +23,7 @@ along with GCC; see the file COPYING3. If not see
> /* Random nu
With this patch GCC implements an Altivec style set of builtins to
make use of vector instructions in C/C++ code. This is provided for
compatibility with the IBM XL compiler.
gcc/
* config.gcc: Add vecintrin.h to extra_headers. Add s390-c.o to
c_target_objs and cxx_target_objs.
On 11/05/15 03:34, Patrick Palka wrote:
In gcc/cp/error.c we initialize the C++ pretty printer object twice:
first during statics initialization and later in a placement-new in
init_error(). This double-initialization causes a memory leak of about
7kb according to valgrind. I don't see a reason
gcc/
* config/s390/constraints.md (j00, jm1, jxx, jyy, v): New
constraints.
* config/s390/predicates.md (const0_operand, constm1_operand)
(constable_operand): Accept vector operands.
* config/s390/s390-modes.def: Add supported vector modes.
* config/s
gcc/testsuite/
* gcc.target/s390/s390.exp
(check_effective_target_vector): New check.
* gcc.target/s390/vector/vec-abi-1.c: New test.
* gcc.target/s390/vector/vec-abi-2.c: New test.
* gcc.target/s390/vector/vec-abi-3.c: New test.
* gcc.target/s390/vec
gcc/testsuite/
* gcc.target/s390/zvector/vec-dbl-math-compile-1.c: New test.
* gcc.target/s390/zvector/vec-genbytemask-1.c: New test.
* gcc.target/s390/zvector/vec-genmask-1.c: New test.
* gcc.target/s390/zvector/vec-lcbb-1.c: New test.
* gcc.target/s390/zvec
gcc/testsuite/
* lib/target-supports.exp: Vector do not always have natural
alignment on s390*.
---
gcc/testsuite/lib/target-supports.exp |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-sup
1 - 100 of 147 matches
Mail list logo
