On 03/22/2015 09:31 AM, Joel Sherrill wrote:
On 03/20/2015 07:18 AM, Richard Biener wrote:
We've come a long way towards the release criteria of zero P1 bugs.
I thought I would pass along a couple of data points from
the *-rtems targets.
Fourteen *-rtems target build OK on the head. The foll
On 03/26/2015 08:32 AM, Erik Varga wrote:
Hi all,
I've submitted my proposal to the GSoC website, it can be found here: [1]
After hearing some ideas from Oleg, I decided to go with working on
detecting and optimizing a few specific memory access patterns instead
of implementing a PBQP solver.
An
Sorry for the delay on this. I've been swamped with non-GCC things for
the last month or so...
I'm pleased to announce that James Greenhalgh has been appointed as a
reviewer for the AArch64 port and that Kyrylo Tkachov has been appointed
as a reviewer for the ARM port.
James & Kyrylo, if yo
On 04/02/2015 03:39 AM, Bin.Cheng wrote:
Hi,
In function make_compound_operation, the code/comment says:
case ASHIFT:
/* Convert shifts by constants into multiplications if inside
an address. */
if (in_code == MEM && CONST_INT_P (XEXP (x, 1))
&& INTVAL (XEXP (x,
On 03/31/2015 09:34 AM, Trevor Saunders wrote:
On Thu, Mar 26, 2015 at 03:15:22PM +0100, Richard Biener wrote:
On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong wrote:
I think the gimple front end project would be quite useful to gcc so I’d like
to do work on it this summer.
The problem is, it se
On 04/03/2015 07:45 AM, Diego Novillo wrote:
On 04/02/15 11:59, xue yinsong wrote:
I suppose our goal is to translate the dumped program back to
the C source code (otherwise we can simply retain the gotos and
labels since they are already `valid’ in C). In this case we have to
convert the goto
On 04/03/2015 09:30 AM, Diego Novillo wrote:
On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong wrote:
So it’s better not to try to read the exact dump format.
Could we use a similar but more complete syntax instead?
Absolutely. The initial attempt for gimple fe was to use a tuple-based
syntax tha
On 04/03/2015 09:41 AM, Diego Novillo wrote:
On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote:
I was hesitant to offer this option, but it's certainly a good
starting point. The representation encodes CFG, SSA, attributes,
declarations and annotations. It has a relatively fixed syntax,
On 04/17/2015 03:57 AM, Shiva Chen wrote:
Hi,
I think the rtl dump in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916
is not jump2 phase rtl dump.
Because jump2 is after ira, the register number should be hardware
register number.
the jump2 rtl dump should as follow
...
31: NOTE_INSN_B
On 03/10/2015 07:40 AM, BELBACHIR Selim wrote:
Me again :)
I enhanced my patch because it was not generalized for instructions with N
delay_slots.
Mostly OK, though there are some formatting nits that need to be corrected.
We have whitespace around arithmetic, logical and comparison operators
On 04/19/2015 09:28 AM, Ajit Kumar Agarwal wrote:
Hello All:
To reduce the register pressure, I am proposing the following methods of
reducing the registers.
1. Assigning same registers or sharing same register for the logical registers
having the same value.
To determine the logical register
On 04/20/2015 05:08 AM, BELBACHIR Selim wrote:
I've attached the fixed version of the patch. I've tested it on the trunk with
my private target.
I can't provide a test because apparently no backend (other than my private
one) uses delay slots with more that 1 slot.
I was also unable to test th
I'm pleased to announce that Segher Boessenkool has been appointed as
maintainer for instruction combiner (combine.c).
Segher, can you please add yourself to the MAINTAINERS file for the
additional role.
Thanks,
jeff
On 04/20/2015 01:09 AM, Shiva Chen wrote:
Hi, Jeff
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump
pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump
after patch can_replace_by.patch
On 04/22/2015 06:28 AM, Andrew MacLeod wrote:
On 04/22/2015 08:19 AM, Jakub Jelinek wrote:
On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
Is anyone else seeing comparison problems on trunk?
I was having problems testing a patch on a 4/16 extraction, so last
night I
checked out
On 04/18/2015 04:19 AM, Jan Kratochvil wrote:
On Fri, 17 Apr 2015 17:22:13 +0200, Jan Kratochvil wrote:
How to get 'volatile struct sv' GCC 'tree' type for:
volatile struct sv { volatile struct sv *p; };
I have found out how it can work, even with no change on the GCC side:
Instead of
On 03/18/2015 01:21 PM, Oleg Endo wrote:
On Tue, 2015-03-17 at 22:31 -0600, Jeff Law wrote:
I'm not a big fan of keeping the FOR_EACH_blah style iterator and would
prefer to use real C++ iterators. But it ought to give you some ideas
about how to start breaking these things out.
BTW
On 04/27/2015 10:12 AM, Alan Lawrence wrote:
After copyrename3, immediately prior to dom1, the loop body looks like:
:
:
# i_11 = PHI
_5 = a[i_11];
_6 = i_11 & _5;
if (_6 != 0)
goto ;
else
goto ;
:
:
# m_2 = PHI <5(4), 4(3)>
_7 = m_2 * _5;
b[i_1
On 04/27/2015 01:06 PM, Adrian Chadd wrote:
Hi!
I'd like to contribute some FreeBSD patches to gcc. I believe I have
to sign some copyright assignment stuff. What do I need?
Please contact ass...@gnu.org. They ought to be able to get you the
appropriate paperwork.
Jeff
On 04/28/2015 08:36 AM, Alan Lawrence wrote:
Ah, yes, I'd not realized this was connected to the jump-threading
issue, but I see that now. As you say, the best heuristics are unclear,
and I'm not keen on trying *too hard* to predict what later phases
will/won't do or do/don't want...maybe if the
On 05/05/2015 07:27 AM, Renlin Li wrote:
Hi all,
For the following illustrative code,
double f1(int x) { return (double)(float)x; } --> return (double)x;
int f2(double x) { return (int)(float)x; } --> return (int)x;
Is it Okay for the compiler to do the simplifications shown above with
fast-ma
On 05/06/2015 05:11 AM, Richard Biener wrote:
On Wed, May 6, 2015 at 2:56 AM, wrote:
On 05/05/2015 08:27 AM, Renlin Li wrote:
Hi all,
For the following illustrative code,
double f1(int x) { return (double)(float)x; } --> return (double)x;
int f2(double x) { return (int)(float)x; } --> retu
On 05/11/2015 10:19 AM, Georg-Johann Lay wrote:
When pass outof_cfglayout is adding barriers, it appears that it misses
some situations and then runs into "ICE: missing barrier" in the
remainder (or, with checking disabled, into some other assertion).
[ ... ]
The last else is entered for a
On 05/12/2015 08:58 AM, Georg-Johann Lay wrote:
Am 05/11/2015 um 10:43 PM schrieb Steven Bosscher:
On Mon, May 11, 2015 at 7:37 PM, Georg-Johann Lay wrote:
BTW, what's the policy about unconditional jumps at that time? There
are
plenty of unconditional jumps around and all are legitimate; just
On 05/13/2015 06:30 AM, Georg-Johann Lay wrote:
hmmm, it would actually lead to valid machine code: The jump table is
actually a dispatch table, i.e. it contains a list of direct jumps to
the case labels. casesi loads the value of the label associated with
the jump table into a register, add
On 05/17/2015 10:21 AM, Jon Beniston wrote:
Hi,
The gccint docs for pre_modify/post_modify say that the address modifier
must be one of three forms:
(plus:m x z), (minus:m x z), or (plus:m x i), where z is an index register
and i is a constant.
Why isn’t (plus:m x (mult:m z i)) supported, for
On 05/21/2015 01:08 PM, Vladimir Makarov wrote:
On 05/21/2015 05:54 AM, Ilya Enkovich wrote:
Thanks. For me it looks like an inheritance bug. It is really hard
>to fix the bug w/o the source code. Could you send me your patch in
>order I can debug RA with it to investigate more.
>
Sure! Here
On 05/25/2015 09:27 AM, Ilya Enkovich wrote:
2015-05-22 15:01 GMT+03:00 Ilya Enkovich :
2015-05-22 11:53 GMT+03:00 Ilya Enkovich :
2015-05-21 22:08 GMT+03:00 Vladimir Makarov :
So, Ilya, to solve the problem you need to avoid sharing subregs for the
correct LRA/reload work.
Thanks a lot fo
On 05/16/2015 06:49 AM, Ajit Kumar Agarwal wrote:
I have Designed and implemented with the following design for the path
splitting of the loops with conditional IF-THEN-ELSE.
The implementation has gone through the bootstrap for Microblaze target along
DEJA GNU regressions tests and
running th
On 05/29/2015 06:57 PM, DJ Delorie wrote:
In config/s390/s390.c we accept addresses that are SImode:
if (!REG_P (base)
|| (GET_MODE (base) != SImode
&& GET_MODE (base) != Pmode))
return false;
However, there doesn't seem to be anything in the s390's opcode
On 06/01/2015 06:23 AM, Andreas Krebbel wrote:
On 05/30/2015 02:57 AM, DJ Delorie wrote:
In config/s390/s390.c we accept addresses that are SImode:
if (!REG_P (base)
|| (GET_MODE (base) != SImode
&& GET_MODE (base) != Pmode))
return false;
However, there
On 06/01/2015 12:51 PM, Lev Yudalevich wrote:
While working on a custom backend for quite a standard RISC-like
architecture, I defined 'high'/'lo_sum' patterns as follows:
(define_insn "mov_high"
[(set (match_operand:SI 0 "register_operand" "=r")
(high:SI (match_operand:SI 1 "immed
On 06/02/2015 05:22 AM, Andrew Bennett wrote:
Hi,
I am debugging a segmentation fault when compiling some code for MIPS. The
segmentation fault occurs in the plus_constant function in explow.c when it
tries to update a constant pool value. The offending code is below:
case MEM:
/* If t
On 06/02/2015 12:35 AM, Ajit Kumar Agarwal wrote:
I don't offhand know if any of the benchmarks you cite above are free-enough to
derive a testcase from. But one trick many of us use is to instrument the
>>pass and compile some known free software (often gcc
itself) to find triggering code and
On 06/02/2015 09:57 AM, Kyrill Tkachov wrote:
I'm stuck on noce_process_if_block (in ifcvt.c) and what I think is a
restriction that the THEN-block contents have to be only a single set
insn. This fails on aarch64 because we get an extra zero_extend.
In particular, the following check in noce_pr
On 06/02/2015 09:32 AM, Andreas Krebbel wrote:
Bootstrap failed with:
/home/andreas/clean/../gcc/gcc/dwarf2out.c: In function ‘constant_size’:
/home/andreas/clean/../gcc/gcc/dwarf2out.c:6572: error: insn does not satisfy
its constraints:
(insn 39 38 66 6 /home/andreas/clean/../gcc/gcc/toplev.h:
On 05/27/2015 07:20 AM, Ilya Enkovich wrote:
I looked into assign_stack_local_1 call for this spill. LRA correctly
requests 16 bytes size with 16 bytes alignment. But
assign_stack_local_1 look reduces alignment to 8 because estimated
stack alignment before RA is 8 and requested mode's (DI) align
I'm pleased to announce James Bowman has been appointed as the
maintainer for the FT32 port.
James, can you please add yourself to the MAINTAINERS file.
Thanks,
Jeff
On 06/04/2015 06:33 AM, Jakub Jelinek wrote:
On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
Again is this worth a gcc pass?
This isn't a matter of compiler passes; it's additional checks in existing
built-in function handling. Maybe that built-in function handling should
move t
On 08/28/2018 05:40 PM, Segher Boessenkool wrote:
> 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
On 08/31/2018 09:41 AM, Matthew Malcomson wrote:
> Hi there,
>
> I'm looking into whether it's possible to require even numbered
> registers on
> modes that need more than one hard-register to represent them. But only in
> some cases.
>
> The problem is the one mentioned explicitly here
> https:/
On 9/20/18 11:38 AM, Martin Sebor wrote:
> On 09/20/2018 08:08 AM, Vincent Lefevre wrote:
>> On 2018-09-17 10:03:48 -0600, Martin Sebor wrote:
>>> On 09/17/2018 06:00 AM, Umesh Kalappa wrote:
Hi All,
When we try to compile the below case from trunk gcc we get the below
warning (
On 10/1/18 2:20 AM, Richard Biener wrote:
> On Fri, Sep 28, 2018 at 7:08 PM Cory Fields wrote:
>>
>> gcc_qsort as introduced by Alexander Monakov [0] in trunk for 9.x is a
>> great change that defines the order of otherwise-unbalanced internal
>> sorts, some of which would otherwise cause bootstra
On 10/4/18 6:05 AM, Anthony Green wrote:
>
> My builds from HEAD are failing unless I remove these tests. Are these
> invalid tests?
>
> diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c
> index 9444a35cb54..e64ee7e5660 100644
> --- a/gcc/opt-suggestions.c
> +++ b/gcc/opt-suggestions.c
On 10/5/18 7:04 AM, Andrew Stubbs wrote:
> I just tracked down a "reload" bug and was very surprised to find that
> can_create_pseudo_p doesn't return false during register allocation when
> using LRA.
>
> It's still defined like this:
>
> #define can_create_pseudo_p() (!reload_in_progress && !re
On 10/7/18 1:06 PM, Nadav Amit wrote:
> at 9:46 AM, Richard Biener wrote:
>
>> On October 7, 2018 6:09:30 PM GMT+02:00, Nadav Amit wrote:
>>> at 2:18 AM, Borislav Petkov wrote:
>>>
Hi people,
this is an attempt to see whether gcc's inline asm heuristic when
estimating inline
On 10/23/18 11:05 AM, Paul Koning wrote:
>
>
>> On Oct 23, 2018, at 6:08 AM, Richard Biener
>> wrote:
>>
>> On Tue, Oct 23, 2018 at 2:39 AM Paul Koning wrote:
>>>
>>> In running the gcc testsuite on pdp11, I get some failures like this:
>>>
>>> collect2: fatal error: /Users/pkoning/Documents/s
On 10/31/18 3:27 PM, Rainer Orth wrote:
> Hi Paul,
>
>>> On Oct 31, 2018, at 4:11 PM, Rainer Orth
>>> wrote:
>>>
>>> Hi Paul,
>>>
Ok, thanks. So adding a dg-skip-if for my target is indeed correct.
Will do so.
>>>
>>> please don't: since this is going to be common, please add a
>>> co
On 11/15/18 3:29 AM, Richard Biener wrote:
>
>> 2. Did I correctly understand the goal of the parallelization? Can
>> anyone provide extra details to me?
>
> You may want to search the mailing list archives since we had a
> student application (later revoked) for the task with some discussion.
>
On 11/20/18 11:07 AM, Michael Eager wrote:
> On 11/18/2018 08:14 AM, Jeff Law wrote:
>> On 11/18/18 8:44 AM, Michael Eager wrote:
>>> On 11/16/18 14:50, Segher Boessenkool wrote:
>>>> Hi!
>>>>
>>>> On Wed, Nov 14, 2018 at 11:22:58AM -0800, M
On 11/23/18 12:31 PM, Martin Sebor wrote:
> GCC currently accepts the declaration of f0 below but ignores
> the attribute. On aarch64 (and I presume on other targets with
> a default function alignment greater than 1), GCC rejects f1
> with an error, even though it accepts -falign-functions=1
> wi
On 11/28/18 10:00 AM, Michael Eager wrote:
> I have a small test case which generates poor quality code on my target.
> Here is the original:
>
> if (cond1 == 2048 || cond2 == 8)
> {
> x = x + y;
> }
> return x;
>
> This ends up generating a series of instructions to compute a f
On 11/28/18 10:47 AM, Michael Eager wrote:
> On 11/28/18 09:10, Jeff Law wrote:
>> On 11/28/18 10:00 AM, Michael Eager wrote:
>>> I have a small test case which generates poor quality code on my target.
>>> Here is the original:
>>>
>>> if (cond1 =
On 11/28/18 11:39 AM, Martin Sebor wrote:
> On 11/28/18 6:35 AM, Richard Biener wrote:
>> On Tue, Nov 27, 2018 at 3:52 AM Martin Sebor wrote:
>>>
>>> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01759.html
>>>
>>> If there are no objections or suggestions for tweaks I'll commit
>>> this upd
On 11/27/18 11:57 AM, Martin Sebor wrote:
> On 11/26/18 3:37 PM, Jeff Law wrote:
>> On 11/23/18 12:31 PM, Martin Sebor wrote:
>>> GCC currently accepts the declaration of f0 below but ignores
>>> the attribute. On aarch64 (and I presume on other targets with
>&
On 11/21/18 9: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 implement. Reload should insert any needed conversions,
>> especially ones which narrow the size.
>
>
On 11/30/18 12:39 AM, Richard Biener wrote:
> On Wed, Nov 28, 2018 at 6:10 PM Jeff Law wrote:
>>
>> On 11/28/18 10:00 AM, Michael Eager wrote:
>>> I have a small test case which generates poor quality code on my target.
>>> Here is the original:
>>
On 11/30/18 9:14 AM, Jakub Jelinek wrote:
> On Fri, Nov 30, 2018 at 09:08:34AM -0700, Jeff Law wrote:
>>> Sth I don't like very much... maybe we can revisit removing
>>> the few cases in fold-const.c (thus GENERIC folding) and rely
>>> on later GIMPLE pass
On 11/29/18 8:34 AM, Martin Sebor wrote:
>
> GCC does disallow decreasing the function alignment -- but only
> for functions that were already declared with a more restrictive
> one. Like this:
>
> __attribute__ ((aligned (4))) void f (void);
>
> __attribute__ ((aligned (2))) void f (void);
On 12/6/18 5:02 PM, Andi Kleen wrote:
> Radu Ometita writes:
>
>> Hello everyone!
>>
>> We are working on writing a paper about testing the reliability of C
>> compilers by using Csmith (a random C99 program generator).
>>
>> A previous testing effort, using Csmith, found 79 GCC bugs, and 25 of
On 12/18/18 8:36 AM, Richard Biener wrote:
>
> Hi,
>
> in the past weeks I've been looking into prototyping both spectre V1
> (speculative array bound bypass) diagnostics and mitigation in an
> architecture independent manner to assess feasability and some kind
> of upper bound on the performanc
On 1/14/19 9:39 AM, Paolo Carlini wrote:
> Hi,
>
> On 14/01/19 17:28, Jakub Jelinek wrote:
>> I think several testcases check for duplicate error messages, the
>> regexp is
>> against the whole text, so you can just check if it occurs more than once
>> there.
>
> This is essentially https://gcc.g
On 2/22/19 4:29 AM, Richard Biener wrote:
>
> GCC builds are currently not reproducible because for one the checksum
> we compute for PCH purposes (by genchecksum) nowaways includes checksums
> of archives (since we switched from checksumming a dummy executable
> to checksumming object files). Th
On 2/28/19 10:05 AM, Qing Zhao wrote:
> Hi,
>
> I have been debugging a runtime error caused by value range propagation. and
> finally located to the following gcc routine:
>
> vrp_meet_1 in gcc/tree-vrp.c
>
>
> /* Meet operation for value ranges. Given two value ranges VR0 and
>VR1,
On 3/3/19 4:06 PM, Patrick Palka wrote:
> Hi everyone,
>
> I am very interested in working on GCC as part of GSoC this year. A few years
> ago I was a somewhat active code contributor[1] and unfortunately my
> contributing waned once I went back to school, but I'm excited to potentially
> have th
On 3/1/19 10:49 AM, Qing Zhao wrote:
> Jeff,
>
> thanks a lot for the reply.
>
> this is really helpful.
>
> I double checked the dumped intermediate file for pass “dom3", and
> located the following for _152:
>
> BEFORE the pass “dom3”, there is no _152, the corresponding Block
> looks lik
On 3/4/19 4:45 AM, Richard Biener wrote:
> On Fri, Mar 1, 2019 at 10:02 PM Qing Zhao wrote:
>>
>>
>> On Mar 1, 2019, at 1:25 PM, Richard Biener
>> wrote:
>>
>> On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao
>> wrote:
>>
>> Jeff,
>>
>> thanks a lot for the reply.
>>
>> this is really helpful.
On 3/5/19 7:44 AM, Richard Biener wrote:
> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> the MAX_EXPR introduced by folding makes it somewhat ugly.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Any ideas how to make it less so? I can split o
On 3/12/19 2:50 PM, Eric Gallager wrote:
> On 3/12/19, Martin Liška wrote:
>> Hi.
>>
>> I've thinking about the file split about quite some time, mainly
>> in context of PR84402. I would like to discuss if it's fine for
>> maintainers of the target to make such split and into which logical
>> comp
On 3/6/19 3:05 AM, Richard Biener wrote:
> On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
>>
>> On 3/5/19 7:44 AM, Richard Biener wrote:
>>
>>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
>>> the MAX_EXPR
On 3/25/19 10:39 AM, Martin Sebor wrote:
> On 3/23/19 9:49 PM, nick wrote:
>> Greetings all,
>> I just got this in my build output:
>> ar: `u' modifier ignored since `D' is the default (see `U')
>> configure: WARNING: cannot check for properly working vsnprintf when
>> cross compiling, will assume
On 3/31/19 11:25 AM, Paul Koning wrote:
>
>
>> On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote:
>>
>> hi folks,
>>
>> i was interesting in tackling some problems gcc netbsd/vax has.
>> it has some ICEs which are in reload phase. searching around, the answer
>> to that is "switch to LRA first". N
On 4/1/19 12:57 AM, claz...@gmail.com wrote:
> Hi,
>
> I would like to apply the ARC specific fix for bugzilla 89877 to
> include/longlong.h file, but I don't know for sure if I am allowed or
> not. I mention that I am the ARC reviewer.
If it's in ARC specific bits within longlong.h, then yes, you
On 4/2/19 3:46 AM, Ulrich Weigand wrote:
> Hello,
>
> the spu-elf target in GCC supports generating code for the SPU processors
> of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
>
> However, at this point I believe this target is no longer in use:
> - There is no suppor
On 4/2/19 10:49 AM, Eric Gallager wrote:
> On 4/2/19, Ulrich Weigand wrote:
>> Hello,
>>
>> the spu-elf target in GCC supports generating code for the SPU processors
>> of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
>>
>> However, at this point I believe this target is
On 4/4/19 6:24 AM, Martin Jambor wrote:
> Hello Bryan,
>
> On Wed, Apr 03 2019, Bryan Carroll wrote:
>> Hi,
>>
>> I know my first email is vague. I wanted to throw it out there since
>> the April 9th deadline is coming up.
>
> I was hoping Jakub Jelinek, who would be the mentor, would chime in
>
On 4/5/19 2:50 PM, Eric Botcazou wrote:
>> Say if the first bootstrap succeeds and I then change a single
>> GCC .c file and rerun make bootstrap, am I guaranteed to see
>> the same fallout of the change as I would if I did a pristine
>> build in a clean directory?
>
> No, this would imply deletin
On 4/5/19 3:37 PM, Martin Sebor wrote:
> On 4/5/19 3:29 PM, Jeff Law wrote:
>> On 4/5/19 2:50 PM, Eric Botcazou wrote:
>>>> Say if the first bootstrap succeeds and I then change a single
>>>> GCC .c file and rerun make bootstrap, am I guaranteed to see
>>
On 4/8/19 3:19 AM, Richard Biener wrote:
> On Sat, Apr 6, 2019 at 1:09 AM Martin Sebor wrote:
>>
>> On 4/5/19 4:02 PM, Jeff Law wrote:
>>> On 4/5/19 3:37 PM, Martin Sebor wrote:
>>>> On 4/5/19 3:29 PM, Jeff Law wrote:
>>>>> On 4/5/19 2:5
On 4/1/19 6:40 PM, Patrick Palka wrote:
> On Sun, Mar 3, 2019 at 5:16 PM Jeff Law wrote:
>>
>> On 3/3/19 4:06 PM, Patrick Palka wrote:
>>> Hi everyone,
>>>
>>> I am very interested in working on GCC as part of GSoC this year. A few
>>> years
On 4/2/19 2:11 AM, Peter Sewell wrote:
> Dear all,
>
> continuing the discussion from the 2018 GNU Tools Cauldron, we
> (the WG14 C memory object model study group) now
> have a detailed proposal for pointer provenance semantics, refining
> the "provenance not via integers (PNVI)" model presented
On 4/18/19 6:50 AM, Jakub Jelinek wrote:
> On Thu, Apr 18, 2019 at 02:47:18PM +0200, Jakub Jelinek wrote:
>> On Thu, Apr 18, 2019 at 02:42:22PM +0200, Richard Biener wrote:
1.) Compilers do not use conditional equivalences for
optimizations of pointers (or only when additional
condit
On 4/18/19 6:20 AM, Uecker, Martin wrote:
> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
>> On Thu, 18 Apr 2019 at 10:32, Richard Biener
>> wrote:
>
>
>> An equality test of two pointers, on the other hand, doesn't necessarily
>> mean that they are interchangeable. I don't
On 4/24/19 4:19 AM, Richard Biener wrote:
> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote:
>>
>> On 4/18/19 6:20 AM, Uecker, Martin wrote:
>>> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
>>>> On Thu, 18 Apr 2019 at 10:32, Richard Biener
On 4/24/19 4:24 AM, Richard Biener wrote:
> On Fri, Apr 19, 2019 at 11:09 AM Jens Gustedt wrote:
>>
>> Hello Jakub,
>>
>> On Fri, 19 Apr 2019 10:49:08 +0200 Jakub Jelinek
>> wrote:
>>
>>> On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt wrote:
> OTOH GCC transforms
> (uintptr_t)&a !
On 4/29/19 8:24 AM, Thomas Koenig wrote:
> Hi!
>
> Is there a way to mark a TREE statement (or a variable) so that
> a warning is issued at a later stage if the statement has not been
> removed in the meantime?
>
> I am thinking, for example, of Fortran's -Warray-temporaries, which
> issues a war
to answer all the questions,
> but I can try my best.
>
> How do I get this across? comments? straight to gcc-patches? :-)
>
> I know Jeff Law did not like the change to builtins.md as being wrong. I
> can omit them, I forgot about it until typing this email :)
>
> caveat:
On 1/4/19 9:03 AM, Matthew Malcomson wrote:
> Hi there,
>
> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and
> hoping someone here knows.
It doesn't mean very much anymore. I believe it was used to
distinguish between stuff like copying incoming arguments into pseudos
an
On 4/30/19 10:48 AM, Matthew Malcomson wrote:
> Hi Jeff,
>
> On 30/04/19 16:29, Jeff Law wrote:
>> On 1/4/19 9:03 AM, Matthew Malcomson wrote:
>>> Hi there,
>>>
>>> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and
>>>
On 4/30/19 12:34 PM, cmdLP #CODE wrote:
> Hello GCC-team,
>
> I use GCC for all my C and C++ programs. I know how to use GCC, but I am
> not a contributor to GCC (yet). I often discover some problems C and C++
> code have in general. There is often the choice between fast or readable
> code. Some
On 4/30/19 11:24 AM, Matthew Malcomson wrote:
> On 30/04/19 18:01, Jeff Law wrote:
>> On 4/30/19 10:48 AM, Matthew Malcomson wrote:
>>> Hi Jeff,
>>>
>>> On 30/04/19 16:29, Jeff Law wrote:
>>>> On 1/4/19 9:03 AM, Matthew Malcomson wrote:
>
On 5/10/19 9:17 AM, Zack Vu wrote:
> Hi all,
>
> Every year there are new vulnerabilities, and some of them are possible
> because of ROP attacks.
> There are a couple things that come to mind to thwart ROP attacks that
> would rely on compiler changes in particular, instead of a kernel change or
On 5/13/19 2:43 AM, Frank Tetzel wrote:
>>> Every year there are new vulnerabilities, and some of them are
>>> possible because of ROP attacks.
>>> There are a couple things that come to mind to thwart ROP attacks
>>> that would rely on compiler changes in particular, instead of a
>>> kernel change
On 5/13/19 3:48 PM, Zack Vu wrote:
> Given that essentially no CPUs today support CET and given that CPUs
> remain deployed for perhaps 10 years, even more considering that CPU
> performance has plateaued, isn't there a moral imperative
> to mitigate ROP attacks using approaches other than just CET
On 5/23/19 7:10 AM, Richard Biener wrote:
> On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
>>
>> There is a functioning prototype in branch “ssa-range” which is a proof
>> of concept that the approach is functional as well as quick, and can be
>> used to answer questions which come up regar
On 5/29/19 8:32 AM, Thomas Schwinge wrote:
> Hi Ilya!
>
> On Thu, 9 May 2019 15:46:06 +0300, Ilya Verbin wrote:
>> I have left Intel 3 years ago. If you have any questions regarding MIC
>> offloading, you can reach me by iver...@gmail.com
>
> We're (a) looking for somebody to step up as a mainta
On 5/30/19 8:28 AM, Martin Sebor wrote:
> On 5/30/19 3:12 AM, Fredrik Hederstierna wrote:
>> Hi
>>
>> When reading the SEI CERT C Coding Standard rules, looking at
>> "DCL30-C. Declare objects with appropriate storage durations"
>> it seem like GCC does not warn in compile-time for some noncomplian
On 5/31/19 9:40 AM, Andrew MacLeod wrote:
> On 5/29/19 7:15 AM, Richard Biener wrote:
>> On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod
>> wrote:
>>> On 5/27/19 9:02 AM, Richard Biener wrote:
On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod
wrote:
>> The above suggests that iff this i
On 5/31/19 2:26 PM, Andrew MacLeod wrote:
> On 5/31/19 2:16 PM, Jeff Law wrote:
>> On 5/31/19 9:40 AM, Andrew MacLeod wrote:
>>>> stmt-level tracking of ranges are sometimes important. This is
>>>> something the machinery cannot provide - correct? At least no
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 "arm_general_register_operand" "")
>> + (match_operand:SI 1 "arm_general_register_operand" ""))
>> + (set (reg:CC CC_REG
401 - 500 of 1376 matches
Mail list logo
