rep prefix doesn't work with Solaris 2.9 Sun assembler
Solaris 2.9 x86 gcc 4.5.0 configure -without-gnu-as -with-as=/usr/ccs/bin/as
=> Assembly syntax errors in gcov.c whereever there is rep prefix.
I was actually looking for a problem with lock prefixes on 4.3 -- testing
4.5.0, found this instead, which is about about the same.
See:
http://gcc.gnu.org/viewcvs?view=revision&revision=127728
for handling of the lock prefix in a separate instruction.
See:
http://developers.sun.com/sunstudio/downloads/ssx/express_Feb2008_readme.html
"You can now place lock/rep/repnz/repz/repe/repne prefix on the same line as
the following instruction."
But I'd like to stay compatible with the existing Sun assembler
at /usr/ccs/bin/as.
I considered just changing them all to \;, like there is rep\;ret, but
I noticed this:
sync.md: "lock{%;| }or{l}\t{$0, (%%esp)|DWORD PTR [esp], 0}"
which appears to be an attempt to output Microsoft/Intel assembly, so I went
with the space usually and ; only for Darwin/Solaris, like how sync.md
was already using ; for Darwin.
Proposed patch below/attached.
(-w to hide indent change)
I'll open a bug. And test it on some machines maybe.
Any marked with TARGET_64BIT I left alone. Maybe that is too inconsistent
though.
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c ./i386.c
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c Wed Apr 7 23:58:27
2010
+++ ./i386.c Tue May 11 10:01:54 2010
@@ -11896,11 +11896,10 @@
return;
case ';':
-#if TARGET_MACHO
+ if (TARGET_MACHO || TARGET_SOLARIS)
fputs (" ; ", file);
-#else
+ else
putc (' ', file);
-#endif
return;
default:
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.h ./i386.h
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.h Wed Mar 24 21:44:48
2010
+++ ./i386.h Tue May 11 09:59:01 2010
@@ -467,6 +467,9 @@
redefines this to 1. */
#define TARGET_MACHO 0
+/* Like TARGET_MACHO, redefined in sol2.h. */
+#define TARGET_SOLARIS 0
+
/* Likewise, for the Windows 64-bit ABI. */
#define TARGET_64BIT_MS_ABI (TARGET_64BIT && ix86_cfun_abi () == MS_ABI)
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.md ./i386.md
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.md Wed Mar 24 19:49:49
2010
+++ ./i386.md Tue May 11 09:49:05 2010
@@ -13811,7 +13811,7 @@
[(return)
(unspec [(const_int 0)] UNSPEC_REP)]
"reload_completed"
- "rep\;ret"
+ "rep{%;| }ret"
[(set_attr "length" "2")
(set_attr "atom_unit" "jeu")
(set_attr "length_immediate" "0")
@@ -17772,7 +17772,7 @@
(mem:BLK (match_dup 4)))
(use (match_dup 5))]
"!TARGET_64BIT"
- "rep movs{l|d}"
+ "rep{%;| }movs{l|d}"
[(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "both")
@@ -17808,7 +17808,7 @@
(mem:BLK (match_dup 4)))
(use (match_dup 5))]
"!TARGET_64BIT"
- "rep movsb"
+ "rep{%;| }movsb"
[(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "both")
@@ -18023,7 +18023,7 @@
(use (match_operand:SI 2 "register_operand" "a"))
(use (match_dup 4))]
"!TARGET_64BIT"
- "rep stos{l|d}"
+ "rep{%;| }stos{l|d}"
[(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "store")
@@ -18056,7 +18056,7 @@
(use (match_operand:QI 2 "register_operand" "a"))
(use (match_dup 4))]
"!TARGET_64BIT"
- "rep stosb"
+ "rep{%;| }stosb"
[(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "store")
@@ -18188,7 +18188,7 @@
(clobber (match_operand:SI 1 "register_operand" "=D"))
(clobber (match_operand:SI 2 "register_operand" "=c"))]
"!TARGET_64BIT"
- "repz cmpsb"
+ "repz{%;| }cmpsb"
[(set_attr "type" "str")
(set_attr "mode" "QI")
(set_attr "prefix_rep" "1")])
@@ -18239,7 +18239,7 @@
(clobber (match_operand:SI 1 "register_operand" "=D"))
(clobber (match_operand:SI 2 "register_operand" "=c"))]
"!TARGET_64BIT"
- "repz cmpsb"
+ "repz{%;| }cmpsb"
[(set_attr "type" "str")
(set_attr "mode" "QI")
(set_attr "prefix_rep" "1")])
@@ -18305,7 +18305,7 @@
(clobber (match_operand:SI 1 "register_operand" "=D"))
(clobber (reg:CC FLAGS_REG))]
"!TARGET_64BIT"
- "repnz scasb"
+ "repnz{%;| }scasb"
[(set_attr "type" "str")
(set_attr "mode" "QI")
(set_attr "prefix_rep" "1")])
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/sol2.h ./sol2.h
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/sol2.h Wed Mar 31 11:03:29
2010
+++ ./sol2.h Tue May 11 10:02:17 2010
@@ -172,3 +172,6 @@
#define TF_SIZE 113
#define MD_UNWIND_SUPPORT "config/i386/sol2-unwind.h"
+
+#undef TARGET_SOLARIS
+#define TARGET_SOLARIS 1
Thanks,
- JayOnly in .: 1.txt
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c ./i386.c
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c Wed Apr 7
23:58:27 2010
+++ ./i386.cTue May 11 10:01:54 2010
@@ -11896,11 +11896,10 @@
retur
Re: rep prefix doesn't work with Solaris 2.9 Sun assembler
> Proposed patch below/attached. > (-w to hide indent change) See http://gcc.gnu.org/contribute.html for guidelines. > I'll open a bug. See http://gcc.gnu.org/bugs for guidelines. Generally speaking, posting a patch inlined in a message on gcc@gcc.gnu.org will most likely result in it being lost and forgotten. In order to report an issue, please open a ticket with bugzilla. In order to submit a patch, please use gcc-patc...@gcc.gnu.org. In both cases, follow the guidelines written down in the aforementioned documentation. Thanks in advance. -- Eric Botcazou
C/C++ AST
Hello All, I want to know if it is possible to modify AST of the C/C++-Language. What I would like to do is to add some arguments to some function calls or add statements somewhere in the tree. Now I am looking for the root node to modify it. Which is the best pass for that? Is there anywhere sample code available? I'm using gcc4.5 Source with the plugin interface... Thanks, Wolfgang -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
A question regarding bundling and NOPs insertion for VLIW architecture
Hello, I have a question regarding the process of bundling and NOPs insertion for VLIW architecture and I appreciate your answer: I am calling the second scheduler from the machine reorg pass; similar to what is done for IA64. I now want to handle the bundling and NOPs insertion for VLIW architecture with issue rate of 4 and I want to make sure I understand the process: IIUC I can use the insns with TImode that the scheduler marked to indicate a new cycle, so the the question is how many nops to insert after that cycle, if any. I noticed the following approach that was used in c6x which is mentioned in: http://archiv.tu-chemnitz.de/pub/2004/0176/data/index.html "NOP Insertion and Parallel Scheduling If the scheduler is run, it checks dependencies and tries to schedule the instructions as to minimize the processing cycles. The hooks TARGET_SCHED_REORDER(2) are considered to reorder the instructions in the ready cue in case the back end wants to override the default rules. I used the hooks to memorize the program cycle the instruction is scheduled. This value is stored in a hash table I created for that purpose. From the cycle information I can later determine how many NOPs have to be inserted between two instructions. This value then overrides the attribute value." IA64 seems to have much more complicated approach for the bundling and NOPs insertion and I wonder if the reason is due to IA64 specific issues? or there is something I'm missing in the approach mentioned above? Thanks in advance, Revital
RE: rep prefix doesn't work with Solaris 2.9 Sun assembler
Understood, but I'll have to stick to "small" changes as I can't get the papers.
Uros pointed to:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00657.html
which appears to just be *very* coincident timing.
So I Rainer will fix it soon.
I have a patch now based on that discussion.
I used:
case ';':
if ((TARGET_MACHO || TARGET_SOLARIS) && ASSEMBLER_DIALECT == ASM_ATT)
fputs (" ; ", file);
else
fputc (' ', file);
return;
though even better might be to assume 64bit implies more recent assembler:
case ';':
if ((TARGET_MACHO || TARGET_SOLARIS) && ASSEMBLER_DIALECT == ASM_ATT &&
!TARGET_64BIT)
fputs (" ; ", file);
else
fputc (' ', file);
return;
I guess there was an obscure bug where -masm=intel didn't work for Darwin
targets?.
What, people use -masm=intel and masm/nasm/yasm instead of gas? Or just to
human read the output?
Thanks,
- Jay
> From: ebotca...@adacore.com
> To: jay.kr...@cornell.edu
> Subject: Re: rep prefix doesn't work with Solaris 2.9 Sun assembler
> Date: Tue, 11 May 2010 10:35:12 +0200
> CC: gcc@gcc.gnu.org
>
>> Proposed patch below/attached.
>> (-w to hide indent change)
>
> See http://gcc.gnu.org/contribute.html for guidelines.
>
>> I'll open a bug.
>
> See http://gcc.gnu.org/bugs for guidelines.
>
> Generally speaking, posting a patch inlined in a message on gcc@gcc.gnu.org
> will most likely result in it being lost and forgotten. In order to report
> an issue, please open a ticket with bugzilla. In order to submit a patch,
> please use gcc-patc...@gcc.gnu.org. In both cases, follow the guidelines
> written down in the aforementioned documentation. Thanks in advance.
>
> --
> Eric Botcazou
Re: optimizing a DSO
On Tue, 11 May 2010, Jakub Jelinek wrote: And you can use -Wl,-O1 (pass -O1 to the linker) to let the linker determine optimal size of the hash table (minimum number of collisions for reasonably sized section). Was it considered enabling this automatically with -O3 (or -Ofast) when we know the linker is gnu? -- Marc Glisse
Re: A question regarding bundling and NOPs insertion for VLIW architecture
On Tue, 11 May 2010, Revital1 Eres wrote: > > Hello, > > I have a question regarding the process of bundling and NOPs insertion for > VLIW architecture > and I appreciate your answer: > > I am calling the second scheduler from the machine reorg pass; similar to > what is done for IA64. > I now want to handle the bundling and NOPs insertion for VLIW architecture > with issue rate of 4 > and I want to make sure I understand the process: > > IIUC I can use the insns with TImode that the scheduler marked to indicate > a new cycle, so the > the question is how many nops to insert after that cycle, if any. > I noticed the following approach that was used in c6x which is mentioned > in: > http://archiv.tu-chemnitz.de/pub/2004/0176/data/index.html > > "NOP Insertion and Parallel Scheduling > If the scheduler is run, it checks dependencies and tries to schedule the > instructions as to > minimize the processing cycles. The hooks TARGET_SCHED_REORDER(2) are > considered > to reorder the instructions in the ready cue in case the back end wants to > override the > default rules. I used the hooks to memorize the program cycle the > instruction is scheduled. > This value is stored in a hash table I created for that purpose. From the > cycle information > I can later determine how many NOPs have to be inserted between two > instructions. This > value then overrides the attribute value." > > IA64 seems to have much more complicated approach for the bundling and NOPs > insertion and I wonder > if the reason is due to IA64 specific issues? or there is something I'm > missing in the approach > mentioned above? >From skimming the paper I understand that the target processor is a 4-wide VLIW with little or no instruction issue constraints (which insn type may go in which bundle slot) and uses a non-interlocked pipeline, thus requiring NOP insertion to avoid dependencies. IA64 is different in both regards. Bundling in ia64 is complicated because not all combinations of insn types are possible in a bundle (a bundle contains three insns), and instruction issue boundaries can appear in mid-bundles (ia64 architecture uses stop bits to indicate parallel issue boundaries, and there are some bundle kinds with a stop bit in between). Incidentally, ia64 does not need NOP insertion to avoid data dependency violation, because it uses scoreboarding to track register dependencies. Thus, NOP insertion is only needed to satisfy bundling constraints. I think the ia64 port in GCC uses dynamic programming to perform bundling because it would be much harder to extract the instruction placement from the automaton (which I think tracks all of the mentioned constraints internally). Alexander
Coverage of backend rules
Hi, I have a backend and I would like to have a systematic way to know if my testsuite covers all the define_insn and define_expand rules in my md file. What's the best way to achieve this? I initially thought I could use gcov to check the coverage of the code that is generated from the md file but I would like to know if there is any better way to do this since I doubt I am the only one wishing to do this. Cheers, -- PMatos
Re: C++0x Memory model and gcc
Miles Bader wrote: Andrew MacLeod writes: -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right? Right. Its just a single processor memory model, so it doesn't limit any optimizations. Andrew
Re: Build Error
[ Moved to gcc@gcc.gnu.org ] On Tue, May 11, 2010 at 08:46, Sandeep Soni wrote: > On Tue, May 11, 2010 at 4:53 PM, Diego Novillo wrote: >> On Tue, May 11, 2010 at 02:24, Sandeep Soni wrote: >> >>> I installed elfutils-libelf-devel-0.145-1 and that worked. >> >> Yes. Older libelfs will not work. However, you should've gotten a >> configuration-time error. If you can reproduce, could you file a bug? >> The checking done during configuration did not spot the old version >> of libelf. >> > > Here was the configuration output: > > [r...@sandy build]# ../trunk/configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > checking for a BSD-compatible install... /usr/bin/install -c > checking whether ln works... yes > checking whether ln -s works... yes > checking for a sed that does not truncate output... /bin/sed > checking for gawk... gawk > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking for gnatbind... no > checking for gnatmake... no > checking whether compiler driver understands Ada... no > checking how to compare bootstrapped objects... cmp > --ignore-initial=16 $$f1 $$f2 > checking for objdir... .libs > checking for the correct version of gmp.h... yes > checking for the correct version of mpfr.h... yes > checking for the correct version of mpc.h... yes > checking for the correct version of the gmp/mpfr/mpc libraries... yes > checking for version 0.10 (or later revision) of PPL... no > checking how to run the C preprocessor... gcc -E > checking for grep that handles long lines and -e... /bin/grep > checking for egrep... /bin/grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking libelf.h usability... yes > checking libelf.h presence... yes > checking for libelf.h... yes > checking gelf.h usability... yes > checking gelf.h presence... yes > checking for gelf.h... yes > checking libelf/libelf.h usability... yes > checking libelf/libelf.h presence... yes > checking for libelf/libelf.h... yes > checking libelf/gelf.h usability... yes > checking libelf/gelf.h presence... yes > checking for libelf/gelf.h... yes > checking for the correct version of libelf... yes > checking for elf_getshdrstrndx... no > checking for elf_getshstrndx... yes > The following languages will be built: c,c++,fortran,java,lto,objc > *** This configuration is not supported in the following subdirectories: > target-libada gnattools > (Any other directories should still work fine.) > checking for default BUILD_CONFIG... bootstrap-debug > *** removing build-i686-pc-linux-gnu/libiberty/Makefile to force reconfigure > *** removing build-i686-pc-linux-gnu/fixincludes/Makefile to force reconfigure > *** removing prev-intl/Makefile to force reconfigure > *** removing intl/Makefile to force reconfigure > *** removing prev-libiberty/Makefile to force reconfigure > *** removing libiberty/Makefile to force reconfigure > *** removing prev-zlib/Makefile to force reconfigure > *** removing zlib/Makefile to force reconfigure > *** removing prev-libcpp/Makefile to force reconfigure > *** removing libcpp/Makefile to force reconfigure > *** removing prev-libdecnumber/Makefile to force reconfigure > *** removing libdecnumber/Makefile to force reconfigure > *** removing prev-gcc/Makefile to force reconfigure > *** removing gcc/Makefile to force reconfigure > checking for bison... bison -y > checking for bison... bison > checking for gm4... no > checking for gnum4... no > checking for m4... m4 > checking for flex... flex > checking for flex... flex > checking for makeinfo... makeinfo > checking for expect... no > checking for runtest... no > checking for ar... ar > checking for as... as > checking for dlltool... no > checking for ld... ld > checking for lipo... no > checking for nm... nm > checking for ranlib... ranlib > checking for strip... strip > checking for windres... no > checking for windmc... no > checking for objcopy... objcopy > checking for objdump... objdump > checking for cc... cc > checking for c++... c++ > checking for gcc... gcc > checking for gcj... no > checking for gfortran... gfortran > checking for ar... no > checking for ar... ar > chec
Re: optimizing a DSO
Marc Glisse writes: > On Tue, 11 May 2010, Jakub Jelinek wrote: > >> And you can use -Wl,-O1 (pass -O1 to the linker) to let the linker >> determine optimal size of the hash table (minimum number of collisions >> for reasonably sized section). > > Was it considered enabling this automatically with -O3 (or -Ofast) > when we know the linker is gnu? Sounds like a good idea. Would you mind sending a patch or filing a bug report? Ian
Re: C/C++ AST
On 05/11/2010 11:34 AM, wolfgang8...@gmx.de wrote:
Hello All,
I want to know if it is possible to modify AST of the C/C++-Language.
You can modify a middle end representation of source program. I am not
sure if it always should be called an AST.
What I would like to do is to add some arguments to some function calls or add
statements somewhere in the tree.
My suggestion would be to code a GCC pass as a plugin, working on some
GIMPLE representation (I don't know if you need or want it to be in SSA
form or not). The GIMPLE representation is the language & target
"neutral" intermediate representations used inside the middle end of GCC
(and common to every front-end = C, C++, Ada, Fortran & to every target
system = x86, ARM, ...).
The MELT plugin & infrastructure is precisely targeted towards this kind
of extensions.
MELT is a lispy domain specific language designed to easily code
transformations on GIMPLE (& other middle-end) representations. It is
also a plugin (& a GCC branch) implementation. So it seems to be suited
to your needs (which I don't understand well in details).
The main features of MELT are
* a powerful pattern matching facility
* a lispy language (translated to C suitable for GCC internals) with
higher-order (anonymous) functions, objects, garbage collection, &
ability to mix small C code chunks inside the MELT code.
For more about MELT, look at
http://gcc.gnu.org/wiki/MiddleEndLispTranslator or even better ask me
(on the gcc@ mailing list).
Alternatively, you could code your specific pass in plain C in an
ordinary plugin.
If you use MELT or if you code a plugin in C, you need to learn more
about GCC internal representations (notably GIMPLE & Tree/Generic) and
passes.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: rep prefix doesn't work with Solaris 2.9 Sun assembler
Jay K writes: > Understood, but I'll have to stick to "small" changes as I can't get the > papers. Note that for copyright purposes a series of unrelated small changes counts as a big change. If you truly can't do the paperwork, then it's probably best for the project if you avoid sending actual patches. Sorry about that. Ian
Re: Build Error
On Tue, May 11, 2010 at 6:30 PM, Diego Novillo wrote: > [ Moved to gcc@gcc.gnu.org ] > Hmm, it did not detect elf_getshdrstrndx and yet it tried to use it > later on. I think that's the bug. Yes, please file a bug. I believe > it's going to be easy to fix, though. There should be an unguarded > use of that function somewhere, it needs to be changed. Filed a bug. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44079 Thanks. -- Cheers Sandy
Re: optimizing a DSO
On Tue, 11 May 2010, Ian Lance Taylor wrote: Marc Glisse writes: On Tue, 11 May 2010, Jakub Jelinek wrote: And you can use -Wl,-O1 (pass -O1 to the linker) to let the linker determine optimal size of the hash table (minimum number of collisions for reasonably sized section). Was it considered enabling this automatically with -O3 (or -Ofast) when we know the linker is gnu? Sounds like a good idea. Would you mind sending a patch or filing a bug report? Bug#:44080 Sorry, my assignment is still not through so I won't even try to write a patch. -- Marc Glisse
Re: Coverage of backend rules
"Paulo J. Matos" writes: > I have a backend and I would like to have a systematic way to know if > my testsuite covers all the define_insn and define_expand rules in my > md file. > > What's the best way to achieve this? For define_insn you can use the -da option, and scan the debug files for the matched insn names. For define_expand you can reliably use profiling information to look for calls to gen_NAME. This approach won't tell you whether you are testing all alternatives of all define_insns. I don't know of a reasonable way to do that. Ian
Re: rep prefix doesn't work with Solaris 2.9 Sun assembler
> Note that for copyright purposes a series of unrelated small changes > counts as a big change. If you truly can't do the paperwork, then > it's probably best for the project if you avoid sending actual > patches. Sorry about that. A series of *related* small changes certainly would count as a big change, but I'm not so sure about UNrelated changes. However, I do agree with your sentiment that somebody who can't get the assignment paperwork done is probably better off not submitting patches on an ongoing basis.
A branch for 256bit vectorizer
Hi, I created a branch for 256bit vectorizer, branches/vect256/. Richard and I will work on it to extend vectorizer to 256bit. Jason, can you include it in git mirror? We can drop the ix86 branch in git since there are several branches under branches/ix86. Thanks. -- H.J.
Re: A branch for 256bit vectorizer
On 05/11/2010 10:30 AM, H.J. Lu wrote: I created a branch for 256bit vectorizer, branches/vect256/. Richard and I will work on it to extend vectorizer to 256bit. Jason, can you include it in git mirror? We can drop the ix86 branch in git since there are several branches under branches/ix86. It's already mirrored, just not one that is included in the default clone. Assuming you have a clone like that described in http://gcc.gnu.org/wiki/GitMirror, you would say git config --add remote.origin.fetch refs/remotes/vect256:refs/remotes/origin/vect256 git config --add svn-remote.svn.fetch branches/vect256:refs/remotes/origin/vect256 and you should be all set. I did drop the ix86 branch, as the git-svn subdirectory confusion significantly increases the overhead from including it in the clone set. Jason
Re: A branch for 256bit vectorizer
On Tue, May 11, 2010 at 7:49 AM, Jason Merrill wrote: > On 05/11/2010 10:30 AM, H.J. Lu wrote: >> >> I created a branch for 256bit vectorizer, branches/vect256/. Richard >> and I will work on it to extend vectorizer to 256bit. >> >> Jason, can you include it in git mirror? We can drop the ix86 branch >> in git since there are several branches under branches/ix86. > > It's already mirrored, just not one that is included in the default clone. > Assuming you have a clone like that described in > http://gcc.gnu.org/wiki/GitMirror, you would say > > git config --add remote.origin.fetch > refs/remotes/vect256:refs/remotes/origin/vect256 > git config --add svn-remote.svn.fetch > branches/vect256:refs/remotes/origin/vect256 > > and you should be all set. I was hoping git://gcc.gnu.org/git/gcc.git mirror branches/vect256 instead of ix86 so that I can just pull from it. > > I did drop the ix86 branch, as the git-svn subdirectory confusion > significantly increases the overhead from including it in the clone set. From: http://gcc.gnu.org/wiki/GitMirror remotes/origin/ix86 is still listed. I did a clone of git://gcc.gnu.org/git/gcc.git and I got x86 branch. Thanks. -- H.J.
Re: A branch for 256bit vectorizer
On 05/11/2010 11:21 AM, H.J. Lu wrote: On Tue, May 11, 2010 at 7:49 AM, Jason Merrill wrote: git config --add remote.origin.fetch refs/remotes/vect256:refs/remotes/origin/vect256 git config --add svn-remote.svn.fetch branches/vect256:refs/remotes/origin/vect256 I was hoping git://gcc.gnu.org/git/gcc.git mirror branches/vect256 instead of ix86 so that I can just pull from it. It does. You just need to tell your local git to pull it, using the above commands. If you do git ls-remote git://gcc.gnu.org/git/gcc.git you will see refs/remotes/vect256 in the list. From: http://gcc.gnu.org/wiki/GitMirror remotes/origin/ix86 is still listed. Thanks, I'll fix that. I did a clone of git://gcc.gnu.org/git/gcc.git and I got x86 branch. A new clone shouldn't get it, as it isn't in refs/heads anymore. But it won't disappear from your local repository until you do 'git remote prune origin'. Jason
Re: A branch for 256bit vectorizer
"H.J. Lu" writes: > From: > > http://gcc.gnu.org/wiki/GitMirror > > remotes/origin/ix86 is still listed. I did a clone of > > git://gcc.gnu.org/git/gcc.git > > and I got x86 branch. Try running "git remote prune origin". Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: A branch for 256bit vectorizer
On Tue, May 11, 2010 at 9:40 AM, Jason Merrill wrote: > On 05/11/2010 11:21 AM, H.J. Lu wrote: >> >> On Tue, May 11, 2010 at 7:49 AM, Jason Merrill wrote: > >>> git config --add remote.origin.fetch >>> refs/remotes/vect256:refs/remotes/origin/vect256 >>> git config --add svn-remote.svn.fetch >>> branches/vect256:refs/remotes/origin/vect256 >> >> I was hoping >> >> git://gcc.gnu.org/git/gcc.git >> >> mirror branches/vect256 instead of ix86 so that >> I can just pull from it. > > It does. You just need to tell your local git to pull it, using the above > commands. If you do > > git ls-remote git://gcc.gnu.org/git/gcc.git > > you will see refs/remotes/vect256 in the list. It isn't very clear that refs/heads was changed to refs/remotes. http://repo.or.cz/w/official-gcc.git still fetches refs/heads, not refs/remotes. I can't browse branches under refs/remotes. H.J. >> From: >> >> http://gcc.gnu.org/wiki/GitMirror >> >> remotes/origin/ix86 is still listed. > > Thanks, I'll fix that. > >> I did a clone of >> >> git://gcc.gnu.org/git/gcc.git >> >> and I got x86 branch. > > A new clone shouldn't get it, as it isn't in refs/heads anymore. But it > won't disappear from your local repository until you do 'git remote prune > origin'. > > Jason
Re: A branch for 256bit vectorizer
On 05/11/2010 02:28 PM, H.J. Lu wrote: It isn't very clear that refs/heads was changed to refs/remotes. Sure. The git-svn mirror puts everything under refs/remotes, then the git mirror maintainers manually create the equivalent of symbolic links under refs/heads for some branches. I don't know what policy Bernie was using to decide which branches should be included; I guess from an earlier mail that he was just including all active branches, so I should probably just go ahead and add this one too even though I would be inclined toward a different policy. OK, done. http://repo.or.cz/w/official-gcc.git still fetches refs/heads, not refs/remotes. I can't browse branches under refs/remotes. True. Jason
[sysad...@gnu.org: [gnu.org #572859] [gcc-bugs-h...@gcc.gnu.org: ezmlm warning]]
Not sure where to send this, who is responsible for the mail server for gcc.gnu.org? --- Start of forwarded message --- Subject: [gnu.org #572859] [gcc-bugs-h...@gcc.gnu.org: ezmlm warning] From: "Ward Vandewege via RT" To: a...@gnu.org Date: Mon, 10 May 2010 10:28:41 -0400 > [...@gnu.org - Sun May 09 07:42:17 2010]: > > Not sure if it is useful to report these warnings from gcc.gnu.org, > but here is another warning I got. > > Hi. This is the qmail-send program at sourceware.org. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > : > 140.186.70.92 failed after I sent the message. > Remote host said: 550-8-bit characters not allowed in subject > 550 (see RFC 2822, sections 3.6.5, 2.2.1) > --- End of forwarded message --- This was a message with illegal encoding. This is our rule: denysenders = \N[\x80-\xFF]\N message = 8-bit characters not allowed in envelope sender\n\ (see RFC 2821, section 4.1.2) The gcc.gnu.org mailserver should really not be accepting that mail either. Thanks, Ward. - -- Ward Vandewege Free Software Foundation - Senior System Administrator --- End of forwarded message ---
Re: [sysad...@gnu.org: [gnu.org #572859] [gcc-bugs-h...@gcc.gnu.org: ezmlm warning]]
On Tue, May 11, 2010 at 01:12:45PM -0700, Alfred M. Szmidt wrote: > Not sure where to send this, who is responsible for the mail server > for gcc.gnu.org? The admins can be reached at overse...@gcc.gnu.org .
Re: Building GCC & CFLAGS settings
On Wed, 2010-05-05 at 10:42 -0700, H.J. Lu wrote: > On Wed, May 5, 2010 at 10:18 AM, Steve Ellcey wrote: > > > > I was wondering if anyone has built GCC using a CFLAGS (and CXXFLAGS) > > setting > > that causes GCC to generate code that is not compatibile with the default > > GCC output. Basically, I am building GCC on ia64-hp-hpux11.31 where I set > > CFLAGS and CXXFLAGS to "-mlp64" to generate 64 bit code instead of the > > default 32 bit code. During the build libiberty is built in 64 bit mode but > > then the object files that go into genmodes (genmodes.o, errors.o, etc) are > > compiled without using CFLAGS and the link of genmodes fails because > > genmodes.o and errors.o are in 32 bit mode and libiberty is in 64 bit mode. > > > > I am using > > # CC="gcc -m32" CXX="g++ -m32" ./configure > > to bootstrap 32bit gcc on 64bit Linux. I am curious, if you do this does the resulting compiler generate 32 bit code by default? And I assume that if you don't specify CC and CXX with the -m32 flags then the compiler generates 64 bit code by default, right? Steve Ellcey s...@cup.hp.com
arm-elf float-abi defaults...
I discovered that if you build a plain arm-elf toolchain, the default
float-abis for gcc and gas don't match. I added this patch locally to
make it "just work" but it seems to me it would be better to have the
defaults match, although I'm not sure how to enforce that. Comments?
Suggestions?
Index: gcc/config/arm/elf.h
===
RCS file: gcc/config/arm/elf.h,v
--- gcc/config/arm/elf.h
+++ gcc/config/arm/elf.h
@@ -41,7 +41,13 @@
#endif
#ifndef SUBTARGET_EXTRA_ASM_SPEC
-#define SUBTARGET_EXTRA_ASM_SPEC ""
+#if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_SOFT
+#define SUBTARGET_EXTRA_ASM_SPEC \
+ "%{!msoft-float:%{!mhard-float:%{!mfloat-abi=*:-mfloat-abi=soft}}}"
+#else
+#define SUBTARGET_EXTRA_ASM_SPEC \
+ "%{!msoft-float:%{!mhard-float:%{!mfloat-abi=*:-mfloat-abi=hard}}}"
+#endif
#endif
#ifndef SUBTARGET_ASM_FLOAT_SPEC
gcc-4.4-20100511 is now available
Snapshot gcc-4.4-20100511 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100511/ 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 159296 You'll find: gcc-4.4-20100511.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100511.tar.bz2 C front end and core compiler gcc-ada-4.4-20100511.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100511.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100511.tar.bz2 C++ front end and runtime gcc-java-4.4-20100511.tar.bz2 Java front end and runtime gcc-objc-4.4-20100511.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100511.tar.bz2The GCC testsuite Diffs from 4.4-20100504 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: C++0x Memory model and gcc
Andrew MacLeod writes: >>> -fmemory-model=single - Enable all data races introductions, as they >>> are today. (relax all 4 internal restrictions.) >> >> One could still use this mode with a multi-threaded program as long as >> explicit synchronization is done, right? > > Right. Its just a single processor memory model, so it doesn't limit > any optimizations. Hmm, though now that I think about it, I'm not exactly sure what I mean by "explicit synchronization". Standard libraries (boost threads, the upcoming std::thread) provide things like mutexes and conditional-variables, but does using those guarantee that the right things happen with any shared data-structures they're used to coordinate...? Thanks, -Miles -- Vote, v. The instrument and symbol of a freeman's power to make a fool of himself and a wreck of his country.
