RE: [help-texinfo] Re: small font in gcc online docs
Hi Manuel, Karl, Thank you for your replies. [...] > You are expecting that the CSS large/small/x-small/etc match those of > TeX. They are not matched. I don't know what formula TeX uses but > Firefox uses a lookup table that is available here: > > http://mxr.mozilla.org/mozilla/source/layout/style/nsStyleUtil.cpp#165 > > As you can see, for a medium font of 12 or 13 (which is the default > size in Firefox), the small font is 10. There is a bug opened about > this, but it doesn't seem to have attracted much interest. Perhaps you > could explain the issue there and give them some motivation to fix > this once and for all: > > https://bugzilla.mozilla.org/show_bug.cgi?id=187256 Ok, I've added a comment to the bug. It's already been open for six years, so I hope for a Firefox fix in due course.. I had to post the mail-archive link to the thread, as the gcc.gnu.org one doesn’t have any way to see the conversation tree, or even "[Next reply]" links atm, not sure if the InResponseToID changed or something. http://gcc.gnu.org/ml/gcc/2008-10/msg00391.html Kind regards, Jon
Re: [EMAIL PROTECTED]: Results for 4.4.0 20081106 (experimental) [trunk revision 141636] (GCC) testsuite on m32c-unknown-elf]
Hi, On Thu, Nov 06, 2008 at 04:01:13PM -0500, DJ Delorie wrote: > > This new failure seems to have been caused by r141613: > > +2008-11-05 Martin Jambor <[EMAIL PROTECTED]> > + > + PR middle-end/37861 > + * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Don't turn > + pointer arithmetics into array_ref if the array is accessed > + through an indirect_ref. > + > > The m32c-elf target is notoriously picky about getting pointer math > "right" (pointers are 24 bits, not 16 or 32), anyone fiddling with > pointer/array addressing stuff should probably test it to see if it > breaks anything. I only inhibited one particular fwprop action if one particular condition is met. I was slightly afraid of some generated code quality regressions but it should not have really broken anything. > Martin, can you see if you can reproduce this, and verify whether your > change broke it or not? Or if it's something in m32c that your change > expects to be configured differently? My knowledge of backend and RTL in general is very limited and I have no clue what m32c-elf architecture is and don't seem to have access to any such system. >From the logs I see that the testsuite probably uses a cross-compiled gcc? How do you configure gcc to get such a beats? If I manage to reproduce it, I can have a look at what differences in the IR I caused and where that breaks but that all depends on how much my limited RTL knowledge allows me to find out... Martin
Re: [EMAIL PROTECTED]: Results for 4.4.0 20081106 (experimental) [trunk revision 141636] (GCC) testsuite on m32c-unknown-elf]
> My knowledge of backend and RTL in general is very limited and I have > no clue what m32c-elf architecture is and don't seem to have access to > any such system. m32c-elf is one of the many embedded (i.e. cross-compiled) targets which has a simulator. You don't need to have access to physical hardware. See: http://gcc.gnu.org/install/specific.html http://gcc.gnu.org/backends.html > From the logs I see that the testsuite probably uses a > cross-compiled gcc? How do you configure gcc to get such a beast? Like any other cross compiler: ./configure --target=m32c-elf --with-newlib Note that you'll have to build (and install, of course) a cross-binutils first, then build a cross-gcc (libgcc will fail to build), then cross-build and install newlib, then build cross-gcc again (it will work this time) and install it. To get the simulator, you then build a cross-gdb.
Re: [EMAIL PROTECTED]: Results for 4.4.0 20081106 (experimental) [trunk revision 141636] (GCC) testsuite on m32c-unknown-elf]
Hi,
On Fri, Nov 07, 2008 at 01:05:43PM -0500, DJ Delorie wrote:
>
> Note that you'll have to build (and install, of course) a
> cross-binutils first, then build a cross-gcc (libgcc will fail to
> build), then cross-build and install newlib, then build cross-gcc
> again (it will work this time) and install it.
>
Sounds rather complicated, I guess will want to do something like that
one day. However, certainly not today. I thought about the PR37861
again, about associated PR31982 (big thanks to Andrew Pinski who
pointed me to it) and about the regression you discovered and came to
these conclusions:
1. The regression is most probably "caused" by my patch but the gimple
it leads to is (as far as I can tell) valid and so the target may
bump into this problem at some other time. I am sorry but I do not
have the knowledge to be bale to help with fixing it.
2. I might actually be less restrictive in my approach. I've come up
with the following patch which undoes my previous one and adds a
different restriction which also fixes PR37861, does not break
PR31982 and should fix the particular test-case you see regressing
(however, it is possible that the bug might be triggered in some
other way, regardless of my patches). On the other hand, it is a
bit clumsy and not very systematic :-( I am currently bootstrapping
and testing it (on x86_64) and will send it to gcc-patches for
discussion/approval on Monday (or Tuesday) if there are no new
regressions.
If you get a chance, can you please test it for me on the affected
arch?
Thanks,
Martin
2008-11-07 Martin Jambor <[EMAIL PROTECTED]>
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Do not check
for INDIRECT_REFs.
(forward_propagate_addr_into_variable_array_index): Check that the
offset is not computed from a MULT_EXPR, use is_gimple_assign rather
than the gimple code directly.
Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 141673)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -613,19 +613,27 @@ forward_propagate_addr_into_variable_arr
tree index;
gimple offset_def, use_stmt = gsi_stmt (*use_stmt_gsi);
- /* Try to find an expression for a proper index. This is either
- a multiplication expression by the element size or just the
- ssa name we came along in case the element size is one. */
+ /* Get the offset's defining statement. */
+ offset_def = SSA_NAME_DEF_STMT (offset);
+
+ /* Try to find an expression for a proper index. This is either a
+ multiplication expression by the element size or just the ssa name we came
+ along in case the element size is one. In that case, however, we do not
+ allow multiplications because they can be computing index to a higher
+ level dimension (PR 37861). */
if (integer_onep (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (def_rhs)
-index = offset;
- else
{
- /* Get the offset's defining statement. */
- offset_def = SSA_NAME_DEF_STMT (offset);
+ if (is_gimple_assign (offset_def)
+ && gimple_assign_rhs_code (offset_def) == MULT_EXPR)
+ return false;
+ index = offset;
+}
+ else
+{
/* The statement which defines OFFSET before type conversion
must be a simple GIMPLE_ASSIGN. */
- if (gimple_code (offset_def) != GIMPLE_ASSIGN)
+ if (!is_gimple_assign (offset_def))
return false;
/* The RHS of the statement which defines OFFSET must be a
@@ -802,9 +810,6 @@ forward_propagate_addr_expr_1 (tree name
array_ref = TREE_OPERAND (def_rhs, 0);
if (TREE_CODE (array_ref) != ARRAY_REF
|| TREE_CODE (TREE_TYPE (TREE_OPERAND (array_ref, 0))) != ARRAY_TYPE
- /* Avoid accessing hidden multidimensional arrays in this way or VRP
-might give out bogus warnings (see PR 37861) */
- || TREE_CODE (TREE_OPERAND (array_ref, 0)) == INDIRECT_REF
|| !integer_zerop (TREE_OPERAND (array_ref, 1)))
return false;
gcc-4.4-20081107 is now available
Snapshot gcc-4.4-20081107 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081107/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 141691 You'll find: gcc-4.4-20081107.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20081107.tar.bz2 C front end and core compiler gcc-ada-4.4-20081107.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20081107.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20081107.tar.bz2 C++ front end and runtime gcc-java-4.4-20081107.tar.bz2 Java front end and runtime gcc-objc-4.4-20081107.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20081107.tar.bz2The GCC testsuite Diffs from 4.4-20081031 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [EMAIL PROTECTED]: Results for 4.4.0 20081106 (experimental) [trunk revision 141636] (GCC) testsuite on m32c-unknown-elf]
> 2008-11-07 Martin Jambor <[EMAIL PROTECTED]> > > * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Do not check > for INDIRECT_REFs. > (forward_propagate_addr_into_variable_array_index): Check that the > offset is not computed from a MULT_EXPR, use is_gimple_assign rather > than the gimple code directly. That test passes with this patch.
