a hello, and a few gcc v4+ implementation questions
Hello, I've just joined the list as I've returned to the GNU world after almost 9 years. Feels good to be back. :) I've been reading up on GCC through various articles online and have come to understand that GCC now is being written using C++. Would I be correct in my assumption that the older (1998 with 2003 enh) C++ standard is being used? or is it the brand new C++11 (which seems highly improbable). Thanks and Regards, ~Mayuresh
Re: a hello, and a few gcc v4+ implementation questions
On Thu, Jan 3, 2013 at 2:50 AM, Mayuresh Kathe wrote: > Hello, I've just joined the list as I've returned to the GNU world after > almost 9 years. > Feels good to be back. :) > > I've been reading up on GCC through various articles online and have > come to understand that GCC now is being written using C++. > Would I be correct in my assumption that the older (1998 with 2003 enh) > C++ standard is being used? or is it the brand new C++11 (which seems > highly improbable). Right, it's a restricted subset of C++03 at this time. -- James
Copyright assignment forms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I like to contribute some patches to gcc. Therefor im asking kindly for the copyright assignment forms and advice. Cheers Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ5XFlAAoJEB3HOsWs+KJbF9wH/RtQwEd8PiF/Xqz8G4NjD1kR 4HkmcPHAvZO8NO8xLkin2HCz0YzCVYbdsQ9B12EFTfXEuvi0JzfxD92MtnMzgIz8 RaounCO4uxaPEGS1YsXkMMbgVGiOOTm+mTsjqJ0YKFEoNnzG3w23eumyZHlo5u7V WW5uj9/l88nwCyTs2AiOBEOdHAyiQjW5P16589dQwCakWotmEGI6BuWf4Wm3eHb+ WKaVWzzSSNECl2tc5I/AwiTN948iAFmrNYpgm6dAv6nLlH3LO5cRgfWiFmY9eqEE ZZhVNjPVEt1+35FWgDo5sQK7N6VZaJz8CzqS6mPMjf5twkN5o76AEjPmbrY98vk= =DUKD -END PGP SIGNATURE-
Re: Fwd: Updating copyright dates automatically
On Wed, 2 Jan 2013, Jeff Law wrote: > I've always found lazily updating the copyright years to be error prone. If > we could just update all of them now, which is OK according to the FSF > guidelines we could avoid one class of problems. I suspect dealing with generated files will be more complicated for GCC than for glibc. There are more of them, and many of them are architecture-specific with update rules in architecture makefile fragments, so a simple "make" for one architecture won't regenerate them all as it does for glibc. Some may require unusual tools, or special versions of tools, or not have makefile rules at all (e.g. the various ARM files generated using O'Caml). Some may not be listed in contrib/gcc_update either, further complicating identifying them all, although that's certainly a useful place to start getting information about generated files in the source tree. And it's often the case for generated files in GCC that the generator has both its own copyright notice at the top of the file, and a later one that gets put in the generated file, so both need updating before regenerating the generated file (but update-copyright only updates one copyright notice per file). It may make sense to start automation with a limited set of files, under the gcc/ directory only and excluding both generated files and their sources, before gradually extending what's covered by automation for updating copyright notices. Other ways of looking for generated files, apart from targets in makefiles and makefile fragments that update files in srcdir, and apart from the lists in gcc_update, include looking for characteristic comments such as "automatically generated", "Generated automatically", "do not edit manually" and "-*- buffer-read-only: t -*-" that various generators output. (When such things are found, appropriate makefile rules and gcc_update entries could then be added to make future regenerations easier.) -- Joseph S. Myers jos...@codesourcery.com
stabs support in binutils, gcc, and gdb
What is the status of STABS support? I know that there is considerably more activity around DWARF than STABS. It appears that STABS is largely in maintenance mode. Are there any plans to deprecate STABS support? If STABS enhancements were made and posted would they be frowned upon? Or would they be reviewed for possible inclusion in a future release? [We have copyright assignments in place for past and future changes to BINUTILS, GCC, and GDB -- and it took almost 4 years from start to finish -- I do not want to ever have to go through that again with the company lawyers! So, paperwork should not be an issue.] I know that DWARF is more expressive than STABS. And if it didn't cause such an explosion in disk space usage, we would probably have switched from STABS to DWARF years ago. Switching to DWARF causes our build products directory (which contains *NONE* of the intermediate files) to swell from 1.2 GB to 11.5 GB. Ouch! The DWARF ELF files are 8-12 times the size of the STABS ELF files. If the DWARF files were, say, a factor of 2 the size of the STABS files, I could probably sell people on switching to DWARF; but, a factor of 8 to 12 is too much. Thanks. David
Re: stabs support in binutils, gcc, and gdb
On Thu, Jan 3, 2013 at 5:21 PM, David Taylor wrote: > What is the status of STABS support? > > I know that there is considerably more activity around DWARF than STABS. > It appears that STABS is largely in maintenance mode. Are there any > plans to deprecate STABS support? If STABS enhancements were made and > posted would they be frowned upon? Or would they be reviewed for > possible inclusion in a future release? > > [We have copyright assignments in place for past and future changes to > BINUTILS, GCC, and GDB -- and it took almost 4 years from start to > finish -- I do not want to ever have to go through that again with the > company lawyers! So, paperwork should not be an issue.] > > I know that DWARF is more expressive than STABS. And if it didn't cause > such an explosion in disk space usage, we would probably have switched > from STABS to DWARF years ago. > > Switching to DWARF causes our build products directory (which contains > *NONE* of the intermediate files) to swell from 1.2 GB to 11.5 GB. > Ouch! The DWARF ELF files are 8-12 times the size of the STABS ELF > files. > > If the DWARF files were, say, a factor of 2 the size of the STABS files, > I could probably sell people on switching to DWARF; but, a factor of 8 > to 12 is too much. The idea was to have a working DWARF -> STABS translator, eventually as part of binutils. Richard. > Thanks. > > David
Re: stabs support in binutils, gcc, and gdb
> What is the status of STABS support? In terms of GDB, it is no longer actively maintained. But if you submit patches, I will do my best to review them. -- Joel
Re: stabs support in binutils, gcc, and gdb
Hi David, What is the status of STABS support? Essentially it is in maintenance mode. But this is due to lack of developers interested in extending STABS support, rather than a policy of maintenance-only. Are there any plans to deprecate STABS support? No, none. If STABS enhancements were made and posted would they be frowned upon? Or would they be reviewed for possible inclusion in a future release? No, they would be reviewed and, assuming that they are suitable, they would be accepted for inclusion in future releases. Switching to DWARF causes our build products directory (which contains *NONE* of the intermediate files) to swell from 1.2 GB to 11.5 GB. Ouch! The DWARF ELF files are 8-12 times the size of the STABS ELF files. If the DWARF files were, say, a factor of 2 the size of the STABS files, I could probably sell people on switching to DWARF; but, a factor of 8 to 12 is too much. Have you tried using a DWARF compression tool like dwz ? http://gcc.gnu.org/ml/gcc/2012-04/msg00686.html Or maybe the --compress-debug-sections option to objcopy ? Cheers Nick
Re: stabs support in binutils, gcc, and gdb
> "David" == David Taylor writes: David> It appears that STABS is largely in maintenance mode. Are there any David> plans to deprecate STABS support? If STABS enhancements were made and David> posted would they be frowned upon? Or would they be reviewed for David> possible inclusion in a future release? In gdb things are rarely pre-emptively deprecated like this. If someone wants to maintain the stabs code, then it will stay alive. The most important thing is having a reasonably responsive maintainer -- it is the un-maintained code that tends to slowly rot and then eventually be deleted. Tom
Control dependence vs. builtin_unreachable
Hello,
Consider the following test case:
void bar (void);
int foo (int b, int c, int d)
{
int r = 0;
if (b)
res = b * 2 + 4;
if (c)
{
if (d)
r = res;
else
__builtin_unreachable ();
}
return r;
}
This is typical for code in GCC itself in places where
gcc_unreachable() is used.
The corresponding CFG looks like this:
+-+
| bb0 |
+-+
|
|
v
+-+
| bb2 | -+
+-+ |
| |
| |
v |
+-+ |
| bb3 | |
+-+ |
| |
| |
v |
+-+ +-+ |
| bb8 | <-- | bb4 | <+
+-+ +-+
| |
| |
| v
| +-+ +-+
| | bb5 | --> | bb7 |
| +-+ +-+
| |
| |
| v
| +-+
| | bb6 |
| +-+
| |
| |
| v
| +-+
+---> | bb9 |
+-+
|
|
v
+-+
| bb1 |
+-+
In the postdominator tree of the test case, the basic block containing
the call to __builtin_unreachable is postdominated by the EXIT block
(either via fake edges to exit, or by the dead-end handling code in
dominance.c), which makes the "return r" statement control-dependent
on "if (c)" and "if (d)". See the attached CFG dump (t.c.012.cfg.dot)
and the corresponding CFG, postdominator tree, and control dependence
graphs (cdg_bad.dot). Here is the CDG in ascii:
+-+
| bb0 |
+-+
|
+--+---+
| | |
v v v
+-+ +-+ +-+
| bb2 | | bb4 | | bb1 |
+-+ +-+ +-+
| |
| +---+---+
| | | |
v v v |
+-+ +-+ +-+ |
| bb3 | | bb5 | | bb8 | |
+-+ +-+ +-+ |
| |
+--+---+ |
| | | |
v v v |
+-+ +-+ +-+ |
| bb6 | | bb7 | | bb9 |<--+
+-+ +-+ +-+
My question here, is whether __builtin_unreachable (or any other
empty, dead-end basic block) should be taken into account for control
dependence.
Since, by definition, __builtin_unreachable is not reachable, so the
statement "return r" is always executed. So it seems to me that the
"correct" CDG should look like the one in the attached cdg_wish.dot,
or in ascii:
+-+
| bb0 |
+-+
|
+--+---+---+
| | | |
v v v v
+-+ +-+ +-+ +-+
| bb2 | | bb4 | | bb9 | | bb1 |
+-+ +-+ +-+ +-+
| |
| +---+
| | |
v v v
+-+ +-+ +-+
| bb3 | | bb5 | | bb8 |
+-+ +-+ +-+
|
+--+
| |
v v
+-+ +-+
| bb6 | | bb7 |
+-+ +-+
These "false" control dependences are in my way for a couple of
tree-ssa-sink improvements, and probably are harmful for other
control-dependence based transformations as well. It also makes the
control dependence graph larger and more complex than necessary.
Thoughts/comments, ye respected experienced folks? :-)
Thanks,
Ciao!
Steven
cdg_bad.dot
Description: Binary data
cdg_wish.dot
Description: Binary data
t.c.012t.cfg.dot
Description: Binary data
Re: Re: Query for Empty Structure Extension.
Thanks for the quick reply.
As per the C++ standard (ISO/IEC 14882, 1998 first edition)
Section 9: Classes definition says.
Complete objects and member subobjects of class type shall have nonzero size.
Corrent me if i'm wrong here, but from this i had concluded empty object and
structures are not part of C++ standard (or maybe my copy of standard is old).
And they're implemented as part of GCC/G++ extension.
If so, then my question stands that how do we decide that a structure is empty ?
As per the definition of empty structures extension, should have size 1 byte in
g++.
So what do we call structures which return size 0 in g++ ?
Eg:
struct T4
{long int:0;}t4;
//has size 1 in g++
whereas
struct T1
{struct{}a[0]; }t1;
//has size 0 in g++
As based on the size of object, optimization can take place at the caller and
callee side (eg: ignoring of records with 0 size in the argument list of
variable arguments to reduce stack operation).
And since G++/GCC has ABI compatibility with several other compilers, i was
hoping if there would be some rule to distinguish as to when to assign 1 byte
and when 0 for empty structures.
Warm Regards,
Naveen
--- Original Message ---
Sender : Jonathan Wakely
Date : Jan 03, 2013 00:17 (GMT+09:00)
Title : Re: Query for Empty Structure Extension.
On 2 January 2013 14:32, NAVEEN CHANDRAKAR wrote:
>
> My question is what is the definition/grammer of empty structure. As i
> couldn't find it covered in C/Cxx standard document.
The page you linked to defines a GCC extension to the C language, so
if course it's not in the C standard. As the page says, ISO C++ allows
empty structures, it's just a class with no members, which is valid in
ISO C++ anyway.
Re: Control dependence vs. builtin_unreachable
On 01/03/2013 12:01 PM, Steven Bosscher wrote:
Hello,
Consider the following test case:
void bar (void);
int foo (int b, int c, int d)
{
int r = 0;
if (b)
res = b * 2 + 4;
if (c)
{
if (d)
r = res;
else
__builtin_unreachable ();
}
return r;
}
This is typical for code in GCC itself in places where
gcc_unreachable() is used.
The corresponding CFG looks like this:
+-+
| bb0 |
+-+
|
|
v
+-+
| bb2 | -+
+-+ |
| |
| |
v |
+-+ |
| bb3 | |
+-+ |
| |
| |
v |
+-+ +-+ |
| bb8 | <-- | bb4 | <+
+-+ +-+
| |
| |
| v
| +-+ +-+
| | bb5 | --> | bb7 |
| +-+ +-+
| |
| |
| v
| +-+
| | bb6 |
| +-+
| |
| |
| v
| +-+
+---> | bb9 |
+-+
|
|
v
+-+
| bb1 |
+-+
Presumably BB7 was created in response to the builtin_unreachable? One
could argue that an empty dead-end basic block should just be removed
and the CFG appropriately simplified.
You might want to look at a discussion from Oct/Nov 2011 "New pass to
delete unexecutable paths in the CFG" which touches on some of this
stuff. It's not 100% the same, but the concept of eliminating edges
from the CFG which we can never traverse in a conforming program applies
to both your example and the stuff I was playing with.
jeff
Re: stabs support in binutils, gcc, and gdb
On Thu, Jan 3, 2013 at 12:02 PM, Tom Tromey wrote: >> "David" == David Taylor writes: > > David> It appears that STABS is largely in maintenance mode. Are there any > David> plans to deprecate STABS support? If STABS enhancements were made and > David> posted would they be frowned upon? Or would they be reviewed for > David> possible inclusion in a future release? > > In gdb things are rarely pre-emptively deprecated like this. > If someone wants to maintain the stabs code, then it will stay alive. > The most important thing is having a reasonably responsive maintainer -- > it is the un-maintained code that tends to slowly rot and then > eventually be deleted. AIX still uses STABS. GCC produces it and GDB consumes it. Recent releases of AIX now support DWARF as well, but GCC and GDB have not been converted to use it on AIX. - David
Re: stabs support in binutils, gcc, and gdb
On 03 Jan 2013, at 21:53, David Edelsohn wrote: > AIX still uses STABS. GCC produces it and GDB consumes it. More precisely, AIX uses Stabx. It's similar to Stabs, but different in quite a few ways. To add to the confusion, GCC produces and GDB consumes a hybrid of Stabs and Stabx on AIX for some reason (xlc and the native dbx produce/consume pure Stabx, which is not understood by GDB; conversely, dbx does not understand the GCC/GDB Stabx-Stabs hybrid). Jonas
Re: stabs support in binutils, gcc, and gdb
On Thu, Jan 3, 2013 at 4:53 PM, Jonas Maebe wrote: > > On 03 Jan 2013, at 21:53, David Edelsohn wrote: > >> AIX still uses STABS. GCC produces it and GDB consumes it. > > More precisely, AIX uses Stabx. It's similar to Stabs, but different in quite > a few ways. To add to the confusion, GCC produces and GDB consumes a hybrid > of Stabs and Stabx on AIX for some reason (xlc and the native dbx > produce/consume pure Stabx, which is not understood by GDB; conversely, dbx > does not understand the GCC/GDB Stabx-Stabs hybrid). That description is not entirely correct. GDB understands XLC stabs debugging information and GCC can be instructed to emit the subset of stabs information that AIX dbx can consume. - David
Re: stabs support in binutils, gcc, and gdb
On Thu, Jan 3, 2013 at 9:52 AM, nick clifton wrote: >> Switching to DWARF causes our build products directory (which contains >> *NONE* of the intermediate files) to swell from 1.2 GB to 11.5 GB. >> Ouch! The DWARF ELF files are 8-12 times the size of the STABS ELF >> files. >> >> If the DWARF files were, say, a factor of 2 the size of the STABS files, >> I could probably sell people on switching to DWARF; but, a factor of 8 >> to 12 is too much. > > > Have you tried using a DWARF compression tool like dwz ? > > http://gcc.gnu.org/ml/gcc/2012-04/msg00686.html > > Or maybe the --compress-debug-sections option to objcopy ? Yeah, that would be really useful data to have. Plus, there's also -gdwarf-4 -fdebug-types-section. So while plain dwarf may be 8-12x of stabs, progress has been made, and we shouldn't base decisions on incomplete analyses. If we had data to refute (or substantiate) claims that dwarf was *still* X% larger than stabs and people were still avoiding dwarf because of it, that would be really useful.
Re: stabs support in binutils, gcc, and gdb
> AIX still uses STABS. GCC produces it and GDB consumes it. > > Recent releases of AIX now support DWARF as well, but GCC and GDB have > not been converted to use it on AIX. Note that GNU ld is now completely usable; and one of the side effects of using GNU ld is the ability to switch over to DWARF, even on older versions such as AIX 5.1. -- Joel
Re: Re: Re: Query for Empty Structure Extension.
Thanks James. I understood it now.
--- Original Message ---
Sender : James Dennett
Date : Jan 04, 2013 05:28 (GMT+09:00)
Title : Re: Re: Query for Empty Structure Extension.
On Thu, Jan 3, 2013 at 11:35 AM, NAVEEN CHANDRAKAR wrote:
Thanks for the quick reply.
As per the C++ standard (ISO/IEC 14882, 1998 first edition)
Section 9: Classes definition says.
Complete objects and member subobjects of class type shall have nonzero size.
Corrent me if i'm wrong here, but from this i had concluded empty object and
structures are not part of C++ standard (or maybe my copy of standard is old).
I'm afraid you are indeed wrong. The correct conclusion is that empty
structures have nonzero size.
And they're implemented as part of GCC/G++ extension.
If so, then my question stands that how do we decide that a structure is empty ?
As per the definition of empty structures extension, should have size 1 byte in
g++.
So what do we call structures which return size 0 in g++ ?
Eg:
struct T4
{long int:0;}t4;
//has size 1 in g++
whereas
struct T1
{struct{}a[0]; }t1;
//has size 0 in g++
That's a zero-sized array, which is a GCC extension.
-- James
