* Re: Compiling GCC with g++: a report
@ 2005-05-25 5:26 Paul Schlie
2005-05-25 6:10 ` DJ Delorie
0 siblings, 1 reply; 97+ messages in thread
From: Paul Schlie @ 2005-05-25 5:26 UTC (permalink / raw)
To: Gabriel Dos Reis, DJ Delorie; +Cc: gcc
> Gabriel Dos Reis <gdr at integrable-solutions dot net>
>| J Delorie <dj at redhat dot com> writes:
>| And the target can do this in tm.c:
>|
>| class machine_mode SImode ("SI", 32);
>| class machine_mode V4QImode ("V4QI", 8, 0, 8, 4);
>|
>| Then, the MI parts can obtain a mode with certain characteristics,
>| enumerate available modes, and get info about a given mode, but don't
>| have a compile-time identifier for a "well-known named" mode.
>
> I like it.
>
> However, that is orthogonal to changing the plain numeric value "0" to
> the named constant with current machinery, don't you believe?
Might it be more desirable for the compiler's code to only refer to target
"type" modes as opposed to "size" modes? Thereby avoiding the temptation to
incorrectly assume that any particular "size" mode, like SImode corresponds
to the targets int or int* mode for example?
Thereby the compiler's code should only refer to "type" modes:
target_unit_mode:
target_word_mode:
target_vect_mode:
target_char_mode;
target_short_mode;
target_int_mode;
target_ptr_mode;
target_long_mode:
target_long_long_mode
...
Where then the target then defines their corresponding "size" modes:
class machine_mode target_unit_mode ("QI", 8);
class machine_mode target_word_mode ("HI", 16);
class machine_mode target_vect_mode ("SI", 32);
class machine_mode target_char_mode ("QI", 8);
class machine_mode target_short_mode ("HI",16);
class machine_mode target_int_mode ("HI", 32);
class machine_mode target_ptr_mode ("HI", 16);
class machine_mode target_long_mode ("SI", 32);
class machine_mode target_long_long_mode ("SI", 32);
...
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 5:26 Compiling GCC with g++: a report Paul Schlie @ 2005-05-25 6:10 ` DJ Delorie 2005-05-25 11:46 ` Paul Schlie 0 siblings, 1 reply; 97+ messages in thread From: DJ Delorie @ 2005-05-25 6:10 UTC (permalink / raw) To: schlie; +Cc: gdr, gcc > Might it be more desirable for the compiler's code to only refer to > target "type" modes as opposed to "size" modes? Not always, see my mail about Pmode. The problem isn't just how gcc refers to machine words, but that gcc assumes their usage is context independent or inflexible. For example, assuming int_mode is the same size as your general registers (esp when the target interface has a way of asking how big hard regs actually are). > Thereby avoiding the temptation to incorrectly assume that any > particular "size" mode, like SImode corresponds to the targets int > or int* mode for example? I'd like to call my modes "FREDmode" and "WILMAmode" and the MI parts shouldn't care at all. Yes, I want to define addfredwilma3 MD patterns. If they need an "unsigned int" mode, they should ask the target what "unsigned int" means (bits), and find a mode that matches that description. I'd like the MI to ask the target "I need to multiply these types/modes together, what modes should I promote them to, and what mode will the result be?" I don't want to have to define a huge list of "mode types" when MI can figure most of them out from a few BITS_PER_ defines, or from context. > Thereby the compiler's code should only refer to "type" modes: Don't type trees already have a machine_mode field? I.e. TYPE_MODE(integer_type) ? I know decls do. The target already has a set of bits-per-type settings, we can look up modes by size that way and assign them to tree TYPE nodes as needed. The target would need a new set of hooks for things like "mode for address of foo" or "mode of stack pointer" or "best mode for hard reg". The rest of gcc should avoid looking up modes in general, so it's ok for a lookup_integer_mode_by_bits() call to be expensive. Instead, the mode should be deduced (or copied) from the available operands. Perhaps a fast mode_wider_expanded() lookup for expanding multiplies. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 6:10 ` DJ Delorie @ 2005-05-25 11:46 ` Paul Schlie 2005-05-25 18:31 ` DJ Delorie 0 siblings, 1 reply; 97+ messages in thread From: Paul Schlie @ 2005-05-25 11:46 UTC (permalink / raw) To: DJ Delorie; +Cc: gdr, gcc > From: DJ Delorie <dj@redhat.com> >> Might it be more desirable for the compiler's code to only refer to >> target "type" modes as opposed to "size" modes? > > Not always, see my mail about Pmode. The problem isn't just how gcc > refers to machine words, but that gcc assumes their usage is context > independent or inflexible. For example, assuming int_mode is the same > size as your general registers (esp when the target interface has a > way of asking how big hard regs actually are). - ?? which was why it seemed to make sense to have the target neutral sources refer to "type" modes, i.e. target_int_mode, where then the target may declare class machine_mode target_int_mode ("HI", 16), to map it in a target specific way to whatever "size" mode it chooses? and correspondingly architectural type modes could define more generic non-type specific characteristics? target_unit_mode // presumably the target's smallest addressable datum. target_word_mode // presumably the target's largest addressable datum. as there seems no valid reason for the target neutral portion of the compiler to ever refer to XXmode under any circumstance? >> Thereby avoiding the temptation to incorrectly assume that any >> particular "size" mode, like SImode corresponds to the targets int >> or int* mode for example? > > I'd like to call my modes "FREDmode" and "WILMAmode" and the MI parts > shouldn't care at all. - understood, I think, therefore would expect the target to define something like: class machine_mode target_code_ptr_mode ("FRED", 24); class machine_mode target_rodata_prt_mode ("DINO", 24); class machine_mode target_rwdata_ptr_mode ("BARNEY", 16); class machine_mode target_stack_ptr_mode ("WILMA", 16); where correspondingly the MI portions of GCC utilizes the appropriate pointer mode as a function of the type of access being performed, where each may mapped as defined by the target to the same or distinct modes of it's choosing (where I believe the above four cover the four distinct type of semantic accesses GCC seems to need to deal with?) > patterns. If they need an "unsigned int" mode, they should ask the > target what "unsigned int" means (bits), and find a mode that matches > that description. I'd like the MI to ask the target "I need to > multiply these types/modes together, what modes should I promote them > to, and what mode will the result be?" - or as above, just where target specific machine_mode instance data is defined directly for each target data/pointer/architecture "type" mode? > I don't want to have to define a huge list of "mode types" when MI can > figure most of them out from a few BITS_PER_ defines, or from context. - understood, although I honestly don't believe there are that many, and it eliminates any possible confusion, and a host of other #defines. >> Thereby the compiler's code should only refer to "type" modes: > > Don't type trees already have a machine_mode field? > I.e. TYPE_MODE(integer_type) ? I know decls do. > > The target already has a set of bits-per-type settings, we can look up > modes by size that way and assign them to tree TYPE nodes as needed. > > The target would need a new set of hooks for things like "mode for > address of foo" or "mode of stack pointer" or "best mode for hard reg". > > The rest of gcc should avoid looking up modes in general, so it's ok > for a lookup_integer_mode_by_bits() call to be expensive. Instead, > the mode should be deduced (or copied) from the available operands. > Perhaps a fast mode_wider_expanded() lookup for expanding multiplies. - as you've noted, all the information GCC MI portion needs to "do the right thing" already exists scattered in various target definitions, but it hasn't prevented mode assumptions from being made, and XXmodes being hard-coded into the MI sources on occasion; which is the only reason that I thought that by forcing target_TYPE_mode's to be the only thing available, GCC would indirectly be forced to always to the "right thing"? ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 11:46 ` Paul Schlie @ 2005-05-25 18:31 ` DJ Delorie 2005-05-25 21:41 ` Paul Schlie 0 siblings, 1 reply; 97+ messages in thread From: DJ Delorie @ 2005-05-25 18:31 UTC (permalink / raw) To: schlie; +Cc: gdr, gcc > where then the target may declare class machine_mode > target_int_mode ("HI", 16), This is where we disagree. The *target* shouldn't map types to modes. The *MI* should map types to modes. The target just creates the modes it supports and describes them. The MI looks them up by description (NOT NAME). If the MI needs a 32 bit unsigned scalar, it does lookup_mode(32, M_SCALAR, M_UNSIGNED) and uses whatever gets returned. The fact that you're still trying to assign a "well known name" to a given type/mode/whatever means you haven't gotten away from the (to me) fundamental problem, that MI chooses modes according to what they're *for* instead of according to what they *are*. > target_unit_mode // presumably the target's smallest addressable datum. BImode in most cases, not really useful that way. > target_word_mode // presumably the target's largest addressable datum. BLKmode in all cases. Also not useful. > as there seems no valid reason for the target neutral portion of the > compiler to ever refer to XXmode under any circumstance? Ah, but in your case it *is* aware, it just calls it "target_word_mode" instead of "SImode" with all the same problems with assumptions. > where correspondingly the MI portions of GCC utilizes the appropriate > pointer mode as a function of the type of access being performed, In my case, the target has to check the attributes of the function/data to decide what kind of pointer to use. Again, "MI assuming" that all function pointers are the same is WRONG. > - understood, although I honestly don't believe there are that many, and > it eliminates any possible confusion, and a host of other #defines. My current port supports maybe 4-5 hard modes. There are 19 machine_modes defined. That's about 4x as many as I really need to define, and that doesn't even include synthetic vector modes and such. > - as you've noted, all the information GCC MI portion needs to "do the > right thing" already exists scattered in various target definitions, > but it hasn't prevented mode assumptions from being made, and XXmodes > being hard-coded into the MI sources on occasion; which is the only > reason that I thought that by forcing target_TYPE_mode's to be the > only thing available, GCC would indirectly be forced to always to the > "right thing"? The less available the better, true. But target_*_modes don't need to be available either. If you use a query/lookup API, MI can assume there are a *lot* of machine modes (one for each variable, one for each function, one for each C data type, etc), and let the target map them to available modes. targetm.modes.set_mode_for_decl(decl); See? This allows for a custom mode just for the given decl (it might be a 17 bit ternary value in a DSP), doesn't make assumptions about available machine modes, and MI can provide a naive default hook for targets that do "the usual thing". if (!TYPE_MODE (TREE_TYPE (decl))) TYPE_MODE (TREE_TYPE (decl)) = find_mode_for_type (TREE_TYPE (decl)); DECL_MODE (decl) = TYPE_MODE (TREE_TYPE (decl)); or something like that. Caching is OK if you cache it the right way (with a type, not in a global "this is a pointer" variable). ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 18:31 ` DJ Delorie @ 2005-05-25 21:41 ` Paul Schlie 2005-05-26 6:11 ` DJ Delorie 0 siblings, 1 reply; 97+ messages in thread From: Paul Schlie @ 2005-05-25 21:41 UTC (permalink / raw) To: DJ Delorie; +Cc: gdr, gcc > From: DJ Delorie <dj@redhat.com> > >> where then the target may declare class machine_mode >> target_int_mode ("HI", 16), > > This is where we disagree. The *target* shouldn't map types to modes. > The *MI* should map types to modes. The target just creates the modes > it supports and describes them. The MI looks them up by description > (NOT NAME). If the MI needs a 32 bit unsigned scalar, it does > lookup_mode(32, M_SCALAR, M_UNSIGNED) and uses whatever gets returned. - ok, and how does it know that it needs a 32-bit unsigned scalar? Answer: because it wants to know what mode it needs to specify for for an operation on a particular type which has those characteristics as defined by the targets definition of an int for example. (so why in the world is it desirable to go go in a big circle to identify which mode corresponds to a type as defined by the target, rather than simply having the target define it directly?) > The fact that you're still trying to assign a "well known name" to a > given type/mode/whatever means you haven't gotten away from the (to > me) fundamental problem, that MI chooses modes according to what > they're *for* instead of according to what they *are*. - unless I misunderstand (which I admittedly may), the MI portion of the code is and should be based on manipulating data structures which correspond to user programs which are digested down to a canonical representation of "well known named" operators with operands of correspondingly "well known named" types (such as bool, char, int, float); who's sizes are defined by the target. So it would seem to stand to reason that the MI portion of GCC does and should restrict itself to well known "type" modes, which are defined to be mapped to physical modes as defined by the target? please see below) >> target_unit_mode // presumably the target's smallest addressable datum. > > BImode in most cases, not really useful that way. - maybe we are using different terminology, as there would seem to be no reason that a target couldn't define that a bool was a 16-bit wide datum while being able to address memory with a 4-bit wide granularity. (in essence, there needs to be a mechanism by which a target may define the it's address resolution, and alignment requirements, independently of it's specified type sizes, if not this way, then some other) >> target_word_mode // presumably the target's largest addressable datum. > > BLKmode in all cases. Also not useful. - I hope not, as block mode operands seem to be used for moving data with finer granularity than the target's word-width when initializing char array and/or struct members (which need not be aligned to the width of of the target's widest naturally addressable datum, but it's smallest?) >> as there seems no valid reason for the target neutral portion of the >> compiler to ever refer to XXmode under any circumstance? > > Ah, but in your case it *is* aware, it just calls it > "target_word_mode" instead of "SImode" with all the same problems with > assumptions. - no?, I presume that "target_word_mode" would merely describe (mentioned above), an aspect of the physical target's natural memory access granularity, without having any presumed relationship to any particular separately defined target "type" mode such as it's target_int_mode for example. >> where correspondingly the MI portions of GCC utilizes the appropriate >> pointer mode as a function of the type of access being performed, > > In my case, the target has to check the attributes of the > function/data to decide what kind of pointer to use. Again, "MI > assuming" that all function pointers are the same is WRONG. - understood, although it would seem much easier if the MI portion simply identified the type of pointer it required based upon the context of the access which it inherently knows (which the target may map to whatever mode it desires), rather than the target having to try to figure out based upon the more limited tree/rtx context visible to it?) thereby also exposing more potential opportunities for MI optimization to the middle end it would seem? >> - understood, although I honestly don't believe there are that many, and >> it eliminates any possible confusion, and a host of other #defines. > > My current port supports maybe 4-5 hard modes. There are 19 > machine_modes defined. That's about 4x as many as I really need to > define, and that doesn't even include synthetic vector modes and such. - understood, although hardly believe that it's a problem to require that a target define the logical->physical mapping required for for the 20 or so logically distinct type variations that the MI portion is and should be aware of (rather than subject the mapping to any mishandling) >> - as you've noted, all the information GCC MI portion needs to "do the >> right thing" already exists scattered in various target definitions, >> but it hasn't prevented mode assumptions from being made, and XXmodes >> being hard-coded into the MI sources on occasion; which is the only >> reason that I thought that by forcing target_TYPE_mode's to be the >> only thing available, GCC would indirectly be forced to always to the >> "right thing"? > > The less available the better, true. But target_*_modes don't need to > be available either. If you use a query/lookup API, MI can assume > there are a *lot* of machine modes (one for each variable, one for > each function, one for each C data type, etc), and let the target map > them to available modes. - I do believe were just using somewhat different terminology, as the MI portion of the compiler does and must deal with "well known named" typed operations and operands. > targetm.modes.set_mode_for_decl(decl); > > See? This allows for a custom mode just for the given decl (it might > be a 17 bit ternary value in a DSP), doesn't make assumptions about > available machine modes, and MI can provide a naive default hook for > targets that do "the usual thing". - sorry, I don't see; as the program code, and internal tree representation of that code (as you've noted below), identifies all nodes as having one of N canonical types (bool, char, short, int, *, [], etc.) not an arbitrary type, (where these canonical types need only be mapped to target supported/named/defined modes upon code generation, it would seem?) > if (!TYPE_MODE (TREE_TYPE (decl))) > TYPE_MODE (TREE_TYPE (decl)) = find_mode_for_type (TREE_TYPE (decl)); > DECL_MODE (decl) = TYPE_MODE (TREE_TYPE (decl)); - why bother if: TYPE_MODE :: *target_type_mode, i.e: typedef struct { char* name; char* mode: char size: enum attribute {is_signed, is_unsigned, is_floating, is_void}; } target_type_mode; where the target defines: enum type_mode { bool_mode = &(target_type_mode){"bool", "QI", 10, is_unsinged}, char_mode = &(target_type_mode){"char", "QI", 10, is_unsigned}, uint_mode = &(target_type_mode){"uint", "HI", 17, is_unsigned}, ...} thereby the MI portion need only do stuff like: if (TYPE_MODE(...) == char_mode) ... -or- if(TYPE_MODE(...)->size < word_mode->.size) ... where when required for target template mapping, mode names may be extracted via. TYPE_MODE(...)->mode, thereby the MI remains fully abstracted, and never needs to be aware or manipulate physical modes as named and utilized by the target it would seem? > or something like that. Caching is OK if you cache it the right way > (with a type, not in a global "this is a pointer" variable). (but recognize we're likely looking a things from different perspectives) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 21:41 ` Paul Schlie @ 2005-05-26 6:11 ` DJ Delorie 2005-05-26 8:15 ` Paul Schlie 0 siblings, 1 reply; 97+ messages in thread From: DJ Delorie @ 2005-05-26 6:11 UTC (permalink / raw) To: schlie; +Cc: gcc > - ok, and how does it know that it needs a 32-bit unsigned scalar? tm.h: #define INT_TYPE_SIZE 32 Combined with "unsigned int foo;" in the user's source file. The MI doesn't need to know that this fits in a QImode. > the world is it desirable to go go in a big circle to identify > which mode corresponds to a type as defined by the target, rather > than simply having the target define it directly?) Because on many targets, small scalars can be held in larger registers, and large scalars (or complex or vector types) can be held in groups of small registers. There isn't a strict mapping between C types and hardware modes. Plus, the target might provide attributes that alter the mode (think "__attribute__((mode(FRED)))"). > correspondingly "well known named" types (such as bool, char, int, In this case, the "well known named" things are front-end types, like "int" and "short", not back-end types, like PSImode or V4QImode. A simple example of this type of problem is when MI uses "SImode" for integers, on a target with 16-bit integers. SImode is wrong. Any time you have "well known" types coming from the *target* you're setting yourself up for this type of thing. > > BImode in most cases, not really useful that way. > > - maybe we are using different terminology, as there would seem to > be no reason that a target couldn't define that a bool was a 16-bit > wide datum I didn't say anything about bools. See? You're making the same wrong assumptions GCC makes. "bool" should be a well-known name. BImode shouldn't. My chip has an addressing mode that addresses individual bits, has nothing to do with the "bool" type. > (in essence, there needs to be a mechanism by which a target may > define the it's address resolution, and alignment requirements, > independently The chip I'm working on has three addressing modes, with two different resolutions and alignments. Your assumption - that there is one address resolution - already breaks my chip. > >> target_word_mode // presumably the target's largest addressable datum. > > > > BLKmode in all cases. Also not useful. > > - I hope not, as block mode operands seem to be used for moving data > with finer granularity than the target's word-width when > initializing char You said largest addressable, not largest alignment. More assumptions. On some chips, for example, "words" may be unaligned, but "floats" must be aligned. Your "well known name" is already wrong. > - no?, I presume that "target_word_mode" would merely describe > (mentioned above), an aspect of the physical target's natural memory > access granularity, You're assuming the target has ONE "natural" access granularity. Just the dichotomy between scalars and reals breaks that. My chip has four "natural" accessing granularities. Which would I choose? (yes, I was stumped for UNITS_PER_WORD because it was used for many things, and I needed different things it was used for to work with different sized data). Heck, the i386 has five natural modes (QI, HI, SI/SF, DI/DF TF). Pick one. > - understood, although it would seem much easier if the MI portion simply > identified the type of pointer it required based upon the context of the > access which it inherently knows (which the target may map to whatever "inherently" is misleading. The MI has two feasible options - assume all pointers are the same, or let the target decide. There is no usable middle ground. > mode it desires), rather than the target having to try to figure > out based upon the more limited tree/rtx context visible to it?) The tree/decl/rtx is all the MI has too. > - understood, although hardly believe that it's a problem to require that > a target define the logical->physical mapping required for for the 20 > or so logically distinct type variations that the MI portion is and > should be aware of (rather than subject the mapping to any mishandling) Ok, next time a new language front and is added with new data types, you get to update all the target backends. > - I do believe were just using somewhat different terminology, as the MI > portion of the compiler does and must deal with "well known named" typed > operations and operands. Does? Yes. Must? No, outside of the *language* types (not the *target* types). > - sorry, I don't see; as the program code, and internal tree representation > of that code (as you've noted below), identifies all nodes as having one > of N canonical types (bool, char, short, int, *, [], etc.) not an > arbitrary type, *Except* when you consider __attribute__ which can modify *anything* in gcc. This is how we get vector variables, interrupt functions, etc. > - why bother if: TYPE_MODE :: *target_type_mode, i.e: > > typedef struct { > char* name; > char* mode: > char size: > enum attribute {is_signed, is_unsigned, is_floating, is_void}; > } target_type_mode; No, you're missing a lot of variability here. > if (TYPE_MODE(...) == char_mode) ... I'd rather see if (TYPE_MODE(...) == TYPE_MODE(...)) or if (BITS_PER_MODE (TYPE_MODE (...)) <= BITS_PER_BYTE) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-26 6:11 ` DJ Delorie @ 2005-05-26 8:15 ` Paul Schlie 2005-05-26 11:57 ` DJ Delorie 0 siblings, 1 reply; 97+ messages in thread From: Paul Schlie @ 2005-05-26 8:15 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc > From: DJ Delorie <dj@redhat.com> >> - ok, and how does it know that it needs a 32-bit unsigned scalar? > > tm.h: #define INT_TYPE_SIZE 32 > > Combined with "unsigned int foo;" in the user's source file. > > The MI doesn't need to know that this fits in a QImode. - agreed, all it needs to know is that a int_mode operand/operator is required, which is defined to correspond to some physical mode given some name by the target. >> the world is it desirable to go go in a big circle to identify >> which mode corresponds to a type as defined by the target, rather >> than simply having the target define it directly?) > > Because on many targets, small scalars can be held in larger > registers, and large scalars (or complex or vector types) can be held > in groups of small registers. There isn't a strict mapping between C > types and hardware modes. Plus, the target might provide attributes > that alter the mode (think "__attribute__((mode(FRED)))"). - Huh?, can you provide a single example of where a char type would be mapped by the target to two different target specified modes? (as it seems that although multiple char's may be specified as being mapped to into an indexed subreg of a wider target specified mode, the middle end is responsible for identifying how and how many and smaller datum, may be packed into a vector, as defined by the target's specification of it's vector_mode, if supported at all, not the target.) >> correspondingly "well known named" types (such as bool, char, int, > > In this case, the "well known named" things are front-end types, like > "int" and "short", not back-end types, like PSImode or V4QImode. - fully agree, which is why the MI need/should never need to identify the target physical mode (given some name by the target), which corresponds to the canonical type mode name like int_mode as used by the MI until target rtl templates need to be matched. > A simple example of this type of problem is when MI uses "SImode" for > integers, on a target with 16-bit integers. SImode is wrong. Any > time you have "well known" types coming from the *target* you're > setting yourself up for this type of thing. - fully agree, no physical mode name (such as SImode) as may be defined by the target should ever be referred to by the MI portion of the compiler until target specific templates which use the target defined physical mode names need to be matched. >>> BImode in most cases, not really useful that way. >> >> - maybe we are using different terminology, as there would seem to >> be no reason that a target couldn't define that a bool was a 16-bit >> wide datum > > I didn't say anything about bools. See? You're making the same wrong > assumptions GCC makes. "bool" should be a well-known name. BImode > shouldn't. My chip has an addressing mode that addresses individual > bits, has nothing to do with the "bool" type. - sorry, I was just attempting to respond given my best guess as to your intent when you introduced BI mode into the discussion by with the above to: >>>> target_unit_mode // presumably the target's smallest addressable datum. (presuming that you meant that BI mode as presumed to the narrowest width physical mode, which I mistakenly presumed you associated with bool, but agree that the MI portion of the compiler should never presume anything about any particular target named machine physical mode.) >> (in essence, there needs to be a mechanism by which a target may >> define the it's address resolution, and alignment requirements, >> independently > > The chip I'm working on has three addressing modes, with two different > resolutions and alignments. Your assumption - that there is one > address resolution - already breaks my chip. - fully agree, the MI portion of the compiler should make no assumptions about the equality of pointer modes as may be necessary to be distinct for a particular target, but do presume that all stack pointer, function pointer, label pointer, readonly_data pointer, heap pointer, etc. references utilize a common target defined mode, which may all be mapped to the same target physical pointer mode, or different physical pointer modes (i.e. function pointers may be defined to map to WILMA mode, where label pointers may be defined to map to BARNEY mode physical target pointer modes). >>>> target_word_mode // presumably the target's largest addressable datum. >>> >>> BLKmode in all cases. Also not useful. >> >> - I hope not, as block mode operands seem to be used for moving data >> with finer granularity than the target's word-width when >> initializing char > > You said largest addressable, not largest alignment. More > assumptions. On some chips, for example, "words" may be unaligned, > but "floats" must be aligned. Your "well known name" is already > wrong. - fully agreed, my mistake in making the same incorrect assumption which GCC seems to do on occasion, as alignment should likely be an attribute of every target defined logical type -> physical mode mapping definition. >> - no?, I presume that "target_word_mode" would merely describe >> (mentioned above), an aspect of the physical target's natural memory >> access granularity, > > You're assuming the target has ONE "natural" access granularity. Just > the dichotomy between scalars and reals breaks that. > > My chip has four "natural" accessing granularities. Which would I > choose? (yes, I was stumped for UNITS_PER_WORD because it was used > for many things, and I needed different things it was used for to work > with different sized data). > > Heck, the i386 has five natural modes (QI, HI, SI/SF, DI/DF TF). Pick > one. - fully agreed, as above. >> - understood, although it would seem much easier if the MI portion simply >> identified the type of pointer it required based upon the context of the >> access which it inherently knows (which the target may map to whatever > > "inherently" is misleading. The MI has two feasible options - assume > all pointers are the same, or let the target decide. There is no > usable middle ground. - given that the target may only "decide" based on the uniqueness of the contextual of the pointer's use visible to it, it depends on the MI differentiating such uses. Which seems simpler for the MI to do explicitly by named canonical pointer modes (such as function_pointer, label_pointer, rodata_pointer, etc.) rather than leaving it up to chance that they may be discrimated as may be required by the target; which the target may define to map to the same or different physical modes as required by the target, it would seem? >> mode it desires), rather than the target having to try to figure >> out based upon the more limited tree/rtx context visible to it?) > > The tree/decl/rtx is all the MI has too. - but only needs to associate a logical type mode with a target defined physical mode when attempting to match the the target's instruction rtl definitions defined in terms of physical modes SI, DI, WILMA, etc.), it would seem? >> - understood, although hardly believe that it's a problem to require that >> a target define the logical->physical mapping required for for the 20 >> or so logically distinct type variations that the MI portion is and >> should be aware of (rather than subject the mapping to any mishandling) > > Ok, next time a new language front and is added with new data types, > you get to update all the target backends. - yes, as would always need to be done if the language's new data-type precision or representation is target dependant, as most language data-types are? >> - I do believe were just using somewhat different terminology, as the MI >> portion of the compiler does and must deal with "well known named" typed >> operations and operands. > > Does? Yes. Must? No, outside of the *language* types (not the > *target* types). - fully agree, which is why the MI need only deal with *language* type/modes and rely on the target to define their mapping to *target* types/modes. >> - sorry, I don't see; as the program code, and internal tree representation >> of that code (as you've noted below), identifies all nodes as having one >> of N canonical types (bool, char, short, int, *, [], etc.) not an >> arbitrary type, > > *Except* when you consider __attribute__ which can modify *anything* > in gcc. This is how we get vector variables, interrupt functions, > etc. - unless I misunderstand, I suspect you're mixing a few orthogonal issues: - the last first, a vector is just another canonical type, no different than bool, char, etc. and needs it's target specific attributes described by the target, and correspondingly mapped to some target defined named physical mode which the target's rtl is described using. - interrupt, no-return, etc. attributes aren't types per-se, but rather semantic modifiers which GCC has provided as a convenience to both programmers, and the middle-end architecture to enable the incremental specification of semantics in a canonical way by language front-ends, to enable the development of a language neutral middle end? - the use of GCC's __attribute__ extension directly in user code, seems to simply extend this capability to the programmer. And seemingly may be used to introduce "new" types, but only if that "new" type is defined as being physically equivalent to an existing supported type/mode known already to both the MI and the target portions of the compiler, as otherwise neither the MI or target portions of the compiler understands it relationship/conversion to/from other types, or it's corresponding target specific physical mode to use to represent the type, or operations it would seem? >> - why bother if: TYPE_MODE :: *target_type_mode, i.e: >> >> typedef struct { >> char* name; >> char* mode: >> char size: >> enum attribute {is_signed, is_unsigned, is_floating, is_void}; >> } target_type_mode; >> >> enum type_mode { >> bool_mode = &(target_type_mode){"bool", "QI", 10, is_unsinged}, >> char_mode = &(target_type_mode){"char", "QI", 10, is_unsigned}, >> uint_mode = &(target_type_mode){"uint", "HI", 17, is_unsigned}, >> ...} > > No, you're missing a lot of variability here. - like? (observing that it may be easily augmented as desired/required) >> if (TYPE_MODE(...) == char_mode) ... > > I'd rather see > > if (TYPE_MODE(...) == TYPE_MODE(...)) > > or > if (BITS_PER_MODE (TYPE_MODE (...)) <= BITS_PER_BYTE) - out of curiosity, why? (but suspect you simply like flexibility of another level of abstraction) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-26 8:15 ` Paul Schlie @ 2005-05-26 11:57 ` DJ Delorie 0 siblings, 0 replies; 97+ messages in thread From: DJ Delorie @ 2005-05-26 11:57 UTC (permalink / raw) To: schlie; +Cc: gcc > which is defined to correspond to some physical mode Close. Defined to correspond to one or more physical modes. > - Huh?, can you provide a single example of where a char type would > be mapped by the target to two different target specified modes? i386 can hold a char in %al (QImode) or %bx (HImode) or %esi (SImode). It can also be stored in st0 (TFmode). I can't imagine why a target port would want to *force* a char into a wider register on the i386, but I don't want to assume it won't happen either. Imagine, for example, a port with 9 bit chars, with an __attribute__ to get an 8 bit char when different overflow semantics are required. But I can easily imagine a chip (8086) where "int *" can be one of two different sizes (16 or 32 bits). > mapped to into an indexed subreg of a wider target specified mode, the See also WORD_REGISTER_OPERATIONS. > - fully agree, no physical mode name (such as SImode) as may be defined > by the target should ever be referred to by the MI portion of the Note that using integer_mode is equally wrong, if you don't check to see if it's the proper size for the application. long_integer_mode or short_integer_mode might be more appropriate. Copying modes from one of the operands is faster. Consider adding two scalars of modes A and B. Maybe the target has an addAB3 insn (some do!). If not, see if it has {zero|sign})_extendAB2 (or BA depending on bits-per-mode) and addB3. If not, for (bits=bits(B)+1; bits<MAX_MODE_BITS; bits++) see if it has addMODE(bits)3. Note that this kind of thing happens a lot with multiply and divide insns, which reminds me, I need to submit a patch to take out an assumption that the "next wider" mode happens to be the "twice wider" mode. Doesn't work with partial int modes defined. > - sorry, I was just attempting to respond given my best guess as to your > intent when you introduced BI mode into the discussion by with the above > to: > > >>>> target_unit_mode // presumably the target's smallest addressable datum. On some chips, the smallest addressable datum is a bit, not a byte. Given how often gcc makes invalid assumptions about bytes and words, it was worth noting. > modes (i.e. function pointers may be defined to map to WILMA mode, where > label pointers may be defined to map to BARNEY mode physical target > pointer modes). Sigh, more assumptions. Don't group all functions into the same pointer size either. Consider the i386 "near" vs "far" attributes; you need different sized pointers for EACH FUNCTION AND VARIABLE depending on whether it's near or far. > - fully agreed, my mistake in making the same incorrect assumption which > GCC seems to do on occasion, as alignment should likely be an attribute > of every target defined logical type -> physical mode mapping definition. Worse. Some chips have both aligned and unaligned addressing modes for each physical data type. Unaligned modes are normally slower, so you'd want to tag those variables or pointers which may be unaligned, and use a different type of pointer (although perhaps the same size) for those, than the default. > - given that the target may only "decide" based on the uniqueness of the > contextual of the pointer's use visible to it, It knows what the pointer points to, too. "pointer to int" may be different than "pointer to __attribute__((far)) int". > rather than leaving it up to chance that they may be discrimated i386 near vs far again. Borland has supported that since the late 1980's, gcc still doesn't support it. > - but only needs to associate a logical type mode with a target defined > physical mode when attempting to match the the target's instruction > rtl definitions defined in terms of physical modes SI, DI, WILMA, etc.), > it would seem? My point was that MI and target both have the same information available for doing this conversion. There's no advantage to trying to force the MI to do it somehow. > - yes, as would always need to be done if the language's new data-type > precision or representation is target dependant, as most language > data-types are? There are more language types than hard types, for example floating point types might be simulated in software. The target shouldn't need to know about new types if they fit (somehow) into existing modes. > - fully agree, which is why the MI need only deal with *language* type/modes > and rely on the target to define their mapping to *target* types/modes. But the target should *not* know about language types, aside from a few key bits like "bits per int" etc. > >> - sorry, I don't see; as the program code, and internal tree representation > >> of that code (as you've noted below), identifies all nodes as having one > >> of N canonical types (bool, char, short, int, *, [], etc.) not an > >> arbitrary type, > > > > *Except* when you consider __attribute__ which can modify *anything* > > in gcc. This is how we get vector variables, interrupt functions, > > etc. > > - unless I misunderstand, I suspect you're mixing a few orthogonal issues: > > - the last first, a vector is just another canonical type, no different > than bool, char, etc. and needs it's target specific attributes > described by the target, and correspondingly mapped to some target > defined named physical mode which the target's rtl is described using. Vectors can be simulated in software for ports that don't support them. Ports that *do* support them need to map them to existing (nonstandard so far) vector operations. > - interrupt, no-return, etc. attributes aren't types per-se, but rather > semantic modifiers which GCC has provided as a convenience to both > programmers, and the middle-end architecture to enable the incremental > specification of semantics in a canonical way by language front-ends, > to enable the development of a language neutral middle end? Except that "pointer to function" and "pointer to interrupt function" must be different types, because *calling* those two types of functions often requires a different set of opcodes. "pointer to int" and "pointer to unaligned int" must be different so the right addressing modes (or simulations) can be used. Consider this C++: void foo (void __attribute__((far) *); void foo (void __attribute__((near)) *); int j; foo(&j); Which function is called? How can it choose if it doesn't know how to differentiate types that differ only in attributes? > be used to introduce "new" types, but only if that "new" type is defined > as being physically equivalent to an existing supported type/mode known > already to both the MI and the target portions of the compiler, as No. The MI shouldn't need to know about machine modes that are used by the target only to support attribute-tagged types. Essentially, the target causes MI to create a new type (much like "typedef" does in C) that the target happens to have insns for. > otherwise neither the MI or target portions of the compiler understands > it relationship/conversion to/from other types, Why should the MI know how to convert between types in a given class? That's what the extendMN2 insn patterns are for. > > No, you're missing a lot of variability here. > > - like? (observing that it may be easily augmented as desired/required) near vs far comes to mind. Vectors, complex, alignment, signalling, volatile, etc. Two variables of C type "char" might be assigned different machine modes based on something MI doesn't know about. What about CPUs with multiple [different] integer units? You'd want distinct scalar modes so the programmer can assign variables to specific integer units, perhaps. Example: a fast FPU vs an IEEE-accurate FPU. > >> if (TYPE_MODE(...) == char_mode) ... > > > > I'd rather see > > > > if (TYPE_MODE(...) == TYPE_MODE(...)) > > > > or > > if (BITS_PER_MODE (TYPE_MODE (...)) <= BITS_PER_BYTE) > > - out of curiosity, why? If the MI is calling a function and passing three arguments, why should it care if the type is "char" ? If it's offsetting a pointer to access a structure field, who cares if the pointer is Pmode? What about DSPs that have 32 bit chars, but can access 8 bit bytes? Either deal with language types, or deal with machine modes. Don't mix them unless you're lowering to RTL, and only when absolutely needed. That's where the lookup functions get used. But there's a big difference between "give me a mode that is this type" and "give me a mode that I can put this variable in". The first makes unneeded assumptions, the second doesn't. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report @ 2005-05-25 19:27 Richard Kenner 0 siblings, 0 replies; 97+ messages in thread From: Richard Kenner @ 2005-05-25 19:27 UTC (permalink / raw) To: dj; +Cc: gcc And YES I have a port with multiple pointer sizes, and YES the customer wanted both sizes supported in a single compilation unit This is actually not that uncommon. Oh, and sometimes gcc randomly uses pointer_mode instead of Pmode. I haven't a clue why there's a difference, or how badly gcc would break if pointer_mode and Pmode were different. Ok, I lied, I *do* know how badly it breaks if they differ; I did try that at one point. There have been a number of ports where these differ. Though undoubtably there are bugs in this support, it does basically work. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Compiling GCC with g++: a report @ 2005-05-23 11:50 Gabriel Dos Reis 2005-05-23 12:22 ` Ranjit Mathew ` (6 more replies) 0 siblings, 7 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-23 11:50 UTC (permalink / raw) To: gcc; +Cc: jason, mark, dberlin Hi, I spent the week-end trying to get GCC -- mainline -- compilable (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). My summary is: It is largely doable and it is within our reach at this point of development. More specifically, I successfully got all files necessary to build a native GNU C compiler on an i686-pc-linux-gnu. Attempt to get the GNU C++ compiler through the same massage is underway (but I'm going to bed shortly ;-)). I think this project is beneficial to GCC for several reasons: (1) for testing purposes, we can use a compiler with stricter type checking. (2) there have been lots of discussions about more static typing in the data structures, but so far we haven't made anything concrete. Partly because, we need this sort of preliminary preparation of thee source tree. We can have infinite debates about the merits of such approaches, but I think a way to know is to do actual experiments and we better start making that possible now. (3) It might open the door for more contributions and foster more free software based on GCC. (4) <insert your favorite reasons why you would like to see this happen>. What I have learnt from this little experience. Well, the source code seems to have been carefully written to make sure that no lunatic (e.g. the author of this writing) will succeed in feeding a C++ compiler with GCC :-) The first resistance seems to come from the pervasive use of the implicit conversion void* -> T*, mostly with storage allocating functions. We've recently introduced C++ friendly macros in libiberty, but we have yet to take advantage of them. We should start now. (I also noted a happy confusion about the calling convention of the function [x]calloc(), but it is mostly harmless as everything "multiply nicely" in the end and we don't get burned by strict alignment issues). We should generalize the notation for GGC allocators and alloca(). The second resistance is the pervasive use of C++ keywords (e.g. new, class, template, try, catch, ...). The first three are quite frequent in the middle-end. Third, there is some "type-punning" with enums, int and unsigned int, where the middle-end (mostly) relies on implicit conversion from int to enums. That is a bit annoying but could be avoided as most of the time, we do have names for those integer constants. For example, we should be using EXPAND_NORMAL instead of 0, or VOIDmode, instead of 0, TV_TOTAL instead of 0, etc. At this point, I should also note that not implicit conversions between enums (c_tree_code <-> tree_code, or rtx_code <-> reg_note, etc.) is not supported in C++. So, we should probably arrange to make the relationship (mostly subsetting) between more explicit, as opposed to throwing in casts. Also, there are few cases where we want to iterate over all the values of enumerations. I've shamelessly used the following macros: #define NEXT(E) ((__typeof__(E)) (E + 1)) #define PREV(E) ((__typeof__(E)) (E - 1)) #define DECR(E) (E = (__typeof__(E)) (E - 1)) #define INCR(E) (E = (__typeof__(E)) (E + 1)) #define IOR(A,B) ((__typeof__(A)) (A | B)) #define AND(A,B) ((__typeof__(A)) (A & B)) #define XOR(A,B) ((__typeof__(A)) (A ^ B)) but I'm not suggesting that as real replacement; just reporting the dirty tricks I did and I'm looking for better suggestions. Fourth, it appears that we're implicilty using C99's semantics of "extern inline" in our source -- when we have a pure C90 compiler that does not understand "inline", we just #define inline to nothing so we don't get into trouble. With a C++ compiler, we're in trouble because an inline function needs to be defined in every translation where it is used. So, I either move the affected functions to "static inline" or just make then non-inline (cases are in hashtable.c and toplev.c). Fifth, there is a slight difference between "const" in C and in C++. In C++, a const variable implicitly has an internal linkage; so a C++ compiler tends to optimize it out when its address is not taken (so no storage is wasted). This is an issue for the objects automatically generated by the gengtype support machinery. The are supposed to have external linkage, so we need to explicitly say "extern" in their definitions. Sixth, there is a real "mess" about name spaces. It is true that every C programmers knows the rule saying tags inhabit different name space than variable of functions. However, all the C coding standards I've read so far usually suggest typedef struct foo foo; but *not* typedef struct foo *foo; i.e. "bringing" the tag-name into normal name space to name the type structure or enumeration is OK, but not naming a different type! the latter practice will be flagged by a C++ compiler. I guess we may need some discussion about the naming of structure (POSIX reserves anything ending with "_t", so we might want to choose something so that we don't run into problem. However, I do not expect this issue to dominate the discussion :-)) So, if various components maintainers (e.g. C and C++, middle-end, ports, etc.) are willing to help quickly reviewing patches we can have this done for this week (assuming mainline is unslushed soon). And, of course, everybody can help :-) Thanks, -- Gabriel Dos Reis gdr@cs.tamu.edu Texas A&M University -- Department of Computer Science 301, Bright Building -- College Station, TX 77843-3112 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-23 11:50 Gabriel Dos Reis @ 2005-05-23 12:22 ` Ranjit Mathew 2005-05-23 19:07 ` Tom Tromey 2005-05-23 18:04 ` Gabriel Dos Reis ` (5 subsequent siblings) 6 siblings, 1 reply; 97+ messages in thread From: Ranjit Mathew @ 2005-05-23 12:22 UTC (permalink / raw) To: gcc Gabriel Dos Reis wrote: > Hi, > > I spent the week-end trying to get GCC -- mainline -- compilable > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). [...] > > I think this project is beneficial to GCC for several reasons: [...] > > (4) <insert your favorite reasons why you would like to see this happen>. Tom Tromey's GCJX (gcjx_branch in CVS), the completely rewritten Java front-end that is written in C++. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/ ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-23 12:22 ` Ranjit Mathew @ 2005-05-23 19:07 ` Tom Tromey 0 siblings, 0 replies; 97+ messages in thread From: Tom Tromey @ 2005-05-23 19:07 UTC (permalink / raw) To: Ranjit Mathew; +Cc: GCC Mailing List >>>>> "Ranjit" == Ranjit Mathew <rmathew@gmail.com> writes: >> (4) <insert your favorite reasons why you would like to see this happen>. Ranjit> Tom Tromey's GCJX (gcjx_branch in CVS), the completely Ranjit> rewritten Java front-end that is written in C++. Plugging this into gcc has largely been fine, thanks to an earlier round of patches in this area. The biggest unsolved build issue is that it would be nice, when bootstrapping native (build=host=target), to use the just-built g++ and libstdc++ for gcjx. This involves some wacky build reordering that I've been avoiding looking at. Tom ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-23 11:50 Gabriel Dos Reis 2005-05-23 12:22 ` Ranjit Mathew @ 2005-05-23 18:04 ` Gabriel Dos Reis 2005-05-24 4:57 ` Gabriel Dos Reis ` (4 subsequent siblings) 6 siblings, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-23 18:04 UTC (permalink / raw) To: gcc Gabriel Dos Reis <gdr@cs.tamu.edu> writes: | Hi, | | I spent the week-end trying to get GCC -- mainline -- compilable | (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). | | My summary is: It is largely doable and it is within our reach at this | point of development. More specifically, I successfully got all | files necessary to build a native GNU C compiler on an i686-pc-linux-gnu. | Attempt to get the GNU C++ compiler through the same massage is | underway (but I'm going to bed shortly ;-)). | | I think this project is beneficial to GCC for several reasons: I have received several inquiries as whether this is a project to have GCC implemeted in C++. The answer is no. It is a project that will align us with our coding standard that codes should live in the large intersection of C and C++. Those not fluent in C++ should have to worry -- when/if they write "good" codes in C :-). Most certanly, patch reviewers will make suggestions in case a patch falls outside. And since I brought the issue, I volunteer to help fulfill that task. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-23 11:50 Gabriel Dos Reis 2005-05-23 12:22 ` Ranjit Mathew 2005-05-23 18:04 ` Gabriel Dos Reis @ 2005-05-24 4:57 ` Gabriel Dos Reis 2005-05-24 4:59 ` Joseph S. Myers 2005-05-24 21:50 ` Kevin Handy 2005-05-24 5:54 ` Zack Weinberg ` (3 subsequent siblings) 6 siblings, 2 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 4:57 UTC (permalink / raw) To: gcc; +Cc: jason, mark, dberlin Gabriel Dos Reis <gdr@cs.tamu.edu> writes: [...] | Attempt to get the GNU C++ compiler through the same massage is | underway (but I'm going to bed shortly ;-)). I can also report that I got the GNU C++ compiler through -- and apart form uses of C++ keywords (template, namespace, class), it worked out. A note on type sfety issue though: lookup_name() is declared in c-tree.h as extern tree lookup_name (tree); and used in c-common.c:handle_cleanup_attribute() according to that signature. It is however declared and defined in cp/ as extern tree lookup_name (tree, int); That was caught at link time (and dealt with). -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 4:57 ` Gabriel Dos Reis @ 2005-05-24 4:59 ` Joseph S. Myers 2005-05-24 21:50 ` Kevin Handy 1 sibling, 0 replies; 97+ messages in thread From: Joseph S. Myers @ 2005-05-24 4:59 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin On Tue, 24 May 2005, Gabriel Dos Reis wrote: > I can also report that I got the GNU C++ compiler through -- and apart > form uses of C++ keywords (template, namespace, class), it worked > out. A note on type sfety issue though: lookup_name() is declared in > c-tree.h as > > extern tree lookup_name (tree); > > and used in c-common.c:handle_cleanup_attribute() according to that > signature. It is however declared and defined in cp/ as > > extern tree lookup_name (tree, int); We should try to stop c-common.c from including c-tree.h. If it is genuinely common code it shouldn't be including c-tree.h which is a C front end header. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ jsm@polyomino.org.uk (personal mail) joseph@codesourcery.com (CodeSourcery mail) jsm28@gcc.gnu.org (Bugzilla assignments and CCs) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 4:57 ` Gabriel Dos Reis 2005-05-24 4:59 ` Joseph S. Myers @ 2005-05-24 21:50 ` Kevin Handy 2005-05-25 12:02 ` Bernardo Innocenti 1 sibling, 1 reply; 97+ messages in thread From: Kevin Handy @ 2005-05-24 21:50 UTC (permalink / raw) To: gcc Gabriel Dos Reis wrote: >Gabriel Dos Reis <gdr@cs.tamu.edu> writes: > >[...] > >| Attempt to get the GNU C++ compiler through the same massage is >| underway (but I'm going to bed shortly ;-)). > >I can also report that I got the GNU C++ compiler through -- and apart >form uses of C++ keywords (template, namespace, class), it worked >out. A note on type sfety issue though: lookup_name() is declared in >c-tree.h as > > extern tree lookup_name (tree); > >and used in c-common.c:handle_cleanup_attribute() according to that >signature. It is however declared and defined in cp/ as > > extern tree lookup_name (tree, int); > >That was caught at link time (and dealt with). > >-- Gaby > > Would it be possible to add a diagnostic to GCC to warn when C++ keywords are being used as identifiers? Maybe also add any objective C keywords too. This seems like it would be useful to someone writing library functions that could, at some later time, be imported (cut and paste) into code for the other languages, as well as for code being converted from C to C++. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 21:50 ` Kevin Handy @ 2005-05-25 12:02 ` Bernardo Innocenti 0 siblings, 0 replies; 97+ messages in thread From: Bernardo Innocenti @ 2005-05-25 12:02 UTC (permalink / raw) To: Kevin Handy; +Cc: gcc Kevin Handy wrote: >> That was caught at link time (and dealt with). >> >> > Would it be possible to add a diagnostic to GCC to warn when C++ > keywords are being used as identifiers? Maybe also add any > objective C keywords too. > > This seems like it would be useful to someone writing library > functions that could, at some later time, be imported (cut and paste) > into code for the other languages, as well as for code being converted > from C to C++. I'd like such a switch too. Until it's done, we could just poison C++ keywords in system.h. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-23 11:50 Gabriel Dos Reis ` (2 preceding siblings ...) 2005-05-24 4:57 ` Gabriel Dos Reis @ 2005-05-24 5:54 ` Zack Weinberg 2005-05-24 6:04 ` Daniel Jacobowitz ` (3 more replies) 2005-05-24 10:01 ` Florian Weimer ` (2 subsequent siblings) 6 siblings, 4 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-24 5:54 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote: > Hi, > > I spent the week-end trying to get GCC -- mainline -- compilable > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). These results are very interesting. As a general observation: A lot of the things you have found to be problematic, are in fact preferred idioms for C code. For instance, no standard-C programmer would ever write an explicit cast on malloc's return value. I think that we are losing something, if only in readability, if we restrict our code to the subset of C which is also correct C++. Now, if we were migrating to C++, that would be okay, because we would (eventually) get all of the additional expressive power of C++ in exchange. However, if we're not migrating to C++, I'm opposed to the inclusion of patches that restrict our C code to the subset which is correct C++. Furthermore, as I've said before, I support migrating to C++ -- but only if the C++ ABI and libstdc++ soname are first permanently frozen. If we do not do that first, we risk being trapped into a situation where we need specific versions of GCC to compile specific newer versions of GCC, which would be a Bad Thing. The C++ ABI seems to be stable at this point, but there is not yet consensus that it will never again be changed. The libstdc++ team is currently developing yet another new, incompatible version, so I see no hope for a permanent freeze of its soname in the near future. Thus, while you've discovered some interesting things by trying this, I don't think C++ compatibility patches should be applied now. Having said that, some comments on the problems you have found: > Third, there is some "type-punning" with enums, int and unsigned int, > where the middle-end (mostly) relies on implicit conversion from int > to enums. Being allowed to do this is very important. Some enumerated types are to be treated as opaque outside a very narrow context; the only way to do that in C is to have (a typedef of) unsigned int as the visible type, and only declare the enumerated type in the context where it's allowed to be used. I want to see more use of this idiom, not less; for example, 'enum machine_mode' ought to be a black box to almost the entire compiler. I'd be delighted to hear of a more C++-friendly way to code this. Naturally, where the constant is _not_ opaque outside of a defined context, but is part of an interface (as your examples seemed to be), not using it is just sloppy. > Fourth, it appears that we're implicilty using C99's semantics of > "extern inline" in our source -- when we have a pure C90 compiler that > does not understand "inline", we just #define inline to nothing so we > don't get into trouble. With a C++ compiler, we're in trouble because > an inline function needs to be defined in every translation where it > is used. So, I either move the affected functions to "static inline" > or just make then non-inline (cases are in hashtable.c and toplev.c). Use of bare 'inline' is just plain wrong in our source code; this has nothing to do with C++, no two C compilers implement bare 'inline' alike. Patches to add 'static' to such functions (AND MAKING NO OTHER CHANGES) are preapproved, post-slush. > Fifth, there is a slight difference between "const" in C and in C++. > In C++, a const variable implicitly has an internal linkage; so a > C++ compiler tends to optimize it out when its address is not taken > (so no storage is wasted). This is an issue for the objects > automatically generated by the gengtype support machinery. The are > supposed to have external linkage, so we need to explicitly say > "extern" in their definitions. Presumably such constants are declared in some header file, with external linkage. It would be better to make that declaration visible at the point of definition, rather than marking up the declarations with 'extern'. > Sixth, there is a real "mess" about name spaces. It is true that > every C programmers knows the rule saying tags inhabit different name > space than variable of functions. However, all the C coding standards > I've read so far usually suggest > > typedef struct foo foo; > > but *not* > > typedef struct foo *foo; > > i.e. "bringing" the tag-name into normal name space to name the type > structure or enumeration is OK, but not naming a different type! Ugh. Where do we do that? I will suggest, when you find these, that you tack "_s" on the end of the tag-name; that doesn't conflict with POSIX, and should require fewer changes elsewhere in the code. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 5:54 ` Zack Weinberg @ 2005-05-24 6:04 ` Daniel Jacobowitz 2005-05-24 6:22 ` Gabriel Dos Reis 2005-05-24 6:29 ` Zack Weinberg 2005-05-24 6:13 ` Andrew Pinski ` (2 subsequent siblings) 3 siblings, 2 replies; 97+ messages in thread From: Daniel Jacobowitz @ 2005-05-24 6:04 UTC (permalink / raw) To: Zack Weinberg; +Cc: Gabriel Dos Reis, gcc, jason, mark, dberlin On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: > As a general observation: A lot of the things you have found to be > problematic, are in fact preferred idioms for C code. For instance, > no standard-C programmer would ever write an explicit cast on malloc's > return value. I think that we are losing something, if only in > readability, if we restrict our code to the subset of C which is also > correct C++. Now, if we were migrating to C++, that would be okay, > because we would (eventually) get all of the additional expressive power > of C++ in exchange. However, if we're not migrating to C++, I'm opposed > to the inclusion of patches that restrict our C code to the subset which > is correct C++. Furthermore, as I've said before, I support migrating > to C++ -- but only if the C++ ABI and libstdc++ soname are first > permanently frozen. If we do not do that first, we risk being trapped > into a situation where we need specific versions of GCC to compile > specific newer versions of GCC, which would be a Bad Thing. You keep saying this and I don't think it means what you think it means... Being stuck requiring a specific version of GCC to compile a specific newer version of GCC would be a restriction on _source compatibility_ and has nothing to do with binary compatibility. I don't see any way that the libstdc++ soname, for instance, could matter to this at all. If you do, then please be more precise about what problems you're talking about. > The C++ ABI seems to be stable at this point, but there is not yet > consensus that it will never again be changed. The libstdc++ team is > currently developing yet another new, incompatible version, so I see no > hope for a permanent freeze of its soname in the near future. Thus, > while you've discovered some interesting things by trying this, I don't > think C++ compatibility patches should be applied now. There is no such thing as an ABI that will never again be changed. Designing anything at all around that assumption is just asking to be hurt. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:04 ` Daniel Jacobowitz @ 2005-05-24 6:22 ` Gabriel Dos Reis 2005-05-24 6:29 ` Zack Weinberg 1 sibling, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 6:22 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Zack Weinberg, gcc, jason, mark, dberlin Daniel Jacobowitz <drow@false.org> writes: | On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: | > As a general observation: A lot of the things you have found to be | > problematic, are in fact preferred idioms for C code. For instance, | > no standard-C programmer would ever write an explicit cast on malloc's | > return value. I think that we are losing something, if only in | > readability, if we restrict our code to the subset of C which is also | > correct C++. Now, if we were migrating to C++, that would be okay, | > because we would (eventually) get all of the additional expressive power | > of C++ in exchange. However, if we're not migrating to C++, I'm opposed | > to the inclusion of patches that restrict our C code to the subset which | > is correct C++. Furthermore, as I've said before, I support migrating | > to C++ -- but only if the C++ ABI and libstdc++ soname are first | > permanently frozen. If we do not do that first, we risk being trapped | > into a situation where we need specific versions of GCC to compile | > specific newer versions of GCC, which would be a Bad Thing. | | You keep saying this and I don't think it means what you think it | means... Furthermore, I do not believe doing that (at least, as I understand it is any resonable. At any case, it is completely indpendent of the patches that align us to our coding standards. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:04 ` Daniel Jacobowitz 2005-05-24 6:22 ` Gabriel Dos Reis @ 2005-05-24 6:29 ` Zack Weinberg 2005-05-24 6:31 ` Mark Mitchell ` (2 more replies) 1 sibling, 3 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-24 6:29 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin Daniel Jacobowitz <drow@false.org> writes: > On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: >> Furthermore, as I've said before, I support migrating >> to C++ -- but only if the C++ ABI and libstdc++ soname are first >> permanently frozen. If we do not do that first, we risk being trapped >> into a situation where we need specific versions of GCC to compile >> specific newer versions of GCC, which would be a Bad Thing. > > You keep saying this and I don't think it means what you think it > means... > > Being stuck requiring a specific version of GCC to compile a specific > newer version of GCC would be a restriction on _source compatibility_ > and has nothing to do with binary compatibility. I don't see any way > that the libstdc++ soname, for instance, could matter to this at all. > > If you do, then please be more precise about what problems you're > talking about. Um, yeah. I completely botched that explanation. My apologies. I'm concerned about four different scenarios which may arise when the preexisting C++ compiler and runtime are ABI-incompatible with the C++ compiler and runtime being built; none are source compatibility issues, as you point out, however two of them have just the same effect from the user's point of view: imposing constraints on what compiler can be used to build the compiler. Scenario one: Suppose that both libcpp and gcc start using <vector>, and that the initial compiler/runtime's implementation of <vector> is binary incompatible with the implementation being built. Libcpp is currently built only with the initial compiler. Bootstrap will fail in stage 2, when we try to link libcpp modules expecting the older <vector> against a library implementing the newer <vector> (or perhaps the link will succeed but the resulting executable won't work). This scenario, at least theoretically, becomes a non-issue if we make top-level bootstrap the only option before we start using C++ features in GCC, but that hasn't happened yet. Scenario two: Suppose that we have not found every last place where LD_LIBRARY_PATH, or equivalent, needs to be set during bootstrap to ensure that the dynamic linker binds the stage 2 compiler to the shared libstdc++ that it's expecting. If there isn't a libstdc++.so in /usr/lib, or if there is but it is not compatible with the one the compiler wants, again bootstrap will fail. Any time this scenario comes up, it is attributable to a bug in the Makefiles, but you know just how hard it can be to fix such bugs. We've had similar problems with the shared libgcc. Scenario three: Suppose that libstdc++.so.7 (gcc-4.2) and libstdc++.so.7 (gcc-4.3) are compatible in the same way that libc.so.6 (glibc-2.0) and libc.so.6 (glibc-2.1) are compatible: that is, if you build a binary against the first, it'll run against the second, but not vice versa. Now, suppose that on some system gcc-4.2 is /usr/bin/gcc, its libstdc++.so.7 is installed in /usr/lib, and we're trying to use it to compile gcc-4.3, to be installed in /opt/gcc-4.3 or some other weird place that is not in the dynamic linker's default search path. Furthermore, scenarios one and two have been properly avoided. The bootstrap process will produce final compiler binaries that have been linked against the 4.3 libstdc++.so. If we include RPATHs in those binaries, bootstrap will fail, because the library isn't installed yet; if we don't, bootstrap and testing will succeed, but the installed compiler will not run unless the user knows to set LD_LIBRARY_PATH, which has its own problems. DT_RUNPATH could theoretically be used to make this work, but we can't count on DT_RUNPATH. If I were evil, I might point out that this is exactly the same problem that various people were complaining about last week, of depending on newer libraries than one expected to. Scenario four: Suppose that we manage to avoid all the above scenarios. Suppose further that we think we have achieved binary compatibility between different versions of libstdc++, but we are wrong. Then 'make install' is likely to overwrite the libstdc++.so on the system with one that is, in fact, not compatible, and break already-installed software. This could, of course, happen even if we don't start using C++ in GCC itself - I bring it up to caution us against rushing into declaring libstdc++ ABI-frozen. I'd want to see at least two major releases with no libstdc++ soname bump and no problems reported, before I had confidence we'd gotten it right. I want to emphasize that I don't think any of these are unsolvable problems. I do think they are all real problems, and I think there are going to be other problems I haven't listed above, and I want to be sure we have considered the problems and have solutions in hand before we take the plunge. > There is no such thing as an ABI that will never again be changed. > Designing anything at all around that assumption is just asking to > be hurt. C++ ABI stability (including libstdc++ interface) on a par with the C ABI (including libc interface) would suffice. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:29 ` Zack Weinberg @ 2005-05-24 6:31 ` Mark Mitchell 2005-05-24 7:08 ` Zack Weinberg 2005-05-24 16:07 ` Paolo Bonzini 2005-05-24 16:44 ` Daniel Jacobowitz 2 siblings, 1 reply; 97+ messages in thread From: Mark Mitchell @ 2005-05-24 6:31 UTC (permalink / raw) To: Zack Weinberg; +Cc: Gabriel Dos Reis, gcc, jason, dberlin Zack Weinberg wrote: > Um, yeah. I completely botched that explanation. My apologies. I'm > concerned about four different scenarios which may arise when the > preexisting C++ compiler and runtime are ABI-incompatible with the C++ > compiler and runtime being built; none are source compatibility > issues, as you point out, however two of them have just the same > effect from the user's point of view: imposing constraints on what > compiler can be used to build the compiler. I agree that these are valid concerns. Certainly, I can imagine us (CodeSourcery) considering shipping statically linked binaries for quite some time in order to avoid problems for customers, even though that would be less efficient. Like you, I do think these problems are surmountable; but, also like you, I think it would take some time to get all the problems solved. I don't really think, though, that this is immediately relevant; Gaby's trying to fix things that seem to me like they will actually make for better C code, and, right now at least, going to C++ isn't on the table. I think you agree that most of the changes Gaby wants to make are for the better (with the possible exception of casting the return value of malloc, which will be hidden in a macro that's probably less error-prone that writing out the malloc calls directly) -- but you're concerned about the fact that doing this work now might make it too easy for us to switch to C++ without thinking about all the issues? -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:31 ` Mark Mitchell @ 2005-05-24 7:08 ` Zack Weinberg 2005-05-24 7:09 ` Mark Mitchell 2005-05-24 7:39 ` Gabriel Dos Reis 0 siblings, 2 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-24 7:08 UTC (permalink / raw) To: Mark Mitchell; +Cc: Gabriel Dos Reis, gcc, jason, dberlin Mark Mitchell <mark@codesourcery.com> writes: ... > Like you, I do think these problems are surmountable; but, also like > you, I think it would take some time to get all the problems solved. > I don't really think, though, that this is immediately relevant; > Gaby's trying to fix things that seem to me like they will actually > make for better C code, and, right now at least, going to C++ isn't on > the table. I think you agree that most of the changes Gaby wants to > make are for the better (with the possible exception of casting the > return value of malloc, which will be hidden in a macro that's > probably less error-prone that writing out the malloc calls directly) > -- but you're concerned about the fact that doing this work now might > make it too easy for us to switch to C++ without thinking about all > the issues? Yes, that's what I'm trying to get at. Secondarily, I don't want to lose some of the expressive power of C-that-is-not-C++ if we're not getting the expressive power of C++ in exchange -- for instance, I really don't want to have to avoid the set of C++ keywords when coding in C, or remember the semantic difference between C and C++ struct tags. I'd change my tune if Gaby could demonstrate a place where the C++ compiler caught a user-visible bug that the C compiler missed. That would be worth the extra discipline. All the bugs described so far, however, have been things that, while formally incorrect, haven't affected the visible behavior of the compiler. (And I'd be less grumpy about coding to the intersection of C and C++ if someone coded up warnings for the C compiler to catch things outside the intersection.) zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:08 ` Zack Weinberg @ 2005-05-24 7:09 ` Mark Mitchell 2005-05-24 7:39 ` Gabriel Dos Reis 1 sibling, 0 replies; 97+ messages in thread From: Mark Mitchell @ 2005-05-24 7:09 UTC (permalink / raw) To: Zack Weinberg; +Cc: Gabriel Dos Reis, gcc, jason, dberlin Zack Weinberg wrote: > (And I'd be less grumpy about coding to the intersection of C and C++ > if someone coded up warnings for the C compiler to catch things > outside the intersection.) My feeling on this is that it's not fair to expect people to know C++, until and unless we switch to actually using C++. I'd say just code how you always have, within our existing coding standards, and ignore the issue; let people who care fix it up after the fact, or comment on your patches when you post them. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:08 ` Zack Weinberg 2005-05-24 7:09 ` Mark Mitchell @ 2005-05-24 7:39 ` Gabriel Dos Reis 2005-05-24 8:48 ` Zack Weinberg 2005-05-25 0:47 ` Russ Allbery 1 sibling, 2 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 7:39 UTC (permalink / raw) To: Zack Weinberg; +Cc: Mark Mitchell, gcc, jason, dberlin Zack Weinberg <zack@codesourcery.com> writes: | Mark Mitchell <mark@codesourcery.com> writes: | ... | > Like you, I do think these problems are surmountable; but, also like | > you, I think it would take some time to get all the problems solved. | > I don't really think, though, that this is immediately relevant; | > Gaby's trying to fix things that seem to me like they will actually | > make for better C code, and, right now at least, going to C++ isn't on | > the table. I think you agree that most of the changes Gaby wants to | > make are for the better (with the possible exception of casting the | > return value of malloc, which will be hidden in a macro that's | > probably less error-prone that writing out the malloc calls directly) | > -- but you're concerned about the fact that doing this work now might | > make it too easy for us to switch to C++ without thinking about all | > the issues? | | Yes, that's what I'm trying to get at. Secondarily, I don't want to | lose some of the expressive power of C-that-is-not-C++ if we're not | getting the expressive power of C++ in exchange -- for instance, I | really don't want to have to avoid the set of C++ keywords when coding | in C, or remember the semantic difference between C and C++ struct tags. But we do not get any expressive power by using C++ keywords. Using C++ keywords just make it impossible to have better checking provided by C++ compilers. That is no gain. It is a lost. Furthermore, if you ever move to C++ as you wanted to do, you will have to abondon those keywords anyway, so it does not represent any essential to expressive power. I find the insistance of using C++ keywords (while wishing for moving to C++) very inconsistent, if not contrary to our coding conventions. | I'd change my tune if Gaby could demonstrate a place where the C++ | compiler caught a user-visible bug that the C compiler missed. That | would be worth the extra discipline. All the bugs described so far, | however, have been things that, while formally incorrect, haven't | affected the visible behavior of the compiler. That is an extreme statement. First, I just complete the project this afternoon. Furthermore, the fact that a function was called with with one argument, but its definition was poking at a second argument is a bug whose effect is hard to trace down correcly. But that was just the first one I came across. Furthermore, the benefits are not just what bugs we can catch right now, but how we make it possible to build free software based on GCC, and encourage more contributions. I know of a number of projects that are done with proprietary compilers, that could have been done with GCC (and people are ready to move to GCC, I know at a number of Codesourcery customers ;-)) if it were possible to have GCC compilable with a C++ compiler. Frankly, there does not seem to be any benefit to obsctructing these patches that would align us with our own coding conventions. | (And I'd be less grumpy about coding to the intersection of C and C++ | if someone coded up warnings for the C compiler to catch things | outside the intersection.) Consider that to be a follow-up that I'm willing to do, if these preliminary patches are in. For sure, I do want to make sure that we do not break things too easily. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:39 ` Gabriel Dos Reis @ 2005-05-24 8:48 ` Zack Weinberg 2005-05-24 13:41 ` Gabriel Dos Reis 2005-05-25 0:47 ` Russ Allbery 1 sibling, 1 reply; 97+ messages in thread From: Zack Weinberg @ 2005-05-24 8:48 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Mark Mitchell, gcc, jason, dberlin Gabriel Dos Reis <gdr@integrable-solutions.net> writes: > But we do not get any expressive power by using C++ keywords. Readability, readability, readability. (for instance, 'class' vs. 'klass' - I can read decimal orders of magnitude faster if all the English words in what I'm reading are correctly spelled) > That is an extreme statement. *shrug* That's what would make it worthwhile to me. > Furthermore, the benefits are not just what bugs we can catch right > now, but how we make it possible to build free software based on > GCC, and encourage more contributions. The YAGNI principle applies, in my opinion. > | (And I'd be less grumpy about coding to the intersection of C and > | C++ if someone coded up warnings for the C compiler to catch > | things outside the intersection.) > > Consider that to be a follow-up that I'm willing to do, if these > preliminary patches are in. Thank you, I appreciate that. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 8:48 ` Zack Weinberg @ 2005-05-24 13:41 ` Gabriel Dos Reis 0 siblings, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 13:41 UTC (permalink / raw) To: Zack Weinberg; +Cc: Mark Mitchell, gcc, jason, dberlin Zack Weinberg <zack@codesourcery.com> writes: | Gabriel Dos Reis <gdr@integrable-solutions.net> writes: | | > But we do not get any expressive power by using C++ keywords. | | Readability, readability, readability. | | (for instance, 'class' vs. 'klass' When replacing "class" with a new identifier, "klass" it not the only choice. Therefore, it does not appear that you have exhibited any loss of readability. You have just suggested a worst choise, but it is not the only one we have. [...] | > | (And I'd be less grumpy about coding to the intersection of C and | > | C++ if someone coded up warnings for the C compiler to catch | > | things outside the intersection.) | > | > Consider that to be a follow-up that I'm willing to do, if these | > preliminary patches are in. | | Thank you, I appreciate that. So, were do we stand? Notice again that none of the changes are outside our existing coding conventions. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:39 ` Gabriel Dos Reis 2005-05-24 8:48 ` Zack Weinberg @ 2005-05-25 0:47 ` Russ Allbery 2005-05-25 1:24 ` Gabriel Dos Reis 1 sibling, 1 reply; 97+ messages in thread From: Russ Allbery @ 2005-05-25 0:47 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc Gabriel Dos Reis <gdr@integrable-solutions.net> writes: > Zack Weinberg <zack@codesourcery.com> writes: > | (And I'd be less grumpy about coding to the intersection of C and C++ > | if someone coded up warnings for the C compiler to catch things > | outside the intersection.) > Consider that to be a follow-up that I'm willing to do, if these > preliminary patches are in. For sure, I do want to make sure that we > do not break things too easily. Even apart from this project and this discussion, this would be awesome to have, and I would be deeply grateful if you or someone else would implement this. Various people have requested over the years that some of the packages I maintain compile cleanly with a C++ compiler, and while I can test such compiles with special effort, being able to integrate the warnings about it into my normal make warnings build would be incredibly useful. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:47 ` Russ Allbery @ 2005-05-25 1:24 ` Gabriel Dos Reis 0 siblings, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 1:24 UTC (permalink / raw) To: Russ Allbery; +Cc: gcc Russ Allbery <rra@stanford.edu> writes: | Gabriel Dos Reis <gdr@integrable-solutions.net> writes: | > Zack Weinberg <zack@codesourcery.com> writes: | | > | (And I'd be less grumpy about coding to the intersection of C and C++ | > | if someone coded up warnings for the C compiler to catch things | > | outside the intersection.) | | > Consider that to be a follow-up that I'm willing to do, if these | > preliminary patches are in. For sure, I do want to make sure that we | > do not break things too easily. | | Even apart from this project and this discussion, this would be awesome to | have, and I would be deeply grateful if you or someone else would | implement this. I'm implementing this. However, Zack has decided to gratuituously to stand in the way, contrary to our coding conventions. You would need to alk to him, or the Steering Committ need to talk to him. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:29 ` Zack Weinberg 2005-05-24 6:31 ` Mark Mitchell @ 2005-05-24 16:07 ` Paolo Bonzini 2005-05-24 16:44 ` Daniel Jacobowitz 2 siblings, 0 replies; 97+ messages in thread From: Paolo Bonzini @ 2005-05-24 16:07 UTC (permalink / raw) To: Zack Weinberg, GCC Development > This scenario, at least theoretically, becomes a non-issue if we make > top-level bootstrap the only option before we start using C++ features > in GCC, but that hasn't happened yet. It will happen soon after the end of the slush. The last preliminary patch has already been posted, then all one has to do is to flip the default. In the meanwhile, the CFT is open since last September :-) Last time I ran a toplevel bootstrap was a couple of weeks ago. Paolo ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:29 ` Zack Weinberg 2005-05-24 6:31 ` Mark Mitchell 2005-05-24 16:07 ` Paolo Bonzini @ 2005-05-24 16:44 ` Daniel Jacobowitz 2005-05-24 23:53 ` Zack Weinberg 2 siblings, 1 reply; 97+ messages in thread From: Daniel Jacobowitz @ 2005-05-24 16:44 UTC (permalink / raw) To: Zack Weinberg; +Cc: Gabriel Dos Reis, gcc, jason, mark, dberlin [Rearranging] > I want to emphasize that I don't think any of these are unsolvable > problems. I do think they are all real problems, and I think there > are going to be other problems I haven't listed above, and I want to > be sure we have considered the problems and have solutions in hand > before we take the plunge. On the other hand, I've spent time thinking about all of these already. For instance, let me point one thing out that you mention a couple of times but don't give enough attention to: > just how hard it can be to fix such bugs. We've had similar problems > with the shared libgcc. We've fixed a lot of these problems already; I will be brave and say that we have fixed most of them. On Mon, May 23, 2005 at 11:04:14PM -0700, Zack Weinberg wrote: > Scenario one: Suppose that both libcpp and gcc start using <vector>, > and that the initial compiler/runtime's implementation of <vector> is > binary incompatible with the implementation being built. Libcpp is > currently built only with the initial compiler. Bootstrap will fail > in stage 2, when we try to link libcpp modules expecting the older > <vector> against a library implementing the newer <vector> (or perhaps > the link will succeed but the resulting executable won't work). This > scenario, at least theoretically, becomes a non-issue if we make > top-level bootstrap the only option before we start using C++ features > in GCC, but that hasn't happened yet. As Paolo wrote, it will soon. This isn't the only thing it'll fix. For instance it would let us use bool in those interfaces again, without breaking Darwin. > Scenario two: Suppose that we have not found every last place where > LD_LIBRARY_PATH, or equivalent, needs to be set during bootstrap to > ensure that the dynamic linker binds the stage 2 compiler to the > shared libstdc++ that it's expecting. If there isn't a libstdc++.so > in /usr/lib, or if there is but it is not compatible with the one the > compiler wants, again bootstrap will fail. Any time this scenario > comes up, it is attributable to a bug in the Makefiles, but you know > just how hard it can be to fix such bugs. We've had similar problems > with the shared libgcc. With top level bootstrap this is trivial to get right. The top level should set the library path appropriately for the stage. > Scenario three: Suppose that libstdc++.so.7 (gcc-4.2) and > libstdc++.so.7 (gcc-4.3) are compatible in the same way that libc.so.6 > (glibc-2.0) and libc.so.6 (glibc-2.1) are compatible: that is, if you > build a binary against the first, it'll run against the second, but > not vice versa. Now, suppose that on some system gcc-4.2 is > /usr/bin/gcc, its libstdc++.so.7 is installed in /usr/lib, and we're > trying to use it to compile gcc-4.3, to be installed in /opt/gcc-4.3 > or some other weird place that is not in the dynamic linker's default > search path. Furthermore, scenarios one and two have been properly > avoided. The bootstrap process will produce final compiler binaries > that have been linked against the 4.3 libstdc++.so. If we include > RPATHs in those binaries, bootstrap will fail, because the library > isn't installed yet; if we don't, bootstrap and testing will succeed, > but the installed compiler will not run unless the user knows to set > LD_LIBRARY_PATH, which has its own problems. DT_RUNPATH could > theoretically be used to make this work, but we can't count on > DT_RUNPATH. You do realize that libgcc is "compatible" in the same way as glibc, right? If you do this and don't copy the hypothetical gcc 4.3 libgcc_s.so.1 into your system library directory, C++ stands a decent chance of not working. Not a new problem. I don't know why you think that the DT_RPATH would cause the build to fail. A DT_RPATH pointing at a non-existant directory is harmless and LD_LIBRARY_PATH will still be used. It's only if you had an old copy in $prefix that DT_RPATH would bite you. And there are plenty of other ways around this - for instance, a shell script named xgcc in the build tree which LD_PRELOADs the correct copy using a full path. > Scenario four: Suppose that we manage to avoid all the above > scenarios. Suppose further that we think we have achieved binary > compatibility between different versions of libstdc++, but we are > wrong. Then 'make install' is likely to overwrite the libstdc++.so on > the system with one that is, in fact, not compatible, and break > already-installed software. This could, of course, happen even if we > don't start using C++ in GCC itself - I bring it up to caution us > against rushing into declaring libstdc++ ABI-frozen. I'd want to see > at least two major releases with no libstdc++ soname bump and no > problems reported, before I had confidence we'd gotten it right. You mean, like GCC 3.4 and GCC 4.0? -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 16:44 ` Daniel Jacobowitz @ 2005-05-24 23:53 ` Zack Weinberg 2005-05-25 0:06 ` Daniel Jacobowitz 2005-05-25 0:26 ` Paolo Carlini 0 siblings, 2 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-24 23:53 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Gabriel Dos Reis, gcc, jason, mark, dberlin On Tue, 2005-05-24 at 09:41 -0400, Daniel Jacobowitz wrote: > We've fixed a lot of these problems already; I will be brave and say > that we have fixed most of them. I'm glad you're optimistic about it. It's good to have someone balancing out pessimistic people like me. :) > > This scenario, at least theoretically, becomes a non-issue if we make > > top-level bootstrap the only option before we start using C++ features > > in GCC, but that hasn't happened yet. > > As Paolo wrote, it will soon. This isn't the only thing it'll fix. > For instance it would let us use bool in those interfaces again, > without breaking Darwin. Actually it won't. We could only use a real 'bool' if we switched to C++. Short of that, we can't count on bool being a real bool, so we have to #define it to unsigned char everywhere so that no one accidentally writes code that relies on bool having Boolean semantics. You might think we could get away with it in stage 2, but that's actually a recipe for comparison failures. (I'm pleasantly surprised to report that HP's C++ compiler *doesn't* have the bool/_Bool bugs that their C compiler does.) > > Scenario two: Suppose that we have not found every last place where > > LD_LIBRARY_PATH, or equivalent, needs to be set during bootstrap to > > ensure that the dynamic linker binds the stage 2 compiler to the > > shared libstdc++ that it's expecting. > > With top level bootstrap this is trivial to get right. The top level > should set the library path appropriately for the stage. Um, there have been plenty of cases in the past where the top level set something correctly and the subdirectory makefiles overrode it with an incorrect setting. > You do realize that libgcc is "compatible" in the same way as glibc, > right? If you do this and don't copy the hypothetical gcc 4.3 > libgcc_s.so.1 into your system library directory, C++ stands a decent > chance of not working. Not a new problem. No, not a new problem. In a lot of ways, C++ use in GCC would inflict on us the same problems we've been inflicting on our users since before 3.0. ;-/ > I don't know why you think that the DT_RPATH would cause the build to > fail. A DT_RPATH pointing at a non-existant directory is harmless and > LD_LIBRARY_PATH will still be used. It's only if you had an old copy > in $prefix that DT_RPATH would bite you. And there are plenty of other > ways around this - for instance, a shell script named xgcc in the build > tree which LD_PRELOADs the correct copy using a full path. I had misremembered what DT_RPATH did if the directory didn't exist; my bad. In private mail someone suggested $ORIGIN to me as a possible solution. I really don't mean to be giving the impression that these are intractable problems; I just don't want them considered non-problems. > > I'd want to see at least two major releases with no libstdc++ soname > > bump and no problems reported, before I had confidence we'd gotten > > it right. > > You mean, like GCC 3.4 and GCC 4.0? If GCC 4.1 comes out without anyone having reported 3.4/4.0 incompatibilities, and continues to provide libstdc++.so.6, then yes, that would be like what I mean. However, the active development on the libstdc++.so.7 branch means that we haven't even started the clock running on this criterion yet. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 23:53 ` Zack Weinberg @ 2005-05-25 0:06 ` Daniel Jacobowitz 2005-05-25 0:11 ` Richard Henderson 2005-05-25 0:22 ` Zack Weinberg 2005-05-25 0:26 ` Paolo Carlini 1 sibling, 2 replies; 97+ messages in thread From: Daniel Jacobowitz @ 2005-05-25 0:06 UTC (permalink / raw) To: Zack Weinberg; +Cc: Gabriel Dos Reis, gcc, jason, mark, dberlin On Tue, May 24, 2005 at 04:20:27PM -0700, Zack Weinberg wrote: > Um, there have been plenty of cases in the past where the top level set > something correctly and the subdirectory makefiles overrode it with an > incorrect setting. Ah, but once we have a globally correct setting in the top level we can brutally eliminate settings further down. This does require toplevel bootstrap. > In private mail someone suggested $ORIGIN to me as a possible solution. > I really don't mean to be giving the impression that these are > intractable problems; I just don't want them considered non-problems. $ORIGIN is nifty; but do you know how portable it is? I've got no clue. > > > I'd want to see at least two major releases with no libstdc++ soname > > > bump and no problems reported, before I had confidence we'd gotten > > > it right. > > > > You mean, like GCC 3.4 and GCC 4.0? > > If GCC 4.1 comes out without anyone having reported 3.4/4.0 > incompatibilities, and continues to provide libstdc++.so.6, then yes, > that would be like what I mean. However, the active development on the > libstdc++.so.7 branch means that we haven't even started the clock > running on this criterion yet. That would be three major releases unless you're counting differently than I am. My point was that we did preserve the soname between 3.4 and 4.0, and no one's reported trouble because of that yet - and I have fairly high confidence that no one will. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:06 ` Daniel Jacobowitz @ 2005-05-25 0:11 ` Richard Henderson 2005-05-25 0:22 ` Zack Weinberg 1 sibling, 0 replies; 97+ messages in thread From: Richard Henderson @ 2005-05-25 0:11 UTC (permalink / raw) To: Zack Weinberg, Gabriel Dos Reis, gcc, jason, mark, dberlin On Tue, May 24, 2005 at 07:17:22PM -0400, Daniel Jacobowitz wrote: > $ORIGIN is nifty; but do you know how portable it is? I've got no > clue. Solaris and Linux only, afaik. r~ ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:06 ` Daniel Jacobowitz 2005-05-25 0:11 ` Richard Henderson @ 2005-05-25 0:22 ` Zack Weinberg 1 sibling, 0 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-25 0:22 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Gabriel Dos Reis, gcc, jason, mark, dberlin On Tue, 2005-05-24 at 19:17 -0400, Daniel Jacobowitz wrote: > On Tue, May 24, 2005 at 04:20:27PM -0700, Zack Weinberg wrote: > > Um, there have been plenty of cases in the past where the top level set > > something correctly and the subdirectory makefiles overrode it with an > > incorrect setting. > > Ah, but once we have a globally correct setting in the top level we can > brutally eliminate settings further down. This does require toplevel > bootstrap. Can, yeah, but how long will it take to get done? It's two years later and we're still ripping 2.13isms out of gcc/configure.ac at a painfully slow rate. > $ORIGIN is nifty; but do you know how portable it is? I've got no > clue. Linux and Solaris, is all I know. Note that the solution needn't be the same on all platforms. > > If GCC 4.1 comes out without anyone having reported 3.4/4.0 > > incompatibilities, and continues to provide libstdc++.so.6, then yes, > > that would be like what I mean. However, the active development on the > > libstdc++.so.7 branch means that we haven't even started the clock > > running on this criterion yet. > > That would be three major releases unless you're counting differently > than I am. My point was that we did preserve the soname between 3.4 > and 4.0, and no one's reported trouble because of that yet - and I have > fairly high confidence that no one will. I'm counting two full development cycles since the initial release with the frozen ABI. Or, perhaps it will make more sense if I describe it as one full development cycle since the release of the second compiler that implements the frozen ABI. This is to give people time to find and report problems, which they are more likely to do when it involves comparing two official releases than when it involves comparing a released version to the development trunk. 4.0 has only been out for what, a month now? And people are being skittish about adopting it because of all the optimizer changes. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 23:53 ` Zack Weinberg 2005-05-25 0:06 ` Daniel Jacobowitz @ 2005-05-25 0:26 ` Paolo Carlini 2005-05-25 0:37 ` Zack Weinberg 1 sibling, 1 reply; 97+ messages in thread From: Paolo Carlini @ 2005-05-25 0:26 UTC (permalink / raw) To: Zack Weinberg Cc: Daniel Jacobowitz, Gabriel Dos Reis, gcc, jason, mark, dberlin Hi, >.......................... However, the active development on the >libstdc++.so.7 branch means that we haven't even started the clock >running on this criterion yet. > > Maybe a clarification is in order: actually, the name libstdcxx_so_7-branch is somewhat misleading, right now. Indeed, it's absolutely true that a lot of active development is going on in that branch (consider the nice changes contributed by Chris Jefferson, for instance, and more will come), but not necessarily all those changes actually break to ABI. In a nutshell, we are using that branch for new, experimental features/optimizations that *may* break the ABI. For instance, in my understanding at least, if we decide somehow in the future to ship a different implementation of basic_string, that will break the ABI. Probably this is not the case for many changes to the containers, *very* little of which is present in the built *.a and *.so. Really, during the next months we want to re-evaluate the various subsets of changes for possible merge to 4.1 or, anyway, not-ABI-breaking branches. I'm not sure what the above may imply for your ongoing discussion, tough... Paolo. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:26 ` Paolo Carlini @ 2005-05-25 0:37 ` Zack Weinberg 2005-05-25 0:43 ` Daniel Jacobowitz 2005-05-25 12:44 ` Christoph Hellwig 0 siblings, 2 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-25 0:37 UTC (permalink / raw) To: Paolo Carlini Cc: Daniel Jacobowitz, Gabriel Dos Reis, gcc, jason, mark, dberlin On Wed, 2005-05-25 at 01:45 +0200, Paolo Carlini wrote: > >.......................... However, the active development on the > >libstdc++.so.7 branch means that we haven't even started the clock > >running on this criterion yet. > > Maybe a clarification is in order: actually, the name > libstdcxx_so_7-branch is somewhat misleading, right now. Indeed, it's > absolutely true that a lot of active development is going on in that > branch (consider the nice changes contributed by Chris Jefferson, for > instance, and more will come), but not necessarily all those changes > actually break to ABI. Thanks for the clarification. I did not know this. > I'm not sure what the above may imply for your ongoing discussion, tough... Well, if I were running the show, the 'clock' would only start running when it was consensus among the libstdc++ developers that the soname would not be bumped again - that henceforth libstdc++ was committed to binary compatibility as good as glibc's. Or better, if y'all can manage it. It doesn't sound like we're there yet, to me. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:37 ` Zack Weinberg @ 2005-05-25 0:43 ` Daniel Jacobowitz 2005-05-25 0:48 ` Zack Weinberg 2005-05-25 12:44 ` Christoph Hellwig 1 sibling, 1 reply; 97+ messages in thread From: Daniel Jacobowitz @ 2005-05-25 0:43 UTC (permalink / raw) To: Zack Weinberg; +Cc: Paolo Carlini, Gabriel Dos Reis, gcc, jason, mark, dberlin On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote: > Well, if I were running the show, the 'clock' would only start running > when it was consensus among the libstdc++ developers that the soname > would not be bumped again - that henceforth libstdc++ was committed to > binary compatibility as good as glibc's. Or better, if y'all can manage > it. It doesn't sound like we're there yet, to me. If that's why you were confused by my response, I was not suggesting freezing the ABI. I think it's an awful idea. You specifically objected to shipping two versions using the same SONAME in case we installed the new one and it turned out to be incompatible - which we've done. I still haven't seen a valid objection to bumping the SONAME whenever necessary. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:43 ` Daniel Jacobowitz @ 2005-05-25 0:48 ` Zack Weinberg 2005-05-25 1:02 ` Paolo Carlini ` (2 more replies) 0 siblings, 3 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-25 0:48 UTC (permalink / raw) To: Daniel Jacobowitz Cc: Paolo Carlini, Gabriel Dos Reis, gcc, jason, mark, dberlin On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote: > On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote: > > Well, if I were running the show, the 'clock' would only start running > > when it was consensus among the libstdc++ developers that the soname > > would not be bumped again - that henceforth libstdc++ was committed to > > binary compatibility as good as glibc's. Or better, if y'all can manage > > it. It doesn't sound like we're there yet, to me. > > If that's why you were confused by my response, I was not suggesting > freezing the ABI. I think it's an awful idea. Why? To be honest, I keep harping on this mostly because I think it should happen. All the C++-in-GCC noise is a digression. You know how much work it is for the distributors every time we bump the libstdc++ soname. Why wouldn't we want to stop inflicting that pain on them? zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:48 ` Zack Weinberg @ 2005-05-25 1:02 ` Paolo Carlini 2005-05-25 3:14 ` Daniel Jacobowitz 2005-05-25 16:18 ` Jason Merrill 2 siblings, 0 replies; 97+ messages in thread From: Paolo Carlini @ 2005-05-25 1:02 UTC (permalink / raw) To: Zack Weinberg Cc: Daniel Jacobowitz, Gabriel Dos Reis, gcc, jason, mark, dberlin Zack Weinberg wrote: >Why? To be honest, I keep harping on this mostly because I think it >should happen. All the C++-in-GCC noise is a digression. > > I was wondering: is it too late to organize a Panel at GCCSummit? Otherwise we can meet anyway more informally and discuss all those issues anyway. In my opinion, during the last years too often the various points of view remained implicit: it's probably in order a little bit of planning based on clear, open discussion and, hopefully, consensus. Paolo. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:48 ` Zack Weinberg 2005-05-25 1:02 ` Paolo Carlini @ 2005-05-25 3:14 ` Daniel Jacobowitz 2005-05-25 16:18 ` Jason Merrill 2 siblings, 0 replies; 97+ messages in thread From: Daniel Jacobowitz @ 2005-05-25 3:14 UTC (permalink / raw) To: Zack Weinberg; +Cc: Paolo Carlini, Gabriel Dos Reis, gcc, jason, mark, dberlin On Tue, May 24, 2005 at 05:32:27PM -0700, Zack Weinberg wrote: > On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote: > > On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote: > > > Well, if I were running the show, the 'clock' would only start running > > > when it was consensus among the libstdc++ developers that the soname > > > would not be bumped again - that henceforth libstdc++ was committed to > > > binary compatibility as good as glibc's. Or better, if y'all can manage > > > it. It doesn't sound like we're there yet, to me. > > > > If that's why you were confused by my response, I was not suggesting > > freezing the ABI. I think it's an awful idea. > > Why? To be honest, I keep harping on this mostly because I think it > should happen. All the C++-in-GCC noise is a digression. > > You know how much work it is for the distributors every time we bump the > libstdc++ soname. Why wouldn't we want to stop inflicting that pain on > them? I know exactly how much work it is for Debian. I wouldn't mind slowing down. I wouldn't mind using symbol versioning to solve the problem, if I honestly thought that were feasible (which I don't, for a C++ implementation library). But the fact of the matter is, the distros know how to deal with this once in a while. I think that it's more important that we continue to improve the library, for now. In a couple years I'll probably think differently. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:48 ` Zack Weinberg 2005-05-25 1:02 ` Paolo Carlini 2005-05-25 3:14 ` Daniel Jacobowitz @ 2005-05-25 16:18 ` Jason Merrill 2 siblings, 0 replies; 97+ messages in thread From: Jason Merrill @ 2005-05-25 16:18 UTC (permalink / raw) To: Zack Weinberg Cc: Daniel Jacobowitz, Paolo Carlini, Gabriel Dos Reis, gcc, mark, dberlin On Tue, 24 May 2005 17:32:27 -0700, Zack Weinberg <zack@codesourcery.com> wrote: > On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote: >> If that's why you were confused by my response, I was not suggesting >> freezing the ABI. I think it's an awful idea. > > Why? To be honest, I keep harping on this mostly because I think it > should happen. All the C++-in-GCC noise is a digression. The problem is that for a library that uses inlines and templates extensively, the implementation is the interface, and so a change of implementation frequently results in an ABI change. So we can't freeze the library ABI until we're willing to commit to the implementation. C++ is much less friendly to separate compilation than C, at least if you use templates. Jason ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:37 ` Zack Weinberg 2005-05-25 0:43 ` Daniel Jacobowitz @ 2005-05-25 12:44 ` Christoph Hellwig 2005-05-25 13:33 ` Florian Weimer 2005-05-27 3:10 ` Marcin Dalecki 1 sibling, 2 replies; 97+ messages in thread From: Christoph Hellwig @ 2005-05-25 12:44 UTC (permalink / raw) To: Zack Weinberg Cc: Paolo Carlini, Daniel Jacobowitz, Gabriel Dos Reis, gcc, jason, mark, dberlin On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote: > > I'm not sure what the above may imply for your ongoing discussion, tough... > > Well, if I were running the show, the 'clock' would only start running > when it was consensus among the libstdc++ developers that the soname > would not be bumped again - that henceforth libstdc++ was committed to > binary compatibility as good as glibc's. Or better, if y'all can manage > it. It doesn't sound like we're there yet, to me. Why can't libstdc++ use symbol versioning? glibc has maintained the soname and binary comptiblity despite changing fundamental types like FILE ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 12:44 ` Christoph Hellwig @ 2005-05-25 13:33 ` Florian Weimer 2005-05-27 3:10 ` Marcin Dalecki 1 sibling, 0 replies; 97+ messages in thread From: Florian Weimer @ 2005-05-25 13:33 UTC (permalink / raw) To: Christoph Hellwig Cc: Zack Weinberg, Paolo Carlini, Daniel Jacobowitz, Gabriel Dos Reis, gcc, jason, mark, dberlin * Christoph Hellwig: > Why can't libstdc++ use symbol versioning? Via stack allocation, templates and inline functions, the internal representation of libstdc++ data structures is exported. All of its users would have to be versioned, too, and you'd need bridging code between the ABIs (e.g. to pass a std::string from a v6 library to a v7 library). ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 12:44 ` Christoph Hellwig 2005-05-25 13:33 ` Florian Weimer @ 2005-05-27 3:10 ` Marcin Dalecki 1 sibling, 0 replies; 97+ messages in thread From: Marcin Dalecki @ 2005-05-27 3:10 UTC (permalink / raw) To: Christoph Hellwig Cc: Zack Weinberg, Paolo Carlini, Daniel Jacobowitz, Gabriel Dos Reis, gcc, jason, mark, dberlin On 2005-05-25, at 08:06, Christoph Hellwig wrote: > On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote: > >>> I'm not sure what the above may imply for your ongoing >>> discussion, tough... >>> >> >> Well, if I were running the show, the 'clock' would only start >> running >> when it was consensus among the libstdc++ developers that the soname >> would not be bumped again - that henceforth libstdc++ was >> committed to >> binary compatibility as good as glibc's. Or better, if y'all can >> manage >> it. It doesn't sound like we're there yet, to me. >> > > Why can't libstdc++ use symbol versioning? glibc has maintained > the soname > and binary comptiblity despite changing fundamental types like FILE Please stop spreading rumors: 1. libgcc changes with compiler release. glibc is loving libgcc. ergo: glibc has not maintained the soname and binary compatibility. 2. The whole linker tricks glibc plays to accomplish this are not portable and not applicable to C++ code. 3. Threads are the death to glibc backward compatibility. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 5:54 ` Zack Weinberg 2005-05-24 6:04 ` Daniel Jacobowitz @ 2005-05-24 6:13 ` Andrew Pinski 2005-05-24 6:25 ` Gabriel Dos Reis 2005-05-27 4:04 ` Marcin Dalecki 2005-05-24 6:18 ` Gabriel Dos Reis 2005-05-24 6:26 ` Mark Mitchell 3 siblings, 2 replies; 97+ messages in thread From: Andrew Pinski @ 2005-05-24 6:13 UTC (permalink / raw) To: Zack Weinberg; +Cc: jason, Gabriel Dos Reis, gcc, mark, dberlin On May 24, 2005, at 12:01 AM, Zack Weinberg wrote: > Use of bare 'inline' is just plain wrong in our source code; this has > nothing to do with C++, no two C compilers implement bare 'inline' > alike. Patches to add 'static' to such functions (AND MAKING NO OTHER > CHANGES) are preapproved, post-slush. That will not work for the cases where the bare 'inline' are used because they are external also in this case. Now this is where C99 and C++ differs at what a bare 'inline' means so I have no idea what to do, except for removing the 'inline' in first place. Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:13 ` Andrew Pinski @ 2005-05-24 6:25 ` Gabriel Dos Reis 2005-05-27 4:04 ` Marcin Dalecki 1 sibling, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 6:25 UTC (permalink / raw) To: Andrew Pinski; +Cc: Zack Weinberg, jason, gcc, mark, dberlin Andrew Pinski <pinskia@physics.uc.edu> writes: | On May 24, 2005, at 12:01 AM, Zack Weinberg wrote: | > Use of bare 'inline' is just plain wrong in our source code; this has | > nothing to do with C++, no two C compilers implement bare 'inline' | > alike. Patches to add 'static' to such functions (AND MAKING NO OTHER | > CHANGES) are preapproved, post-slush. | That will not work for the cases where the bare 'inline' are used | because they are external also in this case. Now this is where C99 and | C++ differs at what a bare 'inline' means so I have no idea what to | do, except for removing the 'inline' in first place. It suffices to make the function "static inline". See our current extensive usage. That works for both C and C++. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:13 ` Andrew Pinski 2005-05-24 6:25 ` Gabriel Dos Reis @ 2005-05-27 4:04 ` Marcin Dalecki 1 sibling, 0 replies; 97+ messages in thread From: Marcin Dalecki @ 2005-05-27 4:04 UTC (permalink / raw) To: Andrew Pinski; +Cc: Zack Weinberg, jason, Gabriel Dos Reis, gcc, mark, dberlin On 2005-05-24, at 06:00, Andrew Pinski wrote: > > On May 24, 2005, at 12:01 AM, Zack Weinberg wrote: > >> Use of bare 'inline' is just plain wrong in our source code; this has >> nothing to do with C++, no two C compilers implement bare 'inline' >> alike. Patches to add 'static' to such functions (AND MAKING NO >> OTHER >> CHANGES) are preapproved, post-slush. >> > That will not work for the cases where the bare 'inline' are used > because they are external also in this case. Now this is where C99 > and > C++ differs at what a bare 'inline' means so I have no idea what to > do, except for removing the 'inline' in first place. This actually applies only to two function from libiberty: /* Return the current size of given hash table. */ -inline size_t -htab_size (htab) - htab_t htab; +size_t +htab_size (htab_t htab) { return htab->size; } /* Return the current number of elements in given hash table. */ -inline size_t -htab_elements (htab) - htab_t htab; +size_t +htab_elements (htab_t htab) { return htab->n_elements - htab->n_deleted; } It could be resolved easy be moving those "macro wrappers" in to a header and making the static inline there. Actually this could improve the GCC code overall a bit. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 5:54 ` Zack Weinberg 2005-05-24 6:04 ` Daniel Jacobowitz 2005-05-24 6:13 ` Andrew Pinski @ 2005-05-24 6:18 ` Gabriel Dos Reis 2005-05-24 6:43 ` Zack Weinberg 2005-05-24 6:26 ` Mark Mitchell 3 siblings, 1 reply; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 6:18 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc, jason, mark, dberlin Zack Weinberg <zack@codesourcery.com> writes: | On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote: | > Hi, | > | > I spent the week-end trying to get GCC -- mainline -- compilable | > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). | | These results are very interesting. | | As a general observation: A lot of the things you have found to be | problematic, are in fact preferred idioms for C code. For instance, | no standard-C programmer would ever write an explicit cast on malloc's | return value. I think that we are losing something, if only in | readability, if we restrict our code to the subset of C which is also | correct C++. I think opinions are variable here a lot. If for example, you take a look at examples in The C Programming Language (all editions), you'll find explicit casts on malloc's return value. Yet, I would refrain from calling Dennis Ritchie as a non standard-C programmer or his book, TCPL2, not describing standard C. Most of the C programmers I've met have learnt from his book. (Yes, I've also read some C programmers comment that nobody should cast the return value of malloc, but for large scale sofwtare, I have not seen their opinions as dorminating). The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC and such. It is not anything you'll find in the code directly. So, in fact we do not lose readability as you claim. | Now, if we were migrating to C++, that would be okay, | because we would (eventually) get all of the additional expressive power | of C++ in exchange. However, if we're not migrating to C++, I'm opposed | to the inclusion of patches that restrict our C code to the subset which | is correct C++. The patches are aligning us to our coding standards. I don't think it is reasonable to throw roadblocks in the way, especially when they are contrary to our current coding standards. The claim that the cast will obscure the code is unjustified as the use of the libiberty macros relieve us of springling cast in the code. See my previous patches to libiberty and fixincludes. I don't think your suggestion of moving to C++ is workable at this point. The patches of aligning us to the common subsets of C90 and C++ is following the consensus we developed as our coding standards. | Furthermore, as I've said before, I support migrating | to C++ -- but only if the C++ ABI and libstdc++ soname are first | permanently frozen. If we do not do that first, we risk being trapped | into a situation where we need specific versions of GCC to compile | specific newer versions of GCC, which would be a Bad Thing. Throwing roadblocks in the way is not going to help the GCC project. It is unreasonable to that at this time. | The C++ ABI seems to be stable at this point, but there is not yet | consensus that it will never again be changed. The libstdc++ team is | currently developing yet another new, incompatible version, so I see no | hope for a permanent freeze of its soname in the near future. Thus, | while you've discovered some interesting things by trying this, I don't | think C++ compatibility patches should be applied now. The issue of moving to C++ is independent of our aligning ourselves to our coding standards. I don't beleive it is reasonable to block these patches on the ground that we could conceive moving to C++ (which is a controversial issue). The decision to code at the intersection of C90 and C++ is a consensus we reached after repeated debates. | Having said that, some comments on the problems you have found: | | > Third, there is some "type-punning" with enums, int and unsigned int, | > where the middle-end (mostly) relies on implicit conversion from int | > to enums. | | Being allowed to do this is very important. Some enumerated types are | to be treated as opaque outside a very narrow context; the only way to | do that in C is to have (a typedef of) unsigned int as the visible type, | and only declare the enumerated type in the context where it's allowed | to be used. I have looked at every of those uses -- since I went through editing almost every file needed for compiling GNU C and GNU C++ compilers. None of the cases appear important. The only compelling cases are when front-ends (eg.g C or C++) extend them (e.g. c_tree_code or cplus_tree_code). However, none of the current approach is necessary. As, RTH pointed out in the past, front-ends should define those enumerators as a whole by appropriately #include the file. We can arrange for that -- in fact I've tested variants of that in my experiments. No cast is neeeded when done properly. | I want to see more use of this idiom, not less; for | example, 'enum machine_mode' ought to be a black box to almost the | entire compiler. Me too, but the way to make it a black box is not to cast it so unsigned int back forth willy nilly -- that does not make it a black box, on the contrary. For example, we should be using EXPAND_NORMAL instead of plain "0". | I'd be delighted to hear of a more C++-friendly way to | code this. See above. | Naturally, where the constant is _not_ opaque outside of a | defined context, but is part of an interface (as your examples seemed to | be), not using it is just sloppy. | | > Fourth, it appears that we're implicilty using C99's semantics of | > "extern inline" in our source -- when we have a pure C90 compiler that | > does not understand "inline", we just #define inline to nothing so we | > don't get into trouble. With a C++ compiler, we're in trouble because | > an inline function needs to be defined in every translation where it | > is used. So, I either move the affected functions to "static inline" | > or just make then non-inline (cases are in hashtable.c and toplev.c). | | Use of bare 'inline' is just plain wrong in our source code; this has | nothing to do with C++, no two C compilers implement bare 'inline' | alike. Well, the way I figureed it out was running the code source through a C++ compiler. I'm aware that inline is absent from C90 and that many of the current compilers that claim to implement C99 have their own opinions on the matter. However, what I was reporting is an *actual* experiment, no a thought. And it popped up only because I ran the source code through g++. Which, I think I should mention. | Patches to add 'static' to such functions (AND MAKING NO OTHER | CHANGES) are preapproved, post-slush. | | > Fifth, there is a slight difference between "const" in C and in C++. | > In C++, a const variable implicitly has an internal linkage; so a | > C++ compiler tends to optimize it out when its address is not taken | > (so no storage is wasted). This is an issue for the objects | > automatically generated by the gengtype support machinery. The are | > supposed to have external linkage, so we need to explicitly say | > "extern" in their definitions. | | Presumably such constants are declared in some header file, with | external linkage. It would be better to make that declaration visible | at the point of definition, rather than marking up the declarations with | 'extern'. I'm talking of the various gt_* objects created by the gengtype. Please, do have a look at the actual contents of the file and re-read what I wrote. | > Sixth, there is a real "mess" about name spaces. It is true that | > every C programmers knows the rule saying tags inhabit different name | > space than variable of functions. However, all the C coding standards | > I've read so far usually suggest | > | > typedef struct foo foo; | > | > but *not* | > | > typedef struct foo *foo; | > | > i.e. "bringing" the tag-name into normal name space to name the type | > structure or enumeration is OK, but not naming a different type! | | Ugh. Where do we do that? In our source code. :-) To name one that come to mind, alias.c:96:typedef struct alias_set_entry *alias_set_entry; I've also found that we have hash_table from libcpp as a typedef-name and hash_table as global (static variable) in cselib.c. | I will suggest, when you find these, that | you tack "_s" on the end of the tag-name; That is what I did in my local tree. But I believe we need to standardize on a coherent coding standards. Which is why I brought up the issue. | that doesn't conflict with | POSIX, and should require fewer changes elsewhere in the code. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:18 ` Gabriel Dos Reis @ 2005-05-24 6:43 ` Zack Weinberg 2005-05-24 7:04 ` Mark Mitchell 2005-05-24 7:38 ` Gabriel Dos Reis 0 siblings, 2 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-24 6:43 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin Gabriel Dos Reis <gdr@integrable-solutions.net> writes: [...] > The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC > and such. It is not anything you'll find in the code directly. So, > in fact we do not lose readability as you claim. To be honest, I think XNEW* are less readable than bare xmalloc, and I regret that I ever invented them. > The patches of aligning us to the common subsets of C90 and C++ is > following the consensus we developed as our coding standards. I don't see that there is any such consensus. I certainly consider coding to the intersection of C90 and C++ acceptable only as a stepping stone to coding in C++. If we aren't going to do that, and in short order, we have sacrificed the additional expressiveness of C-that-is-not-C++ for no gain. I was unclear in my previous message: it seems that you have found a number of things, by your experiment, that are not just code outside the intersection, but outright bugs. The bugs should of course be fixed. Things that I consider outright bugs include: functions being called with prototypes in scope that don't match their definitions; use of numeric constants in interfaces when enumeration constants are defined for those interfaces; 'typedef struct foo *foo'. Things I consider correct coding, but outside the intersection of C90 and C++, include: not casting the return value of allocator functions; not casting to void* when passing an arbitrary pointer to a function that takes a void* parameter; unrestricted use of C++ keywords; declaring structure fields with the same name as a structure tag in scope. > | I want to see more use of this idiom, not less; for > | example, 'enum machine_mode' ought to be a black box to almost the > | entire compiler. > > Me too, but the way to make it a black box is not to cast it so > unsigned int back forth willy nilly -- that does not make it a black > box, on the contrary. For example, we should be using EXPAND_NORMAL > instead of plain "0". > > | I'd be delighted to hear of a more C++-friendly way to > | code this. > > See above. This isn't an answer to the question I asked. I asked for a more C++ friendly way to code *black box* use of enums, where (in C) one is deliberately relying on the unchecked conversion to and from integral types. > I'm talking of the various gt_* objects created by the gengtype. > Please, do have a look at the actual contents of the file and > re-read what I wrote. I haven't time; please post a reduced example and explain why my suggestion won't work. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:43 ` Zack Weinberg @ 2005-05-24 7:04 ` Mark Mitchell 2005-05-24 8:00 ` Gabriel Dos Reis 2005-05-25 3:45 ` Kaveh R. Ghazi 2005-05-24 7:38 ` Gabriel Dos Reis 1 sibling, 2 replies; 97+ messages in thread From: Mark Mitchell @ 2005-05-24 7:04 UTC (permalink / raw) To: Zack Weinberg; +Cc: Gabriel Dos Reis, gcc, jason, dberlin Zack Weinberg wrote: > Gabriel Dos Reis <gdr@integrable-solutions.net> writes: > > [...] > >>The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC >>and such. It is not anything you'll find in the code directly. So, >>in fact we do not lose readability as you claim. > > > To be honest, I think XNEW* are less readable than bare xmalloc, and I > regret that I ever invented them. Too late. :-) We have adopted them, and people have started using them. Unlike you, I still think they're a good thing. More importantly, I think it would be a mistake to reopen this issue; I don't think the difference is terribly important, but not having the debate seems like a win. :-) > Things I consider correct coding, but outside the intersection of C90 > and C++, include: not casting the return value of allocator functions; See above. > not casting to void* when passing an arbitrary pointer to a function > that takes a void* parameter That's not necessary in C++ either; the C++ difference is that you must cast "void *" to "int *" to call a function accepting an "int *"; not the opposite. Maybe that's what you meant? > unrestricted use of C++ keywords; > > declaring structure fields with the same name as a structure tag in > scope. I don't think we should be reverting patches that fall afoul of these last two, even if they break Gaby's build-with-a-C++-compiler builds. But, I would tend to accept patches from Gaby to fix such problems. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:04 ` Mark Mitchell @ 2005-05-24 8:00 ` Gabriel Dos Reis 2005-05-25 3:45 ` Kaveh R. Ghazi 1 sibling, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 8:00 UTC (permalink / raw) To: Mark Mitchell; +Cc: Zack Weinberg, gcc, jason, dberlin Mark Mitchell <mark@codesourcery.com> writes: [...] | > unrestricted use of C++ keywords; | > | > declaring structure fields with the same name as a structure tag in | > scope. | | I don't think we should be reverting patches that fall afoul of these | last two, even if they break Gaby's build-with-a-C++-compiler | builds. But, I would tend to accept patches from Gaby to fix such | problems. I guess we had a preliminary discussion about this a while ago. I volunteered to maintain this compatibility issue. At a first stage, once the patches are in, I would like to adapt Geoff's regression scirpt to run the build with a C++ compiler. Next, I'm willing to follow-up with patches that implement warnings about C/C++ compatibility but that would be a much more extensive project, so I don't think it would be fair to require it for 4.1 or hold patches on that. They are improvements we can get by increments. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:04 ` Mark Mitchell 2005-05-24 8:00 ` Gabriel Dos Reis @ 2005-05-25 3:45 ` Kaveh R. Ghazi 2005-05-25 7:45 ` DJ Delorie 1 sibling, 1 reply; 97+ messages in thread From: Kaveh R. Ghazi @ 2005-05-25 3:45 UTC (permalink / raw) To: mark; +Cc: dberlin, gcc, gdr, jason, zack > > unrestricted use of C++ keywords; declaring structure fields with > > the same name as a structure tag in scope. > > I don't think we should be reverting patches that fall afoul of these > last two, even if they break Gaby's build-with-a-C++-compiler > builds. But, I would tend to accept patches from Gaby to fix such > problems. This reminds me of the last time we were coding to two C-family variants, named K&R vs ISO. I had improved -Wtraditional to the point where it caught most problems, and we had macros (PARAMS, etc) to cover most other cases. Now we have e.g. XNEW* and all we need is a new -W* flag to catch things like using C++ keywords and it should be fairly automatic to keep incompatibilities out of the sources. IMHO Gaby should volunteer to write the new -W flag, it'll be easier for him than fixing breakage after the fact. --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 3:45 ` Kaveh R. Ghazi @ 2005-05-25 7:45 ` DJ Delorie 2005-05-25 8:36 ` Gabriel Dos Reis 2005-05-25 13:38 ` Kaveh R. Ghazi 0 siblings, 2 replies; 97+ messages in thread From: DJ Delorie @ 2005-05-25 7:45 UTC (permalink / raw) To: ghazi; +Cc: gcc > Now we have e.g. XNEW* and all we need is a new -W* flag to catch > things like using C++ keywords and it should be fairly automatic to > keep incompatibilities out of the sources. Why not this? #ifndef __cplusplus #pragma GCC poison class template new . . . #endif ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 7:45 ` DJ Delorie @ 2005-05-25 8:36 ` Gabriel Dos Reis 2005-05-25 13:38 ` Kaveh R. Ghazi 1 sibling, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 8:36 UTC (permalink / raw) To: DJ Delorie; +Cc: ghazi, gcc DJ Delorie <dj@redhat.com> writes: | > Now we have e.g. XNEW* and all we need is a new -W* flag to catch | > things like using C++ keywords and it should be fairly automatic to | > keep incompatibilities out of the sources. | | Why not this? | | #ifndef __cplusplus | #pragma GCC poison class template new . . . | #endif I like it for GCC source code. It would be nice to have for libiberty.h when everything is converted :-) There was a suggestion from a different person that they might want to check similar things that for their projects, so there might be some usefulness to a -W switch... -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 7:45 ` DJ Delorie 2005-05-25 8:36 ` Gabriel Dos Reis @ 2005-05-25 13:38 ` Kaveh R. Ghazi 2005-05-26 13:40 ` Gabriel Dos Reis 1 sibling, 1 reply; 97+ messages in thread From: Kaveh R. Ghazi @ 2005-05-25 13:38 UTC (permalink / raw) To: dj; +Cc: gcc > > Now we have e.g. XNEW* and all we need is a new -W* flag to catch > > things like using C++ keywords and it should be fairly automatic to > > keep incompatibilities out of the sources. > > Why not this? > > #ifndef __cplusplus > #pragma GCC poison class template new . . . > #endif That's limited. A new -W flag could catch not only this, but also other problems like naked void* -> FOO* conversions. E.g. IIRC, the -Wtraditional flag eventually caught over a dozen different problems. Over time this new warning flag for c/c++ intersection could be similarly refined. --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 13:38 ` Kaveh R. Ghazi @ 2005-05-26 13:40 ` Gabriel Dos Reis 0 siblings, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-26 13:40 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: dj, gcc "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes: | > > Now we have e.g. XNEW* and all we need is a new -W* flag to catch | > > things like using C++ keywords and it should be fairly automatic to | > > keep incompatibilities out of the sources. | > | > Why not this? | > | > #ifndef __cplusplus | > #pragma GCC poison class template new . . . | > #endif | | That's limited. A new -W flag could catch not only this, but also | other problems like naked void* -> FOO* conversions. E.g. IIRC, the | -Wtraditional flag eventually caught over a dozen different problems. | Over time this new warning flag for c/c++ intersection could be | similarly refined. This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759 -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:43 ` Zack Weinberg 2005-05-24 7:04 ` Mark Mitchell @ 2005-05-24 7:38 ` Gabriel Dos Reis 2005-05-24 8:32 ` Zack Weinberg 2005-05-24 17:17 ` Paul Koning 1 sibling, 2 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 7:38 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc, jason, mark, dberlin Zack Weinberg <zack@codesourcery.com> writes: | Gabriel Dos Reis <gdr@integrable-solutions.net> writes: | | [...] | > The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC | > and such. It is not anything you'll find in the code directly. So, | > in fact we do not lose readability as you claim. | | To be honest, I think XNEW* are less readable than bare xmalloc, and I | regret that I ever invented them. Then, we would have just agree to disagree. At least, with the explicit call to malloc + explicit specification of sizeof, I've found a number of wrong codes -- while replacing the existing xmalloc/xcallo with XNEWVEC and friends (see previous patches and messages) in libiberty, not counting the happy confusion about xcalloc() in the current GCC codes. Those are bugs we do not have with the XNEWVEC and friends. Not only, we do get readable code, we also get right codes. | > The patches of aligning us to the common subsets of C90 and C++ is | > following the consensus we developed as our coding standards. | | I don't see that there is any such consensus. I certainly consider http://www.gnu.org/software/gcc/codingconventions.html Avoid the use of identifiers or idioms that would prevent code compiling with a C++ compiler. Identifiers such as new or class, that are reserved words in C++, should not be used as variables or field names. Explicit casts should be used to convert between void* and other pointer types. Previous discussions reached this: http://gcc.gnu.org/ml/gcc/2004-07/msg00601.html | coding to the intersection of C90 and C++ acceptable only as a | stepping stone to coding in C++. If converting GCC to C++ is your ultimate goal, then I don't think you should block these patches. They do not introduce C++, but also they do provide a path to local experiments before we ever have any huge fight about that. I do not think converting GCC to C++ is on the table or will happen any time soon -- see previous long discussions. However, I do not believe it would help the GCC project to block any patch that bring us in alignment to our own committment. We can have our cake and it. I.e. we can have the source code in a form compilable with a C++ compiler and test conjectures/experiments. | If we aren't going to do that, and | in short order, we have sacrificed the additional expressiveness of | C-that-is-not-C++ for no gain. I don't think so. These patches make it possible to compile the source code with a C++ compiler. We gain better checking by doing that. In particular, it makes it possible for people to test any conjecture about the benefits of moving to C++, without actually requiring it at the moment. Those benefits largely offset the inconvenient of using XNEWVEC (with all its benefits). I was able to find those problems because I could get the source code through a C++ compiler. Making that possible to everyone, including those who do no like to use C++ in GCC is a win for everybody. | I was unclear in my previous message: it seems that you have found a | number of things, by your experiment, that are not just code outside | the intersection, but outright bugs. Exactly. I was able to find those because I spent the time to convert the souorce to be compilable to C++. I do not believe it makes to require everybody to wste such time locally, whereas it could be done one for all. | The bugs should of course be | fixed. Things that I consider outright bugs include: functions being | called with prototypes in scope that don't match their definitions; | use of numeric constants in interfaces when enumeration constants are | defined for those interfaces; 'typedef struct foo *foo'. | | Things I consider correct coding, but outside the intersection of C90 | and C++, include: not casting the return value of allocator functions; | not casting to void* when passing an arbitrary pointer to a function | that takes a void* parameter; unrestricted use of C++ keywords; | declaring structure fields with the same name as a structure tag in | scope. These do not being us any benefits as far as checking is concerned. The point of being able to do so and therefore prevent ourselves from having freely avaliable tools to catch errors completely escape my understanding. | > | I want to see more use of this idiom, not less; for | > | example, 'enum machine_mode' ought to be a black box to almost the | > | entire compiler. | > | > Me too, but the way to make it a black box is not to cast it so | > unsigned int back forth willy nilly -- that does not make it a black | > box, on the contrary. For example, we should be using EXPAND_NORMAL | > instead of plain "0". | > | > | I'd be delighted to hear of a more C++-friendly way to | > | code this. | > | > See above. | | This isn't an answer to the question I asked. I asked for a more C++ | friendly way to code *black box* use of enums, where (in C) one is | deliberately relying on the unchecked conversion to and from integral | types. The point was that an enum by itself is a black box. There is no foward declaration of enums. There is no need here for an abstraction for an abstraction. The named constants stand by themselves are abstraction layer over the values they represent. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:38 ` Gabriel Dos Reis @ 2005-05-24 8:32 ` Zack Weinberg 2005-05-24 13:18 ` Gabriel Dos Reis 2005-05-27 1:20 ` Marcin Dalecki 2005-05-24 17:17 ` Paul Koning 1 sibling, 2 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-24 8:32 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin Gabriel Dos Reis <gdr@integrable-solutions.net> writes: [dropping most of the message - if I haven't responded, assume I don't agree but I also don't care enough to continue the argument. Also, rearranging paragraphs a bit so as not to have to repeat myself] > with the explicit call to malloc + explicit specification of sizeof, > I've found a number of wrong codes -- while replacing the existing > xmalloc/xcallo with XNEWVEC and friends (see previous patches and > messages) in libiberty, not counting the happy confusion about > xcalloc() in the current GCC codes. Those are bugs we do not have > with the XNEWVEC and friends. Not only, we do get readable code, we > also get right codes. ... > I don't think so. These patches make it possible to compile the > source code with a C++ compiler. We gain better checking by doing > that. Have you found any places where the bugs you found could have resulted in user-visible incorrect behavior (of any kind)? If you have, I will drop all of my objections. > If converting GCC to C++ is your ultimate goal, then I don't think > you should block these patches. They do not introduce C++, but also > they do provide a path to local experiments before we ever have any > huge fight about that. To be clear, my ultimate goal is neither to introduce C++ nor to block it. My goal is to make sure that *if* a transition to C++ happens, it happens with great care and attention to detail. Part of this is not doing anything that makes it seem easier to convert to C++ than it actually is. See my earlier response to Mark. Now, if there's a benefit to your patches other than making that hypothetical transition easier - like finding actual user-visible bugs - then I don't have a problem with them. > | This isn't an answer to the question I asked. I asked for a more C++ > | friendly way to code *black box* use of enums, where (in C) one is > | deliberately relying on the unchecked conversion to and from integral > | types. > > The point was that an enum by itself is a black box. There is no > foward declaration of enums. There is no need here for an abstraction > for an abstraction. So you don't see any value whatsoever to having (for instance) the individual constants of 'enum machine_mode' be inaccessible in most of GCC? 'cos I sure do. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 8:32 ` Zack Weinberg @ 2005-05-24 13:18 ` Gabriel Dos Reis 2005-05-24 23:45 ` Zack Weinberg 2005-05-27 1:20 ` Marcin Dalecki 1 sibling, 1 reply; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 13:18 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc, jason, mark, dberlin Zack Weinberg <zack@codesourcery.com> writes: | Gabriel Dos Reis <gdr@integrable-solutions.net> writes: | | [dropping most of the message - if I haven't responded, assume I don't | agree but I also don't care enough to continue the argument. Also, | rearranging paragraphs a bit so as not to have to repeat myself] | | > with the explicit call to malloc + explicit specification of sizeof, | > I've found a number of wrong codes -- while replacing the existing | > xmalloc/xcallo with XNEWVEC and friends (see previous patches and | > messages) in libiberty, not counting the happy confusion about | > xcalloc() in the current GCC codes. Those are bugs we do not have | > with the XNEWVEC and friends. Not only, we do get readable code, we | > also get right codes. | ... | > I don't think so. These patches make it possible to compile the | > source code with a C++ compiler. We gain better checking by doing | > that. | | Have you found any places where the bugs you found could have resulted | in user-visible incorrect behavior (of any kind)? As I said, I ran a preliminary experiment to estimate how difficult the task would be to have the existing source respect our own coding conventions: http://www.gnu.org/software/gcc/codingconventions.html Avoid the use of identifiers or idioms that would prevent code compiling with a C++ compiler. Identifiers such as new or class, that are reserved words in C++, should not be used as variables or field names. Explicit casts should be used to convert between void* and other pointer types. The mere fact of doing that and catch the errors I mentioned earlier, was quite positive. Of course, I do not doubt that we would find more bugs (and if we do not find any, then we do get another level of confidence in the code), but this is something that happens quicker and go through extensive coverage when it is possible for more people to do. I do believe that the fact that the compiler is relying on a second inexisting argument to do name lookup is a user visible bug (not mentioning stack corruption), but we do get better and existing checking by making the change avaialble to a wider number of people. The benefits are not just the immediate bugs I find. | If you have, I will drop all of my objections. | | > If converting GCC to C++ is your ultimate goal, then I don't think | > you should block these patches. They do not introduce C++, but also | > they do provide a path to local experiments before we ever have any | > huge fight about that. | | To be clear, my ultimate goal is neither to introduce C++ nor to block | it. My goal is to make sure that *if* a transition to C++ happens, it | happens with great care and attention to detail. Part of this is not | doing anything that makes it seem easier to convert to C++ than it | actually is. See my earlier response to Mark. I understand that, but none of the patches is in line of unthinking, that makes any hypothetical move to C++ (nor non-move move-to) difficult. (1) if we move to C++, we have to avoid the keywords (which are already prohibited by our current coding conventions) (2) if we move to C++, we have to avoid the implicit convertion void* -> T* (which is already prohibited by our coding conventions) (3) if we don't move to C++, we still follow our coding conventions. (4) if we don't move to C++, we still can use additional testing provided by a C++ compiler. | > | This isn't an answer to the question I asked. I asked for a more C++ | > | friendly way to code *black box* use of enums, where (in C) one is | > | deliberately relying on the unchecked conversion to and from integral | > | types. | > | > The point was that an enum by itself is a black box. There is no | > foward declaration of enums. There is no need here for an abstraction | > for an abstraction. | | So you don't see any value whatsoever to having (for instance) the | individual constants of 'enum machine_mode' be inaccessible in most of | GCC? 'cos I sure do. What I'm saying is that when you have a name like EXPAND_NORMAL, you do not need to know the value it represents. Just that it names a constant. If you want to introduce a new name for that name, people would still have to use that name, therefore the question is exactly what do you gain in this specific case by introducing a second name (which does not hide more than the first name) over the existing practice where people use numerical values, that you do not gai by introducing just a single layer (enumeration)? -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 13:18 ` Gabriel Dos Reis @ 2005-05-24 23:45 ` Zack Weinberg 2005-05-25 0:29 ` Gabriel Dos Reis 0 siblings, 1 reply; 97+ messages in thread From: Zack Weinberg @ 2005-05-24 23:45 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote: > | So you don't see any value whatsoever to having (for instance) the > | individual constants of 'enum machine_mode' be inaccessible in most of > | GCC? 'cos I sure do. > > What I'm saying is that when you have a name like EXPAND_NORMAL, you > do not need to know the value it represents. Just that it names a > constant. We appear to be still talking about two different cases. I am talking about the case where, in C++, you might declare something like class machine_mode { enum { VOIDmode, SImode, // ... } value; // accessors, whatever ... }; and then pass around 'machine_mode' objects. Does this help? zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 23:45 ` Zack Weinberg @ 2005-05-25 0:29 ` Gabriel Dos Reis 2005-05-25 0:37 ` Zack Weinberg 0 siblings, 1 reply; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 0:29 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc, jason, mark, dberlin Zack Weinberg <zack@codesourcery.com> writes: | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote: | > | So you don't see any value whatsoever to having (for instance) the | > | individual constants of 'enum machine_mode' be inaccessible in most of | > | GCC? 'cos I sure do. | > | > What I'm saying is that when you have a name like EXPAND_NORMAL, you | > do not need to know the value it represents. Just that it names a | > constant. | | We appear to be still talking about two different cases. I am talking | about the case where, in C++, you might declare something like | | class machine_mode | { | enum { | VOIDmode, SImode, // ... | } value; | | // accessors, whatever ... | }; | | and then pass around 'machine_mode' objects. Does this help? Nothing in what I said or is proposing prevents that scenario, if you decided to go there (despite pessimizations on x86 targets). To pass machine_mode around, you need it to be declared. That same condition holds it it were an enum. Currently, what you want to do is not directly possible, because functions are using numeric values directly, therefore breaking the abstraction barrier. What I'm proposing is to use the *names* (instead of the values). If and when you convert machine_mode to a class, then you still need a way to refer to those values, and the named constants could be silently changed to const class machine_mode objects, that won't change anything to the rest of the code. That is a value of named constant abstraction I was talking about. You get the abstraction for free, with the changes I'm proposing. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:29 ` Gabriel Dos Reis @ 2005-05-25 0:37 ` Zack Weinberg 2005-05-25 0:52 ` DJ Delorie 2005-05-25 1:12 ` Gabriel Dos Reis 0 siblings, 2 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-25 0:37 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote: > Zack Weinberg <zack@codesourcery.com> writes: > > | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote: > | > | So you don't see any value whatsoever to having (for instance) the > | > | individual constants of 'enum machine_mode' be inaccessible in most of > | > | GCC? 'cos I sure do. > | > > | > What I'm saying is that when you have a name like EXPAND_NORMAL, you > | > do not need to know the value it represents. Just that it names a > | > constant. > | > | We appear to be still talking about two different cases. I am talking > | about the case where, in C++, you might declare something like > | > | class machine_mode > | { > | enum { > | VOIDmode, SImode, // ... > | } value; > | > | // accessors, whatever ... > | }; > | > | and then pass around 'machine_mode' objects. Does this help? > > Nothing in what I said or is proposing prevents that scenario, if you > decided to go there (despite pessimizations on x86 targets). This is still not an answer to the question I originally asked - do you see any way IN C to write code which has the relevant property of the class above (that is, that the FOOmode constants are not accessible except to authorized code) and which does not rely on free conversion between enumeration constants and integral types? zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:37 ` Zack Weinberg @ 2005-05-25 0:52 ` DJ Delorie 2005-05-25 0:55 ` Zack Weinberg 2005-05-25 1:12 ` Gabriel Dos Reis 1 sibling, 1 reply; 97+ messages in thread From: DJ Delorie @ 2005-05-25 0:52 UTC (permalink / raw) To: zack; +Cc: gcc > This is still not an answer to the question I originally asked - do you > see any way IN C to write code which has the relevant property of the > class above (that is, that the FOOmode constants are not accessible > except to authorized code) and which does not rely on free conversion > between enumeration constants and integral types? enum { TVQ_BAR_GRILL = (DATESTAMP % 10), TVQ_NEXT2, TVQ_NEXT3, TVQ_NEXT4 } TheValQuux; It's evil, but it will keep programmers from hard-coding integer constants anywhere. The "constants" will need to be different every day. "Authorized code" can always offset by (DATESTAMP%10) if the intrinsic values of the enums are important to it. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:52 ` DJ Delorie @ 2005-05-25 0:55 ` Zack Weinberg 2005-05-25 1:02 ` Ian Lance Taylor ` (2 more replies) 0 siblings, 3 replies; 97+ messages in thread From: Zack Weinberg @ 2005-05-25 0:55 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc On Tue, 2005-05-24 at 20:27 -0400, DJ Delorie wrote: > > This is still not an answer to the question I originally asked - do you > > see any way IN C to write code which has the relevant property of the > > class above (that is, that the FOOmode constants are not accessible > > except to authorized code) and which does not rely on free conversion > > between enumeration constants and integral types? > > enum { > TVQ_BAR_GRILL = (DATESTAMP % 10), > TVQ_NEXT2, > TVQ_NEXT3, > TVQ_NEXT4 > } TheValQuux; > > It's evil, but it will keep programmers from hard-coding integer > constants anywhere. The "constants" will need to be different every > day. This doesn't do what I want at all. The goal is to make the *symbolic enumeration constants* inaccessible to most code. Think about how machine_mode values are used. Almost the entire compiler is supposed to treat them as opaque things. You get them from e.g. int_mode_for_size; you may iterate over a class with GET_MODE_WIDER_MODE; you stash them in RTL and you pass them to predicates. Appearances of "SImode" in the machine-independent compiler are usually bugs. This is a major contributing factor to the brokenness of ports that don't set BITS_PER_UNIT==8. The goal is to make "SImode" and its friends inaccessible in the machine-independent compiler, so that that category of bugs cannot arise. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:55 ` Zack Weinberg @ 2005-05-25 1:02 ` Ian Lance Taylor 2005-05-25 1:36 ` DJ Delorie 2005-05-25 1:47 ` Gabriel Dos Reis 2 siblings, 0 replies; 97+ messages in thread From: Ian Lance Taylor @ 2005-05-25 1:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: DJ Delorie, gcc Zack Weinberg <zack@codesourcery.com> writes: > Think about how machine_mode values are used. Almost the entire > compiler is supposed to treat them as opaque things. You get them from > e.g. int_mode_for_size; you may iterate over a class with > GET_MODE_WIDER_MODE; you stash them in RTL and you pass them to > predicates. Appearances of "SImode" in the machine-independent compiler > are usually bugs. This is a major contributing factor to the brokenness > of ports that don't set BITS_PER_UNIT==8. Well, do you want a nice clean solution, like using a C++ class, or do you want a hideous hacked up solution that works for C? mv machmode.h real-machmode.h cat <<EOF machmode.h #include "real-machmode.h" #define SImode diediedie #define HImode diediedie ... EOF find config -name '*.[ch]' -print | while read f; do sed -e 's/"machmode.h"/"real-machmode.h"/' < $f > $f.new mv $f.new $f done Ian ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:55 ` Zack Weinberg 2005-05-25 1:02 ` Ian Lance Taylor @ 2005-05-25 1:36 ` DJ Delorie 2005-05-25 1:40 ` Zack Weinberg 2005-05-25 1:50 ` Gabriel Dos Reis 2005-05-25 1:47 ` Gabriel Dos Reis 2 siblings, 2 replies; 97+ messages in thread From: DJ Delorie @ 2005-05-25 1:36 UTC (permalink / raw) To: zack; +Cc: gcc > This doesn't do what I want at all. The goal is to make the *symbolic > enumeration constants* inaccessible to most code. Oh. enum { THE_VAL_QUUX_ENUMS } TheValQuux; If not defined, you get one enum, THE_VAL_QUUX_ENUMS. The "authority" can define it to a list of enums, so it gets expanded. Now, if we can figure out a solution to the "enums are the smallest integral type they fit in" problem, we'd be all set. This might work with a suitable terminator on the real list: enum { THE_VAL_QUUX_ENUMS = 32767; } TheValQuux; The private header would have something like: #define THE_VAL_QUUX_ENUMS \ TVQ_FOO1, \ TVQ_FOO2, \ TVQ_FOO3, \ TVQ_NUM_ENTRIES, \ TVQ_INT_MAX If it's OK to have the enums in a header, provided you can't *use* them... enum { #ifdef TVQ_AUTHORITATIVE_ENUMS TVQ_FOO1, TVQ_FOO2, TVQ_FOO3, TVQ_NUM_ENTRIES, #endif TVQ_INT_SIZER = 32767; } TheValQuux; This won't stop a suitably enthusiastic programmer from getting to them anyway, but that's always the case. Or... #ifndef TVG_ENUM #define TVG_ENUM(X) DONT_USE_ME_TVG_##x #endif enum { TVG_ENUM(FOO1), TVG_ENUM(FOO2), TVG_ENUM(FOO3), } TheValQuux; With the "authority" suitably defining TVG_ENUM. Of course, these are all just hacks to hide the enumerations. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 1:36 ` DJ Delorie @ 2005-05-25 1:40 ` Zack Weinberg 2005-05-25 2:24 ` Gabriel Dos Reis 2005-05-25 1:50 ` Gabriel Dos Reis 1 sibling, 1 reply; 97+ messages in thread From: Zack Weinberg @ 2005-05-25 1:40 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc On Tue, 2005-05-24 at 20:54 -0400, DJ Delorie wrote: > > This doesn't do what I want at all. The goal is to make the *symbolic > > enumeration constants* inaccessible to most code. > ... > If it's OK to have the enums in a header, provided you can't *use* them... > > enum { > #ifdef TVQ_AUTHORITATIVE_ENUMS > TVQ_FOO1, > TVQ_FOO2, > TVQ_FOO3, > TVQ_NUM_ENTRIES, > #endif > TVQ_INT_SIZER = 32767; > } TheValQuux; > > This won't stop a suitably enthusiastic programmer from getting to > them anyway, but that's always the case. Ooh, I like this one for enum machine_mode. The relevant header (machmode.def) is already machine-generated, so it would be a fairly small change. And doesn't in any way interfere with Gabriel's cleanups to use the enumeration type instead of 'int', which is good. Be a hell of a lot of breakage to sort through, though. Unless we've got a volunteer with a whole lot of time, I don't think this is happening for 4.1. Oh well. zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 1:40 ` Zack Weinberg @ 2005-05-25 2:24 ` Gabriel Dos Reis 0 siblings, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 2:24 UTC (permalink / raw) To: Zack Weinberg; +Cc: DJ Delorie, gcc Zack Weinberg <zack@codesourcery.com> writes: | On Tue, 2005-05-24 at 20:54 -0400, DJ Delorie wrote: | > > This doesn't do what I want at all. The goal is to make the *symbolic | > > enumeration constants* inaccessible to most code. | > | ... | > If it's OK to have the enums in a header, provided you can't *use* them... | > | > enum { | > #ifdef TVQ_AUTHORITATIVE_ENUMS | > TVQ_FOO1, | > TVQ_FOO2, | > TVQ_FOO3, | > TVQ_NUM_ENTRIES, | > #endif | > TVQ_INT_SIZER = 32767; | > } TheValQuux; | > | > This won't stop a suitably enthusiastic programmer from getting to | > them anyway, but that's always the case. | | Ooh, I like this one for enum machine_mode. The relevant header | (machmode.def) is already machine-generated, so it would be a fairly | small change. And doesn't in any way interfere with Gabriel's cleanups | to use the enumeration type instead of 'int', which is good. I want to say a public thank to DJ and Mark for building the bridge between Zack and me. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 1:36 ` DJ Delorie 2005-05-25 1:40 ` Zack Weinberg @ 2005-05-25 1:50 ` Gabriel Dos Reis 2005-05-25 2:20 ` DJ Delorie 1 sibling, 1 reply; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 1:50 UTC (permalink / raw) To: DJ Delorie; +Cc: zack, gcc DJ Delorie <dj@redhat.com> writes: [...] | If it's OK to have the enums in a header, provided you can't *use* them... | | enum { | #ifdef TVQ_AUTHORITATIVE_ENUMS | TVQ_FOO1, | TVQ_FOO2, | TVQ_FOO3, | TVQ_NUM_ENTRIES, | #endif | TVQ_INT_SIZER = 32767; | } TheValQuux; | | This won't stop a suitably enthusiastic programmer from getting to | them anyway, but that's always the case. Furthermore, that does not stop an enthusiastic programmer from feeding the interface functions with the wrong values if he is supposed to convert between integers and enums. That is a far more important problem that trying to prevent using the names. If you provide the names, then you have control over what they mean and there is no incitation to cast things, therefore there is more chance to get things right and less chance to get the horrible bugs one would like to prevent by making the names inaccessible. The names are not the problem. | Or... | | #ifndef TVG_ENUM | #define TVG_ENUM(X) DONT_USE_ME_TVG_##x | #endif | enum { | TVG_ENUM(FOO1), | TVG_ENUM(FOO2), | TVG_ENUM(FOO3), | } TheValQuux; | | With the "authority" suitably defining TVG_ENUM. | | Of course, these are all just hacks to hide the enumerations. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 1:50 ` Gabriel Dos Reis @ 2005-05-25 2:20 ` DJ Delorie 0 siblings, 0 replies; 97+ messages in thread From: DJ Delorie @ 2005-05-25 2:20 UTC (permalink / raw) To: gdr; +Cc: zack, gcc > Furthermore, that does not stop an enthusiastic programmer from > feeding the interface functions with the wrong values If you seed the first enum from DATESTAMP, and properly range check, you can find these cases pretty quickly and abort. TVQ_SEED = (DATESTAMP%10) * 1000, TVQ_FOO1, ... > if he is supposed to convert between integers and enums. I can't imagine any situation where the programmer is *supposed* to feed integers where enums are expected, in the cases where we're trying to hide the names (like machine_mode). I think the problem you're trying to solve is enumerations that, for example, define an ABI to hardware or something, where they *must* have specific values. Still, you can use the DATESTAMP trick, and offset it in the authoritative functions to get the needed integer values. enum { TVQ_SEED = (DATESTAMP%10) * 1000, TVQ_NOP, TVQ_READ, TVQ_WRITE } tvq_dma_command; int tvq_dma (tvq_dma_command cmd) { *port = (int)cmd - ((int)TVQ_SEED+1); } If you really must stop people from using integers found in ABI manuals, list the enums in reverse order. You can still use math to find the right integers, but you can't use TVQ_NOP+2 to mean "the chip expects a 2". Worse, use a random order and a private lookup table ;-) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:55 ` Zack Weinberg 2005-05-25 1:02 ` Ian Lance Taylor 2005-05-25 1:36 ` DJ Delorie @ 2005-05-25 1:47 ` Gabriel Dos Reis 2005-05-25 2:08 ` DJ Delorie 2 siblings, 1 reply; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 1:47 UTC (permalink / raw) To: Zack Weinberg; +Cc: DJ Delorie, gcc Zack Weinberg <zack@codesourcery.com> writes: | On Tue, 2005-05-24 at 20:27 -0400, DJ Delorie wrote: | > > This is still not an answer to the question I originally asked - do you | > > see any way IN C to write code which has the relevant property of the | > > class above (that is, that the FOOmode constants are not accessible | > > except to authorized code) and which does not rely on free conversion | > > between enumeration constants and integral types? | > | > enum { | > TVQ_BAR_GRILL = (DATESTAMP % 10), | > TVQ_NEXT2, | > TVQ_NEXT3, | > TVQ_NEXT4 | > } TheValQuux; | > | > It's evil, but it will keep programmers from hard-coding integer | > constants anywhere. The "constants" will need to be different every | > day. | | This doesn't do what I want at all. The goal is to make the *symbolic | enumeration constants* inaccessible to most code. But, you wrong in that goal. The goal should not be to prevent access to the names, but to prevent access to the values behind the names. You are looking at the wrong thing. | Think about how machine_mode values are used. ^^^^^^ That is the key. *Values*. You want to make sure the invariants for the values are kept consistent. Not, that the names that designate the values are inaccessible. | Almost the entire | compiler is supposed to treat them as opaque things. Yes, and the names do provide that abstraction layer. Furthermore, if you remove the current type mocking unsigned int <-> int <-> enums, you do make a step further toward making sure that people treats the machine_mode values as opaque. | You get them from | e.g. int_mode_for_size; you may iterate over a class with | GET_MODE_WIDER_MODE; you stash them in RTL and you pass them to | predicates. Appearances of "SImode" in the machine-independent compiler | are usually bugs. That is wrong. If you remove the names and provide interface where people use integers and type casts, you promote more opportunities for bugs. That is not what you want. You want something different. You want better control. The need for iterating over the modes is real. So what you do is provide an interface for that. In the earlier message, I even said I used macros NEXT(), PREV(). | This is a major contributing factor to the brokenness | of ports that don't set BITS_PER_UNIT==8. | | The goal is to make "SImode" and its friends inaccessible in the No, the goal is to make the *values* inaccessible, not the names. | machine-independent compiler, so that that category of bugs cannot | arise. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 1:47 ` Gabriel Dos Reis @ 2005-05-25 2:08 ` DJ Delorie 2005-05-25 2:36 ` Gabriel Dos Reis 0 siblings, 1 reply; 97+ messages in thread From: DJ Delorie @ 2005-05-25 2:08 UTC (permalink / raw) To: gdr; +Cc: zack, gcc > No, the goal is to make the *values* inaccessible, not the names. No, *I* want gcc to stop doing *&$@ like this: stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx); It should use GET_MODE(stack_parm) in case the target has multiple pointer sizes. And YES I have a port with multiple pointer sizes, and YES the customer wanted both sizes supported in a single compilation unit and NO I couldn't get gcc to do it, because Pmode was hardcoded in a LOT of inappropriate places. Oh, and sometimes gcc randomly uses pointer_mode instead of Pmode. I haven't a clue why there's a difference, or how badly gcc would break if pointer_mode and Pmode were different. Ok, I lied, I *do* know how badly it breaks if they differ; I did try that at one point. Here's another [quickly found, possibly inappropriate] one: void initialize_sizetypes (bool signed_p) { tree t = make_node (INTEGER_TYPE); TYPE_MODE (t) = SImode; size_t is 16 bits on that platform, but SImode is 32 bits. Is hard-coding SImode the right thing to do? ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 2:08 ` DJ Delorie @ 2005-05-25 2:36 ` Gabriel Dos Reis 2005-05-25 3:34 ` DJ Delorie 0 siblings, 1 reply; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 2:36 UTC (permalink / raw) To: DJ Delorie; +Cc: zack, gcc DJ Delorie <dj@redhat.com> writes: | > No, the goal is to make the *values* inaccessible, not the names. | | No, *I* want gcc to stop doing *&$@ like this: | | stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx); | | It should use GET_MODE(stack_parm) in case the target has multiple | pointer sizes. Ah, that I have no problem with and I completelty agree with. The cases I've found in my conversion was when codes use plain "0" instead of VOIDmode or whatever machine_mode is appropriate. That use of plain 0 breaks compilation with a C++ compiler. Now, once we have the appropriate XXXmode in place, they would be easier to grep for :-) Thanks, -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 2:36 ` Gabriel Dos Reis @ 2005-05-25 3:34 ` DJ Delorie 2005-05-25 5:01 ` Gabriel Dos Reis 0 siblings, 1 reply; 97+ messages in thread From: DJ Delorie @ 2005-05-25 3:34 UTC (permalink / raw) To: gdr; +Cc: gcc > The cases I've found in my conversion was when codes use plain > "0" instead of VOIDmode or whatever machine_mode is appropriate. > That use of plain 0 breaks compilation with a C++ compiler. If the #include isn't portable enough, just hard code a 42. We'd need suitable changes for insn-modes.c et al (null mode_names should stop some of them!), but this was just to give you the idea ;-) Index: genmodes.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/genmodes.c,v retrieving revision 1.15 diff -p -U3 -r1.15 genmodes.c --- genmodes.c 15 Oct 2004 14:47:07 -0000 1.15 +++ genmodes.c 25 May 2005 02:02:14 -0000 @@ -24,6 +24,10 @@ Software Foundation, 59 Temple Place - S #include "errors.h" #include "hashtab.h" +static int some_random_number = +#include "DATESTAMP" +; + /* enum mode_class is normally defined by machmode.h but we can't include that header here. */ #include "mode-classes.def" @@ -780,6 +784,8 @@ emit_insn_modes_h (void) \n\ enum machine_mode\n{"); + printf(" MIN_MACHINE_MODE = %d,\n", some_random_number % 10 + 5); + for (c = 0; c < MAX_MODE_CLASS; c++) for (m = modes[c]; m; m = m->next) { ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 3:34 ` DJ Delorie @ 2005-05-25 5:01 ` Gabriel Dos Reis 0 siblings, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 5:01 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc DJ Delorie <dj@redhat.com> writes: | > The cases I've found in my conversion was when codes use plain | > "0" instead of VOIDmode or whatever machine_mode is appropriate. | > That use of plain 0 breaks compilation with a C++ compiler. | | If the #include isn't portable enough, just hard code a 42. We'd need | suitable changes for insn-modes.c et al (null mode_names should stop | some of them!), but this was just to give you the idea ;-) I'll get back to that later, when I'm done with the syntactical part :-) -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 0:37 ` Zack Weinberg 2005-05-25 0:52 ` DJ Delorie @ 2005-05-25 1:12 ` Gabriel Dos Reis 2005-05-25 1:47 ` DJ Delorie 1 sibling, 1 reply; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 1:12 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc, jason, mark, dberlin Zack Weinberg <zack@codesourcery.com> writes: | On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote: | > Zack Weinberg <zack@codesourcery.com> writes: | > | > | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote: | > | > | So you don't see any value whatsoever to having (for instance) the | > | > | individual constants of 'enum machine_mode' be inaccessible in most of | > | > | GCC? 'cos I sure do. | > | > | > | > What I'm saying is that when you have a name like EXPAND_NORMAL, you | > | > do not need to know the value it represents. Just that it names a | > | > constant. | > | | > | We appear to be still talking about two different cases. I am talking | > | about the case where, in C++, you might declare something like | > | | > | class machine_mode | > | { | > | enum { | > | VOIDmode, SImode, // ... | > | } value; | > | | > | // accessors, whatever ... | > | }; | > | | > | and then pass around 'machine_mode' objects. Does this help? | > | > Nothing in what I said or is proposing prevents that scenario, if you | > decided to go there (despite pessimizations on x86 targets). | | This is still not an answer to the question I originally asked - do you Oh this is getting silly, as I suggested the answer at the beginning and repeated it over and over. | see any way IN C to write code which has the relevant property of the | class above (that is, that the FOOmode constants are not accessible | except to authorized code) and which does not rely on free conversion | between enumeration constants and integral types? Yes. (1) Use the names. What you want to prevent is the direct fidling with the bits, not the name. Names are the messengers, not the message. Don't shoot them. So, no mocking around with type conversion unsigned int <-> enums. When and if you move to class, codes using FOOmode will still work correctly. (2) When and if you switch to this: class machine_mode { enum value_t { VOIDmode, SImode, // ... } value; // accessors, whatever ... }; You replace the global named constants with named constant objects extern const machine_mode FOOmode; This will not conflict with the other (enumeration values) FOOmode in machine_mode, because a class in C++ (unlike C) defines a scope, therefore shields them from the outside. And people using FOOmode won't see any difference (except those breaking the abstraction barrier, but then you catch them). Furthermore, because you have access checking (brought to you for free) you do catch anyone who try to mock directly with the values. So, using the named constants do make it easy for you if you move to C++. And if you decide not to go to C++, you still get better code. -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 1:12 ` Gabriel Dos Reis @ 2005-05-25 1:47 ` DJ Delorie 2005-05-25 3:20 ` Gabriel Dos Reis 0 siblings, 1 reply; 97+ messages in thread From: DJ Delorie @ 2005-05-25 1:47 UTC (permalink / raw) To: gdr; +Cc: gcc > (2) When and if you switch to this: > > class machine_mode > { > enum value_t { > VOIDmode, SImode, // ... > } value; > > // accessors, whatever ... > }; I think what Mark wants is to migrate to this: class machine_mode_desc { unsigned char bits; unsigned char is_signed:1; unsigned char partial_bits; unsigned char vector_width; char *name; // accessors, whatever }; class machine_mode { machine_mode_desc *mode_data; // various constructors } And the target can do this in tm.c: class machine_mode SImode ("SI", 32); class machine_mode V4QImode ("V4QI", 8, 0, 8, 4); Then, the MI parts can obtain a mode with certain characteristics, enumerate available modes, and get info about a given mode, but don't have a compile-time identifier for a "well-known named" mode. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-25 1:47 ` DJ Delorie @ 2005-05-25 3:20 ` Gabriel Dos Reis 0 siblings, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-25 3:20 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc DJ Delorie <dj@redhat.com> writes: | > (2) When and if you switch to this: | > | > class machine_mode | > { | > enum value_t { | > VOIDmode, SImode, // ... | > } value; | > | > // accessors, whatever ... | > }; | | I think what Mark wants is to migrate to this: | | class machine_mode_desc | { | unsigned char bits; | unsigned char is_signed:1; | unsigned char partial_bits; | unsigned char vector_width; | char *name; | // accessors, whatever | }; | class machine_mode | { | machine_mode_desc *mode_data; | // various constructors | } | | And the target can do this in tm.c: | | class machine_mode SImode ("SI", 32); | class machine_mode V4QImode ("V4QI", 8, 0, 8, 4); | | Then, the MI parts can obtain a mode with certain characteristics, | enumerate available modes, and get info about a given mode, but don't | have a compile-time identifier for a "well-known named" mode. I like it. However, that is orthogonal to changing the plain numeric value "0" to the named constant with current machinery, don't you believe? -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 8:32 ` Zack Weinberg 2005-05-24 13:18 ` Gabriel Dos Reis @ 2005-05-27 1:20 ` Marcin Dalecki 1 sibling, 0 replies; 97+ messages in thread From: Marcin Dalecki @ 2005-05-27 1:20 UTC (permalink / raw) To: Zack Weinberg; +Cc: Gabriel Dos Reis, gcc, jason, mark, dberlin On 2005-05-24, at 09:09, Zack Weinberg wrote: > Gabriel Dos Reis <gdr@integrable-solutions.net> writes: > > [dropping most of the message - if I haven't responded, assume I don't > agree but I also don't care enough to continue the argument. Also, > rearranging paragraphs a bit so as not to have to repeat myself] > > >> with the explicit call to malloc + explicit specification of sizeof, >> I've found a number of wrong codes -- while replacing the existing >> xmalloc/xcallo with XNEWVEC and friends (see previous patches and >> messages) in libiberty, not counting the happy confusion about >> xcalloc() in the current GCC codes. Those are bugs we do not have >> with the XNEWVEC and friends. Not only, we do get readable code, we >> also get right codes. >> > ... > >> I don't think so. These patches make it possible to compile the >> source code with a C++ compiler. We gain better checking by doing >> that. >> > > Have you found any places where the bugs you found could have resulted > in user-visible incorrect behavior (of any kind)? > > If you have, I will drop all of my objections. You could look at the linkage issues for darwin I have found several months ago. They where *real*. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:38 ` Gabriel Dos Reis 2005-05-24 8:32 ` Zack Weinberg @ 2005-05-24 17:17 ` Paul Koning 2005-05-24 17:25 ` Andreas Schwab 2005-05-24 17:49 ` Gabriel Dos Reis 1 sibling, 2 replies; 97+ messages in thread From: Paul Koning @ 2005-05-24 17:17 UTC (permalink / raw) To: gdr; +Cc: zack, gcc, jason, mark, dberlin >>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes: Gabriel> http://www.gnu.org/software/gcc/codingconventions.html Gabriel> Avoid the use of identifiers or idioms that would prevent Gabriel> code compiling with a C++ compiler. Identifiers such as new Gabriel> or class, that are reserved words in C++, should not be used Gabriel> as variables or field names. Explicit casts should be used Gabriel> to convert between void* and other pointer types. I hope that doesn't require (void *) casts for pointer arguments passed to the likes of memcpy... Gabriel> If converting GCC to C++ is your ultimate goal, then I don't Gabriel> think you should block these patches. They do not introduce Gabriel> C++, but also they do provide a path to local experiments Gabriel> before we ever have any huge fight about that. I do not Gabriel> think converting GCC to C++ is on the table or will happen Gabriel> any time soon -- see previous long discussions. However, I Gabriel> do not believe it would help the GCC project to block any Gabriel> patch that bring us in alignment to our own committment. We Gabriel> can have our cake and it. I.e. we can have the source code Gabriel> in a form compilable with a C++ compiler and test Gabriel> conjectures/experiments. I think that's a good argument. I also find the argument of better type checking persuasive, whether or not it has yet caught a user-visible bug. paul ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 17:17 ` Paul Koning @ 2005-05-24 17:25 ` Andreas Schwab 2005-05-24 20:43 ` Joe Buck 2005-05-24 17:49 ` Gabriel Dos Reis 1 sibling, 1 reply; 97+ messages in thread From: Andreas Schwab @ 2005-05-24 17:25 UTC (permalink / raw) To: Paul Koning; +Cc: gdr, zack, gcc, jason, mark, dberlin Paul Koning <pkoning@equallogic.com> writes: >>>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes: > > Gabriel> http://www.gnu.org/software/gcc/codingconventions.html > > Gabriel> Avoid the use of identifiers or idioms that would prevent > Gabriel> code compiling with a C++ compiler. Identifiers such as new > Gabriel> or class, that are reserved words in C++, should not be used > Gabriel> as variables or field names. Explicit casts should be used > Gabriel> to convert between void* and other pointer types. > > I hope that doesn't require (void *) casts for pointer arguments > passed to the likes of memcpy... Only the (void*) -> (any*) direction requires a cast in C++, the other direction is still converted implicitly. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 17:25 ` Andreas Schwab @ 2005-05-24 20:43 ` Joe Buck 2005-05-24 21:40 ` Dale Johannesen 0 siblings, 1 reply; 97+ messages in thread From: Joe Buck @ 2005-05-24 20:43 UTC (permalink / raw) To: Andreas Schwab; +Cc: Paul Koning, gdr, zack, gcc, jason, mark, dberlin On Tue, May 24, 2005 at 05:03:27PM +0200, Andreas Schwab wrote: > Paul Koning <pkoning@equallogic.com> writes: > > I hope that doesn't require (void *) casts for pointer arguments > > passed to the likes of memcpy... > > Only the (void*) -> (any*) direction requires a cast in C++, the other > direction is still converted implicitly. In my view, the decision by the C standards committees to allow the omission of the cast in the reverse direction was a bad mistake (and I wrote my first C program in 1981, if I recall correctly). While, in int * int_p = malloc(num_integers * sizeof(int)); the operation is safe, this is only because the void* returned by malloc is different from the void* obtained by, say, double d_var; void * p; ... p = &d_var; since one is safe to assign to an int* and the other is not. We really have two different types here; one represents the top of a lattice and the other represents the bottom. It would have been nice if there were a type "aligned_pointer_t" to represent the kind of object returned by malloc. For this reason, I always cast the result of malloc to the proper type; it just feels wrong otherwise. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 20:43 ` Joe Buck @ 2005-05-24 21:40 ` Dale Johannesen 0 siblings, 0 replies; 97+ messages in thread From: Dale Johannesen @ 2005-05-24 21:40 UTC (permalink / raw) To: Joe Buck Cc: Dale Johannesen, gdr, Paul Koning, gcc, Andreas Schwab, zack, mark, jason, dberlin On May 24, 2005, at 9:43 AM, Joe Buck wrote: > On Tue, May 24, 2005 at 05:03:27PM +0200, Andreas Schwab wrote: >> Paul Koning <pkoning@equallogic.com> writes: >>> I hope that doesn't require (void *) casts for pointer arguments >>> passed to the likes of memcpy... >> >> Only the (void*) -> (any*) direction requires a cast in C++, the other >> direction is still converted implicitly. > > For this reason, I always cast the result of malloc to the proper type; > it just feels wrong otherwise. Yes, if the cast looks odd to you, you probably don't go back far enough. I've certainly used compilers that warned when you didn't have a cast there. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 17:17 ` Paul Koning 2005-05-24 17:25 ` Andreas Schwab @ 2005-05-24 17:49 ` Gabriel Dos Reis 1 sibling, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 17:49 UTC (permalink / raw) To: Paul Koning; +Cc: zack, gcc, jason, mark, dberlin Paul Koning <pkoning@equallogic.com> writes: | >>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes: | | Gabriel> http://www.gnu.org/software/gcc/codingconventions.html | | Gabriel> Avoid the use of identifiers or idioms that would prevent | Gabriel> code compiling with a C++ compiler. Identifiers such as new | Gabriel> or class, that are reserved words in C++, should not be used | Gabriel> as variables or field names. Explicit casts should be used | Gabriel> to convert between void* and other pointer types. | | I hope that doesn't require (void *) casts for pointer arguments | passed to the likes of memcpy... It doesn't. The implicit conversion T* -> void* is OK. (I think that if written properly, we will barely have to see casts explicit in the codes.) -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 5:54 ` Zack Weinberg ` (2 preceding siblings ...) 2005-05-24 6:18 ` Gabriel Dos Reis @ 2005-05-24 6:26 ` Mark Mitchell 2005-05-24 6:54 ` Zack Weinberg 3 siblings, 1 reply; 97+ messages in thread From: Mark Mitchell @ 2005-05-24 6:26 UTC (permalink / raw) To: Zack Weinberg; +Cc: Gabriel Dos Reis, gcc, jason, dberlin Zack Weinberg wrote: > On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote: > >>Hi, >> >> I spent the week-end trying to get GCC -- mainline -- compilable >>(i.e. those compoenents written in C) with a C++ compiler (e.g. g++). > > > These results are very interesting. > > As a general observation: A lot of the things you have found to be > problematic, are in fact preferred idioms for C code. For instance, > no standard-C programmer would ever write an explicit cast on malloc's > return value. I don't know that I agree; I used to write such casts on other projects. I learned C and C++ at the same time, and did a fair amount of work with formal type systems, though, so I may not be representative. > is correct C++. Furthermore, as I've said before, I support migrating > to C++ -- but only if the C++ ABI and libstdc++ soname are first > permanently frozen. If we do not do that first, we risk being trapped > into a situation where we need specific versions of GCC to compile > specific newer versions of GCC, which would be a Bad Thing. Line Daniel, I'm confused by this. I think we would need to be sure of source compatibility with a reasonably large set of compilers, so I'd say that it would be bad to depend on (say) a fix for a bug with templates that was fixed in the last release. But, it's doable to specify a super-conservative subset of C++ that works with anything that vaguely smells like a C++ compiler. I'd certainly say that the common subset of C and C++ is such a subset. > Being allowed to do this is very important. Some enumerated types are > to be treated as opaque outside a very narrow context; the only way to > do that in C is to have (a typedef of) unsigned int as the visible type, > and only declare the enumerated type in the context where it's allowed > to be used. I agree with the goal of more hiding. You can do this in C by using an incomplete structure type in most places, and then, in the files where you want the definition visible, defining the structure to have a single field of the enumerated type. That is a little messy, but it is C++-compatible. (In fact, in ISO C++, without the additions presently in the WP, you can't do better; forward declarations of enums are still not allowed.) (The other thing you can do is to depend on the fact that enums and unsigned ints have the same representation, which you can force in C++ by declaring extra enumeration constants of values like UINT_MAX, and then use explicit casts at places where you want to go back and forth. I think this is not as nice as the incomplete structure approach.) -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:26 ` Mark Mitchell @ 2005-05-24 6:54 ` Zack Weinberg 2005-05-24 7:04 ` Mark Mitchell 0 siblings, 1 reply; 97+ messages in thread From: Zack Weinberg @ 2005-05-24 6:54 UTC (permalink / raw) To: Mark Mitchell; +Cc: Gabriel Dos Reis, gcc, jason, dberlin Mark Mitchell <mark@codesourcery.com> writes: [snip stuff addressed elsewhere] > I agree with the goal of more hiding. > > You can do this in C by using an incomplete structure type in most > places, and then, in the files where you want the definition visible, > defining the structure to have a single field of the enumerated > type. That is a little messy, but it is C++-compatible. (In fact, in > ISO C++, without the additions presently in the WP, you can't do > better; forward declarations of enums are still not allowed.) Doesn't work, at least not as a drop-in replacement; you can't pass an incomplete structure by value. We do do this in places where there's a real structure that can be passed around by pointer... zw ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 6:54 ` Zack Weinberg @ 2005-05-24 7:04 ` Mark Mitchell 2005-05-24 15:03 ` Kai Henningsen 2005-05-25 9:51 ` Jason Merrill 0 siblings, 2 replies; 97+ messages in thread From: Mark Mitchell @ 2005-05-24 7:04 UTC (permalink / raw) To: Zack Weinberg; +Cc: Gabriel Dos Reis, gcc, jason, dberlin Zack Weinberg wrote: > Mark Mitchell <mark@codesourcery.com> writes: > > [snip stuff addressed elsewhere] > >>I agree with the goal of more hiding. >> >>You can do this in C by using an incomplete structure type in most >>places, and then, in the files where you want the definition visible, >>defining the structure to have a single field of the enumerated >>type. That is a little messy, but it is C++-compatible. (In fact, in >>ISO C++, without the additions presently in the WP, you can't do >>better; forward declarations of enums are still not allowed.) > > > Doesn't work, at least not as a drop-in replacement; you can't pass an > incomplete structure by value. We do do this in places where there's > a real structure that can be passed around by pointer... Good point; yes, you would have to pass a pointer. I guess you could create a singleton representative of each value in the enum, and pass them around, but I agree that's getting pretty ugly. Of course, the problem with "unsigned int" is that it is a complete type, and people can accidentally pass in "7", even if there's no such enumeral. You really want forward-declared enums, but you haven't got them; it may be you just lose. :-( -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:04 ` Mark Mitchell @ 2005-05-24 15:03 ` Kai Henningsen 2005-05-25 9:51 ` Jason Merrill 1 sibling, 0 replies; 97+ messages in thread From: Kai Henningsen @ 2005-05-24 15:03 UTC (permalink / raw) To: gcc mark@codesourcery.com (Mark Mitchell) wrote on 23.05.05 in <4292C8C9.9040400@codesourcery.com>: > Zack Weinberg wrote: > > Mark Mitchell <mark@codesourcery.com> writes: > > > > [snip stuff addressed elsewhere] > > > >>I agree with the goal of more hiding. > >> > >>You can do this in C by using an incomplete structure type in most > >>places, and then, in the files where you want the definition visible, > >>defining the structure to have a single field of the enumerated > >>type. That is a little messy, but it is C++-compatible. (In fact, in > >>ISO C++, without the additions presently in the WP, you can't do > >>better; forward declarations of enums are still not allowed.) > > > > > > Doesn't work, at least not as a drop-in replacement; you can't pass an > > incomplete structure by value. We do do this in places where there's > > a real structure that can be passed around by pointer... > > Good point; yes, you would have to pass a pointer. I guess you could > create a singleton representative of each value in the enum, and pass > them around, but I agree that's getting pretty ugly. Of course, the > problem with "unsigned int" is that it is a complete type, and people > can accidentally pass in "7", even if there's no such enumeral. You > really want forward-declared enums, but you haven't got them; it may be > you just lose. :-( What I've done, in a similar situation, was to declare a complete structure encapsulating the value - this at least makes sure you need to acknowledge the structure whenever you access the value. Plus, I've added inline functions for accessing the value, so those places don't need to know the structure details either. This makes it fairly type safe, and you can grep for all kinds of uses (including people who naughtily access the structure contents directly). MfG Kai ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 7:04 ` Mark Mitchell 2005-05-24 15:03 ` Kai Henningsen @ 2005-05-25 9:51 ` Jason Merrill 1 sibling, 0 replies; 97+ messages in thread From: Jason Merrill @ 2005-05-25 9:51 UTC (permalink / raw) To: Mark Mitchell; +Cc: Zack Weinberg, Gabriel Dos Reis, gcc, dberlin On Mon, 23 May 2005 23:25:13 -0700, Mark Mitchell <mark@codesourcery.com> wrote: > Good point; yes, you would have to pass a pointer. I guess you could > create a singleton representative of each value in the enum, and pass > them around, but I agree that's getting pretty ugly. Of course, the > problem with "unsigned int" is that it is a complete type, and people can > accidentally pass in "7", even if there's no such enumeral. You really > want forward-declared enums, but you haven't got them; it may be you just > lose. :-( You don't have foward-declared enums because you don't know how large they need to be. If what you want is an opaque enum, such that other files treat it as an integer and only certain files know the enumerators, then declare your variables to some typedef of an integer. People could accidentally pass in "7" anyway in C. You either get the opacity or the type checking (when compiled as C++), but not both. Jason ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-23 11:50 Gabriel Dos Reis ` (3 preceding siblings ...) 2005-05-24 5:54 ` Zack Weinberg @ 2005-05-24 10:01 ` Florian Weimer 2005-05-24 14:22 ` Gabriel Dos Reis 2005-05-24 18:00 ` Diego Novillo 2005-05-27 1:20 ` Marcin Dalecki 6 siblings, 1 reply; 97+ messages in thread From: Florian Weimer @ 2005-05-24 10:01 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin * Gabriel Dos Reis: > The first resistance seems to come from the pervasive use of the implicit > conversion void* -> T*, mostly with storage allocating functions. This can be worked around on the C++ side, see the example code below. It's a kludge, but it's not too bad IMHO. class xmalloc_result; xmalloc_result xmalloc (size_t); class xmalloc_result { friend xmalloc_result xmalloc (size_t); const size_t size_; xmalloc_result (size_t size) : size_ (size) { } xmalloc_result operator= (const xmalloc_result&); // not implemented public: template <typename T> operator T* () const { return static_cast<T*> (malloc(size_)); } }; inline xmalloc_result xmalloc (size_t size) { return xmalloc_result (size); } char * foo (void) { return xmalloc (1); } void bar (int **result) { *result = xmalloc (sizeof (int)); } ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 10:01 ` Florian Weimer @ 2005-05-24 14:22 ` Gabriel Dos Reis 0 siblings, 0 replies; 97+ messages in thread From: Gabriel Dos Reis @ 2005-05-24 14:22 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc, jason, mark, dberlin Florian Weimer <fw@deneb.enyo.de> writes: | * Gabriel Dos Reis: | | > The first resistance seems to come from the pervasive use of the implicit | > conversion void* -> T*, mostly with storage allocating functions. | | This can be worked around on the C++ side, see the example code below. | It's a kludge, but it's not too bad IMHO. Yes. However, if we were to use C++ in the source code, I know of a few numbers of ways to make the exsting code far better :-) However, the idea is to have the *C* source code through a C++ compiler -- for a number of reasons, for starter using C++ in GCC is not on the table. (And the implicit conversion is still unable to catch the various wrong codes I repported earlier and the confusion about xcalloc). -- Gaby ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-23 11:50 Gabriel Dos Reis ` (4 preceding siblings ...) 2005-05-24 10:01 ` Florian Weimer @ 2005-05-24 18:00 ` Diego Novillo 2005-05-24 20:41 ` Richard Guenther ` (2 more replies) 2005-05-27 1:20 ` Marcin Dalecki 6 siblings, 3 replies; 97+ messages in thread From: Diego Novillo @ 2005-05-24 18:00 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote: > So, if various components maintainers (e.g. C and C++, middle-end, > ports, etc.) are willing to help quickly reviewing patches we can > have this done for this week (assuming mainline is unslushed soon). > And, of course, everybody can help :-) > If the final goal is to allow GCC components to be implemented in C++, then I am all in favour of this project. I'm pretty sick of all this monkeying around we do with macros to make up for the lack of abstraction. Diego. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 18:00 ` Diego Novillo @ 2005-05-24 20:41 ` Richard Guenther 2005-05-24 23:14 ` Kevin Handy 2005-05-27 3:47 ` Marcin Dalecki 2 siblings, 0 replies; 97+ messages in thread From: Richard Guenther @ 2005-05-24 20:41 UTC (permalink / raw) To: Diego Novillo; +Cc: Gabriel Dos Reis, gcc, jason, mark, dberlin On 5/24/05, Diego Novillo <dnovillo@redhat.com> wrote: > On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote: > > > So, if various components maintainers (e.g. C and C++, middle-end, > > ports, etc.) are willing to help quickly reviewing patches we can > > have this done for this week (assuming mainline is unslushed soon). > > And, of course, everybody can help :-) > > > If the final goal is to allow GCC components to be implemented in > C++, then I am all in favour of this project. I'm pretty sick of > all this monkeying around we do with macros to make up for the > lack of abstraction. It's also a good test to see how/whether the different trees the C++ frontend presents to the middle-end impact our ability to optimize gcc itself. There are quite some subtle differences out there asking to be "fixed", regardless if we go to adopt C++ for writing gcc or not. Richard. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 18:00 ` Diego Novillo 2005-05-24 20:41 ` Richard Guenther @ 2005-05-24 23:14 ` Kevin Handy 2005-05-27 3:47 ` Marcin Dalecki 2 siblings, 0 replies; 97+ messages in thread From: Kevin Handy @ 2005-05-24 23:14 UTC (permalink / raw) To: gcc Diego Novillo wrote: >On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote: > > > >>So, if various components maintainers (e.g. C and C++, middle-end, >>ports, etc.) are willing to help quickly reviewing patches we can >>have this done for this week (assuming mainline is unslushed soon). >>And, of course, everybody can help :-) >> >> >> >If the final goal is to allow GCC components to be implemented in >C++, then I am all in favour of this project. I'm pretty sick of >all this monkeying around we do with macros to make up for the >lack of abstraction. > > >Diego. > > > It might be interesting, sometime in the future, to fork a version of GCC into a C++ version, just to see what can be done with it. It might make it easier for someone to write their own front/back end by using existing classes to fill out most of the standard stuff, and to build up trees using classes, etc. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-24 18:00 ` Diego Novillo 2005-05-24 20:41 ` Richard Guenther 2005-05-24 23:14 ` Kevin Handy @ 2005-05-27 3:47 ` Marcin Dalecki 2 siblings, 0 replies; 97+ messages in thread From: Marcin Dalecki @ 2005-05-27 3:47 UTC (permalink / raw) To: Diego Novillo; +Cc: Gabriel Dos Reis, gcc, jason, mark, dberlin On 2005-05-24, at 18:06, Diego Novillo wrote: > On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote: > > >> So, if various components maintainers (e.g. C and C++, middle-end, >> ports, etc.) are willing to help quickly reviewing patches we can >> have this done for this week (assuming mainline is unslushed soon). >> And, of course, everybody can help :-) >> >> > If the final goal is to allow GCC components to be implemented in > C++, then I am all in favour of this project. I'm pretty sick of > all this monkeying around we do with macros to make up for the > lack of abstraction. Amen. GCC cries and woes through struct tree for polymorphism. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Compiling GCC with g++: a report 2005-05-23 11:50 Gabriel Dos Reis ` (5 preceding siblings ...) 2005-05-24 18:00 ` Diego Novillo @ 2005-05-27 1:20 ` Marcin Dalecki 6 siblings, 0 replies; 97+ messages in thread From: Marcin Dalecki @ 2005-05-27 1:20 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc, jason, mark, dberlin On 2005-05-23, at 08:15, Gabriel Dos Reis wrote: > > > Sixth, there is a real "mess" about name spaces. It is true that > every C programmers knows the rule saying tags inhabit different name > space than variable of functions. However, all the C coding standards > I've read so far usually suggest > > typedef struct foo foo; > > but *not* > > typedef struct foo *foo; > > i.e. "bringing" the tag-name into normal name space to name the type > structure or enumeration is OK, but not naming a different type! the > latter practice will be flagged by a C++ compiler. I guess we may > need some discussion about the naming of structure (POSIX reserves > anything ending with "_t", so we might want to choose something so > that we don't run into problem. However, I do not expect this issue > to dominate the discussion :-)) > In 80% of the cases you are talking about the GCC source code already follows the semi-convention of appending _s to the parent type. ^ permalink raw reply [flat|nested] 97+ messages in thread
end of thread, other threads:[~2005-05-27 0:54 UTC | newest] Thread overview: 97+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-05-25 5:26 Compiling GCC with g++: a report Paul Schlie 2005-05-25 6:10 ` DJ Delorie 2005-05-25 11:46 ` Paul Schlie 2005-05-25 18:31 ` DJ Delorie 2005-05-25 21:41 ` Paul Schlie 2005-05-26 6:11 ` DJ Delorie 2005-05-26 8:15 ` Paul Schlie 2005-05-26 11:57 ` DJ Delorie -- strict thread matches above, loose matches on Subject: below -- 2005-05-25 19:27 Richard Kenner 2005-05-23 11:50 Gabriel Dos Reis 2005-05-23 12:22 ` Ranjit Mathew 2005-05-23 19:07 ` Tom Tromey 2005-05-23 18:04 ` Gabriel Dos Reis 2005-05-24 4:57 ` Gabriel Dos Reis 2005-05-24 4:59 ` Joseph S. Myers 2005-05-24 21:50 ` Kevin Handy 2005-05-25 12:02 ` Bernardo Innocenti 2005-05-24 5:54 ` Zack Weinberg 2005-05-24 6:04 ` Daniel Jacobowitz 2005-05-24 6:22 ` Gabriel Dos Reis 2005-05-24 6:29 ` Zack Weinberg 2005-05-24 6:31 ` Mark Mitchell 2005-05-24 7:08 ` Zack Weinberg 2005-05-24 7:09 ` Mark Mitchell 2005-05-24 7:39 ` Gabriel Dos Reis 2005-05-24 8:48 ` Zack Weinberg 2005-05-24 13:41 ` Gabriel Dos Reis 2005-05-25 0:47 ` Russ Allbery 2005-05-25 1:24 ` Gabriel Dos Reis 2005-05-24 16:07 ` Paolo Bonzini 2005-05-24 16:44 ` Daniel Jacobowitz 2005-05-24 23:53 ` Zack Weinberg 2005-05-25 0:06 ` Daniel Jacobowitz 2005-05-25 0:11 ` Richard Henderson 2005-05-25 0:22 ` Zack Weinberg 2005-05-25 0:26 ` Paolo Carlini 2005-05-25 0:37 ` Zack Weinberg 2005-05-25 0:43 ` Daniel Jacobowitz 2005-05-25 0:48 ` Zack Weinberg 2005-05-25 1:02 ` Paolo Carlini 2005-05-25 3:14 ` Daniel Jacobowitz 2005-05-25 16:18 ` Jason Merrill 2005-05-25 12:44 ` Christoph Hellwig 2005-05-25 13:33 ` Florian Weimer 2005-05-27 3:10 ` Marcin Dalecki 2005-05-24 6:13 ` Andrew Pinski 2005-05-24 6:25 ` Gabriel Dos Reis 2005-05-27 4:04 ` Marcin Dalecki 2005-05-24 6:18 ` Gabriel Dos Reis 2005-05-24 6:43 ` Zack Weinberg 2005-05-24 7:04 ` Mark Mitchell 2005-05-24 8:00 ` Gabriel Dos Reis 2005-05-25 3:45 ` Kaveh R. Ghazi 2005-05-25 7:45 ` DJ Delorie 2005-05-25 8:36 ` Gabriel Dos Reis 2005-05-25 13:38 ` Kaveh R. Ghazi 2005-05-26 13:40 ` Gabriel Dos Reis 2005-05-24 7:38 ` Gabriel Dos Reis 2005-05-24 8:32 ` Zack Weinberg 2005-05-24 13:18 ` Gabriel Dos Reis 2005-05-24 23:45 ` Zack Weinberg 2005-05-25 0:29 ` Gabriel Dos Reis 2005-05-25 0:37 ` Zack Weinberg 2005-05-25 0:52 ` DJ Delorie 2005-05-25 0:55 ` Zack Weinberg 2005-05-25 1:02 ` Ian Lance Taylor 2005-05-25 1:36 ` DJ Delorie 2005-05-25 1:40 ` Zack Weinberg 2005-05-25 2:24 ` Gabriel Dos Reis 2005-05-25 1:50 ` Gabriel Dos Reis 2005-05-25 2:20 ` DJ Delorie 2005-05-25 1:47 ` Gabriel Dos Reis 2005-05-25 2:08 ` DJ Delorie 2005-05-25 2:36 ` Gabriel Dos Reis 2005-05-25 3:34 ` DJ Delorie 2005-05-25 5:01 ` Gabriel Dos Reis 2005-05-25 1:12 ` Gabriel Dos Reis 2005-05-25 1:47 ` DJ Delorie 2005-05-25 3:20 ` Gabriel Dos Reis 2005-05-27 1:20 ` Marcin Dalecki 2005-05-24 17:17 ` Paul Koning 2005-05-24 17:25 ` Andreas Schwab 2005-05-24 20:43 ` Joe Buck 2005-05-24 21:40 ` Dale Johannesen 2005-05-24 17:49 ` Gabriel Dos Reis 2005-05-24 6:26 ` Mark Mitchell 2005-05-24 6:54 ` Zack Weinberg 2005-05-24 7:04 ` Mark Mitchell 2005-05-24 15:03 ` Kai Henningsen 2005-05-25 9:51 ` Jason Merrill 2005-05-24 10:01 ` Florian Weimer 2005-05-24 14:22 ` Gabriel Dos Reis 2005-05-24 18:00 ` Diego Novillo 2005-05-24 20:41 ` Richard Guenther 2005-05-24 23:14 ` Kevin Handy 2005-05-27 3:47 ` Marcin Dalecki 2005-05-27 1:20 ` Marcin Dalecki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).