Re: GNAT mysterious "missing stub for subunit" error.
On Tue, 2009-09-08 at 07:21 +0100, Dave Korn wrote: > EH_MECHANISM=-gcc I don't think this is correct for windows targets: EH_MECHANISM must be left to its original empty definition to get sjlj exceptions which are the only one working on windows IIRC. Sincerely, Laurent
Trunk in regular stage1 again
On Thu, 3 Sep 2009, Richard Guenther wrote: > As we've got quite some build problems on some targets and we clashed > with VTA, free-lang-data, expand and scheduler changes it's a good > time to slush the trunk for a short time. > > Thus, starting from now the trunk is in regression and documentation > fixes only mode. > > Please help sorting out issues on your targets. We're back in a reasonable state. The trunk is open under the usual stage1 rules again. Richard.
hppa testsuite stalls?
Hi, the testsuite on the hppa machine (gcc61 on the compile farm) has always hanged for me from time to time. However, lately (at least since I returned from vacation last Monday) it hangs every time. I have the compiler configured for c and c++ only, without bootstrap. I run the testsuite without the -j flag, so there should be just a single thread. Since I started looking at where this happens it has always hanged when running the libstdc++ testsuite, albeit at a different place in that suite (as far as the log file tells, the last few lines from the libstc++.log of one such run file are below but don't reveal much). This is revision 151323. Is this a know problem? How should I investigate such problems? It makes proper testing on that platform rather impossible for me. Thanks, Martin Executing on host: /home/jamborm/gcc/trunk/obj/./gcc/g++ -shared-libgcc -B/home/jamborm/gcc/trunk/obj/./gcc -nostdinc++ -L/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/libstdc++-v3/src -L/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/jamborm/gcc/inst/trunk/hppa2.0-unknown-linux-gnu/bin/ -B/home/jamborm/gcc/inst/trunk/hppa2.0-unknown-linux-gnu/lib/ -isystem /home/jamborm/gcc/inst/trunk/hppa2.0-unknown-linux-gnu/include -isystem /home/jamborm/gcc/inst/trunk/hppa2.0-unknown-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/libstdc++-v3/include/hppa2.0-unknown-linux-gnu -I/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/libstdc++-v3/include -I/home/jamborm/gcc/trunk/libstdc++-v3/libsupc++ -I/home/jamborm/gcc/trunk/libstdc++-v3/include/backward -I/home/jamborm/gcc/trunk/libstdc++-v3/testsuite/util /home/jamborm/gcc/trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoul.cc -std=gnu++0x ./libtestc++.a -Wl,--gc-sections -lm -o ./stoul.exe (timeout = 600) PASS: 21_strings/basic_string/numeric_conversions/wchar_t/stoul.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/home/jamborm/gcc/trunk/obj/gcc:/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/./libstdc++-v3/src/.libs::/home/jamborm/gcc/trunk/obj/gcc:/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/libstdc++-v3/.libs:/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/libmudflap/.libs:/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/libssp/.libs:/home/jamborm/gcc/trunk/obj/hppa2.0-unknown-linux-gnu/libgomp/.libs:/home/jamborm/gcc/trunk/obj/./gcc:/home/jamborm/gcc/trunk/obj/./prev-gcc PASS: 21_strings/basic_string/numeric_conversions/wchar_t/stoul.cc execution test got a INT signal, interrupted by user === libstdc++ Summary === # of expected passes782 # of unexpected failures1 # of expected failures 26 # of unsupported tests 10 runtest completed at Mon Sep 7 16:04:28 2009
question about DSE
Dear all,
Im writing to you regarding the dead store elimination (dse) which runs after
register allocation. Apparently dse removes wrongly the following store
(present in bb2):
(insn 374 47 52 2 test.c:107 (set (mem/c:SI (plus:PSI (reg/f:PSI 55 ptr15)
(const_int 96 [0x60])) [19 fac_iter+0 S4 A32])
(reg/v:SI 16 r16 [orig:161 step109 ] [161])) 48
{si_indexed_store_incl_ra} (nil))
despite being consumed (in bb3) by the following 2 loads:
(insn 380 71 64 3 test.c:112 (set (reg:HI 1 r1)
(mem:HI (plus:PSI (reg/f:PSI 55 ptr15)
(const_int 96 [0x60])) [0 S2 A16])) 12 {load} (nil))
(insn 382 346 65 3 test.c:112 (set (reg:HI 5 r5)
(mem:HI (plus:PSI (reg/f:PSI 55 ptr15)
(const_int 98 [0x62])) [0 S2 A16])) 12 {load} (nil))
Can anyone point what may be the problem?
As you can see the store is SI while the loads are HI. While looking to the
comments from dse.c I get to the following remark:
" There are three cases where dse falls short:
a) Reload sometimes creates the slot for one mode of access, and
then inserts loads and/or stores for a smaller mode. "
Does it mean that such cases are not treated properly by dse?
I observed that if I run with the flag -fno-strict-aliasing the wrongly removed
store is no longer removed and the code is runs correctly.
Im wondering does the dse after register allocation make use of type based
alias analysis?
reagards,
Alex
Re: question about DSE
Alex Turjan wrote:
> Dear all,
> Im writing to you regarding the dead store elimination (dse) which runs after
> register allocation. Apparently dse removes wrongly the following store
> (present in bb2):
>
> (insn 374 47 52 2 test.c:107 (set (mem/c:SI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 96 [0x60])) [19 fac_iter+0 S4 A32])
> (reg/v:SI 16 r16 [orig:161 step109 ] [161])) 48
> {si_indexed_store_incl_ra} (nil))
>
> despite being consumed (in bb3) by the following 2 loads:
> (insn 380 71 64 3 test.c:112 (set (reg:HI 1 r1)
> (mem:HI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 96 [0x60])) [0 S2 A16])) 12 {load} (nil))
>
> (insn 382 346 65 3 test.c:112 (set (reg:HI 5 r5)
> (mem:HI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 98 [0x62])) [0 S2 A16])) 12 {load} (nil))
>
>
> Can anyone point what may be the problem?
>
> As you can see the store is SI while the loads are HI. While looking to the
> comments from dse.c I get to the following remark:
>
> " There are three cases where dse falls short:
> a) Reload sometimes creates the slot for one mode of access, and
> then inserts loads and/or stores for a smaller mode. "
>
> Does it mean that such cases are not treated properly by dse?
>
> I observed that if I run with the flag -fno-strict-aliasing the wrongly
> removed store is no longer removed and the code is runs correctly.
> Im wondering does the dse after register allocation make use of type based
> alias analysis?
Here's part of the comment in alias.c:
/* The alias sets assigned to MEMs assist the back-end in determining
which MEMs can alias which other MEMs. In general, two MEMs in
different alias sets cannot alias each other ...
There's a lot more information in the comments there.
Andrew.
Re: question about DSE
Hi,
On Tue, 8 Sep 2009, Alex Turjan wrote:
> (insn 374 47 52 2 test.c:107 (set (mem/c:SI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 96 [0x60])) [19 fac_iter+0 S4 A32])
> (reg/v:SI 16 r16 [orig:161 step109 ] [161])) 48
> {si_indexed_store_incl_ra} (nil))
An SI store to a MEM of alias set 19 (and a non-trapping while we're at
it, the /c marker on the MEM) ...
> despite being consumed (in bb3) by the following 2 loads:
> (insn 380 71 64 3 test.c:112 (set (reg:HI 1 r1)
> (mem:HI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 96 [0x60])) [0 S2 A16])) 12 {load} (nil))
>
> (insn 382 346 65 3 test.c:112 (set (reg:HI 5 r5)
> (mem:HI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 98 [0x62])) [0 S2 A16])) 12 {load} (nil))
... and two HI loads of MEMs of alias set 0. This should be fine as set 0
aliases with everything. Either you need to open a bugreport with
necessary patches to reproduce the above, or make it reproduce on trunk,
or you need to debug dse.c yourself.
There is one peculiarity about dse.c which might be able to help you in
determining the cause. dse.c operates under the assumption that all spill
slot accesses generated by reload are using exactly the same alias set and
that any such slot is completely unaliased by anything else including
stuff with alias set 0. This is done only by the after-reload dse pass.
See functions dse_record_singleton_alias_set and friends. Your loads
should kill the active stores in function check_mem_read_rtx should you
need to debug it that far.
My assumption would be these two split loads of HImode are generated by
your backend from a given SImode MEM. If so, you need to make sure to
copy the MEM_ALIAS_SET, at least for spill slots (better for everything)
into the newly generated HImode mems. For spill slots it's not enough to
set it to zero.
Ciao,
Michael.
Re: GNAT mysterious "missing stub for subunit" error.
Laurent GUERBY wrote: > On Tue, 2009-09-08 at 07:21 +0100, Dave Korn wrote: >> EH_MECHANISM=-gcc > > I don't think this is correct for windows targets: > EH_MECHANISM must be left to its original empty > definition to get sjlj exceptions which are the only > one working on windows IIRC. I was planning to do whatever's needed to make it work on windows. I don't think this line cause the build failure, because it certainly appeared to work, when I tried it on 4.3.2 (without all the other changes to the target pair list); but for some reason the same trick isn't working on 4.3.4. cheers, DaveK
Re: GNAT mysterious "missing stub for subunit" error.
> I was planning to do whatever's needed to make it work on windows. I > don't think this line cause the build failure, because it certainly > appeared to work, when I tried it on 4.3.2 (without all the other changes > to the target pair list); but for some reason the same trick isn't working > on 4.3.4. I'd do things step by step, i.e. first try to have a full cygwin port without changing the EH mechanism, then change it. -- Eric Botcazou
Re: GNAT mysterious "missing stub for subunit" error.
Eric Botcazou wrote: >> I was planning to do whatever's needed to make it work on windows. I >> don't think this line cause the build failure, because it certainly >> appeared to work, when I tried it on 4.3.2 (without all the other changes >> to the target pair list); but for some reason the same trick isn't working >> on 4.3.4. > > I'd do things step by step, i.e. first try to have a full cygwin port without > changing the EH mechanism, then change it. > That's what I am doing, kind of, just the other way round. In 4.3.2 I compiled the existing port and switched it over to ZCX, and it worked well enough to pass most of the testsuite, including EH. Now I'm changing the target pairs on top of that and suddenly it's complaining, which is why I'm confused; I thought that bit was stable. Guess I could try backing out the EH changes and seeing what happens. Still don't understand what the compiler's trying to tell me is wrong though. cheers, DaveK
Re: GNAT mysterious "missing stub for subunit" error.
> That's what I am doing, kind of, just the other way round. In 4.3.2 I > compiled the existing port and switched it over to ZCX, and it worked well > enough to pass most of the testsuite, including EH. Now I'm changing the > target pairs on top of that and suddenly it's complaining, which is why I'm > confused; I thought that bit was stable. Your .diff contains this + EH_MECHANISM=-gcc so it looks as though the base compiler was SJLJ. -- Eric Botcazou
Re: make bootstrap and make not working for gcc-4.4.1
With the addition of the definition the LD_LIBRARY_PATH, the configuration, make bootstrap, make and make install worked. Thanks to everyone that gave me suggestions. On Sep 5, 2009, at 12:48 PM, Dave Korn wrote: Margaret Doll wrote: I was following the instructions on the build from http://gcc.gnu.org/java/build-snapshot.html 5. Compile and install gcc/gcj/libgcj $ cd compile $ mkdir objdir $ cd objdir $ ../gcc/configure --enable-threads=posix --prefix=/home/joerg/gcc \ --enable-shared --enable-languages=c++,java \ --with-as=/opt/gnu/ bin/as --with-ld=/opt/gnu/bin/ld $ make bootstrap $ make $ make install ? I thought we weren't supposed to use "make bootstrap" any more, that it was the default you got from just running plain "make". I'd omit the "make bootstrap" and just go straight to the next line. cd /usr/local/gcc-4.1.1 ./configure ends in the error that I have the wrong version of mpfr.h. I am using mpfr-2.4.1. The error log says that I should be using mpfr 2.3.2+ Possibly you have an old version lying around and it's finding it first? Does it help if you add a suitable --with-mpfr= option? Otherwise you may have to reproduce the failing autoconf test to figure out why it thinks you have an outdated mpfr header. cheers, DaveK
Re: GNAT mysterious "missing stub for subunit" error.
Eric Botcazou wrote: >> That's what I am doing, kind of, just the other way round. In 4.3.2 I >> compiled the existing port and switched it over to ZCX, and it worked well >> enough to pass most of the testsuite, including EH. Now I'm changing the >> target pairs on top of that and suddenly it's complaining, which is why I'm >> confused; I thought that bit was stable. > > Your .diff contains this > > + EH_MECHANISM=-gcc > > so it looks as though the base compiler was SJLJ. > Ah, bingo! Thanks Eric; yes, I have a recent build of an SJLJ Gnat from HEAD lying around my PATH ahead of my old 4.3.2-with-ZCX. Getting that out of the way should help! cheers, DaveK
Re: i370 port
I understand current GCC supports various source and target character
sets a lot better out of the box, so it may be EBCDIC isn't even an
issue any more. If there are other problems related to MVS host
I think the EBCDIC support is largely theoretical and not tested on any
actual EBCDIC host (or target). cpplib knows the character set name
UTF-EBCDIC, but whenever it does anything internally that involves the
encoding of its internal character set it uses UTF-8 rules (which is not
something valid to do with UTF-EBCDIC).
Results are finally in.
EBCDIC (or arbitrary character set) support was introduced in 3.4.6,
and continues to be the same today, correct?
I've just succeeded today in getting gcc 3.4.6 to self-compile on an
EBCDIC host. :-) That's after a gcc 3.4.6 ascii to ebcdic cross-compile.
It's fascinating to look back at what it took. Note that there are still
some relatively minor cleanups I have yet to do, but it won't change
much.
Caveats:
1. The generated (from machine definition) files are still generated on
the PC.
2. I am unable to do an optimized compile even as a cross-compile,
I get an internal error in this function:
gcse.c:
static void
compute_hash_table_work (struct hash_table *table)
{
...
if (!current_bb) /* +++ why are we getting NULL here? */
{
printf("internal error in gcse\n");
exit(EXIT_FAILURE);
}
FOR_EACH_BB (current_bb)
and indeed, I can't see anything that would initialize that current_bb,
so it's not that surprising that it's NULL!
3. As with gcc 3.2.3, the compiler is still producing slightly different
results on the PC vs mainframe, probably still because of floating
point comparisons being done to select the next register to use
or something like that.
4. There is one thing that doesn't have proper ASCII to EBCDIC
translation being done - the __FUNCTION__ builtin.
So here is the code generated on the PC:
COPY PDPTOP
CSECT
* Program text area
@@V1 EQU *
DCX'78'
DCX'31'
DCX'32'
DCX'33'
DCX'0'
LC0 EQU *
DCC'%s %d %s'
DCX'15'
DCX'0'
LC1 EQU *
DCC'zatest.c'
DCX'0'
DS0F
* X-func x123 prologue
X123 PDPPRLG CINDEX=0,FRAME=104,BASER=12,ENTRY=YES
B FEN0
LTORG
FEN0 EQU *
DROP 12
BALR 12,0
USING *,12
PG0 EQU *
LR11,1
L 10,=A(PGT0)
* Function x123 code
MVC 88(4,13),=A(LC0)
MVC 92(4,13),=A(LC1)
MVC 96(4,13),=F'5'
MVC 100(4,13),=A(@@V1)
LA1,88(,13)
L 15,=V(PRINTF)
BALR 14,15
* Function x123 epilogue
PDPEPIL
* Function x123 literal pool
DS0F
LTORG
* Function x123 page table
DS0F
PGT0 EQU *
DCA(PG0)
END
for this source:
#include
void x123(void)
{
printf("%s %d %s\n", __FILE__, __LINE__, __FUNCTION__);
}
However, that anomaly is not integral to getting the compiler on the
mainframe, and once on the mainframe, the problem goes away
with the next pass. :-)
I think the problem is this function:
c-decl.c:
c_make_fname_decl (tree id, int type_dep)
needs to call cpp_interpret_string or something like that to get
converted into EBCDIC.
There's not that much mainline code that needs to be changed.
You can see for youself here:
http://rapidshare.com/files/277287822/gccnew-beta51.zip
The file is 250k compressed containing diffs, but most of them are
simply the generated files (which appear as new). Here are the
real file changes:
diff -c gccnew/gcc/builtins.c:1.1.1.1 gccnew/gcc/builtins.c:1.3
diff -c gccnew/gcc/c-common.c:1.1.1.1 gccnew/gcc/c-common.c:1.2
diff -c gccnew/gcc/c-incpath.c:1.1.1.1 gccnew/gcc/c-incpath.c:1.3
diff -c gccnew/gcc/c-opts.c:1.1.1.1 gccnew/gcc/c-opts.c:1.2
diff -c gccnew/gcc/c-parse.c:1.1.1.1 gccnew/gcc/c-parse.c:1.5
diff -c gccnew/gcc/c-pch.c:1.1.1.1 gccnew/gcc/c-pch.c:1.3
diff -c gccnew/gcc/cppcharset.c:1.1.1.1 gccnew/gcc/cppcharset.c:1.6
diff -c gccnew/gcc/cpperror.c:1.1.1.1 gccnew/gcc/cpperror.c:1.2
diff -c gccnew/gcc/cppfiles.c:1.1.1.1 gccnew/gcc/cppfiles.c:1.7
diff -c gccnew/gcc/cpplib.h:1.1.1.1 gccnew/gcc/cpplib.h:1.2
diff -c gccnew/gcc/cppmacro.c:1.1.1.1 gccnew/gcc/cppmacro.c:1.2
diff -c gccnew/gcc/cppspec.c:1.1.1.1 gccnew/gcc/cppspec.c:1.3
diff -c gccnew/gcc/gcc.c:1.1.1.1 gccnew/gcc/gcc.c:1.6
diff -c gccnew/gcc/gcc.h:1.1.1.1 gccnew/gcc/gcc.h:1.2
diff -c gccnew/gcc/gcov-io.c:1.1.1.1 gccnew/gcc/gcov-io.c:1.2
diff -c gccnew/gcc/gcov-io.h:1.1.1.1 gccnew/gcc/gcov-io.h:1.2
diff -c gccnew/gcc/gcse.c:1.1.1.1 gccnew/gcc/gcse.c:1.3
diff -c gccnew/gcc/hwint.h:1.1.1.1 gccnew/gcc/hwint.h:1.2
diff -c gccnew/gcc/longlong.h:1.1.1.1 gccnew/gcc/longlong.h:1.2
diff -c gccnew/gcc/opts.c:1.1.1.1 gccnew/gcc/opts.c:1.2
diff -c gccnew/gcc/opts.h:1.1.1.1 gccnew/gcc/opts.h:1.3
diff -c gccnew/gcc/opts.sh:1.1.1.1 gccnew/gcc/opts.sh:1.1.1.2
diff -c gccnew
Re: hppa testsuite stalls?
On Tue, Sep 08, 2009 at 09:31:14AM -0700, Steve Ellcey wrote: > Is gcc61 running HP-UX or Linux? I haven't seen any hangs in > my hppa HP-UX testing. I don't do any hppa Linux testing. > I guess I should have specified that. It indeed does run Linux. Thanks, Martin
Re: hppa testsuite stalls?
Is gcc61 running HP-UX or Linux? I haven't seen any hangs in my hppa HP-UX testing. I don't do any hppa Linux testing. Steve Ellcey s...@cup.hp.com
The Linux binutils 2.20.51.0.1 is released
This is the beta release of binutils 2.20.51.0.1 for Linux, which is
based on binutils 2009 0905 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.20.51.0.1 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.19.51.0.14:
1. Update from binutils 2009 0905.
2. Add Intel L1OM support.
3. Add MicroBlaze support.
4. Fix assembler for DWARF info without .file/.loc directives. PR 10531.
5. Improve -pie with TLS relocations on ia32 and x86-64. PRs 6443/10434.
6. Fix linker page size support. PR 10569.
7. Fix wildcard in linker version script. PR 10518.
8. Fix strip with STB_GNU_UNIQUE. PR 10492.
9. Fix strip on unwriteable files. PR 10364.
10. Fix crash with "ld --build-id /usr/lib/libc.a". PR 10555.
11. Fix linker for Linux kernel build. PR 10429.
12. Support string merge on .comment section.
13. Improve build with C++ compiler.
14. Improve gold.
15. Improve arm support.
16. Improve bfin support.
11. Improve m32c support.
17. Improve m68k support.
18. Improve mep support.
19. Improve mips support.
20. Improve ppc support.
21. Improve spu support.
22. Improve xtensa support.
Changes from binutils 2.19.51.0.13:
1. Update from binutils 2009 0722.
2. Fix linker for STT_GNU_IFUNC symbols in static executables. PR 10433.
3. Fix linker bug for Linux kernel build. PR 10429.
Changes from binutils 2.19.51.0.12:
1. Update from binutils 2009 0721.
2. Fix linker for undefined STT_GNU_IFUNC symbols. PR 10426.
3. Fix x86 assembler for nops in 64bit. PR 10420.
4. Add a new option, --insn-width, to objdump.
5. Improve arm support.
6. Improve mips support.
7. Improve gold support.
Changes from binutils 2.19.51.0.11:
1. Update from binutils 2009 0716.
2. Fix x86 assembler for jumping to local STT_GNU_IFUNC symbols.
3. Fix x86 linker for relocatable link with local STT_GNU_IFUNC symbols.
4. Implement ppc STT_GNU_IFUNC support.
5. Support x86 FMA4.
6. Fix linker regression with Linux kernel build.
7. Support unordered references in DWARF reader.
8. Improve PE/COFF support.
8. Improve arm support.
9. Improve m10300 support.
10. Improve ppc support.
11. Improve spu support.
12. Improve gold support.
Changes from binutils 2.19.51.0.10:
1. Update from binutils 2009 0627.
2. Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337.
3. Add STB_GNU_UNIQUE support.
4. Fix objcopy o
Re: conditional gcov instrumentation
On 09/07/2009 08:28 PM, Hayawardh V wrote:
+ gcov_ctr_fn_type = build_function_type_list(void_type_node,
gcov_type_ptr, NULL_TREE);
+
+ decl = build_decl(FUNCTION_DECL, get_identifier("__gcov_ctr"),
gcov_ctr_fn_type);
Well you certainly don't want to be generating a
different function decl for every edge you instrument.
r~
No c++0x threads using win32 threading model (with MinGW-w64)
Hello, (first of all: sorry to post this message to a second list, I've sent it to the wrong list at first) I am using g++ in MinGW-w64 running in a Windows environment. I'm especially interested in the c++0x threads because it allows standard cross-platform multi-threading. Unfortunately I didn't get this to work (using a very recent Mingw-w64 snapshot that uses gcc 4.5.0). I did some research and I think I found out why. Perhaps somebody on this list could confirm this and/or answer some of the questions I have about the win32 threading model. First of all, the c++0x threads don't seem to work because in the `thread' header file the file `gthr.h' is included, which includes in turn some threading model specific files (like `gthr_posix.h'). While the header `gthr_win32.h' does exist, it is not included from `gthr.h'. The comments in `gthr.h' further mention support for several threading models, but the win32 threading model is not amongst these. Am I looking in the right direction for reasons why the c++0x threads do not work with the win32 threading model? If the above is correct: is support for win32 c++0x threads being worked on at the moment? If that is the case, any indication when it will be in a usable state? What must be undertaken to implement this support? I hope somebody can give me some insight in these questions. Regards, Heiko
Re: Large slowdown with gfortran vs f77 (x7)
> "Jeremy" == Jeremy Sanders writes: Jeremy> You can see the very large speed differences by telling gfortran Jeremy> to always use double precision numbers. Jeremy> This can be replicated with this simple program: Jeremy> Compiled with gfortran -O2: Jeremy> real0m29.921s Jeremy> user0m29.912s Jeremy> sys 0m0.000s Jeremy> Compiled with gfortran -O2 -fdefault-real-8: Jeremy> real0m4.306s Jeremy> user0m4.304s Jeremy> sys 0m0.000s Jeremy> This is with a newly built gcc 4.4.1 on Fedora 10 (glibc 2.9), x86-64. I tried it on my 1Ghz PIII laptop running Gentoo with gcc 4.1.1 and glibc 2.10.1. I added -march=pentium3 to the gcc cmd line; that probably made little difference. (glibc was also compiled with -march=pentium3 -O2). I got nearly identical user times for the two compiles; user time was always within 0.03 of 23.40 over multiple runs. Incidently, while the real-8 compile output 271828665.96115601, the real4 compile output 67108976. This does, then, seem to be an x86-64 issue. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Minor problem messaging C++ wrappers in Objective-C with gcc4.2
Hi,
I've found it very useful to be able to use C++ to extend Objective-C
using a little judicious operator overloading and I notice that gcc-4.2
now automatically "unboxes" wrapper classes with no warning when
they are messaged - provided an appropriate cast is available.
For example:
class AStringClass {
NSMutaableString *str;
public:
AStringClass( NSMutableString *str ) {
this->str = str;
}
operator NSMutableString * () {
return str;
}
};
This class can now be messaged in gcc4.2 as below without a warning:
AStringClass aString( nil );
[aString doubleValue];
Unfortunately is can also be sent a message which the compiler
is in a position to know is not available given the only cast
available was to a NSMutableString:
[aString count]; // not a valid method for NSMutableString *
This happens as internally as there is an implicit cast to type "id" in
${GCCROOT}gcc/objc/objc-act,c, function: objc_finish_message_expr
/* APPLE LOCAL begin decay function/array receivers */
#ifndef OBJCPLUS
/* In C need to decay array/function receivers so can be converted
to id. */
struct c_expr exp;
exp.value = receiver;
exp = default_function_array_conversion (exp);
receiver = exp.value;
/* APPLE LOCAL begin radar 3533972 */
#else
if (can_convert_arg (objc_object_type, TREE_TYPE (receiver),
receiver, LOOKUP_NORMAL))
{
/* In rare cases, 'receiver' must be converted to type 'id' using
user-defined type conversion. 'id' is type of the 1st
argument to
objc_msgSend (id self, SEL op, ...); */
tree cnv_rec = perform_implicit_conversion (objc_object_type,
receiver);
if (cnv_rec && cnv_rec != error_mark_node)
return objc_finish_message_expr (cnv_rec, sel_name,
method_params);
}
/* APPLE LOCAL end radar 3533972 */
#endif
Would it not be possible for the implicit conversion retain the type
which it was forced into using when searching for a match for "id"
and using this as the type of the receiver of the message rather
than "id". I've looked and the code but can't quite get to where
the change (probably quite a small one) would need to be made.
Perhaps even, this is already fixed...
Can anybody help?
John Holdsworth
objcpp.johnholdsworth.com
On 8 Apr 2009, at 14:34, David Ayers wrote:
Am Samstag, den 21.03.2009, 11:59 +0100 schrieb John Holdsworth:
I was wondering if it would be a useful extension to Objective-C
expand the [] operator
to support array and hash references to NSArray and NSDictionary
classes directly to
greatly improve the readability of code:
I'm not an ObjC front end maintainer and have no authority but one
issue
I would have with this feature with gcc proper is that the ObjC front
end would have to learn about the semantics of "NSArray" and
"NSDictionary" which are actually not part of the language but part of
an external library.
Now gcc already supports the -fconstant-string-class option as one way
to embed knowledge about an external library into an executable.
But I
would like adding options with all these semantics from a foreign
library into the language implementation.
Maybe this could be done more elegantly with plugin infrastructure
that
that es being currently added: http://gcc.gnu.org/wiki/plugins
Cheers,
David
Re: The reincarnation of PR15242
Andrew Haley writes: > This seems to be an an old bug that has come back. We're generating > > L1210: > jmp *%eax > .L4: > .L5: > ... > jmp .L1210 > .L1171: > .L1172: > ... > jmp .L1210 > .L1168: > .L1169: > ... > jmp .L1210 > > > instead of > > .L1210: > jmp *%eax > .L4: > .L5: > ... > jmp *%eax > .L1171: > .L1172: > ... > jmp *%eax > .L1168: > .L1169: > ... > jmp *%eax > > Current gcc trunk, x86, gcc -O3 ef.i -S -m32. > > Attachment in old Bugzilla entry at > http://gcc.gnu.org/bugzilla/attachment.cgi?id=6206&action=view We should have something like this in the testsuite. Ian
Re: MSVC hook function prologue
Ok, Alexandre hasn't changed his opinion, the function attrib is ok with him.
I attached another version of the patch, this time adding some testcases. Two
more questions though:
*) How can I skip the tests if msvc_prologue is not available because as
doesn't support the swap suffix? I think it would be wrong if the tests
failed in that case because the compiler says sorry().
I am currently scanning the other tests for hints, haven't found any yet.
*) Is the way I added the new files in the diff ok? (diff -u /dev/null
newfile). Or is there some more SVN-ish way?
Am Sunday 06 September 2009 11:36:23 schrieb Andreas Schwab:
> There are no x86-*-* targets, they must match i[34567]86-*-*.
Fixed that issue as well
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 151512)
+++ gcc/doc/extend.texi (working copy)
@@ -2672,6 +2672,14 @@ when targeting Windows. On all other systems, the
Note, This feature is currently sorried out for Windows targets trying to
+...@item msvc_prologue
+...@cindex @code{msvc_prologue} attribute
+
+On 32 bit i[34567]86-*-* targets, you can use this function attribute to make
+gcc generate the "hot-patching" function prologue used in Win32 API
+functions in Microsoft Windows XP Service Pack 2 and newer. This requires
+support for the swap suffix in the assembler. (GNU Binutils 2.19.51 or later)
+
@item naked
@cindex function without a prologue/epilogue code
Use this attribute on the ARM, AVR, IP2K and SPU ports to indicate that
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 151512)
+++ gcc/configure.ac (working copy)
@@ -3035,6 +3035,12 @@ foo: nop
[AC_DEFINE(HAVE_AS_IX86_SAHF, 1,
[Define if your assembler supports the sahf mnemonic.])])
+gcc_GAS_CHECK_FEATURE([swap suffix],
+ gcc_cv_as_ix86_swap,,,
+ [movl.s %esp, %ebp],,
+ [AC_DEFINE(HAVE_AS_IX86_SWAP, 1,
+[Define if your assembler supports the swap suffix.])])
+
gcc_GAS_CHECK_FEATURE([different section symbol subtraction],
gcc_cv_as_ix86_diff_sect_delta,,,
[.section .rodata
Index: gcc/config/i386/i386.h
===
--- gcc/config/i386/i386.h (revision 151512)
+++ gcc/config/i386/i386.h (working copy)
@@ -2388,6 +2388,9 @@ struct GTY(()) machine_function {
to be used. MS_ABI means ms abi. Otherwise SYSV_ABI means sysv abi. */
enum calling_abi call_abi;
struct machine_cfa_state cfa;
+ /* This value is used for i386 targets and specifies if the function
+ * should start with the hooking-friendly Win32 function prologue */
+ int msvc_prologue;
};
#endif
Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 151512)
+++ gcc/config/i386/i386.md (working copy)
@@ -237,6 +237,7 @@
(UNSPECV_RDTSC 18)
(UNSPECV_RDTSCP 19)
(UNSPECV_RDPMC 20)
+ (UNSPECV_VSWAPMOV 21)
])
;; Constants to represent pcomtrue/pcomfalse variants
@@ -15747,6 +15748,16 @@
(set_attr "length_immediate" "0")
(set_attr "modrm" "0")])
+(define_insn "vswapmov"
+ [(set (match_operand:SI 0 "register_operand" "=r")
+(match_operand:SI 1 "register_operand" "r"))
+ (unspec_volatile [(const_int 0)] UNSPECV_VSWAPMOV)]
+ ""
+ "movl.s\t%1,%0"
+ [(set_attr "length" "2")
+ (set_attr "length_immediate" "0")
+ (set_attr "modrm" "0")])
+
;; Pad to 16-byte boundary, max skip in op0. Used to avoid
;; branch prediction penalty for the third jump in a 16-byte
;; block on K8.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 151512)
+++ gcc/config/i386/i386.c (working copy)
@@ -4777,6 +4777,24 @@ ix86_function_type_abi (const_tree fntype)
return ix86_abi;
}
+static int
+ix86_function_msvc_prologue (const_tree fntype)
+{
+ if (!TARGET_64BIT && fntype != NULL)
+{
+ if(lookup_attribute ("msvc_prologue", TYPE_ATTRIBUTES (fntype)))
+{
+#ifdef HAVE_AS_IX86_SWAP
+ return 1;
+#else
+ sorry ("msvc_prologue needs swap suffix support in as");
+ return 0;
+#endif
+}
+}
+ return 0;
+}
+
static enum calling_abi
ix86_function_abi (const_tree fndecl)
{
@@ -4808,6 +4826,11 @@ ix86_call_abi_override (const_tree fndecl)
cfun->machine->call_abi = ix86_abi;
else
cfun->machine->call_abi = ix86_function_type_abi (TREE_TYPE (fndecl));
+
+ if (fndecl == NULL_TREE)
+cfun->machine->msvc_prologue = 0;
+ else
+cfun->machine->msvc_prologue = ix86_function_msvc_prologue (TREE_TYPE (fndecl));
}
/* MS and SYSV ABI have different set of call used registers. Avoid expensive
@@ -8316,6 +8339,7 @@ ix86_expand_prologue (void)
bool pic_reg_used;
struct ix86_frame frame;
HOST_WIDE_INT allocate;
+ int gen_
gcc-4.4-20090908 is now available
Snapshot gcc-4.4-20090908 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090908/ 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/branches/gcc-4_4-branch revision 151537 You'll find: gcc-4.4-20090908.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090908.tar.bz2 C front end and core compiler gcc-ada-4.4-20090908.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090908.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090908.tar.bz2 C++ front end and runtime gcc-java-4.4-20090908.tar.bz2 Java front end and runtime gcc-objc-4.4-20090908.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090908.tar.bz2The GCC testsuite Diffs from 4.4-20090901 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: hppa testsuite stalls?
> the testsuite on the hppa machine (gcc61 on the compile farm) has > always hanged for me from time to time. However, lately (at least > since I returned from vacation last Monday) it hangs every time. This is likely a kernel problem. There are long standing problems with testsuite timeouts and occassional hangs on linux. The frequency of these is kernel and hardware dependent. > Is this a know problem? How should I investigate such problems? It > makes proper testing on that platform rather impossible for me. It's very difficult as there's little relationship between cause and symptoms. If you come across a reproducible testcase, please report it to the parisc-linux list. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
m32c vs loop-opts - possible work-around
If loop optimization assumes sizeof(void *) == sizeof(size_t) and won't work correctly otherwise, perhaps a check for that condition in gate_tree_ssa_loop_ivopts() would be appropriate? I thought of just disabling that flag in m32c.c, but I figured a more generic solution would make more sense, and occasionally get the attention of the loop maintainers to remind them of the limitation.
