Re: Google Summer of Code

[Martin Jambor]

Hi Supriya.

On Thu, Apr 04 2019, Supriya Palli wrote:
> Hello,
>
> My name is Supriya Palli and I am a first-year Computer Science B.S.
> student at Florida State University. I currently finishing up a C++ course
> in Object Oriented Programming and am looking for ways to continue my
> learning in C++ and other technologies over the summer. I noticed that some
> of the projects you have listed for Google Summer of Code include C++ as a
> skill, but I am not sure I would meet the other skill requirements. Are
> there any specific projects you would recommend for beginners? Or any
> projects I could contribute to outside of the Google Summer of Code program?
>

we are delighted you found contributing to GCC interesting.  On the
other hand, I am afraid you not only need fairly solid knowledge of
C/C++ to do that but also at least some rudimentary theoretical
background in the area of compilers.

Couple of days back another student asked for a textbook and I
recommended "Building an Optimizing Compiler" by Bob Morgan.  If you
read and understand it - or some other solid textbook on compilers - you
will be very well equipped for a GSoC with us... but not this year I am
afraid.

Good luck,

Martin Jambor

Re: Google Summer of Code

[Jonathan Wakely]

On Fri, 5 Apr 2019 at 04:50, Supriya Palli wrote:
> My name is Supriya Palli and I am a first-year Computer Science B.S.
> student at Florida State University. I currently finishing up a C++ course
> in Object Oriented Programming and am looking for ways to continue my
> learning in C++ and other technologies over the summer. I noticed that some
> of the projects you have listed for Google Summer of Code include C++ as a
> skill, but I am not sure I would meet the other skill requirements. Are
> there any specific projects you would recommend for beginners? Or any
> projects I could contribute to outside of the Google Summer of Code program?

Hi,

The https://gcc.gnu.org/wiki/LibstdcxxTodo page shows lots of missing
features/fixes in the C++ standard library, libstdc++. Some of those
are small, some are much larger. If you want to contribute to GCC I'm
sure you could find something there to work on. The libstdc++ library
has its own mailing list at libstd...@gcc.gnu.org

Re: Putting an all-zero variable into BSS

[Richard Biener]

On Thu, Apr 4, 2019 at 9:53 PM Thomas Koenig  wrote:
>
> Hi Andreas,
>
> >> Well, nothing is going to write to it (this is not accessible by
> >> user code), so that should not be a problem.
> > Then don't make it read-only.
>
> I tried this, and while it solves the executable size problem, it
> causes an OpenMP regression (see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487#c22 ),
> so now I am out of ideas.
>
> Oh well, I would have liked fixing this before 9.0, but it
> seems that this may not be possible.

Putting readonly data into .rodata isn't required by the C standard I think
so we could freely choose .bss for data exceeding a reasonable
size limit.  IIRC GCC behaved one or another way in the past already
and the last change might be due to security concerns.  Btw, large
all-zeros constant objects don't make very much sense...

Richard.

Re: GSOC Proposal

[Richard Biener]

On Wed, 3 Apr 2019, nick wrote:

> 
> 
> On 2019-04-03 7:30 a.m., Richard Biener wrote:
> > On Mon, 1 Apr 2019, nick wrote:
> > 
> >>
> >>
> >> On 2019-04-01 9:47 a.m., Richard Biener wrote:
> >>> On Mon, 1 Apr 2019, nick wrote:
> >>>
>  Well I'm talking about the shared roots of this garbage collector core 
>  state 
>  data structure or just struct ggc_root_tab.
> 
>  But also this seems that this to be no longer shared globally if I'm not 
>  mistaken 
>  or this:
>  static vec extra_root_vec;
> 
>  Not sure after reading the code which is a bigger deal through so I wrote
>  my proposal not just asking which is a better issue for not being thread
>  safe. Sorry about that.
> 
>  As for the second question injection seems to not be the issue or outside
>  callers but just internal so phase 3 or step 3 would now be:
>  Find internal callers or users of x where x is one of the above rather
>  than injecting outside callers. Which answers my second question about
>  external callers being a issue still.
> 
>  Let me know which  of the two is a better issue:
>  1. struct ggc_root_tabs being shared
>  2.static vec extra_root_vec; as a shared heap or
>  vector of root nodes for each type of allocation
> 
>  and I will gladly rewrite my proposal sections for that
>  as needs to be reedited.
> >>>
> >>> I don't think working on the garbage collector as a separate
> >>> GSoC project is useful at this point.  Doing locking around
> >>> allocation seems like a good short-term solution and if that
> >>> turns out to be a performance issue for the threaded part
> >>> using per-thread freelists is likely an easy to deploy
> >>> solution.
> >>>
> >>> Richard.
> >>>
> >> I agree but we were discussing this:
> >> Or maybe a project to be more
> >> explicit about regions of the code that assume that the garbage-
> >> collector can't run within them?[3] (since the GC is state that would
> >> be shared by the threads).
> > 
> > The process of collecting garbage is not the only issue (and that
> > very issue is easiest mitigated by collecting only at specific
> > points - which is what we do - and have those be serializing points).
> > The main issue is the underlying memory allocator (GCC uses memory
> > that is garbage collected plus regular heap memory).
> > 
> >> In addition I moved my paper back to our discussion about garbage collector
> >> state with outside callers.Seems we really need to do something about
> >> my wording as the idea of my project in a nutshell was to figure
> >> out how to mark shared state by callers and inject it into the
> >> garbage collector letting it known that the state was not shared between
> >> threads or shared. Seems that was on the GSoc page and in our discussions 
> >> the issue
> >> is marking outside code for shared state. If that's correct then my
> >> wording of outside callers is incorrect it should have been shared
> >> state between threads on outside callers to the garbage collector.
> >> If the state is that in your wording above then great as I understand
> >> where we are going and will gladly change my wording.
> > 
> > I'm still not sure what you are shooting at, the above sentences do
> > not make any sense to me.
> > 
> >> Also freelists don't work here as the state is shared at the caller's 
> >> end which would need two major issues:
> >> 1. Locking on nodes of the 
> >> freelists when two threads allocate at the same thing which can be a 
> >> problem if the shared state is shared a lot
> >> 2. Locking allocation with 
> >> large numbers of callers can starve threads
> > 
> > First of all allocating memory from the GC pool is not the main
> > work of GIMPLE passes so simply serializing at allocation time might
> > work out.  Second free lists of course do work.  What you'd do is
> > have a fast path in allocation using a thread-local "free list"
> > which you can allocate from without taking any lock.  Maybe I should
> > explain "free list" since that term doesn't make too much sense in
> > a garbage collector world.  What I'd do is when a client thread
> > asks for memory of size N allocate M objects of that size but put
> > M - 1 on the client thread local "free list" to be allocated lock-free
> > from for the next M - 1 calls.  Note that garbage collected memory
> > objects are only handed out in fixed chunks (powers of two plus
> > a few special sizes) so you'd have one "free list" per chunk size
> > per thread.
> > 
> > The collection itself (mark & sweep) would be fully serialized still
> > (and not return to any threads local "free list").
> > 
> > ggc_free'd objects _might_ go to the threads "free list"s (yeah, we
> > _do_ have ggc_free ...).
> > 
> > As said, I don't see GC or the memory allocator as sth interesting
> > to work on for parallelization until the basic setup works and it
> > proves to be a bottleneck.
> > 
> >> Seems that working on the garb

non-volatile automatic variables in setjmp tests

[Jozef Lawrynowicz]

Some setjmp/longjmp tests[1] depend on the value of an auto set before setjmp
to to be retained after returning from the longjmp. As I understand, this
behaviour is actually undefined, according to the gccint manual.

Section 3 "Interfacing to GCC Output" of gccint says:
  If you use longjmp, beware of automatic variables. ISO C says that automatic
  variables that are not declared volatile have undefined values after a
  longjmp. And this is all GCC promises to do, because it is very difficult to
  restore register variables correctly, and one of GCC’s features is that it
  can put variables in registers without your asking it to.
  
However, ISO C says [2]:
  ... values of objects of automatic storage duration are unspecified if they
  meet all the following conditions:
  * They are local to the function containing the corresponding setjmp()
invocation.
  * They do not have volatile-qualified type.
  * They are changed between the setjmp() invocation and longjmp() call.

Technically this third condition is not satisfied in these tests, as the auto
variable is not modified between the setjmp and longjmp calls. But I'm assuming
the gccint manual overrides this.

gcc.dg/torture/stackalign/setjmp-1.c and
gcc.c-torture/execute/built-in-setjmp.c actually fail at execution for
msp430-elf @ -O1, because the auto being tested after the longjmp has not been
restored correctly.
These tests feature a contrived way of making the auto appear used up to the
longjmp, so I wonder if they have been written deliberately without a
volatile, or if it was just an oversight.
For msp430-elf @ -O1, this code to make the auto appear used is ineffective as
an optimization replaces the variable with a constant, which is what
triggers the test failure.

Are these tests that rely on the value of a non-volatile auto after a longjmp
invalid? I can patch them to make the auto variable a global instead.

Thanks,
Jozef

[1] The C setjmp/longjmp tests using autos:
gcc.c-torture/execute/built-in-setjmp.c
gcc.c-torture/execute/pr60003.c
gcc.dg/torture/pr66101.c
gcc.dg/torture/stackalign/setjmp-4.c
gcc.dg/torture/stackalign/setjmp-3.c
gcc.dg/torture/stackalign/setjmp-1.c
gcc.dg/torture/pr48542.c
gcc.dg/setjmp-4.c
gcc.dg/setjmp-3.c
gcc.dg/tree-prof/pr34999.c
gcc.dg/tree-ssa/pr79803.c

[2] http://pubs.opengroup.org/onlinepubs/009695399/functions/longjmp.html

[ GSoC ] Add new math.h and complex.h functions as built-ins

[Youssef Mohamed]

Hi, everyone

I hope you are all well , with good health

I am sending this mail to apply to GCC GSoC for the idea:
Add new math.h and complex.h functions as built-ins

meanwhile if someone may be my mentor to implement TySan (Type Sanitizer) I
would really appreciate it

Thanks everyone

My Best Wishes

Re: GCC GSOC 2019

[Martin Liška]

On 4/4/19 1:44 PM, Shubham Narlawar wrote:
> On Thu, Apr 4, 2019 at 2:13 PM Martin Liška  wrote:
> 
>> On 4/3/19 6:31 PM, Martin Jambor wrote:
>>> Hello Shubham,
>>>
>>> On Fri, Mar 29 2019, Shubham Narlawar wrote:
 Hi, here is my proposal for the above idea. Please review and suggest
 necessary changes.


>> https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing
>>>
>>> I have had a quick look and the proposal seems very nice.
>>>
>>> How did you select the attributes you want to implement in csmith?  It
>>> is for example a little strange that you decided to include "pure" but
>>> not "const."  If you handle visibility, you might as well consider
>>> throwing in externally_visible too, I guess.  As a stretch goal, the
>>> alias function attribute might be useful to exercise nasty paths in GCC
>>> IPA optimizations.
>>>
>>> I assume Andi Kleen has seen this proposal and if he is fine with it, so
>>> am I.
>>>
>>> Thanks,
>>>
>>> Martin
>>>
>>
>> Hi.
>>
>> Just for the record, Martin Jambor asked me to co-mentor during time period
>> when Andi will be on vacation (if I'm correct).
>>
> 
> I have included your name as co-mentor in my proposal. Is it fine?

Yes.

> 
> 
>> I have couple of questions/ideas about the proposal:
>>
>> 1) I would not spend much time with nested functions, it's quite legacy
>> C extension
>>
> 
> Once Andi Kleen suggested that nested functions has lot of potential for
> bugs.
> I will not only just add nested functions but I plan to do integration
> testing along with merging of previously implemented extensions in phase 3
> of gsoc timeline

I would be more interested in lambda functions, which is also kind of a nested 
function.

> 
> 
>> 2) for functions, I would basically include add potential attribute:
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
>>
>> see:
>> gcc/c-family/c-attribs.c:242
>> const struct attribute_spec c_common_attribute_table[] =
>> ...
>>
> 
> 
>> I assume potential attributes means attributes that will trigger different
> components of GCC. Can you point out such potential attributes such as
> alias.

Basically majority of them can stress a component in GCC. More you add better 
coverage
we'll have.

> 
> 
> 
>>
>> 3) similarly for variables:
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes
> 
> 
> Few of variables attributes like packed, unused, section, aligned are
> already implemented in Csmith.

Great then.

> 
> 
>>
>> 4) and similarly for types
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attribute
>> 
> 
> 5) One big question about csmith I have. It's quite easy to come up with a
>> test-case which
>> causes an ICE. But it's more difficult to come up with a test-case that is
>> miscompiled
>> by a compiler. It's mainly due to an invalid behavior in the generated
>> test-case.
>> One can theoretically catch that with sanitizers (ASAN, UBSAN, ...). But
>> still, it's
>> not easy. Are you considering catching wrong-code issue?
>>
> 
> I use option -fsanitize=undefined and valgrind to check undefined
> behaviour. Are there any other ways to check it rather than sanitizers?

I'm not aware of any others. I'm curious if you we able to find a wrong-code
with your periodic csmith runner?

Thanks for working on csmith,
Martin

> 
> Thanks,
> Shubham
> 
> 
>>
>> Thanks,
>> Martin
>>

Re: GSOC Proposal

[nick]

On 2019-04-05 6:25 a.m., Richard Biener wrote:
> On Wed, 3 Apr 2019, nick wrote:
> 
>>
>>
>> On 2019-04-03 7:30 a.m., Richard Biener wrote:
>>> On Mon, 1 Apr 2019, nick wrote:
>>>


 On 2019-04-01 9:47 a.m., Richard Biener wrote:
> On Mon, 1 Apr 2019, nick wrote:
>
>> Well I'm talking about the shared roots of this garbage collector core 
>> state 
>> data structure or just struct ggc_root_tab.
>>
>> But also this seems that this to be no longer shared globally if I'm not 
>> mistaken 
>> or this:
>> static vec extra_root_vec;
>>
>> Not sure after reading the code which is a bigger deal through so I wrote
>> my proposal not just asking which is a better issue for not being thread
>> safe. Sorry about that.
>>
>> As for the second question injection seems to not be the issue or outside
>> callers but just internal so phase 3 or step 3 would now be:
>> Find internal callers or users of x where x is one of the above rather
>> than injecting outside callers. Which answers my second question about
>> external callers being a issue still.
>>
>> Let me know which  of the two is a better issue:
>> 1. struct ggc_root_tabs being shared
>> 2.static vec extra_root_vec; as a shared heap or
>> vector of root nodes for each type of allocation
>>
>> and I will gladly rewrite my proposal sections for that
>> as needs to be reedited.
>
> I don't think working on the garbage collector as a separate
> GSoC project is useful at this point.  Doing locking around
> allocation seems like a good short-term solution and if that
> turns out to be a performance issue for the threaded part
> using per-thread freelists is likely an easy to deploy
> solution.
>
> Richard.
>
 I agree but we were discussing this:
 Or maybe a project to be more
 explicit about regions of the code that assume that the garbage-
 collector can't run within them?[3] (since the GC is state that would
 be shared by the threads).
>>>
>>> The process of collecting garbage is not the only issue (and that
>>> very issue is easiest mitigated by collecting only at specific
>>> points - which is what we do - and have those be serializing points).
>>> The main issue is the underlying memory allocator (GCC uses memory
>>> that is garbage collected plus regular heap memory).
>>>
 In addition I moved my paper back to our discussion about garbage collector
 state with outside callers.Seems we really need to do something about
 my wording as the idea of my project in a nutshell was to figure
 out how to mark shared state by callers and inject it into the
 garbage collector letting it known that the state was not shared between
 threads or shared. Seems that was on the GSoc page and in our discussions 
 the issue
 is marking outside code for shared state. If that's correct then my
 wording of outside callers is incorrect it should have been shared
 state between threads on outside callers to the garbage collector.
 If the state is that in your wording above then great as I understand
 where we are going and will gladly change my wording.
>>>
>>> I'm still not sure what you are shooting at, the above sentences do
>>> not make any sense to me.
>>>
 Also freelists don't work here as the state is shared at the caller's 
 end which would need two major issues:
 1. Locking on nodes of the 
 freelists when two threads allocate at the same thing which can be a 
 problem if the shared state is shared a lot
 2. Locking allocation with 
 large numbers of callers can starve threads
>>>
>>> First of all allocating memory from the GC pool is not the main
>>> work of GIMPLE passes so simply serializing at allocation time might
>>> work out.  Second free lists of course do work.  What you'd do is
>>> have a fast path in allocation using a thread-local "free list"
>>> which you can allocate from without taking any lock.  Maybe I should
>>> explain "free list" since that term doesn't make too much sense in
>>> a garbage collector world.  What I'd do is when a client thread
>>> asks for memory of size N allocate M objects of that size but put
>>> M - 1 on the client thread local "free list" to be allocated lock-free
>>> from for the next M - 1 calls.  Note that garbage collected memory
>>> objects are only handed out in fixed chunks (powers of two plus
>>> a few special sizes) so you'd have one "free list" per chunk size
>>> per thread.
>>>
>>> The collection itself (mark & sweep) would be fully serialized still
>>> (and not return to any threads local "free list").
>>>
>>> ggc_free'd objects _might_ go to the threads "free list"s (yeah, we
>>> _do_ have ggc_free ...).
>>>
>>> As said, I don't see GC or the memory allocator as sth interesting
>>> to work on for parallelization until the basic setup works and it
>>> proves to be a bottle

Re: non-volatile automatic variables in setjmp tests

[Michael Matz]

Hello,

On Fri, 5 Apr 2019, Jozef Lawrynowicz wrote:

> Some setjmp/longjmp tests[1] depend on the value of an auto set before setjmp
> to to be retained after returning from the longjmp. As I understand, this
> behaviour is actually undefined, according to the gccint manual.
> 
> Section 3 "Interfacing to GCC Output" of gccint says:
>   If you use longjmp, beware of automatic variables. ISO C says that automatic
>   variables that are not declared volatile have undefined values after a
>   longjmp. And this is all GCC promises to do, because it is very difficult to
>   restore register variables correctly, and one of GCC’s features is that it
>   can put variables in registers without your asking it to.

That is very old text, from 1997, and doesn't reflect what GCC actually 
does, which is ...

> However, ISO C says [2]:
>   ... values of objects of automatic storage duration are unspecified if they
>   meet all the following conditions:
>   * They are local to the function containing the corresponding setjmp()
> invocation.
>   * They do not have volatile-qualified type.
>   * They are changed between the setjmp() invocation and longjmp() call.

... supporting this (and in any case if there's a direct conflict between 
the GCC docu and a relevant standard, then the former is likely the wrong 
one).  The are two modi: (a) the target has a setjmp/longjmp combination 
which restores all callee-saved registers (to the values at just before 
the setjmp call) and (b) the target doesn't save all these.

For (a) GCC treats the setjmp call as a normal function call from a 
register-clobber perspective, so any auto variable live over the 
setjmp that is stored in a callee-saved register is restored to the 
pre-setjmp value.

For (b) GCC makes sure to not allocate variables live over setjmp to 
registers.  This is the conservative assumption.

Most targets in GCC follow the (b) model, even though the specific 
setjmp/longjmp mechanism would allow for (a).

> gcc.dg/torture/stackalign/setjmp-1.c and
> gcc.c-torture/execute/built-in-setjmp.c actually fail at execution for
> msp430-elf @ -O1, because the auto being tested after the longjmp has not been
> restored correctly.

So the testcases should indeed work without volatile and you need to 
investigate why the restoring doesn't happen correctly.

> These tests feature a contrived way of making the auto appear used up to the
> longjmp, so I wonder if they have been written deliberately without a
> volatile, or if it was just an oversight.
> 
> For msp430-elf @ -O1, this code to make the auto appear used is 
> ineffective as an optimization replaces the variable with a constant, 
> which is what triggers the test failure.

Well, then it should be the correct constant, and hence be unaffected by 
setjmp/longjmp, so if that still doesn't work the constant is wrong, 
right?

> Are these tests that rely on the value of a non-volatile auto after a 
> longjmp invalid? I can patch them to make the auto variable a global 
> instead.

No, they should work as is.


Ciao,
Michael.

is re-running bootstrap after a change safe?

[Martin Sebor]

Is it safe to rerun make bootstrap after changing GCC source?

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?

I have been assuming this is safe and so after each tweak to
a patch I work on I rerun make bootstrap in the same build
directory.  It can speed things up quite a bit.

But the recent bootstrap breakage (PR 89980) makes me wonder
if it is, in fact, safe.  I can see the broken bootstrap today
in a clean build yet the bootstrap I did just before checking
in the change went fine.

Martin

Re: is re-running bootstrap after a change safe?

[H.J. Lu]

On Fri, Apr 5, 2019 at 12:55 PM Martin Sebor  wrote:
>
> Is it safe to rerun make bootstrap after changing GCC source?
>
> 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?
>
> I have been assuming this is safe and so after each tweak to
> a patch I work on I rerun make bootstrap in the same build
> directory.  It can speed things up quite a bit.
>
> But the recent bootstrap breakage (PR 89980) makes me wonder
> if it is, in fact, safe.  I can see the broken bootstrap today
> in a clean build yet the bootstrap I did just before checking
> in the change went fine.
>

You need to do a clean bootstrap.

-- 
H.J.

Re: is re-running bootstrap after a change safe?

[Eric Botcazou]

> 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 deleting the stage2 and stage3 compilers and that isn't 
what happens.  Instead the compiler of each stage is updated in isolation.

-- 
Eric Botcazou

Re: is re-running bootstrap after a change safe?

[Jeff Law]

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 deleting the stage2 and stage3 compilers and that isn't 
> what happens.  Instead the compiler of each stage is updated in isolation.
> 
RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
directories along with the "compare" stamp file.

Jeff

Re: is re-running bootstrap after a change safe?

[Martin Sebor]

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
the same fallout of the change as I would if I did a pristine
build in a clean directory?


No, this would imply deleting the stage2 and stage3 compilers and that isn't
what happens.  Instead the compiler of each stage is updated in isolation.


RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
directories along with the "compare" stamp file.


Thanks (all of you).  It's amazing that I have been getting away
with it for all these years.

Why is this not done automatically?  I mean, what is the use case
for make bootstrap without doing these steps first?

Martin

Re: is re-running bootstrap after a change safe?

[Jeff Law]

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
 the same fallout of the change as I would if I did a pristine
 build in a clean directory?
>>>
>>> No, this would imply deleting the stage2 and stage3 compilers and
>>> that isn't
>>> what happens.  Instead the compiler of each stage is updated in
>>> isolation.
>>>
>> RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
>> directories along with the "compare" stamp file.
> 
> Thanks (all of you).  It's amazing that I have been getting away
> with it for all these years.
I got away without removing the "compare" stamp file for a long time,
then broke the trunk with a comparison failure :(

> 
> Why is this not done automatically?  I mean, what is the use case
> for make bootstrap without doing these steps first?
During development folks often want to rebuild without going through a
full bootstrap.  Obviously for testing the final version of a patch the
"quick" approach of just rebuilding without blowing away the stage
directories isn't sufficient.

This is actually one of the things I'd really like to just automate.
You point to a git commit in a public repo, the tester picks it up and
does a bootstrap & regression test from scratch on whatever targets you
ask for.

jeff

gcc-8-20190405 is now available

[gccadmin]

Snapshot gcc-8-20190405 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190405/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 270178

You'll find:

 gcc-8-20190405.tar.xzComplete GCC

  SHA256=bb80013e1660ef7c8b73aa1e1e984fb6494de6b8ae0dbf4b0961452624ca1208
  SHA1=9ecc7031f2f9464b74f61bcbeba4e072611f7b24

Diffs from 8-20190329 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: is re-running bootstrap after a change safe?

[Martin Sebor]

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: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 deleting the stage2 and stage3 compilers and
that isn't
what happens.  Instead the compiler of each stage is updated in
isolation.


RIght.  Thus I always blow away stage2-* stage3-*, and stage1 target
directories along with the "compare" stamp file.


Thanks (all of you).  It's amazing that I have been getting away
with it for all these years.

I got away without removing the "compare" stamp file for a long time,
then broke the trunk with a comparison failure :(



Why is this not done automatically?  I mean, what is the use case
for make bootstrap without doing these steps first?

During development folks often want to rebuild without going through a
full bootstrap.  Obviously for testing the final version of a patch the
"quick" approach of just rebuilding without blowing away the stage
directories isn't sufficient.


I see.  So after a bootstrap and a subsequent change to a .c file,
at each stage the next bootstrap recompiles just the changed file
and relinks gcc.  It doesn't actually recompile all source files
in stage 2 or 3 with the changed compiler from the last stage.
That's why it's so much faster!  Make check then correctly reflects
the change but the compiler doesn't get as fully exercised because
the test suite has low coverage.


This is actually one of the things I'd really like to just automate.
You point to a git commit in a public repo, the tester picks it up and
does a bootstrap & regression test from scratch on whatever targets you
ask for.


That would be great to validate the final patch.

So to be clear: the safe and also most efficient to "rebootstrap"
GCC is to remove what exactly?  (I don't see any stage2 or stage3
directories in my build tree.)  Is there a make target for this?

Thanks
Martin

New Template 3

[Sam Taylor]

PRE-LAUNCHPROMOTIONAL PRICE                                        10 Units 
only !!!BUY BACK OPTION - 7 % GUARANTEE FOR 15 YEARS 
Rental Guarantee condition:Special promotion 7% NET (subject to WHT) rental 
guarantee -NO monthly fee-NO electricity-NO maintenance-NO sinking fundFor 15 
years !  

Send me more info !POOL VILLA WITH PREMIUM SEA VIEW
SIZE : 75 Sq.m
PRICE : 10,900,000 THB                    PROMOTION : 8,900,000 THB
POOL VILLA WITH SEA VIEWSIZE : 75 Sq.m
PRICE : 9,900,000 THB
PROMOTION : 7,900,000 THB
BUY BACK OPTION - 7 % GUARANTEE FOR 15 YEARS 

More info  >SEA VIEW COTTAGES WITH JACUZZI
SIZE : 65 Sq.m
PRICE : 8,900,000 THB
PROMOTION : 6,900,000 THB
GARDEN VIEW COTTAGES WITH JACUZZISIZE : 65 Sq.m
PRICE : 6,900,000 THB
PROMOTION : 5,900,000 THB


For more options View this email 

online if it doesn't display correctlySOLO MIO• Free furniture package
• 30% unit price growth by the end of construction
• Guaranteed return on investment from 7% per year for 5 years
• Free two weeks stay in hotel per year






More info >Sea ViewRental guarantee conditions: Special promotion 7% 
NET (subject to WHT) rental guarantee (no monthly fees, no electricity, no 
maintenance, no sinking fund…) for the first 15 years. The rental guarantee 
will be paid every year in advance.

More info >Stunning Residence
Rental guarantee conditions: 7% NET (subject to WHT) rental guarantee (no 
monthly fees, no electricity, no maintenance, no sinking fund…) for the first 
15 years. After 15 years possibility of renegotiating a new rental guarantee 
period.



More info >
Ihsane benazzouz, Boat Laggon Marina, Phuket, Ko keaw, 83000, Thailand

UNSUBSCRIBE

Re: is re-running bootstrap after a change safe?

[Andreas Schwab]

On Apr 05 2019, Martin Sebor  wrote:

> So to be clear: the safe and also most efficient to "rebootstrap"
> GCC is to remove what exactly?  (I don't see any stage2 or stage3
> directories in my build tree.)  Is there a make target for this?

make stage1-start; rm -rf stage[23]-* compare

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."