Re: Incorporation of Objective-C 2.0 changes into GCC trunk
On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzini wrote: > Gregory Casamento wrote: >> As far as I'm aware apple has an assignment for changes to gcc, so it >> should be possible to pull them in. > > You're not forced to assign changes that you do not want to assign. I don't understand. Yes you are forced to assign copyright to the FSF for changes you contribute to FSF GCC. You are of course not forced to do this for your own forks of GCC. Richard.
GCC 4.4.2 Status Report (2009-07-22)
Status == GCC 4.4.1 has been released, I'll announce it once uploaded to ftp.gnu.org and mirrors get a chance to mirror it. The 4.4 branch is again open under the usual release branch rules. Quality Data Priority # Change from Last Report --- --- P10 P2 81 P32 --- --- Total83 Previous Report === http://gcc.gnu.org/ml/gcc/2009-07/msg00273.html The next report for 4.4 will be sent by Joseph.
Re: Incorporation of Objective-C 2.0 changes into GCC trunk
On 07/22/2009 10:57 AM, Richard Guenther wrote: On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzini wrote: Gregory Casamento wrote: As far as I'm aware apple has an assignment for changes to gcc, so it should be possible to pull them in. You're not forced to assign changes that you do not want to assign. I don't understand. Yes you are forced to assign copyright to the FSF for changes you contribute to FSF GCC. You are of course not forced to do this for your own forks of GCC. Yeah, if Apple didn't send the code to FSF GCC, the fact that Apple has an assignment does not count. They're not forced to assign changes that they do not want to assign -- as long as they keep the changes local, which they did for Objective C 2.0. The only way to know, would be to ask someone at Apple. Paolo
Re: Incorporation of Objective-C 2.0 changes into GCC trunk
Gregory Casamento wrote: > If not, I would like to know what the GNUstep project can do to help > make this happen. Persuade Apple to de-embargo their engineers from showing their faces in public round here?(*) At least from the outside, it appears that Apple(**) is simply not interested in contributing to GCC. cheers, DaveK -- (*) - http://gcc.gnu.org/ml/gcc/2008-02/msg00523.html (**) - Corporately, I'm sure there will be individuals within the organisation who disagree with the policy but whose hands are tied.
Re: default library search path for native *-w64-mingw32 builds is broken somehow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rainer Emrich schrieb:
> Rainer Emrich schrieb:
>> Kai Tietz schrieb:
>>> 2009/7/20 Kai Tietz :
2009/7/20 Rainer Emrich :
>
>>> For the native compiler I get:
>>> $ x86_64-w64-mingw32-gcc -print-search-dirs
>>> installiere:
>>> c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.5.0/
>>> Programme:
>>> =c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.0/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../libexec/gcc/;/usr/libexec/gcc/x86_64-w64-mingw32/4.5.0/;
>>> /usr/libexec/gcc/x86_64-w64-mingw32/;
>>> /usr/lib/gcc/x86_64-w64-mingw32/4.5.0/;
>>> /usr/lib/gcc/x86_64-w64-mingw32/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.0/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/bin/
>>> Bibliotheken:
>>> =c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/;
>>> /usr/lib/gcc/x86_64-w64-mingw32/4.5.0/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.0/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/../lib64/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../x86_64-w64-mingw32/4.5.0/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../lib64/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../../mingw/mingw/lib64/x86_64-w64-mingw32/4.5.0/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../../mingw/mingw/lib64/../lib64/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../;
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../../mingw/mingw/lib64/
>>> $ x86_64-w64-mingw32-gcc -Wl,--verbose -o test.exe test.o -lxyz
>>> GNU ld (GNU Binutils) 2.19.51.20090719
>>> Supported emulations:
>>> i386pep
>>> i386pe
>>> using internal linker script:
>>> ==
>>> /* Default linker script, for normal executables */
>>> OUTPUT_FORMAT(pei-x86-64)
>>> SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
>>> SECTIONS
>>> {
>>> .
>>> .
>>> .
>>> }
>
>>> ==
>>> attempt to open
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/crt2.o
>>> succeeded
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/crt2.o
>>> attempt to open
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/crtbegin.o
>>> succeeded
>>> c:/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/crtbegin.o
>>> attempt to open test.o succeeded
>>> test.o
>>> attempt to open
>>> c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../../mingw/usr/lib/libxyz.dll
>>> failed
>>> attempt to open
>>> c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../../mingw/usr/lib/xyz.dll
>>> failed
>>> attempt to open
>>> c:\mingw\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin\../../mingw/usr/lib\xyz.lib
>>> failedC:\MinGW\gcc\gcc-4.5.0\x86_64-w64-mingw32\mingw\bin/ld.exe: cannot
>>> find -lxyz
>>> collect2: ld gab 1 als Ende-Status zurück
>
>>> So, there's a strange difference between the search path information and the
>>> actually searched directories for the native bild. None of the gcc internal
>>> and
>>> sysroot directories are searched. The same is true for a i686-w64-mingw32
>>> build.
>>> An attempt to do a three stage bootstrap fails for the same reason at
>>> configure
>>> time of libgcc in stage 1.
>>> Any idea?
>>> Rainer
Could you take a look on
http://mingw-w64.wiki.sourceforge.net/Answer+Multilib+Toolchain FAQ. I
think it could help you.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
>>> Does this patch solves your issue?
>>> Cheers,
>>> Kai
>> Thank you for your fast reply. To clearify, I have a cross setup from
>> i686-pc-mingw32. Building of the cross compilers is without any issues. I get
>> the failure only with the native ones build with this cross compilers. I know
>> the build instructions, the only point I mi
Re: Incorporation of Objective-C 2.0 changes into GCC trunk
On Jul 22, 2009, at 2:58 AM, Paolo Bonzini wrote: On 07/22/2009 10:57 AM, Richard Guenther wrote: On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzini wrote: Gregory Casamento wrote: As far as I'm aware apple has an assignment for changes to gcc, so it should be possible to pull them in. You're not forced to assign changes that you do not want to assign. I don't understand. Yes you are forced to assign copyright to the FSF for changes you contribute to FSF GCC. You are of course not forced to do this for your own forks of GCC. Yeah, if Apple didn't send the code to FSF GCC, the fact that Apple has an assignment does not count. They're not forced to assign changes that they do not want to assign -- as long as they keep the changes local, which they did for Objective C 2.0. The only way to know, would be to ask someone at Apple. If someone is seriously interested in merging pieces of the Apple GCC tree into the main FSF tree, and if there is a process in place to make the assignment happy, I would be happy to try to make it happen. The major caveats are that the Apple GCC tree isn't in great shape (it will take some work to make the objc2 changes "submission quality" because they may break the gnu runtime, be overly darwin specific, etc), Apple engineers will not be able to help with this work, and it may take some time to get the approval to assign copyright of the code. What is the process for getting a blob of code assigned to the FSF that is not just being committed into the tree? -Chris
Re: Incorporation of Objective-C 2.0 changes into GCC trunk
What is the process for getting a blob of code assigned to the FSF that is not just being committed into the tree? Creating a branch on gcc.gnu.org and committing it there should be enough. Paolo
RFA: Issues to enable x86 defaulted multilib version
Hello,
Possibly somebody could give me a hint what the issue here is. In the
patch I attached, I enable multilib for x86 default mingw target
(i686-w64-mingw32). The core compilers are translating nicely. But
when it tries to build libgcc by -m64 it throws always the same error
message for any array : "error: size of array "..." is too large". I
am curious as the configuration patch is pretty equal to linux
version, but something I seem to miss here.
Thanks in advance,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Index: gcc/gcc/config/i386/mingw-w64.h
===
--- gcc.orig/gcc/config/i386/mingw-w64.h 2009-07-21 14:27:18.820073000 +0200
+++ gcc/gcc/config/i386/mingw-w64.h 2009-07-21 15:07:27.718073000 +0200
@@ -37,6 +37,10 @@
#undef STANDARD_INCLUDE_DIR
#define STANDARD_INCLUDE_DIR "/mingw/include"
+/* Adjust STANDARD_STARTFILE_PREFIX_1 pointing to lib. */
+#undef STANDARD_STARTFILE_PREFIX_1
+#define STANDARD_STARTFILE_PREFIX_1 "/mingw/lib/"
+
/* Enable multilib. */
#undef ASM_SPEC
@@ -67,3 +71,4 @@
%{static:-Bstatic} %{!static:-Bdynamic} \
%{shared|mdll: -e _dllmaincrtstar...@12 --enable-auto-image-base} \
%(shared_libgcc_undefs)"
+
Index: gcc/gcc/config.gcc
===
--- gcc.orig/gcc/config.gcc 2009-07-21 14:27:18.825073000 +0200
+++ gcc/gcc/config.gcc 2009-07-21 17:19:12.217073000 +0200
@@ -1294,9 +1294,28 @@
use_gcc_stdint=wrap
;;
i[34567]86-*-mingw* | x86_64-*-mingw*)
- tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h dbxcoff.h i386/cygming.h i386/mingw32.h"
+ tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h dbxcoff.h"
xm_file=i386/xm-mingw32.h
# This makes the logic if mingw's or the w64 feature set has to be used
+ if test x$enable_targets = xall; then
+ tm_defines="${tm_defines} TARGET_BI_ARCH=1"
+ need_64bit_hwint=yes
+ case X"${with_cpu}" in
+ Xgeneric|Xatom|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx)
+ ;;
+ X)
+ if test x$with_cpu_64 = x; then
+with_cpu_64=generic
+ fi
+ ;;
+ *)
+ echo "Unsupported CPU used in --with-cpu=$with_cpu, supported values:" 1>&2
+ echo "generic atom core2 nocona x86-64 amdfam10 barcelona k8 opteron athlon64 athlon-fx" 1>&2
+ exit 1
+ ;;
+ esac
+ fi
+ tm_file="${tm_file} i386/cygming.h i386/mingw32.h"
case ${target} in
*-w64-*)
tm_file="${tm_file} i386/mingw-w64.h"
The Linux binutils 2.19.51.0.14 is released
This is the beta release of binutils 2.19.51.0.14 for Linux, which is
based on binutils 2009 0722 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.19.51.0.14 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
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 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 on empty file. PR 10321.
5. Fix debug section for PE-COFF.
6. Suport build with gcc 4.5.0.
7. Improve arm support.
8. Improve ppc support.
9. Improve m10300 support.
10. Improve mep support.
11. Improve MacOS support.
12. Improve gold support.
Changes from binutils 2.19.51.0.9:
1. Update from binutils 2009 0618.
2. Update STT_GNU_IFUNC symbol support. PR 10269/10270.
3. Fix an assembler CFI bug. PR 10255.
4. Improve objdump. PR 10263/10288
5. Improve readelf.
6. Improve arm support.
7. Improve moxie support.
8. Improve spu support.
9. Improve vax support.
10. Improve COFF/PE support.
11. Improve MacOS support.
Changes from binutils 2.19.51.0.8:
1. Update from binutils 2009 0606.
2. Update STT_GNU_IFUNC symbol support.
Changes from binutils 2.19.51.0.7:
1. Update from binutils 2009 0603.
2. Fix STT_GNU_IFUNC symbol with pointer equality.
Changes from binutils 2.19.51.0.6:
1. Update from binutils 2009 0601.
2. U
[trans-mem] cgraph edges vs function cloning
Could I convince you to have a look at the transactional-memory branch test libitm/testsuite/libitm.c++/eh-1.C? I'm getting z.c:36:1: error: edge void f1()->void* __cxa_allocate_exception(long unsigned int) has no corresponding call_stmt D.2114_4 = __cxa_allocate_exception (4); z.c:36:1: error: edge void f1()->void __cxa_throw(void*, void*, void (*)(void*)) has no corresponding call_stmt __cxa_throw (D.2114_4, &_ZTIi, 0B); void f1()/10(-1) @0x72d75500 availability:available 32 time, 10 benefit 14 size, 1 benefit reachable body finalized called by: void f2()/1 (1.00 per call) (can throw external) calls: void _ITM_cxa_throw(void*, void*, void (*)(void*))/12 (1.00 per call) (can throw external) void* _ITM_cxa_allocate_exception(long unsigned int)/11 (1.00 per call) void* __cxa_allocate_exception(long unsigned int)/8 (1.00 per call) void __cxa_throw(void*, void*, void (*)(void*))/9 (1.00 per call) (can throw external) z.c:36:1: internal compiler error: verify_cgraph_node failed This happens because cgraph_copy_node_for_versioning duplicated all of the callee edges from the original function, and tree_function_versioning created new edges when copying the body of the function instead of updating the edges we duplicated. Frankly, the unholy mess of edge update options has me stumped. I have no idea what's going on in this area. Why bother with any of it anyway? Why not just always create all new callee edges when instantiating the new body? r~
#pragma startup doesn't work on GCC
Hi, gcc doesn't seem to support "#pragma startup" and "#pragma exit". I used gcc 4.0.0. Does there exist equivalent commands for these pragmas in gcc? Regards, Debarshi
Re: #pragma startup doesn't work on GCC
Debarshi Sanyal writes: > gcc doesn't seem to support "#pragma startup" and "#pragma exit". I > used gcc 4.0.0. > Does there exist equivalent commands for these pragmas in gcc? This question is not appropriate for the mailing list gcc@gcc.gnu.org, which is for developers of gcc. It is appropriate for gcc-h...@gcc.gnu.org. Please take any followups to that list. Thanks. See the constructor and destructor function attributes. Ian
