Re: C as intermediate language, signed integer overflow and -ftrapv

[Richard Biener]

On Wed, Jul 23, 2014 at 9:56 PM, David Wohlferd  wrote:
> I believe that sometimes gcc is promoting the ints to long longs when doing
> the overflow testing.  If I try to overflow a long long, I get the trap as
> expected.

Yes, I think that's one issue - see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52478 - it's probably
also the most important
bug to fix in the current implementation (but also not the easiest).

Fact is that if somebody is interested in
-ftrapv he/she is welcome to contribute patches.  Especially testing
coverage is poor.

Note that the way to go forward with -ftrapv is doing it different than
currently.  See comments in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580

There is now -fsanitize=undefined which provides (heavier weight)
overflow checking.

Richard.

> See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
>
> dw
>
>
> On 7/23/2014 7:56 AM, Thomas Mertes wrote:
>>
>> C is popular as intermediate language. This means that some compilers
>> generate C and use a C compiler as backend. Wikipedia lists several
>> languages, which use C as intermediate language:
>> Eiffel, Sather, Esterel, some dialects of Lisp (Lush, Gambit),
>> Haskell (Glasgow Haskell Compiler), Squeak's Smalltalk-subset Slang,
>> Cython, Seed7 and Vala.
>>
>> When C is used as backend the features needed from a C compiler are
>> different from the features that a human programmer of C needs.
>>
>> One such feature is the detection of signed integer overflow. It is
>> not hard, to detect signed integer overflow with a generated C
>> program, but the performance is certainly not optimal. Signed integer
>> overflow is undefined behavior in C and the access to some overflow
>> flag of the CPU is machine dependent. So the generated C code must
>> recogize overflow before it happens or use unsigned computations and
>> recognize the overflow afterwards. I have doubts that this leads to
>> optimal performance.
>>
>> The C compiler is much better suited to do signed integer overflow
>> checks. The C compiler can do low level tricks, that would be
>> undefined behavior in C, and the C compiler also knows about overflow
>> flags and other details of the CPU. Maybe the CPU can be switched to
>> a mode where it traps signed integer overflow for free.
>>
>> The gcc compiler option -ftrapv promises to do exactly that, but it
>> seems broken. At least my test suite shows that both gcc version
>> 4.6.3 and 4.8.1 fail to detect integer overflow with -ftrapv. The
>> detection fails even for addition and subtraction. I know that 4.6.3
>> and 4.8.1 are old, but I found nothing in the internet that tells
>> me that the situation is better now. So for gcc as C compiler backend
>> -ftrapv cannot be used and overflow checking in the generated C code
>> is necessary.
>>
>> Clang supports -ftrapv reliably. Signed integer overflow raises the
>> signal SIGILL, which can be catched. Btw. SIGILL seems to be a better
>> choice, because under windows (7) SIGABRT causes some text to be
>> written to the console. Is it possible to choose a -ftrapv signal?
>>
>> A sanitizer such as ubsan is good as tool to find errors in C
>> programs. But I don't think that ubsan is well suited to do overflow
>> detection with maximum performance. Is just not the goal of this
>> tool.
>>
>> The argumantation that nobody uses -ftrapv is self-fulfilling
>> prophecy. How can someone expect that a buggy feature is used.
>> The counterexample is clang, where -ftrapv works and is also used
>> (E.g. by the integer overflow detection of Seed7).
>>
>> Conclusion:
>> Signed integer overflow detection with -ftrapv is NOT something that
>> nobody uses. It is an important feature. Especially when C is used as
>> intermediate language. When it works it results in a significant
>> speed up of signed overflow detection. A sanitizer has a different
>> purpose and cannot be used as replacement.
>>
>> I can offer some help with this issue:
>> I have test programs for cases with integer overflow and for cases
>> where the result is as big or as small as possible without causing an
>> overflow. The test programs are not written in C, but are licensed
>> with the GPL, and it would be possible to convert them to C with
>> reasonable effort. Maybe this is not necessary, because clang must
>> have some test suites for -ftrapv.
>>
>> Greetings Thomas Mertes
>>
>> --
>> Seed7 Homepage:  http://seed7.sourceforge.net
>> Seed7 - The extensible programming language: User defined statements
>> and operators, abstract data types, templates without special
>> syntax, OO with interfaces and multiple dispatch, statically typed,
>> interpreted or compiled, portable, runs under linux/unix/windows.
>>
>

Re: GCC version bikeshedding

[Richard Biener]

On Wed, Jul 23, 2014 at 10:00 PM, Jakub Jelinek  wrote:
> On Wed, Jul 23, 2014 at 09:20:23AM -0700, Ian Lance Taylor wrote:
>> I think that if anybody has strong objections, now is the time to make
>> them.  Otherwise I think we should go with this plan.
>
> My preference was to keep the current versioning scheme, after all, even
> right now it is IMHO worthwhile to tell users about to significant user
> visible change with libstdc++ ABI.
> But not a strong objection from me.

The point is we have significant user visible changes for each release.
Where the "significance" is of course a subjective matter.

The other thing I could have lived with is doing 4.10.0 (and keeping
the major at 4 forever).  But "randomly" bumping the major version
looks crap to me, esp. as 5.0.0 will be seen as very very experimental.

Richard.

> Jakub

Re: C as intermediate language, signed integer overflow and -ftrapv

[Marek Polacek]

On Wed, Jul 23, 2014 at 04:56:06PM +0200, Thomas Mertes wrote:
> A sanitizer such as ubsan is good as tool to find errors in C
> programs. But I don't think that ubsan is well suited to do overflow
> detection with maximum performance. Is just not the goal of this
> tool.

That's true.  But if you only use
-fsanitize=signed-integer-overflow, then the overhead shouldn't be
that bad, especially on x86_64 where we try to make use of jo (jump if
overflow) instruction.  Perhaps use that option together with
-fsanitize-undefined-trap-on-error, so it doesn't call libubsan
routines at all.

Marek

Does -fdump-tree-original-raw dumps out the full AST?

[Francois Berenger]

Hello,

If I use the -fdump-tree-original-raw option
of gcc, I understand it will dump out the AST
in a text file.

Is that text file complete?

Complete in the sense that, by parsing back this text file
with an external program it would be possible to reconstruct the original AST
that gcc was working on (and dumped out).

Thanks a lot,
Francois.

GNU Tools Cauldron 2014 - Slides for presentations

[Diego Novillo]

If you made a presentation at this year's Cauldron and are
allowed to share your slides, please add them to the wiki
in the slides and notes section:

https://gcc.gnu.org/wiki/cauldron2014#Slides_and_Notes

If you don't have access to GCC's wiki, you can create your own
user. If that does not work, let me know and I'll upload the
slides for you.

Sessions were recorded on video. We will be publishing them from
the GNU Tools Google+ page when they are available.


Thanks. Diego.

Re: Slides from Cauldron talks

[David Edelsohn]

On Thu, Jul 24, 2014 at 2:19 AM, Tobias Burnus  wrote:
> David Malcolm wrote:
>>
>> I didn't see a place to post slides for Cauldron talks, so am posting
>> links to them here.
>
>
> I have added the links to
> https://gcc.gnu.org/wiki/cauldron2014#Slides_and_Notes
>
>
>> Does anyone know if any Cauldron talks were recorded?
>
>
> At least the ones in Lecture Theatre One were. However, I don't know when
> the organizers will upload the videos.

The videos will be uploaded to the GNU Tools Google+ page when available.

Thanks, David

Re: Does -fdump-tree-original-raw dumps out the full AST?

[Diego Novillo]

On Thu, Jul 24, 2014 at 7:17 AM, Francois Berenger
 wrote:

> Complete in the sense that, by parsing back this text file
> with an external program it would be possible to reconstruct the original AST
> that gcc was working on (and dumped out).

It isn't. These dumps are meant to be debugging aids. It is not
possible to reconstruct the original program out of them.


Diego.

Symtab node table introduction and GGC issues

[Martin Liška]

Hello,
   I would like to encapsulate all symtab_nodes to a class called 'symtab'. To 
respect gcc:context, I would like to add the class to global context 
(gcc::context) and I have troubles with GTY and GGC.

design:

class GTY(()) symtab
{
public:
  symtab_node* GTY(()) nodes;
};

class GTY(()) context
{
public:
  context () {}
  void init ();

  /* Pass-management.  */
  pass_manager *get_passes () { gcc_assert (m_passes); return m_passes; }

  /* Handling dump files.  */
  dump_manager *get_dumps () {gcc_assert (m_dumps); return m_dumps; }

  /* Symbol table.  */
  symtab *get_symtab () { gcc_assert (symbol_table); return symbol_table; }

  /* Symbol table.  */
  symtab * GTY(()) symbol_table;

private:
  /* Pass-management.  */
  pass_manager * GTY((skip)) m_passes;

  /* Dump files.  */
  dump_manager * GTY((skip)) m_dumps;
}; // class context

} // namespace gcc

/* The global singleton context aka "g".
   (the name is chosen to be easy to type in a debugger).  */
extern GTY(()) gcc::context *g;



gcc:context in created by g = ggc_cleared_alloc (); and 
g->symbol_table too.
My problem is that during pg_pch_restore:
#3  0x00850043 in gt_pch_restore (f=0x1ac9100) at 
../../gcc/ggc-common.c:691

When I add watch to *(&g), gcc::context *g is restored ^ and 
gcc:context::m_passes and gcc:context::m_dumps are set to an inaccessible address.

Is my GGC construct correct?

Thank you,
Martin

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Joseph S. Myers]

On Thu, 24 Jul 2014, Diego Novillo wrote:

> Sessions were recorded on video. We will be publishing them from
> the GNU Tools Google+ page when they are available.

I take it they'll be available in an unencumbered format such as WebM, not 
just MP4?  (Some of the video links from the Cauldron 2013 page don't work 
for me in Firefox - I don't know how to get YouTube to make a given video 
available in an unencumbered format.  And using youtube_dl to interrogate 
the available formats for other videos, I see that some that are available 
in WebM don't have it in as high as resolution as the MP4 versions - we 
ought to ensure the highest-resolution version is available in an 
unencumbered format.)

In accordance with GNU principles we should be making the videos available 
without depending on non-free JavaScript as well (I don't know if Google+ 
makes videos readily available without JS or with only free JS).  I've 
just added a link to 
https://www.gnu.org/philosophy/whats-wrong-with-youtube.html above the 
list of videos on https://gcc.gnu.org/wiki/cauldron2013 so that people are 
first pointed to a free software way of obtaining the videos.  Some 
similar link may be needed from the 2014 page to ensure free software 
access to videos is recommended before any non-free means of access.  (If 
Google+ provides stable URLs for direct links to WebM files of the videos, 
or for pages that show the videos without non-free JS, just linking to 
those is of course simplest.)

I'd say the videos should also be freely licensed if possible, with the 
license explicitly stated where the videos are posted - of course that 
needs approval from the speakers as well as from whoever may own rights in 
the video itself (and I'm not sure what the GNU recommendation is for 
licenses on videos about free software, so that should be determined 
first).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC version bikeshedding

[Jeff Law]

On 07/23/14 10:20, Ian Lance Taylor wrote:

I am also fine with it.

I think that if anybody has strong objections, now is the time to make
them.  Otherwise I think we should go with this plan.

To me, the basic summary of the idea is that there is no clear reason
to ever change the GCC major version number.  There were real
objections to changing it when we went from 3 to 4.  There will be
real objections for any future change from 4 to 5.  At the same time,
we face the fact that going from 4.9 to 4.10 will break some people's
existing scripts, as is also true of any other decision we can make.

Given that there is no clear reason to ever change the major version
number, making that change will not convey any useful information to
our users.  So let's just drop the major version number.  Once we've
made that decision, then the next release (in 2015) naturally becomes
5.0, the release after that (in 2016) becomes 6.0, etc.
Agreed.   It's not 100% perfect, but, IMHO, it's significantly better 
than what we're doing now and better than the various alternatives that 
have been proposed.


Jeff

Re: Does -fdump-tree-original-raw dumps out the full AST?

[Francois Berenger]

On Thu, Jul 24, 2014 at 4:29 PM, Diego Novillo  wrote:
> On Thu, Jul 24, 2014 at 7:17 AM, Francois Berenger
>  wrote:
>
>> Complete in the sense that, by parsing back this text file
>> with an external program it would be possible to reconstruct the original AST
>> that gcc was working on (and dumped out).
>
> It isn't. These dumps are meant to be debugging aids. It is not
> possible to reconstruct the original program out of them.

Would it be possible to make these dumps complete?
Let's say for the C frontend of gcc.

> Diego.

Re: Symtab node table introduction and GGC issues

[David Malcolm]

On Thu, 2014-07-24 at 16:23 +0100, Martin Liška wrote:
> Hello,
> I would like to encapsulate all symtab_nodes to a class called
> 'symtab'.

Thanks!

>  To respect gcc:context, I would like to add the class to global
> context (gcc::context) and I have troubles with GTY and GGC.
> 
> design:
> 
> class GTY(()) symtab
> {
> public:
>symtab_node* GTY(()) nodes;
> };
> 
> class GTY(()) context
> {
> public:
>context () {}
>void init ();
> 
>/* Pass-management.  */
>pass_manager *get_passes () { gcc_assert (m_passes); return m_passes; }
> 
>/* Handling dump files.  */
>dump_manager *get_dumps () {gcc_assert (m_dumps); return m_dumps; }
> 
>/* Symbol table.  */
>symtab *get_symtab () { gcc_assert (symbol_table); return symbol_table; }
> 
>/* Symbol table.  */
>symtab * GTY(()) symbol_table;
> 
> private:
>/* Pass-management.  */
>pass_manager * GTY((skip)) m_passes;
> 
>/* Dump files.  */
>dump_manager * GTY((skip)) m_dumps;
> }; // class context
> 
> } // namespace gcc
> 
> /* The global singleton context aka "g".
> (the name is chosen to be easy to type in a debugger).  */
> extern GTY(()) gcc::context *g;
> 
> 
> 
> gcc:context in created by g = ggc_cleared_alloc (); and 
> g->symbol_table too.
> My problem is that during pg_pch_restore:
> #3  0x00850043 in gt_pch_restore (f=0x1ac9100) at 
> ../../gcc/ggc-common.c:691
> 
> When I add watch to *(&g), gcc::context *g is restored ^ and 
> gcc:context::m_passes and gcc:context::m_dumps are set to an inaccessible 
> address.
> 
> Is my GGC construct correct?

Back when we introduced the context and the pass_manager (called the
"pipeline" in the initial patch submissions), those two classes were
GTY-marked, but I reverted the change in r201887 (aka
5d068519b66a37ab391c427d0aac13f66a9b5c4e):

Revert my last two changes, r201865 and r201864

2013-08-20  David Malcolm  

Revert my last two changes, r201865 and r201864:

Revert r201865:
2013-08-20  David Malcolm  

Make opt_pass and gcc::pass_manager be GC-managed, so that pass
instances can own GC refs.

* Makefile.in (GTFILES): Add pass_manager.h and tree-pass.h.
* context.c (gcc::context::gt_ggc_mx): Traverse passes_.
(gcc::context::gt_pch_nx): Likewise.
(gcc::context::gt_pch_nx):  Likewise.
* ggc.h (gt_ggc_mx ): New.
(gt_pch_nx_with_op ): New.
(gt_pch_nx ): New.
* passes.c (opt_pass::gt_ggc_mx): New.
(opt_pass::gt_pch_nx): New.
(opt_pass::gt_pch_nx_with_op): New.
(pass_manager::gt_ggc_mx): New.
(pass_manager::gt_pch_nx): New.
(pass_manager::gt_pch_nx_with_op): New.
(pass_manager::operator new): Use
ggc_internal_cleared_alloc_stat rather than xcalloc.
* pass_manager.h (class pass_manager): Add GTY((user)) marking.
(pass_manager::gt_ggc_mx): New.
(pass_manager::gt_pch_nx): New.
(pass_manager::gt_pch_nx_with_op): New.
* tree-pass.h (class opt_pass): Add GTY((user)) marking.
(opt_pass::operator new): New.
(opt_pass::gt_ggc_mx): New.
(opt_pass::gt_pch_nx): New.
(opt_pass::gt_pch_nx_with_op): New.

Revert r201864:
2013-08-20  David Malcolm  

* Makefile.in (GTFILES): Add context.h.
* context.c (gcc::context::operator new): New.
(gcc::context::gt_ggc_mx): New.
(gcc::context::gt_pch_nx): New.
(gcc::context::gt_pch_nx): New.
* context.h (gcc::context): Add GTY((user)) marking.
(gcc::context::operator new): New.
(gcc::context::gt_ggc_mx): New.
(gcc::context::gt_pch_nx): New.
(gcc::context::gt_pch_nx): New.
(g): Add GTY marking.
(gt_ggc_mx (gcc::context *)): New.
(gt_pch_nx (gcc::context *)): New.
(gt_pch_nx (gcc::context *ctxt, gt_pointer_operator op,
void *cookie)): New.
* gengtype.c (open_base_files) : Add context.h.

Looking over the list archives, I found this reason for the revert:
https://gcc.gnu.org/ml/gcc/2013-08/msg00214.html
the integration of GTY into context and pass_manager wasn't fully-baked,
and was causing PCH crashes.  Looks like I didn't go back and fully
debug the issue; sorry.

As for the issue you're seeing... I'm guessing you've put the "skip"
clauses on m_passes and m_dumps as a workaround for the issue from last
year, but they don't seem in themselves to be valid: the context is
GTY-marked, and hence saved to/restored from PCH (albeit buggily,
presumably), but the skip clauses mean that those fields aren't
interacting with PCH, merely copied as raw bytes to/from disk, and so
those pointers are going to be pointing to the address they pointed to
in the process that created the PCH, which will likely be nonsensical in
the process reading the PCH file, which would explain the symptoms
you're seeing.

For now, maybe keep the

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Diego Novillo]

On Thu, Jul 24, 2014 at 11:47 AM, Diego Novillo  wrote:

> If sourceware has enough room, I suppose they could be converted into
> an appropriate format and stored in sourceware's ftp space. Could you
> take care of the conversion, upload and publishing, in case the
> original format is not desirable?

Forgot to add: I still have the 2013 videos in raw form, if you want
to do the same thing to them.


Diego.

Re: Does -fdump-tree-original-raw dumps out the full AST?

[Diego Novillo]

On Thu, Jul 24, 2014 at 11:57 AM, Francois Berenger
 wrote:
> On Thu, Jul 24, 2014 at 4:29 PM, Diego Novillo  wrote:
>> On Thu, Jul 24, 2014 at 7:17 AM, Francois Berenger
>>  wrote:
>>
>>> Complete in the sense that, by parsing back this text file
>>> with an external program it would be possible to reconstruct the original 
>>> AST
>>> that gcc was working on (and dumped out).
>>
>> It isn't. These dumps are meant to be debugging aids. It is not
>> possible to reconstruct the original program out of them.
>
> Would it be possible to make these dumps complete?
> Let's say for the C frontend of gcc.

That's likely to be a significant effort. The tree representation is
not really streamable. The front end keeps a lot of state in-memory
that is not attached to the tree themselves.

There was some preliminary effort to achieve this with the pre-parsed
headers project (a precursor to C++ modules). We've since abandoned
the effort, but you can still get at the code and documentation:
https://gcc.gnu.org/wiki/pph


Diego.

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Diego Novillo]

On Thu, Jul 24, 2014 at 11:36 AM, Joseph S. Myers
 wrote:
> On Thu, 24 Jul 2014, Diego Novillo wrote:
>
>> Sessions were recorded on video. We will be publishing them from
>> the GNU Tools Google+ page when they are available.
>
> I take it they'll be available in an unencumbered format such as WebM, not
> just MP4?

No clue. I didn't record the videos.

To make them available via the GNU Tools page, we will need to share
them using G+ tools and format.  I think G+ uses the same encoding
used by Youtube. I know enough to smash the button that makes the
video available, but I never bothered with the details.

If sourceware has enough room, I suppose they could be converted into
an appropriate format and stored in sourceware's ftp space. Could you
take care of the conversion, upload and publishing, in case the
original format is not desirable?

Thanks. Diego.

> (Some of the video links from the Cauldron 2013 page don't work
> for me in Firefox - I don't know how to get YouTube to make a given video
> available in an unencumbered format.  And using youtube_dl to interrogate
> the available formats for other videos, I see that some that are available
> in WebM don't have it in as high as resolution as the MP4 versions - we
> ought to ensure the highest-resolution version is available in an
> unencumbered format.)
>
> In accordance with GNU principles we should be making the videos available
> without depending on non-free JavaScript as well (I don't know if Google+
> makes videos readily available without JS or with only free JS).  I've
> just added a link to
> https://www.gnu.org/philosophy/whats-wrong-with-youtube.html above the
> list of videos on https://gcc.gnu.org/wiki/cauldron2013 so that people are
> first pointed to a free software way of obtaining the videos.  Some
> similar link may be needed from the 2014 page to ensure free software
> access to videos is recommended before any non-free means of access.  (If
> Google+ provides stable URLs for direct links to WebM files of the videos,
> or for pages that show the videos without non-free JS, just linking to
> those is of course simplest.)
>
> I'd say the videos should also be freely licensed if possible, with the
> license explicitly stated where the videos are posted - of course that
> needs approval from the speakers as well as from whoever may own rights in
> the video itself (and I'm not sure what the GNU recommendation is for
> licenses on videos about free software, so that should be determined
> first).
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: Slides from Cauldron talks

[Giuseppe Scrivano]

David Edelsohn  writes:

> On Thu, Jul 24, 2014 at 2:19 AM, Tobias Burnus  wrote:
>> David Malcolm wrote:
>>>
>>> I didn't see a place to post slides for Cauldron talks, so am posting
>>> links to them here.
>>
>>
>> I have added the links to
>> https://gcc.gnu.org/wiki/cauldron2014#Slides_and_Notes
>>
>>
>>> Does anyone know if any Cauldron talks were recorded?
>>
>>
>> At least the ones in Lecture Theatre One were. However, I don't know when
>> the organizers will upload the videos.
>
> The videos will be uploaded to the GNU Tools Google+ page when available.

would it make sense to ask FSF to upload these videos to 
ftp://ftp.gnu.org/video/?

Regards,
Giuseppe

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Joseph S. Myers]

On Thu, 24 Jul 2014, Diego Novillo wrote:

> On Thu, Jul 24, 2014 at 11:36 AM, Joseph S. Myers
>  wrote:
> > On Thu, 24 Jul 2014, Diego Novillo wrote:
> >
> >> Sessions were recorded on video. We will be publishing them from
> >> the GNU Tools Google+ page when they are available.
> >
> > I take it they'll be available in an unencumbered format such as WebM, not
> > just MP4?
> 
> No clue. I didn't record the videos.
> 
> To make them available via the GNU Tools page, we will need to share
> them using G+ tools and format.  I think G+ uses the same encoding
> used by Youtube. I know enough to smash the button that makes the
> video available, but I never bothered with the details.
> 
> If sourceware has enough room, I suppose they could be converted into
> an appropriate format and stored in sourceware's ftp space. Could you
> take care of the conversion, upload and publishing, in case the
> original format is not desirable?

Given the original files on sourceware I'm happy to use ffmpeg to convert 
them to WebM at a similar bit-rate (though someone else may have more 
experience and a better idea of the best configuration for the conversion 
- I'd just be following instructions such as 
).  (If there's space I think we 
should have both the original files and the WebM files there, to allow for 
future reencoding from the original to whatever better unencumbered 
formats may become available in future to replace WebM.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Diego Novillo]

On Thu, Jul 24, 2014 at 12:21 PM, Joseph S. Myers
 wrote:
> On Thu, 24 Jul 2014, Diego Novillo wrote:
>
>> On Thu, Jul 24, 2014 at 11:36 AM, Joseph S. Myers
>>  wrote:
>> > On Thu, 24 Jul 2014, Diego Novillo wrote:
>> >
>> >> Sessions were recorded on video. We will be publishing them from
>> >> the GNU Tools Google+ page when they are available.
>> >
>> > I take it they'll be available in an unencumbered format such as WebM, not
>> > just MP4?
>>
>> No clue. I didn't record the videos.
>>
>> To make them available via the GNU Tools page, we will need to share
>> them using G+ tools and format.  I think G+ uses the same encoding
>> used by Youtube. I know enough to smash the button that makes the
>> video available, but I never bothered with the details.
>>
>> If sourceware has enough room, I suppose they could be converted into
>> an appropriate format and stored in sourceware's ftp space. Could you
>> take care of the conversion, upload and publishing, in case the
>> original format is not desirable?
>
> Given the original files on sourceware I'm happy to use ffmpeg to convert
> them to WebM at a similar bit-rate (though someone else may have more
> experience and a better idea of the best configuration for the conversion

I need 147Gb of free space, but my home directory on gcc.gnu.org only has 117Gb.

overseers, any way to create room somewhere on sourceware for me to
upload the 2013 videos?


Diego.

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Joseph S. Myers]

On Thu, 24 Jul 2014, Diego Novillo wrote:

> >> If sourceware has enough room, I suppose they could be converted into
> >> an appropriate format and stored in sourceware's ftp space. Could you
> >> take care of the conversion, upload and publishing, in case the
> >> original format is not desirable?
> >
> > Given the original files on sourceware I'm happy to use ffmpeg to convert
> > them to WebM at a similar bit-rate (though someone else may have more
> > experience and a better idea of the best configuration for the conversion
> 
> I need 147Gb of free space, but my home directory on gcc.gnu.org only has 
> 117Gb.
> 
> overseers, any way to create room somewhere on sourceware for me to
> upload the 2013 videos?

Given that the converted videos would probably take up a similar amount of 
space to the originals to have a similar quality (and until the MP4 
patents all expire - around 2027, apparently, by which time 147Gb may be a 
negligible amount of space - we'll want both the originals and the best 
available unencumbered format), maybe we should ask gnu-prog-discuss what 
the best place is for hosting large amounts of high-quality GNU-related 
video?  The issue can hardly be unique to the Cauldrons.

(The above assumes the originals are MP4 or some other patent-encumbered 
format.  If an unencumbered format there's no real point in converting 
unless the result of conversion is much smaller than the original - which 
might well be the case if the original format is one that only compresses 
individual frames, such formats also being more likely to be 
unencumbered.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Symtab node table introduction and GGC issues

[Martin Liška]

On 07/24/2014 05:53 PM, David Malcolm wrote:

On Thu, 2014-07-24 at 16:23 +0100, Martin Liška wrote:

Hello,
 I would like to encapsulate all symtab_nodes to a class called
'symtab'.

Thanks!


  To respect gcc:context, I would like to add the class to global
context (gcc::context) and I have troubles with GTY and GGC.

design:

class GTY(()) symtab
{
public:
symtab_node* GTY(()) nodes;
};

class GTY(()) context
{
public:
context () {}
void init ();

/* Pass-management.  */
pass_manager *get_passes () { gcc_assert (m_passes); return m_passes; }

/* Handling dump files.  */
dump_manager *get_dumps () {gcc_assert (m_dumps); return m_dumps; }

/* Symbol table.  */
symtab *get_symtab () { gcc_assert (symbol_table); return symbol_table; }

/* Symbol table.  */
symtab * GTY(()) symbol_table;

private:
/* Pass-management.  */
pass_manager * GTY((skip)) m_passes;

/* Dump files.  */
dump_manager * GTY((skip)) m_dumps;
}; // class context

} // namespace gcc

/* The global singleton context aka "g".
 (the name is chosen to be easy to type in a debugger).  */
extern GTY(()) gcc::context *g;



gcc:context in created by g = ggc_cleared_alloc (); and 
g->symbol_table too.
My problem is that during pg_pch_restore:
#3  0x00850043 in gt_pch_restore (f=0x1ac9100) at 
../../gcc/ggc-common.c:691

When I add watch to *(&g), gcc::context *g is restored ^ and 
gcc:context::m_passes and gcc:context::m_dumps are set to an inaccessible address.

Is my GGC construct correct?

Back when we introduced the context and the pass_manager (called the
"pipeline" in the initial patch submissions), those two classes were
GTY-marked, but I reverted the change in r201887 (aka
5d068519b66a37ab391c427d0aac13f66a9b5c4e):

 Revert my last two changes, r201865 and r201864
 
 2013-08-20  David Malcolm  
 
 Revert my last two changes, r201865 and r201864:
 
 Revert r201865:

 2013-08-20  David Malcolm  
 
 Make opt_pass and gcc::pass_manager be GC-managed, so that pass

 instances can own GC refs.
 
 * Makefile.in (GTFILES): Add pass_manager.h and tree-pass.h.

 * context.c (gcc::context::gt_ggc_mx): Traverse passes_.
 (gcc::context::gt_pch_nx): Likewise.
 (gcc::context::gt_pch_nx):  Likewise.
 * ggc.h (gt_ggc_mx ): New.
 (gt_pch_nx_with_op ): New.
 (gt_pch_nx ): New.
 * passes.c (opt_pass::gt_ggc_mx): New.
 (opt_pass::gt_pch_nx): New.
 (opt_pass::gt_pch_nx_with_op): New.
 (pass_manager::gt_ggc_mx): New.
 (pass_manager::gt_pch_nx): New.
 (pass_manager::gt_pch_nx_with_op): New.
 (pass_manager::operator new): Use
 ggc_internal_cleared_alloc_stat rather than xcalloc.
 * pass_manager.h (class pass_manager): Add GTY((user)) marking.
 (pass_manager::gt_ggc_mx): New.
 (pass_manager::gt_pch_nx): New.
 (pass_manager::gt_pch_nx_with_op): New.
 * tree-pass.h (class opt_pass): Add GTY((user)) marking.
 (opt_pass::operator new): New.
 (opt_pass::gt_ggc_mx): New.
 (opt_pass::gt_pch_nx): New.
 (opt_pass::gt_pch_nx_with_op): New.
 
 Revert r201864:

 2013-08-20  David Malcolm  
 
 * Makefile.in (GTFILES): Add context.h.

 * context.c (gcc::context::operator new): New.
 (gcc::context::gt_ggc_mx): New.
 (gcc::context::gt_pch_nx): New.
 (gcc::context::gt_pch_nx): New.
 * context.h (gcc::context): Add GTY((user)) marking.
 (gcc::context::operator new): New.
 (gcc::context::gt_ggc_mx): New.
 (gcc::context::gt_pch_nx): New.
 (gcc::context::gt_pch_nx): New.
 (g): Add GTY marking.
 (gt_ggc_mx (gcc::context *)): New.
 (gt_pch_nx (gcc::context *)): New.
 (gt_pch_nx (gcc::context *ctxt, gt_pointer_operator op,
 void *cookie)): New.
 * gengtype.c (open_base_files) : Add context.h.

Looking over the list archives, I found this reason for the revert:
https://gcc.gnu.org/ml/gcc/2013-08/msg00214.html
the integration of GTY into context and pass_manager wasn't fully-baked,
and was causing PCH crashes.  Looks like I didn't go back and fully
debug the issue; sorry.

As for the issue you're seeing... I'm guessing you've put the "skip"
clauses on m_passes and m_dumps as a workaround for the issue from last
year, but they don't seem in themselves to be valid: the context is
GTY-marked, and hence saved to/restored from PCH (albeit buggily,
presumably), but the skip clauses mean that those fields aren't
interacting with PCH, merely copied as raw bytes to/from disk, and so
those pointers are going to be pointing to the address they pointed to
in the process that created the PCH, which will likely be nonsensical in
the process reading the PCH file, which would explain the symptoms
you're seeing.

For now, mayb

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Joseph S. Myers]

FWIW, it seems

http://audio-video.gnu.org/

is official GNU hosting for videos.  But I don't know if they'll archive 
the original files for later conversion to future unencumbered formats, 
and of course you still need somewhere to put the 147Gb of files to get 
them to the audio-video people.  I suppose it may be worth filing an issue 
in http://savannah.gnu.org/task/?group=audio-video explaining what files 
you have and asking how to provide them.

We should be able to assume that having videos hosted there (possibly in 
addition to other places) is sufficient for GNU purposes (if that project 
is provided with the source material in as good a quality as provided to 
some other site, I hope they will ensure they provide the video in an 
unencumbered format and readily accessible with only free software with 
quality as good as on the other site).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Does -fdump-tree-original-raw dumps out the full AST?

[Florian Weimer]

On 07/24/2014 05:57 PM, Francois Berenger wrote:

Would it be possible to make these dumps complete?
Let's say for the C frontend of gcc.


The C front end currently does not produce an AST in the usual sense. 
It would certainly be possible to dump out the trees it produces, but 
most control flow statements have already been rewritten at this stage, 
so it may not be helpful to you.


--
Florian Weimer / Red Hat Product Security

gcc-4.8-20140724 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch 
revision 213031

You'll find:

 gcc-4.8-20140724.tar.bz2 Complete GCC

  MD5=c043054df867ee3fda50919003757e74
  SHA1=9ee4e2411cd66727d59faf0f49a2e913df8a8c23

Diffs from 4.8-20140717 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.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.

New Mail

[Admin]

Read Prize Information In Attachment

MGLP.docx
Description: Binary data