On Sun, Oct 16, 2016 at 05:05:17PM -0500, Daniel Santos wrote:
> >>The insn that's getting deleted is 75, where RCX is set. I'm starting
> >>to think that maybe df_analyze() presumes that my call (to the stub) is
> >>invalidating RCX, although it does not.
> >It looks like you don't use add_functi
Hi Nicolai,
On Fri, Nov 11, 2016 at 12:03:44AM +0100, Nicolai Stange wrote:
> in the course of doing some benchmarks on arm with -Os, I noticed that
> some list traversion code became significantly slower since gcc 5.3 when
> instruction caches are cold.
But is it smaller? This tiny example func
Hi Nicolai,
On Fri, Nov 11, 2016 at 02:16:18AM +0100, Nicolai Stange wrote:
> >> >From the discussion on gcc-patches [1] of what is now the aforementioned
> >> r228318 ("bb-reorder: Add -freorder-blocks-algorithm= and wire it up"),
> >> it is not clear to me whether this change can actually reduce
On Wed, Nov 16, 2016 at 01:48:41PM -0700, Martin Sebor wrote:
> I'm also curious if there really is a policy/convention for dealing
> with exceptions in GCC, what it actually is/says.
https://gcc.gnu.org/codingconventions.html#Exceptions
Segher
On Wed, Dec 07, 2016 at 06:27:56PM +0100, Florian Weimer wrote:
> >> > When I am writing a test with noinline + noclone then my
> >> > expectation is that no such propagation happens, because
> >> > otherwise a test might turn trivial...
> >>
> >> The usual ways to prevent that are to add some vol
Hi Claudiu,
On Mon, Dec 19, 2016 at 12:28:54PM +, Claudiu Zissulescu wrote:
> I have the following rtl before asmcons pass:
>
> (insn 8 13 9 2 (set (reg:SI 157 [ list ])
> (asm_operands:SI ("") ("=g") 0 [
> (const:SI (unspec:SI [
> (symbol_r
On Thu, Dec 22, 2016 at 03:28:56PM +0100, Ulrich Weigand wrote:
> However, there still seems to be a problem, but this time related to
> alignment issues. We do have the 16-byte atomic instructions, but they
> only work on 16-byte aligned data. This is a problem in particular
> since the default
On Wed, Jan 04, 2017 at 10:05:49AM +0100, Richard Biener wrote:
> > The code size is identical, but the trunk version executes one more
> > instruction everytime the loop runs (explicit jump to .L5 with trunk vs
> > fallthrough with 4.8) - it's faster only if the loop never runs. This
> > happens i
On Thu, Jan 05, 2017 at 05:18:46PM +0100, Aurelien Buhrig wrote:
> The issue happens when reloading:
>
> (set (reg:QI 47 [ _9 ])
> (mem:QI (plus:SI (reg/v/f:SI 68 [orig:51 in ] [51])
> (const_int 1 [0x1])
>
> My understanding is that IRA allocates hardregs to allocno which are
>
On Fri, Jan 06, 2017 at 11:26:40AM +0100, Aurelien Buhrig wrote:
> > Look at the dump file for reload to see where things come from. Also
> > everything Jeff said; you really want LRA.
>
> I will try switching to LRA in a second step, but I think I need first to
> remove the old cc0...
:-)
> B
On Tue, Jul 22, 2014 at 08:44:41AM +0100, Richard Sandiford wrote:
> So why
> not just stick to the current scheme and have 5.0.0, 5.0.1, 5.0.2 etc.?
Yes, why would we use a different numbering scheme now? There is no change
in development / release planning, unless I missed something. Is this j
On Tue, Aug 05, 2014 at 01:32:00PM +0930, Alan Modra wrote:
> On Mon, Aug 04, 2014 at 05:54:04PM -0700, Carrot Wei wrote:
> > Another problem is in the definition of insn pattern "*movdi_internal64".
> >
> > (define_insn "*movdi_internal64"
> > [(set (match_operand:DI 0 "nonimmediate_operand"
>
On Tue, Aug 12, 2014 at 04:16:34PM +0100, Kyrill Tkachov wrote:
> >I managed to get combine to recognise this pattern:
> >(set (match_operand:GPI 0 "register_operand" "=r")
> > (plus:GPI (xor:GPI (neg:GPI (match_operand:GPI 1
> >"register_operand" "r"))
> > (mat
On Wed, Aug 13, 2014 at 03:57:31PM +0100, Richard Earnshaw wrote:
> The problem with the frankenmonster patterns is that they tend to
> proliferate into the machine description, and before you know where you
> are the back-end is full of them.
>
> Furthermore, they are very sensitive to the greedy
On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote:
> I've been considering that too, but not sure what info people find valuable
> and what they don't.
The ten million "Running blablablalba.exp ..." messages on a very parallel
run aren't helpful in my opinion. There might be more but
On Mon, Sep 22, 2014 at 05:49:12PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 22, 2014 at 10:44:06AM -0500, Segher Boessenkool wrote:
> > On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote:
> > > I've been considering that too, but not sure what info people find
&
On Thu, Oct 02, 2014 at 09:52:31PM +0200, Jan-Benedict Glaw wrote:
> It seems that a full bootstrap including Ada got broken somewhere in
> the range of r215789 .. r215799.
I'm bisecting it (on powerpc64-linux, where it also shows up); it needs
full bootstrapping every time, so will be another one
On Thu, Oct 02, 2014 at 07:32:10PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 02, 2014 at 09:52:31PM +0200, Jan-Benedict Glaw wrote:
> > It seems that a full bootstrap including Ada got broken somewhere in
> > the range of r215789 .. r215799.
>
> I'm bisecting it (on
On Thu, Oct 23, 2014 at 06:52:20PM +0100, Charles Baylis wrote:
> ( tl;dr: How do I handle intrinsic or builtin functions where there
> are restrictions on the arguments which can't be represented in a C
> function prototype? Do other ports have this problem, how do they
> solve it? Language extens
On Thu, Nov 13, 2014 at 01:14:41PM +0100, Richard Biener wrote:
> It might be that RTL alias analysis / CSE give up too early here
> (we don't optimize across asm() on the GIMPLE level at all ... heh).
>
> I didn't look where it gives up (even though appearantly it does).
The cse1 pass doesn't ca
On Tue, Nov 25, 2014 at 08:18:39AM -0800, David Kang wrote:
> (define_expand "fix_sfsi2"
The proper name is "fixsfsi2", no underscore. You might want
"fix_truncsfsi2" instead though.
Segher
On Tue, Nov 25, 2014 at 10:45:06AM -0800, David Kang wrote:
> Is the logical operators described similarly?
> I tried "seqf2", "cmpseqf2", and "one_cmplseqf2" for "eq" of two floating
> point numbers as it is shown below.
> But none of them work.
>
> (define_expand "seqf2"
> [(set (match_
On Thu, Dec 11, 2014 at 03:13:50PM +0800, Bin.Cheng wrote:
> So I am wondering if I can rely on INSN_LUID checking orders of
> difference instruction. If it can be done, I can easily differentiate
> live range shrink and extend.
> Further question is, if we don't insert new insns, can I use INSN_L
ss :-P
Cheers,
Segher
>From 1c1ebc41fca45f497e019a5ab433c68d23010f31 Mon Sep 17 00:00:00 2001
Message-Id:
<1c1ebc41fca45f497e019a5ab433c68d23010f31.1422864485.git.seg...@kernel.crashing.org>
From: Segher Boessenkool
Date: Sat, 12 Oct 2013 15:41:50 -0700
Subject: [PATCH] Make mergeable read
On Thu, Mar 12, 2015 at 03:09:52PM -0700, David Wohlferd wrote:
> Ahh. So perhaps as I suspected: this is more commonly used on non-i386
> platforms. So clearly removing this is out of the question.
glibc uses it for PowerPC and s390 at least (I only grepped for "3",
quotes included -- there ma
On Fri, Mar 13, 2015 at 05:54:48PM +0300, Max Filippov wrote:
> 2. alloca seems to make an additional 16-bytes padding to each stack
> allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17)
> moves it by 48 bytes, etc.
This sounds like PR 50938, 47353, 34548, maybe more? Happ
On Fri, Mar 13, 2015 at 11:36:47PM +0300, Max Filippov wrote:
> >> 2. alloca seems to make an additional 16-bytes padding to each stack
> >> allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17)
> >> moves it by 48 bytes, etc.
> >
> > This sounds like PR 50938, 47353, 34548, m
On Fri, Mar 13, 2015 at 03:56:38PM -0500, Segher Boessenkool wrote:
> On Fri, Mar 13, 2015 at 11:36:47PM +0300, Max Filippov wrote:
> > >> 2. alloca seems to make an additional 16-bytes padding to each stack
> > >> allocation: alloca(1) results in moving sp
On Fri, Apr 03, 2015 at 09:25:57AM -0600, Jeff Law wrote:
> On 04/03/2015 07:45 AM, Diego Novillo wrote:
> >Not quite. The output of the debug dumpers is not really meant to be fed
> >back to the compiler. They are debug dumps only. They do not contain
> >enough information for code generation or a
On Tue, Apr 21, 2015 at 12:27:40AM +0200, Steven Bosscher wrote:
> On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote:
> > I might be wrong but I think you have a bloated code because you use
> > scratches. I already told several times that usage of scratch is always a
> > bad idea. It was
On Tue, Apr 21, 2015 at 11:55:33PM -0400, Vladimir Makarov wrote:
> >The combiner can add or remove clobbers of scratches whenever needed,
> >but it cannot do that for clobbers of pseudos.
> >
> Yes, I think there are some pitfalls with scratches in other passes.
Probably. But this one is documen
On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote:
> (1) Each target defines a set of constraint strings,
> (2) A new target hook post-processes the asm_insn, looking for the
> new constraint strings. The hook expands the condition prescribed
> by the string, adjusting the
On Tue, May 05, 2015 at 08:37:01AM -0700, Linus Torvalds wrote:
> On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool
> wrote:
> >
> > Since it is pre-processed, there is no real reason to overlap this with
> > the constraints namespace; we could have e.g. "=@[xy]
On Thu, May 21, 2015 at 08:06:04PM +0930, Alan Modra wrote:
> FAIL: gcc.target/powerpc/ti_math1.c scan-assembler-times adde 1
> is seen on powerpc64le-linux since somewhere between revision 218587
> and 218616. See
> https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg01287.html and
> https://gcc.gn
On Thu, May 21, 2015 at 11:34:14AM -0700, Richard Henderson wrote:
> On 05/21/2015 05:39 AM, Segher Boessenkool wrote:
> >> > Trying 18, 9 -> 24:
> >> > Failed to match this instruction:
> >> > (set (reg:DI 4 4 [+8 ])
> >> > (plus:DI (plu
On Fri, May 22, 2015 at 11:48:42AM +0930, Alan Modra wrote:
> > I think we should add to
> > the canonicalisation rules so that fixed regs sort after other regs.
> > That requires a lot of testing.
>
> What if you have two hard regs as above? Which of reg 5 and reg 76
> sorts first? If they are
On Fri, May 29, 2015 at 12:09:42AM +0930, Alan Modra wrote:
> It's really annoying when you fix a combine bug and get worse code..
Heh. You've been on the receiving end of that a lot lately :-/
> void foo (signed char *p) { if (*p != 0) *p = 1; }
>
> before after
> foo:
On Fri, May 29, 2015 at 12:41:20PM +0930, Alan Modra wrote:
> I'll tell you one of the reasons why they are
> slower, as any decent hardware engineer could probably figure this out
> themselves anyway. The record form instructions are cracked into two
> internal ops, the basic arithmetic/logic op,
On Fri, May 29, 2015 at 11:20:08PM +0930, Alan Modra wrote:
> On Fri, May 29, 2015 at 07:58:38AM -0500, Segher Boessenkool wrote:
> > On Fri, May 29, 2015 at 12:41:20PM +0930, Alan Modra wrote:
> > > +/* Describe how rtl operations on registers behave on this target when
>
On Sat, May 30, 2015 at 10:47:27AM +0930, Alan Modra wrote:
> > > > I think this is too simplistic though. For example, AND with -7 is not
> > > > zero-extended (rlwinm rD,rA,0,31,28 sets the high 32 bits of rD to the
> > > > low
> > > > 32 bits of rA).
> > >
> > > We take some pains in rs6000.m
On Mon, Jun 01, 2015 at 11:33:18AM +0930, Alan Modra wrote:
> Unifying andsi_mask with anddi_mask, and the fact that constraints for
> const_int see VOIDmode rather than the operand mode is why we get
> rldicr rather than rlwinm. Easily fixed by separating the si/di
> patterns, and with a little m
On Tue, Jun 02, 2015 at 08:49:37AM +0930, Alan Modra wrote:
> > > In and3 expander I think you want the following since
> > > and64_2_operand covers the extra double-rotate cases, not all DImode.
> > >
> > > - if ((mode == DImode && !and64_2_operand (operands[2],
> > > mode))
> > > - || (mo
Hi Joel,
On Tue, Aug 28, 2018 at 04:21:25PM -0500, Joel Sherrill wrote:
> Just wanting to confirm with someone PowerPC knowledgeable that
> the -mspe option was indeed removed on the master and the
> documentation needs to be updated to reflect this.
I don't see it listed in the PowerPC options a
On Mon, Aug 20, 2018 at 11:01:29AM -0600, Jeff Law wrote:
> On 08/20/2018 10:50 AM, Paul Koning wrote:
> > The internals manual seems to say that memory subregs are an old mechanism
> > that should still work, give or take. If indeed it breaks LRA perhaps the
> > documentation should be updated
Hi Claudiu,
On Tue, Sep 04, 2018 at 11:11:44AM +0200, Claudiu Zissulescu wrote:
> I am trying to get LRA fully working for ARC, but I've got an issue.
> Whenever, LRA analyses an instruction having (clobber
> (match_scratch:SI 3 "=X, ...)) in its pattern I hit the assert in
> lra-constraints.c:410
On Tue, Aug 28, 2018 at 05:34:31PM -0500, Joel Sherrill wrote:
> Is dropping the -mno-spe option with gcc 8 and lower equivalent to the
> current gcc master? We had it in some BSPs and I don't want them to
> break with gcc 8.
For *-linux targets (so no "spe" in there), -mno-spe was the default
alr
Hi!
On Wed, Oct 10, 2018 at 08:55:12PM -0400, Paul Koning wrote:
[ snip ]
> Note that this isn't permitted by the .md file -- the mode is wrong (QI not
> HI).
Other targets use an expander and check the mode explicitly in there. See
rs6000 or sh for example.
> It's not obvious to me how that
On Thu, Oct 18, 2018 at 09:48:22AM -0500, Aaron Sawdey wrote:
> On 10/17/18 4:03 PM, Florian Weimer wrote:
> I'm aware of this. One thing that will help is that I believe the vsx
> expansion for strcmp/strncmp does not have this problem, so with
> current gcc9 trunk the problem should only be seen
Hi Umesh,
On Fri, Oct 26, 2018 at 12:22:37PM +0530, Umesh Kalappa wrote:
> Cced maintainer like David Edelsohn and Segher Boessenkool .
I did see the mail, even started writing a reply, but I got lost in it.
> Any suggestions/comments for the below query ?
No, I have no idea what it mean
On Sun, Oct 28, 2018 at 01:39:16PM -0400, Paul Koning wrote:
> I was reviewing some back end code that handles integer values of various
> sizes, and got confused reading about CONST_INT and CONST_DOUBLE.
>
> It's pretty clear that CONST_DOUBLE is used for values bigger than
> HOST_WIDE_INT. Bu
On Wed, Oct 31, 2018 at 02:20:38PM -0400, Paul Koning wrote:
> I see some test cases that say dg-add-options ieee. That apparently means:
> pretend we have IEEE float even when the target does not.
It means:
(from testsuite/lib/target-supports.exp)
===
# Add to FLAGS all the target-specific fl
Hi Peter,
On Thu, Nov 01, 2018 at 07:49:36PM -0500, Peter Bergner wrote:
> On 11/1/18 7:25 PM, Paul Koning wrote:
> > I'm running the testsuite on the pdp11 target, and I get a failure when
> > using LRA that works correctly with the old allocator. The issue is that
> > LRA is producing an insn
Hi Paulo,
On Tue, Nov 06, 2018 at 09:35:35PM +0100, Paulo Matos wrote:
> I remember from awhile ago that there's some option (or there was...)
> that gets GCC to print some register allocation information together
> with the assembler output.
>
> I am interested in obtaining the live registers pe
On Wed, Nov 07, 2018 at 08:52:15AM +0100, Paulo Matos wrote:
> On 07/11/2018 00:40, Segher Boessenkool wrote:
> > -fdump-rtl-alignments[-all] is the last dump with all that information I
> > think. This one also has all this info without -all it seems. With -all
> > it show
On Wed, Nov 07, 2018 at 09:49:02PM +0100, Paulo Matos wrote:
> On 07/11/2018 20:27, Segher Boessenkool wrote:
> > Sure, it shows the register information at the edges of basic blocks
> > only. This is what you asked for btw ;-)
>
> True, but I need a way to map that inform
On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
> The internal RTL should not be dictating what the target arch can or
> cannot implement. Reload should insert any needed conversions,
> especially ones which narrow the size.
Well, that depends. A zero_extract of mem is only defi
On Wed, Nov 21, 2018 at 08:52:21AM -0800, Michael Eager wrote:
> On 11/21/2018 08:33 AM, Segher Boessenkool wrote:
> >On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
> >>The internal RTL should not be dictating what the target arch can or
> >>cannot imple
Hi Arseny,
On Fri, Nov 23, 2018 at 06:15:47PM +0700, Arseny Solokha wrote:
> I've found recently that rs6000 and powerpcspe backends can easily trip over
> various gcc_unreachable()'s and gcc_assert()'s in their respective copies of
> print_operand() when provided with some invalid assembly (i.e.
Hi!
On Mon, Nov 26, 2018 at 08:41:24AM +0700, Arseny Solokha wrote:
> > On Fri, Nov 23, 2018 at 06:15:47PM +0700, Arseny Solokha wrote:
> >> I've found recently that rs6000 and powerpcspe backends can easily trip
> >> over
> >> various gcc_unreachable()'s and gcc_assert()'s in their respective co
On Wed, Dec 05, 2018 at 02:19:14AM +0100, Stefan Kanthak wrote:
> "Paul Koning" wrote:
>
> > Yes, that's a rather nasty cut & paste error I made.
>
> I suspected that.
> Replacing
> !(den & (1L<<31))
> with
> (signed short) den >= 0
> avoids this type of error: there's no need for a cons
On Fri, Dec 07, 2018 at 05:57:39PM +, Andrew Stubbs wrote:
> Since the postreload_jump pass was added I'm having trouble with the AMD
> GCN port.
[ snip a lot ]
It seems thread_jump does not notice your scc in its "nonequal" regset,
so it thinks every later jump is based on the same scc sett
On Mon, Dec 10, 2018 at 02:05:57PM +, Andrew Stubbs wrote:
> On 07/12/2018 22:41, Segher Boessenkool wrote:
> >On Fri, Dec 07, 2018 at 05:57:39PM +, Andrew Stubbs wrote:
> >>Since the postreload_jump pass was added I'm having trouble with the AMD
> >&
Hi!
On Tue, Dec 11, 2018 at 12:02:42PM +0200, Claudiu Zissulescu wrote:
> This issue still keeps biting me, specially in the glibc upstreaming
> process. I have made a bugzilla entry for this
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001) where I also
> added my solution for the given issu
Hi!
On Thu, Dec 13, 2018 at 09:39:52AM +, senthilkumar.selva...@microchip.com
wrote:
> When debugging PR 88253, I found that force_to_mode uses a parameter
> (just_select) to prevent the function from returning a const0_rtx even
> if none of the bits set by the rtx are needed. The comme
On Fri, Dec 14, 2018 at 06:32:32AM +, senthilkumar.selva...@microchip.com
wrote:
> Segher Boessenkool writes:
> > On Thu, Dec 13, 2018 at 09:39:52AM +,
> > senthilkumar.selva...@microchip.com wrote:
> >> When debugging PR 88253, I found that force_
Hi!
On Sat, Dec 29, 2018 at 10:41:54AM +0300, Alexander Monakov wrote:
> On Sat, 29 Dec 2018, Bin.Cheng wrote:
> > tracer-1.c: Assembler messages:
> > tracer-1.c:16: Error: symbol `foo_label' is already defined
> >
> > Root cause is in tracer.c which duplicates basic block without
> > checking if
Hi Daniel,
Some mostly boring comments:
On Fri, Jan 04, 2019 at 09:25:10PM +0100, Daniel Marjamäki wrote:
> The first reason is the hard problem, but maybe we can ignore this now also:
>
> void f()
> {
> } // <- looking at the indentation, it seems preferable to warn about
> this
> }
I th
On Mon, Jan 07, 2019 at 09:29:09AM +0100, Richard Biener wrote:
> On Sun, 6 Jan 2019, Jan Hubicka wrote:
> > Even though it is late in release cycle I wonder if we can do that for
> > GCC 9? Performance of vectorization is very architecture specific, I
> > would propose enabling vectorization for
On Sat, Jan 05, 2019 at 06:02:08PM +0100, Daniel Marjamäki wrote:
> > I think the indentation warnings should catch that?
>
> I get this:
>
> void f()
> {
> }
> } // <- error: expected identifier or '(' before '}' token
>
> I ran with -Wall -Wextra -pedantic and did not see a indentation
> war
Hi!
On Mon, Jan 14, 2019 at 09:53:18PM +, Steve Ellcey wrote:
> I have a question about PR87763, these are aarch64 specific tests
> that are failing after r265398 (combine: Do not combine moves from hard
> registers).
>
> These tests are all failing when the assembler scan looks for
> specifi
Hi!
On Mon, Jan 14, 2019 at 12:24:43PM +, Matthew Malcomson wrote:
> I've found a testcase where the stack protector code generated through
> `-fstack-protector-all` doesn't actually protect anything.
[ snip ]
> When compiling on aarch64 with
> ~gcc -fstack-protector-all -g -S stack-reorder.
On Sun, Jan 27, 2019 at 01:19:08PM -0800, Andrew Pinski wrote:
> On Sun, Jan 27, 2019 at 1:02 PM Thomas König wrote:
> >
> > Am 27.01.19 um 21:52 schrieb Steve Kargl:
> >
> > > In fact, I would be in favor of removing -Wall, as it is misnamed,
> > > in favor of -Wlevel=0,1,2,3... -Wlevel=0 defaul
OneWed, Feb 13, 2019 at 07:13:21AM +, Peng Fan wrote:
> We met an issue when building a piece jailhouse hypervisor code, "stxr %w0,
> %3, %2\n\t" is
> compiled as "stxr w4,x5,[x4]" which triggers the warning
> "Warning: unpredictable: identical transfer and status registers"
This is not a
On Wed, Feb 20, 2019 at 10:08:07AM -0600, Peter Bergner wrote:
> On 2/19/19 9:09 PM, Alan Modra wrote:
> > On Mon, Feb 18, 2019 at 01:13:31PM -0600, Peter Bergner wrote:
> >> long input;
> >> long
> >> bug (void)
> >> {
> >> register long output asm ("r3");
> >> asm ("blah %0, %1, %2" : "=&r" (
On Thu, Feb 21, 2019 at 05:16:48PM -0600, Peter Bergner wrote:
> About the only usage of register asm that is guaranteed, is their
> usage in inline asm. If you specify a hard register for a variable
> and then use that variable in an inline asm, you are guaranteed
> that that variable will use th
Hi!
On Mon, Feb 25, 2019 at 06:32:53PM +, Michael Matz wrote:
> On Thu, 21 Feb 2019, Segher Boessenkool wrote:
> > > That said, the "bug" in the case we're seeing, is that asmcons rewrote
> > > all of "input"'s pseudos, and it should be
Hi!
On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote:
> Forcing "stolen_key" to be zero initialised does not help anyone -
> options for that just make code slower and hide errors that would occur
> with other compiler options. The challenge is to make sure /key/ is
> zeroed out aft
On Tue, Mar 05, 2019 at 09:36:56PM +0100, David Brown wrote:
> On 05/03/2019 19:37, Segher Boessenkool wrote:
> >On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote:
> >>void foo(void) {
> >> char key[20];
> >> strcpy(key, "Top secret")
On Sat, Mar 09, 2019 at 08:30:19AM +, Jonathan Wakely wrote:
> On Sat, 9 Mar 2019, 02:23 Eric Gallager, wrote:
> > How would it handle the case where the parameter name is missing
> > entirely from the prototype? I see a lot of header files with their
> > prototypes written like that.
> >
> >
On Wed, Mar 20, 2019 at 10:13:23AM +, Justin Paston-Cooper wrote:
> Section 6.2.5.2 outlines the line number information state machine's
> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition
> is:
>
> -
> The DW_LNS_set_epilogue_begin opcode takes no operands. It sets the
>
On Tue, Apr 30, 2019 at 03:48:02PM -0600, Jeff Law wrote:
> On 4/30/19 11:24 AM, Matthew Malcomson wrote:
> > That was why I ended up suggesting multiple notes -- it's currently
> > trying to satisfy more than one criteria and they're not quite compatible.
> Well, we obviously have to keep arg set
On Thu, May 02, 2019 at 01:02:14PM +, Matthew Malcomson wrote:
> On 01/05/19 20:40, Segher Boessenkool wrote:
> > On Tue, Apr 30, 2019 at 03:48:02PM -0600, Jeff Law wrote:
> >> On 4/30/19 11:24 AM, Matthew Malcomson wrote:
> >>> That was why I ended up sug
On Thu, May 02, 2019 at 02:17:51PM +0200, Richard Biener wrote:
> On Tue, Apr 30, 2019 at 9:53 PM Jeff Law wrote:
> > This is loop unswitching. It's a standard GCC optimization. If it's
> > not working as well as it should, we're far better off determining why
> > and fixing the automatic transf
On Thu, May 02, 2019 at 03:47:33PM +0200, Rainer Orth wrote:
> I've now tested this RC on i386-pc-solaris2.1[01] and
> sparc-sun-solaris2.1[01]. The only issue (apart from the just-fixed
> spellcheck-options-5.c testcase) is
>
> +FAIL: gcc.target/i386/pr90178.c scan-assembler-times xorl[t
>
On Thu, May 02, 2019 at 08:41:29PM +0200, Rainer Orth wrote:
> Hi Segher,
>
> > On Thu, May 02, 2019 at 03:47:33PM +0200, Rainer Orth wrote:
> >> I've now tested this RC on i386-pc-solaris2.1[01] and
> >> sparc-sun-solaris2.1[01]. The only issue (apart from the just-fixed
> >> spellcheck-options-
On Fri, May 03, 2019 at 09:29:11AM +, Matthew Malcomson wrote:
> On 02/05/19 16:33, Segher Boessenkool wrote:
> > Because other things want to use it as the place to put stack checking,
> > for example. And that cannot be after this note, but it can also not
> > be b
On Mon, May 06, 2019 at 04:01:58PM +0300, Алек�1557147755�й Хилаев via gcc
wrote:
> Gcc riscv won`t emit my insns, binutils and spike(riscv sim) work correctly,
> but gcc don`t. I want to add min/max for integer, gcc compiling correct, sim
> executing correctly.
>
> (define_insn "*min_"
> [(set
On Sun, May 12, 2019 at 03:53:53PM +0100, Iain Sandoe wrote:
> Right now, we don’t install a “cc” [we install gcc] but we do install “c++”
> [ we also install g++, of course].
>
> Some configure scripts (and one or two places in the testsuite) do try to
> invoke ‘cc’ which can lead to inconsis
Hi Umesh,
Please spell out "global entry point", almost everything and everyone does.
On Wed, May 15, 2019 at 08:57:29PM +0530, Umesh Kalappa wrote:
> .set.LTHUNK0,_ZN12Intermediate1vEv
> _ZThn8_N12Intermediate1vEv:
> .LCF2:
> 0: addis 2,12,.TOC.-.LCF2@ha
> addi 2,2,.TO
On Wed, May 15, 2019 at 08:31:27PM +0200, Eric Botcazou wrote:
> > Thank you Eric for the suggestion and say that we support in the loader
> > part ,can you please point on elfv2 reference that says implementation for
> > this specific case.
>
> I don't think there is a reference to this specific
Hi Umesh,
On Thu, May 16, 2019 at 06:12:48PM +0530, Umesh Kalappa wrote:
> We are very new to Power abi and we are thinking to handle this case
> in loader like go through the relocations like R_PPC64_REL24 and
> found symbol has the localentry ,then compute the delta (GEP - LEP )
> and patch t
On Mon, May 20, 2019 at 04:19:54PM +0930, Alan Modra wrote:
> On Thu, May 16, 2019 at 05:52:42PM -0500, Segher Boessenkool wrote:
> > Hi Umesh,
> >
> > On Thu, May 16, 2019 at 06:12:48PM +0530, Umesh Kalappa wrote:
> > > We are very new to Power abi and we ar
On Mon, May 20, 2019 at 05:48:52PM +0930, Alan Modra wrote:
> On Mon, May 20, 2019 at 02:55:33AM -0500, Segher Boessenkool wrote:
> > On Mon, May 20, 2019 at 04:19:54PM +0930, Alan Modra wrote:
> > > On Thu, May 16, 2019 at 05:52:42PM -0500, Segher Boessenkool wrote:
> >
On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
> Interesting, I was also puzzled for a moment. But notice that:
>
> int main ()
> {
> _Float128 x = 18446744073709551617.5f128;
> _Float128 y = __builtin_roundf128 (x);
> }
>
> behaves as expected... the difference is of cou
On Fri, May 31, 2019 at 12:11:18PM +0200, Martin Jambor wrote:
> On Thu, May 30 2019, Segher Boessenkool wrote:
> > On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
> >> Interesting, I was also puzzled for a moment. But notice that:
> >>
> >> int
On Sat, Jun 01, 2019 at 11:41:30PM +, Fredrik Hederstierna wrote:
> +(define_peephole2
> + [(set (match_operand:SI 0 "arm_general_register_operand" "")
> + (match_operand:SI 1 "arm_general_register_operand" ""))
> + (set (reg:CC CC_REGNUM)
> + (compare:CC (match_dup 0) (const_int
On Wed, Jun 05, 2019 at 02:25:59PM +0100, Jozef Lawrynowicz wrote:
> I'm assuming it would not be valid to modify the behaviour of __extension__
> so it can be placed within a declaration, and not just at the
> beginning. However, there is minimal documentation on this keyword (it does
> not
> sta
On Wed, Jun 05, 2019 at 08:49:39PM +0100, Jozef Lawrynowicz wrote:
> On Wed, 5 Jun 2019 11:49:21 -0500
> Segher Boessenkool wrote:
> > The documentation says
> >
> > '-pedantic' and other options cause warnings for many GNU C extensions.
> >
On Wed, Jun 05, 2019 at 05:02:53PM -0600, Jeff Law wrote:
> On 6/2/19 6:28 AM, Segher Boessenkool wrote:
> > On Sat, Jun 01, 2019 at 11:41:30PM +, Fredrik Hederstierna wrote:
> >> +(define_peephole2
> >> + [(set (match_operand:SI 0 &q
201 - 300 of 685 matches
Mail list logo
