Re: Mainline is now regression and documentation fixes only
Dorit Nuzman/Haifa/IBM wrote on 23/01/2008 21:49:51: > There are however a couple of small cost-model changes that were > going to be submitted this week for the Cell SPU - it's unfortunate > if these cannot get into 4.3. It's indeed unfortunate. However, those changes are not crucial and there is still some more work to be done (check on additional benchmarks, etc.). So, I guess, it will have to wait for 4.4. Ira > > dorit >
Re: GCC 4.3 target deprecation proposals
On Mon, Jan 21, 2008 at 07:06:52PM +, Joseph S. Myers wrote: > > Of the others: arc, crx, iq2000, mt, pdp11, stormy16, I see no recent > testing or development. Joern Rennecke was intending to improve ARC > support but is listed as "Waiting for paperwork" in MAINTAINERS; is > there any news on that assignment? It is still held up my legal matters; I am told, however, that this is now handled with much higher priority than it was a year ago.
may_alias attribute and type identity (PR c++/34935)
PR c++/34935 illustrates a problem with the way attributes interact with type identity. The example in question looks something like this: typedef int X __attribute((may_alias)); void foo(X); void foo(int); The fundamental question here is whether 'X' is a new type distinct from 'int', or whether 'X' is really just a typedef of 'int' that adds the 'may_alias' attribute. The failure in PR c++/34935 comes from the canonical types system having a different answer to this question than the normal type-comparison function in the C++ front end (structural_comptypes). Canonical types says that 'int' and 'X' are the same type, which says that this code is fine: we're just declaring the function "foo" twice in the same way. structural_comptypes says that 'int' and 'X' are distinct types, which says that this code is still fine... we're declaring two overloaded functions named "foo". The oddity, for me, is that structural_comptypes isn't deciding that 'X' and 'int' are different because it's looking at attributes or anything like that: it decides they are different because they have different TYPE_MAIN_VARIANTs, and it doesn't bother to look at the guts of the INTEGER_TYPE nodes to see that they are the same. So, I *think* that structural_comptypes need to compare the guts of INTEGER_TYPE nodes, but Richard Guenther's comment on the PR indicates that it's canonical types that are wrong. Which one is it? Note that this is pretty tied up with Mark Mitchell's discussion of semantic and non-semantic attributes, here: http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html - Doug
Re: may_alias attribute and type identity (PR c++/34935)
On Jan 24, 2008 3:58 PM, Doug Gregor <[EMAIL PROTECTED]> wrote: > PR c++/34935 illustrates a problem with the way attributes interact > with type identity. The example in question looks something like this: > > typedef int X __attribute((may_alias)); > > void foo(X); > void foo(int); > > The fundamental question here is whether 'X' is a new type distinct > from 'int', or whether 'X' is really just a typedef of 'int' that adds > the 'may_alias' attribute. The failure in PR c++/34935 comes from the > canonical types system having a different answer to this question than > the normal type-comparison function in the C++ front end > (structural_comptypes). Canonical types says that 'int' and 'X' are > the same type, which says that this code is fine: we're just declaring > the function "foo" twice in the same way. structural_comptypes says > that 'int' and 'X' are distinct types, which says that this code is > still fine... we're declaring two overloaded functions named "foo". > The oddity, for me, is that structural_comptypes isn't deciding that > 'X' and 'int' are different because it's looking at attributes or > anything like that: it decides they are different because they have > different TYPE_MAIN_VARIANTs, and it doesn't bother to look at the > guts of the INTEGER_TYPE nodes to see that they are the same. > > So, I *think* that structural_comptypes need to compare the guts of > INTEGER_TYPE nodes, but Richard Guenther's comment on the PR indicates > that it's canonical types that are wrong. Which one is it? The middle-end type system (useless_type_conversion_p) says that pointers to int and pointers to int __attribute__((may_alias)) are distinct (you can't use one in place of the other without changning semantics) - because the pointed to types have different alias sets. Now, for rvalues that doesn't matter, so indeed a value of type int and a value of type int __attribute__((may_alias)) can be used in place of each other. So I stand corrected and they should indeed have the same canonical type. RIchard. > Note that this is pretty tied up with Mark Mitchell's discussion of > semantic and non-semantic attributes, here: > > http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html > > - Doug >
Re: GCC 4.3 target deprecation proposals
> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes: Joseph> ... There is good coverage for Joseph> bare-metal ELF targets, but none for bare-metal a.out and Joseph> COFF targets (perhaps we should consider deprecating all of Joseph> those, on the presumption that bare-metal use has moved to Joseph> ELF and objcopy is likely to be used in any case to produce a Joseph> raw binary image... I believe pdp11 (all OS flavors) is a.out. Is getting rid of COFF and a.out considered a desirable thing to do? If so I'll look at what that implies in pdp11. paul
Re: may_alias attribute and type identity (PR c++/34935)
On Thu, Jan 24, 2008 at 04:06:47PM +0100, Richard Guenther wrote: > On Jan 24, 2008 3:58 PM, Doug Gregor <[EMAIL PROTECTED]> wrote: > The middle-end type system (useless_type_conversion_p) says that > pointers to int and pointers to int __attribute__((may_alias)) are > distinct (you can't use one in place of the other without changning > semantics) - because the pointed to types have different alias sets. > > Now, for rvalues that doesn't matter, so indeed a value of type > int and a value of type int __attribute__((may_alias)) can be used > in place of each other. So I stand corrected and they should indeed > have the same canonical type. See also http://gcc.gnu.org/PR34936. Is int __attribute__((may_alias)) supposed to be mangled the same as int? And if so, it should for cp/call.c purposes be treated the same as well. Jakub
[C++ PATCH] Re: may_alias attribute and type identity (PR c++/34935, PR c++/34936)
On Jan 24, 2008 11:41 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 24, 2008 at 04:06:47PM +0100, Richard Guenther wrote:
> > On Jan 24, 2008 3:58 PM, Doug Gregor <[EMAIL PROTECTED]> wrote:
> > The middle-end type system (useless_type_conversion_p) says that
> > pointers to int and pointers to int __attribute__((may_alias)) are
> > distinct (you can't use one in place of the other without changning
> > semantics) - because the pointed to types have different alias sets.
> >
> > Now, for rvalues that doesn't matter, so indeed a value of type
> > int and a value of type int __attribute__((may_alias)) can be used
> > in place of each other. So I stand corrected and they should indeed
> > have the same canonical type.
>
> See also http://gcc.gnu.org/PR34936. Is int __attribute__((may_alias))
> supposed to be mangled the same as int? And if so, it should for cp/call.c
> purposes be treated the same as well.
I just started venturing down this rabbit hole when I saw your note.
Since we previously ignored the may_alias attribute, we ended up
treating "int" and its may_alias typedef as identical nodes; that also
seems like the right answer from the perspective of C++, because I
think we want these types to mangle the same, act identical in
overload resolution, etc. However, both the mangler (PR 34936) and the
structural type checking routines (PR 34935) are unprepared for
attribute-qualified typedefs like these, because they depend on the
TYPE_MAIN_VARIANT being equivalent to one the predefined type nodes
(which isn't the case with attribute-qualified typedefs).
The canonical type system gets this right: it sees the types as
equivalent, and always gives us a path from the typedef'd,
attribute-qualified versions of types back to the predefined type
nodes (which are the canonical versions, by design). So, I'm fixing
both PRs by using canonical types. With 34935, we end up just relying
on canonical types to compare INTEGER_TYPE, FIXED_POINT_TYPE, and
REAL_TYPE nodes, because there's no other way to do it without
fundamentally changing how attribute-qualified typedefs are
represented. With 34936, we just map the builtin type down to its
canonical form, which will be one of the predefined type nodes.
The attached patch fixes both PRs. Regression tests are still running
on i686-pc-linux-gnu, but assuming no problems crop up... okay for
mainline?
- Doug
2008-01-24 Douglas Gregor <[EMAIL PROTECTED]>
Jakub Jelinek <[EMAIL PROTECTED]>
PR c++/34935
PR c++/34936
* typeck.c (structural_comptypes): Handle comparisons of
VOID_TYPE, BOOLEAN_TYPE, INTEGER_TYPE, FIXED_POINT_TYPE, and
REAL_TYPE nodes.
* mangle.c (write_builtin_type): Map down to the canonical type,
which will be one of the predefined type nodes.
2008-01-24 Douglas Gregor <[EMAIL PROTECTED]>
Jakub Jelinek <[EMAIL PROTECTED]>
PR c++/34935
PR c++/34936
* g++.dg/ext/alias-canon.C: New.
* g++.dg/ext/alias-mangle.C: New.
Index: cp/typeck.c
===
--- cp/typeck.c (revision 131778)
+++ cp/typeck.c (working copy)
@@ -976,6 +976,30 @@ structural_comptypes (tree t1, tree t2,
/* Compare the types. Break out if they could be the same. */
switch (TREE_CODE (t1))
{
+case VOID_TYPE:
+case BOOLEAN_TYPE:
+ /* All void and bool types are the same. */
+ break;
+
+case INTEGER_TYPE:
+case FIXED_POINT_TYPE:
+case REAL_TYPE:
+ /* With these nodes, we can't determine type equivalence by
+ looking at what is stored in the nodes themselves, because
+ two nodes might have different TYPE_MAIN_VARIANTs but still
+ represent the same type. For example, wchar_t and int could
+ have the same properties (TYPE_PRECISION, TYPE_MIN_VALUE,
+ TYPE_MAX_VALUE, etc.), but have different TYPE_MAIN_VARIANTs
+ and are distinct types. On the other hand, int and the
+ following typedef
+
+ typedef int INT __attribute((may_alias));
+
+ have identical properties, different TYPE_MAIN_VARIANTs, but
+ represent the same type. The canonical type system keeps
+ track of equivalence in this case, so we fall back on it. */
+ return TYPE_CANONICAL (t1) == TYPE_CANONICAL (t2);
+
case TEMPLATE_TEMPLATE_PARM:
case BOUND_TEMPLATE_TEMPLATE_PARM:
if (TEMPLATE_TYPE_IDX (t1) != TEMPLATE_TYPE_IDX (t2)
Index: cp/mangle.c
===
--- cp/mangle.c (revision 131778)
+++ cp/mangle.c (working copy)
@@ -1768,6 +1768,9 @@ write_CV_qualifiers_for_type (const tree
static void
write_builtin_type (tree type)
{
+ if (TYPE_CANONICAL (type))
+type = TYPE_CANONICAL (type);
+
switch (TREE_CODE (type))
{
case VOID_TYPE:
Index: testsuite/g++.dg/ext/alias-canon.C
===
--- testsuite/g++.dg/ext/alias-c
Document building GMP/MPFR in local tree?
Per http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html it is possible to build GMP/MPFR in the local tree with the current Trunk. This build method may ease issues with building gcc. Would it be possible to document this for 4.3? Thanks, Matt
Re: GCC 4.3 target deprecation proposals
On Thu, 24 Jan 2008, Paul Koning wrote: > > "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes: > > Joseph> ... There is good coverage for > Joseph> bare-metal ELF targets, but none for bare-metal a.out and > Joseph> COFF targets (perhaps we should consider deprecating all of > Joseph> those, on the presumption that bare-metal use has moved to > Joseph> ELF and objcopy is likely to be used in any case to produce a > Joseph> raw binary image... > > I believe pdp11 (all OS flavors) is a.out. Is getting rid of COFF and > a.out considered a desirable thing to do? If so I'll look at what > that implies in pdp11. Getting rid of generic *-*-aout* and *-*-coff*, where there are corresponding ELF targets for the same CPU, is what I was suggesting might be considered (and has not attracted any comments on the general idea). This is not the same as getting rid of COFF and a.out altogether, because of various other targets using those formats. It is of course the case that various features in GCC work better with ELF and DWARF than other formats (and LTO is being written to use libelf at present, for example, although I imagine it may be extended to support other file formats with the same raw data embedded in them in due course). -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.3 target deprecation proposals
"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > * Any target with test results posted to gcc-testresults within the > past year, I did a test run of the sh-elf test results script. There are so many multilibs that the email is 437 Kb long. Still want it as-is? Summary attached. === gcc Summary for sh-sim/-m4a-single-only === # of expected passes44683 # of unexpected failures73 # of unexpected successes 1 # of expected failures 86 # of unresolved testcases 92 # of untested testcases 35 # of unsupported tests 376 === gcc Summary === # of expected passes849104 # of unexpected failures1066 # of unexpected successes 16 # of expected failures 1637 # of unresolved testcases 1854 # of untested testcases 665 # of unsupported tests 7144 /sata/dj/gnu/gcc/sh-elf/gcc/xgcc version 4.3.0 20080124 (experimental) [trunk revision 131776] (GCC) === g++ Summary for sh-sim/-m4a-single-only === # of expected passes16696 # of unexpected failures30 # of unexpected successes 2 # of expected failures 81 # of unresolved testcases 49 # of unsupported tests 162 === g++ Summary === # of expected passes317108 # of unexpected failures559 # of unexpected successes 38 # of expected failures 1539 # of unresolved testcases 957 # of unsupported tests 3078 /sata/dj/gnu/gcc/sh-elf/gcc/testsuite/g++/../../g++ version 4.3.0 20080124 (experimental) [trunk revision 131776] (GCC)
Re: GCC 4.3 target deprecation proposals
On Thu, 24 Jan 2008, DJ Delorie wrote: > "Joseph S. Myers" <[EMAIL PROTECTED]> writes: > > * Any target with test results posted to gcc-testresults within the > > past year, > > I did a test run of the sh-elf test results script. There are so many > multilibs that the email is 437 Kb long. Still want it as-is? sh-unknown-elf is already on the list of targets tested since the start of 2007, but I'm only counting those where the results reached gcc-testresults successfully (so were under 400 Kb). Actively maintained targets need a maintainer doing enough work on the results (fixing bugs and arranging for inapplicable tests to be skipped or XFAILed) to get them down below that size. -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.3 target deprecation proposals
> Actively maintained targets need a maintainer doing enough work on > the results (fixing bugs and arranging for inapplicable tests to be > skipped or XFAILed) to get them down below that size. At the moment, I'm working on getting sh, h8300, and m32c in shape for 4.3 (or future). I can easily get the test results under 400k by removing some of the multilibs, but I don't think that's a good idea. My sh-elf test tests 38 multilibs, if I only test one that would be a 12k email, which would easily fit past the filters. Are we artificially penalizing targets with many multilibs? Also, while I'm not suggesting I be a maintainer for sh and h8300, if I'm working on them and producing test results, should I send them in anyway? I can always stop sending them when I stop working on them (for whatever reason), but meanwhile, does that count against deprecation?
Re: GCC 4.3 target deprecation proposals
On Thu, 24 Jan 2008, DJ Delorie wrote: > At the moment, I'm working on getting sh, h8300, and m32c in shape for > 4.3 (or future). I can easily get the test results under 400k by > removing some of the multilibs, but I don't think that's a good idea. > My sh-elf test tests 38 multilibs, if I only test one that would be a > 12k email, which would easily fit past the filters. Are we > artificially penalizing targets with many multilibs? If results are being rejected without indicating the target is in terrible shape, you could ask overseers to increase the size limit on gcc-testresults. I'm not actually convinced these long default multilib lists are a good idea; if a user doesn't just want a single multilib for their processor, the long generic list is likely to be wrong for them as well. sh has a mechanism for selecting multilibs at configure time, and a more general such mechanism would be good as well (for some targets such as GNU/Linux, it would need to deal with SYSROOT_SUFFIX_SPEC and SYSROOT_HEADERS_SUFFIX_SPEC as well as the usual multilib variables; note some targets already generate SYSROOT_SUFFIX_SPEC automatically). > Also, while I'm not suggesting I be a maintainer for sh and h8300, if > I'm working on them and producing test results, should I send them in > anyway? I can always stop sending them when I stop working on them > (for whatever reason), but meanwhile, does that count against > deprecation? Anyone sending results for a target counts against deprecation. I didn't even look at what version the results are for (although maybe in the 4.4 cycle we should only look at results for 4.3 or later). -- Joseph S. Myers [EMAIL PROTECTED]
dwarf2 EH address size
The m32c port has this:
#define DWARF2_ADDR_SIZE4
However, dwarf2asm.c has this:
int
size_of_encoded_value (int encoding)
{
. . .
case DW_EH_PE_absptr:
return POINTER_SIZE / BITS_PER_UNIT;
The net result is that the EH sections have 2 byte pointers for the
m16c variant (HImode pointers), which screws up binutils, which is
expecting 4. The m32c variant (PSImode pointers) is OK.
Before I go hard-coding a "2" into binutils, I ask... is gcc supposed
to honor DWARF2_ADDR_SIZE for absptr? What's the reasoning behind the
way it is?
Re: GCC 4.3 target deprecation proposals
On Thu, Jan 24, 2008 at 11:16:43PM +, Joseph S. Myers wrote: > On Thu, 24 Jan 2008, DJ Delorie wrote: > > > At the moment, I'm working on getting sh, h8300, and m32c in shape for > > 4.3 (or future). I can easily get the test results under 400k by > > removing some of the multilibs, but I don't think that's a good idea. > > My sh-elf test tests 38 multilibs, if I only test one that would be a > > 12k email, which would easily fit past the filters. Are we > > artificially penalizing targets with many multilibs? > > If results are being rejected without indicating the target is in terrible > shape, you could ask overseers to increase the size limit on > gcc-testresults. Or the test script could be fixed to pre-scan the message instead of just piping it to a mailer. If its size exceeds some limit (say 300k), the mail could be replaced by a shortened form, giving only the total numbers of failures with a big message at the beginning indicating that the message was truncated because of the massive number of failures.
Re: GCC 4.3 target deprecation proposals
> I'm not actually convinced these long default multilib lists are a > good idea; If my goal was to write SH software, I'd agree. However, my goal is to try to get the port into shape, so a long list is useful. Internally, we use an even longer list, but the FSF sources don't support (by default) all the multilibs we do.
Re: GCC 4.3 target deprecation proposals
> message was truncated because of the massive number of failures. Or massive number of multilibs :-)
Re: GCC 4.3 target deprecation proposals
On Wed, 2008-01-23 12:57:00 +0100, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote: I played a bit with it, so I can answer these questions myself: > Most specific questions: > > - What is the largest HDD SIMH supports? There seems to be RA92 > support, but that's only 1.5GB. With today's software, I guess > the build requirements (checked-out trees of the software incl. > SCM metadata, ...) are way above that :) > > What's the best way to get a "real" amount of storage into NetBSD > on SIMH? NFS-mounting something from outside? SIMH allows arbitrarily sized disks. Don't use "set rq0 ra92", but "set rq0 rauser=2" to get about 20GB. > - The NetBSD SIMH HOWTO > (http://www.netbsd.org/ports/vax/emulator-howto.html) refers to > load the ka655.bin eprom image, but upstream SIMH "only" contains > the hacked version (ka655x.bin), which supports more RAM. Is it > okay to assume NetBSD will accept this hacked ROM and give me as > much RAM inside the instance as possible with it? Seems this will work with NetBSD. Maximum amount of RAM can be get with "set cpu 512m". MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: Fortschritt bedeutet, einen Schritt so zu machen, the second : daß man den nächsten auch noch machen kann. signature.asc Description: Digital signature
Re: [M16C]: 20-bit access patch for review
Minor stylistic suggestions...
+ "*
+ switch (which_alternative)
+{
+case 0:
+ if (TARGET_A16
+ && GET_CODE (operands[2]) == SYMBOL_REF
+ && far_data_p (operands[2])== 1
+ && near_data_p (operands[2])== 0)
+return m32c_disp_pattern (insn, operands);
+ else
+return \"add.w\t%2,%0\";
This should be done by creating a constraint for the first case, and
adding it to the list of constraints. Then we can avoid a huge switch
statement.
+/* Returns TRUE if given tree has the "far" attribute. */
+int
+far_data_p (rtx x)
+{
This function should account for CONST and offsets, so that it need
not be done many times in the *.md files.
+/* Returns TRUE if given tree has the "far" attribute. */
+int
+far_data_a1a0 (rtx x)
+{
These two functions should have different comments, each describing
the specifics of the two functions.
+
+static tree
+far_data_handler (tree * node, tree name,
+ tree args ATTRIBUTE_UNUSED,
+ int flags ATTRIBUTE_UNUSED, bool * no_add_attrs)
+{
This function should have a comment too.
+/* Returns TRUE if given tree has the "near" attribute. */
+int
+near_data_p (rtx x)
+{
Likewise for these two.
+/* Copy the constant string from '.rodata' section in far memory to
+ 'data' section in near memory */
"copy from" doesn't describe what this function is doing. "Assign to"
would be better.
+/* Returns the instructions to access array elements using the
+ displacement. */
+char *
+m32c_disp_pattern (rtx insn, rtx * operands)
This giant function is better done as a peephole optimization that
resolves to an UNSPEC pattern for the desired output.
--- /gcc/config/m32c/mov.md 2008-01-15 11:37:37.0 +0530
+++ /gcc/config/m32c/mov.md 2008-01-15 17:41:04.0 +0530
@@ -30,6 +30,159 @@
;; Match push/pop before mov.b for passing char as arg,
;; e.g. stdlib/efgcvt.c.
+
+;; M16C-20bit Access
+(define_insn "movqildabs_op"
+ [(set (match_operand:QI 0 "mra_nopp_operand" "=Rqi*Rmm")
+(match_operand:QI 1 "m32c_20babsqi_operand" "Sn"))]
Can these be done with constraints in the generic mov pattern,
instead of a whole separate pattern?
+ else if (GET_CODE (XEXP (operands[1], 0)) == CONST)
+{
+ a = far_data_p (XEXP (XEXP (XEXP (operands[1], 0), 0), 0));
+ b = near_data_p (XEXP (XEXP (XEXP (operands[1], 0), 0), 0));
Again, this should be moved to far_data_p().
Re: dwarf2 EH address size
DJ Delorie <[EMAIL PROTECTED]> writes:
> The m32c port has this:
>
> #define DWARF2_ADDR_SIZE 4
>
> However, dwarf2asm.c has this:
>
> int
> size_of_encoded_value (int encoding)
> {
> . . .
> case DW_EH_PE_absptr:
> return POINTER_SIZE / BITS_PER_UNIT;
>
> The net result is that the EH sections have 2 byte pointers for the
> m16c variant (HImode pointers), which screws up binutils, which is
> expecting 4. The m32c variant (PSImode pointers) is OK.
>
> Before I go hard-coding a "2" into binutils, I ask... is gcc supposed
> to honor DWARF2_ADDR_SIZE for absptr? What's the reasoning behind the
> way it is?
The EH code does seem to use POINTER_SIZE pretty consistently.
DWARF2_ADDR_SIZE is for the debug info, not the exception frame info.
I haven't looked into the history of why this is so.
Note that you can control this to use your preferred size by defining
ASM_PREFERRED_EH_DATA_FORMAT. Have it return, e.g., DW_EH_PE_sdata4
and all should be well.
Ian
