4.3 bootstrap broken on i386-linux
Hi all, My nightly bootstrap of mainline on i386-linux failed tonight, on revision 123192, with: /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ decLibrary.c: In function ?isinfd64?: /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ decLibrary.c:65: error: unrecognizable insn: (insn 11 10 12 3 /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../ libdecnumber/decLibrary.c:62 (set (reg/f:SI 61) (pre_dec:SI (reg/f:SI 7 sp))) -1 (nil) (nil)) /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ decLibrary.c:65: internal compiler error: in extract_insn, at recog.c: 2119 The last revision known to compile OK on that particular setup was: 123178. I filed it as PR 31344 in bugzilla. The compilation fails for -mtune=i[345]86 while it doesn't ICE for -mtune=i686. FX
RFC: integer division by multiply with invariant reciprocal
The strategy that the SHMEDIA port uses to do cse and loop invariant code motion for division by invariant reciprocal can in principle be used by any processor that has a reasonable fast instructions for count leading sign bits (can be substituted with count leading zero bits), widening or highpart multiply, and dynamic shifts, and that typically allows to add a few more pseudo registers without much cost (i.e. 32 GPRS, or efficient stack access like on x86). Basically, the division is split into an invariant computation which takes the divisor as input, and computes a denormalization shift count (SHIFT), an approximate reciprocal factor (INV1), and a reciprocal adjustment factor (INV2). The division is then performed by multiplying the INV2 with the dividend, shifting it right by a constant amount, subtracting that from (or adding to) the product of INV2 with the dividend, denormalize the result, and do an adjustment to take account oif different rounding for signed / unsigned results. The details of how to best compute SHIFT, INV1 and INV2, if INV2 has the same or opposite signe of INV2, and the constant shift count depend on the target instruction set and microarchitecture. However, not all processors are as good as the SH5 in computing the invariant values compared to how fast they can do a straight division; thus instead of chopping the division into multiple RTL pieces and then allowing any kind of CSE and PRE to rip them apart, we would like some finer control that requires a minimum number of divisions with the same divisor before this optimization is applied. Also, exposing this at the tree level will enable other optimizations to work better, e.g. they can make better unrolling decisions, and take advantage of the non-trapping nature of the division by multiply with reciprocal. The question is now how best to respresent the invariant operations as trees. We could have a special tree code for this, but then - It would eat up a tree code. - Producing three results at once, it is likely to be trouble for ssa transformations. Having a single built-in function for this purpose would avoid the tree code cost, but the we'd be faced with a three-valued built-in function. So I think that the easiest way to integrate this with the rest of the compiler is to have a target hook that emits trees to compute SHIFT, INV1 and INV2. These might use additional temporaries, and could use standard arithmetic and/or memory operations, machine-specific builtin functions, or a mixture of both; but any one tree expression would compute only one value. Emitting the computation of the actual division using SHIFT, INV1, INV2 is then done by a second target hook. The parameter for the minimum number of divisions with the same divisor to trigger this optimization should be separate from the one for floating point.
RE: -fkeep-inline-functions and broken Cygwin bootstrap (was: Building GCC 4.3.0 on Cygwin...)
On 25 March 2007 07:37, Andrew Pinski wrote:
> On 3/24/07, Brian Dessent <[EMAIL PROTECTED]> wrote:
>> Dave Korn wrote:
>>
>>> # 405 "/usr/include/stdio.h" 3 4
>>
>> [ Which is from newlib (libc/include/stdio.h) if anyone reading this
>> doesn't have a Cygwin system handy. ]
>>
>>> static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p) {
>>> [...]
>>>
>>> The critical difference is the presence or absence of
>>> -fkeep-inline-functions. I think I remember there being some change
>>> between gcc-3.x and gcc-4.x in inline handling and I think that's what's
>>> biting us now; I think this may only arise in stage1 where we're trying
>>> to use 3.x to compile 4.x.
>>
>> I too thought that this was related to the c99 inline changes, but I
>> think those only apply to "extern inline" which is not the case here.
>>
>> The real cause seems to be that -fkeep-inline-functions was a no-op up
>> until: , which
>> seems to roughly correspond to when bootstrap stopped working on Cygwin.
>>
>
> Actually it was not a no-op in 3.4, just 4.2 (or was it also broken in
> 4.1) broke -fkeep-inline-functions and nobody noticed until later.
> Cygwin's headers are broken with respect of -fkeep-inline-functions
> and need to be fixed.
This is the conclusion I came to. We certainly don't want to emit those
functions in libgcc's _ctors.o.
Eric Bocatzou added -fkeep-inline-functions while fixing PR18058
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058) for I assume was the
specific purpose of making these kinds of problems show up sooner rather than
later.
On 25 March 2007 07:33, Brian Dessent wrote:
> So it looks like we need to either stop using -fkeep-inline-functions
> for this file, change the definition to extern inline (or extern inline
> plus __attribute__((gnu_inline))? I'm still a little confused there),
> or link against -lcygwin. I kind of think the latter sounds wrong,
> since there really is no reason that these unused function bodies should
> end up in the .o file simply because it happens to have #include
> at the top.
Yeh, I'm a little confused too... or do we have to define a macro that gets
set to "static inline" or "extern inline" according to GNUC_xxx version tests?
cheers,
DaveK
--
Can't think of a witty .sigline today
Linking shared libs against shared libs
Hello everyone,
I'm trying to link a shared library against a shared library,
using gcc/ld on Linux and with code like this:
//
//
// test.c (shared library sourcecode)
//
extern int unknown_function(int value);
int testfunc(void)
{
return(unknown_function(0x77));
}
//
Compiling the sourcecode above like this:
gcc test.c -o test.so -shared -fPIC [-s]
The problem is that i'd expect gcc/ld to abort with an error,
but it just 'successfully' links something.
Am i missing something? How can ld link against a
definitely unknown function?
Tested on Debian-64 (amd64), using:
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Same problem on KNOPPIX 3 (x86-32), using:
gcc (GCC) 3.3.5 (Debian 1:3.3.5-3)
--
Cheers,
Oliver 'Bloody' Lange.
Re: Linking shared libs against shared libs
On Sun, Mar 25, 2007 at 07:18:16PM +0200, Oliver Lange wrote: > I'm trying to link a shared library against a shared library, > using gcc/ld on Linux and with code like this: This is really more of a linker question. Followups to [EMAIL PROTECTED], please. > Compiling the sourcecode above like this: > gcc test.c -o test.so -shared -fPIC [-s] > The problem is that i'd expect gcc/ld to abort with an error, > but it just 'successfully' links something. > Am i missing something? How can ld link against a > definitely unknown function? See the linker manual for "-z defs". -- Daniel Jacobowitz CodeSourcery
Does anybody know of testuites/testcases for shared library, dynamic loader, etc
I am looking for testcases for testing the following on interix:- 1: shared library support 2: dynamic loader ld.so working Are then any comprehensive testsuites available for the same ? Thanks Mayank
Re: RFC: integer division by multiply with invariant reciprocal
> So I think that the easiest way to integrate this with the rest of the
> compiler is to have a target hook that emits trees to compute SHIFT, INV1
> and INV2.
(define_tree_expand "name"
"condition"
{
preparation statements;
}
)
:-)
Re: Does anybody know of testuites/testcases for shared library, dynamic loader, etc
Mayank Kumar <[EMAIL PROTECTED]> writes: > I am looking for testcases for testing the following on interix:- > 1: shared library support > 2: dynamic loader ld.so working > > Are then any comprehensive testsuites available for the same ? It's hardly comprehensive, and some of the tests are ELF specific, but you could look at the linker testsuite in the GNU binutils. Ian
Re: [patch] generated string libraries & -Wformat
Joseph S. Myers wrote: > On Sat, 24 Mar 2007, Bruce Korb wrote: > >> This bootstraps in Linux i686 & I can use -Wno-format-contains-nul to >> suppress that warning. OK? > > This is not a complete patch submission, I await one with documentation > and testcases (both for the option disabling the diagnostic and for the > use of -Wformat-contains-nul being diagnosed just as other such "ignored > without" diagnostics are tested in gcc.dg/format/opt-*.c). But, you do think the option is useful overall, then, and that Bruce should proceed with the additional steps you mention? I have no opinion, but it might help Bruce to know for sure whether he's heading in a direction you're likely to approve. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Ian Lance Taylor wrote: > Ryan Hill <[EMAIL PROTECTED]> writes: >> Was there ever any action on this? AFAICS consensus was that the trap >> would be removed and this behaviour be documented as an extension. >> There was a bit more discussion of how exactly the documentation would >> be worded[i] and the thread petered out. Fast forwarding to today the >> abort is still present and the 4.2 branch (4.2.0-pre20070317 (rev. >> 123016)) is still unable to build a working openssl (0.9.8e). > I don't think anything happened with this. > > Is there a gcc bug report open about it? If so, Mark can bump up the > priority. I couldn't find one so I've filed PR #31359. Apologies if it's a duplicate. -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
Re: GCC 4.2.0 Status Report (2007-03-22)
Joseph S. Myers wrote:
> On Thu, 22 Mar 2007, Mark Mitchell wrote:
>
>> Joseph, would you please take a look at PR 31136? Andrew believes this
>> to be a front-end bug.
>
> I don't think this is a front-end bug.
Thank you for investigating.
> (OK to commit this patch to mainline
> subject to the usual testing?)
Yes.
> Index: tree-pretty-print.c
> ===
> --- tree-pretty-print.c (revision 123147)
> +++ tree-pretty-print.c (working copy)
> @@ -539,6 +539,14 @@
> dump_generic_node (buffer, TREE_TYPE (node),
> spc, flags, false);
> }
> + else if (TREE_CODE (node) == INTEGER_TYPE)
> + {
> + pp_string (buffer, (TYPE_UNSIGNED (node)
> + ? " + : " + pp_decimal_int (buffer, TYPE_PRECISION (node));
> + pp_string (buffer, ">");
> + }
> else
>pp_string (buffer, "");
> }
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
On 3/25/07, Ryan Hill <[EMAIL PROTECTED]> wrote: I couldn't find one so I've filed PR #31359. Apologies if it's a duplicate. I will again say, "undocumented extensions" don't exist (except for the case where the documentation is in the source and this was not one of those cases). This was just accidently working before and now it does not work the way you expected it to work. Well considering this undefined bevahior, I think openssl should just fix their code. It is not like this was a documented extension to begin with, it just was accident the behavior changed to be more like what the behavior should have been to begin with. If you want working code, then write in C and not some language which you think is C (yes GNU C has extensions and some of them are not well thought out or documented, does not mean we will add new ones or make a current behavior of GCC defined for good, another good example of where this comes up is from signed integer overflow or aliasing rules). But in this example, we already have a warning at the same time we cause a trap. I think really openssl should not depend on undefined behavior in general to be portable anyways. Even if we make this an extension, some other compiler might decide this code should break in the same way as it is right now as the behavior is undefined. -- Pinski
Re: RFC: integer division by multiply with invariant reciprocal
On 3/25/07, Charles J. Tabony <[EMAIL PROTECTED]> wrote: > So I think that the easiest way to integrate this with the rest of the > compiler is to have a target hook that emits trees to compute SHIFT, INV1 > and INV2. I don't think target hooks to expand trees early is a good idea. RTL is not going away, and in fact GCC's model having two IR is not unique to GCC, XLC uses that model also. Thanks, Andrew Pinski
Re: RFC: integer division by multiply with invariant reciprocal
On Sun, 2007-03-25 at 22:24 -0700, Andrew Pinski wrote: > On 3/25/07, Charles J. Tabony <[EMAIL PROTECTED]> wrote: > > > So I think that the easiest way to integrate this with the rest of the > > > compiler is to have a target hook that emits trees to compute SHIFT, INV1 > > > and INV2. > > I don't think target hooks to expand trees early is a good idea. RTL > is not going away, and in fact GCC's model having two IR is not unique > to GCC, XLC uses that model also. AMEN! Jeff
gcc4.1 compilation issue on solaris 10
I am trying to build gcc with java support on solaris 10 I am getting lot of errors While compiling libjava.I am getting lot of errors for headers error: global qualification of class name is invalid before ':' token for all the header files ..seems to me some issue in Makefile which was used to generate the header files. Can anybody please let me know how to get around this issue. Thanks, Nitesh This e-mail is bound by the terms and conditions described at http://www.subexazure.com/mail-disclaimer.html
Re: A question on ACX_BUGURL
> + no) BUGURL="";
just BUGURL= (no useless trailing semicolon).
> + case ${BUGURL} in
Please quote this as "$BUGURL".
> +REPORT_BUGS_TO="<$BUGURL>"
> +REPORT_BUGS_TEXI="@uref{`echo $BUGURL | sed 's/@/@@/g'`}"
Please do this instead:
[EMAIL PROTECTED] "$BUGURL" | sed 's/@/@@/g'`}
as suggested by Andreas. Quoting is "less" necessary in variable
assignments (it is still necessary for REPORT_BUGS_TO because
of the less-than/greater-than signs).
Otherwise seems okay, but please resubmit.
Paolo
Re: SoC Project: Propagating array data dependencies from Tree-SSA to RTL
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 25/03/2007 05:19:41: > On 3/23/07, Alexander Monakov <[EMAIL PROTECTED]> wrote: > > Hello, > > > > > > I would be pleased to see Ayal Zaks as my mentor, because proposed > > improvement is primarily targeted as modulo scheduling improvement. In > > case this is not possible, I will seek guidance from Maxim Kuvyrkov. > > > Ayal has not signed up to be a mentor (as of yet). If he doesn't, i'd > be happy to mentor you here, since i wrote part of tree-data-ref.c Sorry, I fear I may have too little time to devote to this; plus, it would be very useful to start with a good understanding of tree-data-ref from which to start propagating the dep info. Vladimir Yanovsky and I will be able to help when it comes to what/how to feed the modulo scheduler. Thanks, Ayal.
