where is INTEGER_CST defined?
Hi, I cannot find the declaration of INTEGER_CST. Seems it is generated during the build process? Is there a way to let the building process to generate all the source files that are needed for a smooth source browsing? Thanks _ Turn down-time into play-time with Messenger games http://go.microsoft.com/?linkid=9734385
Re: where is INTEGER_CST defined?
On Jul 9, 2010, at 12:20 AM, BLUE 3TOO wrote: Hi, I cannot find the declaration of INTEGER_CST. Seems it is generated during the build process? Is there a way to let the building process to generate all the source files that are needed for a smooth source browsing? Thanks It is defined in tree.def. tree.h includes tree.def inside an enum declartion. Thanks, Andrew Pinski _ Turn down-time into play-time with Messenger games http://go.microsoft.com/?linkid=9734385
Re: a few beginner questiosn
On 9 July 2010 06:41, BLUE 3TOO wrote: > > Hi, > > I have following questions and would appreciate any comment. Thanks you > very much. > > 1. How to build a debugable version of GCC? I tried to set CFLGAS & > CXXFLAGS to "-O0 -g -fno-inline" in my configure command line, but it seems > it doesn't work. I manually modify all the Makefiles in gcc sub-directories > and replace "-O2" with "-O0 -g", it is dumb but works. I guess there is a > better way that I am not aware of. Can anybody tell me how to do it? See http://gcc.gnu.org/wiki/DebuggingGCC > 2. during the "make" process, i noticed it enters > gcc-4.5.0/host-i686-pc-cygwin/gcc and build the same source files three times: > > E.g. first time: gcc .././gcc/c-typeck.c -o c-typeck.o > 2nd time: xgcc -O2 -gtoggle .././gcc/c-typeck.c -o c-typeck.o > 3rd time: xgcc -O2 -DIN_GCC .././gcc/c-typeck.c -o c-typeck.o > Can anybody tells me what these compilation for? Seems that the first > one is building gcc, how about 2nd and 3rd one? thanks See the description of 3-stage bootstrap at http://gcc.gnu.org/install/build.html#TOC0 > 3. what is libgcc and newlib for? > > 4. what are these directories for? > prev-i686-pc-cygwin/ > stage1-i686-pc-cygwin/ > > > 5. what is libssp for? what is lto-plugin for? The different sub-directories are (briefly) described at http://gcc.gnu.org/onlinedocs/gccint/Top-Level.html
Problem configuring uclinux toolchain
Hi Maxim, Recent changes to config.gcc are preventing me from building a moxie-uclinux toolchain. They look related to your 2010-05-27 change for adding support for the Bionic C library. Your patches says that you updated the moxie-*-uclinux* config, but were you able to test this? I had to add ... tm_defines="$tm_defines LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 OPTION_ANDROID=0" ..to the moxie-*-uclinux* config in config.gcc in order to build. This doesn't seem right. Could you please have a look? Thanks! AG
(define_mode_const), a proposal
Hello!
During the macroization of x86 RTX patterns, it became clear that
certain patterns can't be macroized due to mode-dependant (const_int
N) RTXes, where the value of X depends on current mode. As an example,
here are two insn patterns from i386/i386.md:
(define_insn "x86_64_shld"
[(set (match_operand:DI 0 "nonimmediate_operand" "+r*m")
(ior:DI (ashift:DI (match_dup 0)
(match_operand:QI 2 "nonmemory_operand" "Jc"))
(lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
(minus:QI (const_int 64) (match_dup 2)
(clobber (reg:CC FLAGS_REG))]
...
and
(define_insn "x86_shld"
[(set (match_operand:SI 0 "nonimmediate_operand" "+r*m")
(ior:SI (ashift:SI (match_dup 0)
(match_operand:QI 2 "nonmemory_operand" "Ic"))
(lshiftrt:SI (match_operand:SI 1 "register_operand" "r")
(minus:QI (const_int 32) (match_dup 2)
(clobber (reg:CC FLAGS_REG))]
""
...
These two patterns could easily be macroized, however - there is no
way to express (const_int N) mode dependency*.
If we have had a define_mode_constant expression, similar to
define_mode_attr, where:
(define_mode_const WSZ [(SI "32") (DI "64")])
we could macroize the pattern to:
(define_insn "shld_"
[(set (match_operand:SWI48 0 "nonimmediate_operand" "+r*m")
(ior:SWI48 (ashift:SWI48 (match_dup 0)
(match_operand:QI 2 "nonmemory_operand" "c"))
(lshiftrt:SWI48 (match_operand:SWI48 1 "register_operand" "r")
(minus:QI (const_int {WSZ}) (match_dup 2)
(clobber (reg:CC FLAGS_REG))]
""
...
where {WSZ} would get expanded to correct number through WSZ define_mode_const.
This would help to macroize various push instructions throughout
i386.md and (more important) numerous string instructions, in addition
to the patterns, similar to the example above.
I'm posting this in hope that somebody would pick this idea, my skills
are too limited to implement this proposal by myself ...
* In expanders, it is possible to play various games with (match_dup
...) and create correct integer operand in insn prepare statements.
However, it would be more readable if we could embed correct integer
in the pattern itself.
Uros.
How to pass a pathlist in RUNTESTFLAGS?
Hi, I want to do this: RUNTESTFLAGS="--target_board=unix/-foo/-bar/--sysroot=/path/to/ somewhere " I've tried escaping the path with \ ' inverting the " and ' .. all to no avail .. what gets passed is -foo -bar --sysroot= -mpath -mto -msomewhere .. google hasn't helped.. anyone know what incantation I've missed? cheers, Iain
Re: How to pass a pathlist in RUNTESTFLAGS?
On Fri, Jul 9, 2010 at 9:12 AM, IainS wrote: > Hi, > > I want to do this: > > RUNTESTFLAGS="--target_board=unix/-foo/-bar/--sysroot=/path/to/somewhere " > > I've tried escaping the path with \ ' inverting the " and ' .. all to no > avail .. > > what gets passed is -foo -bar --sysroot= -mpath -mto -msomewhere .. > > google hasn't helped.. > > anyone know what incantation I've missed? > cheers, > Iain > IIRC i needed something like (can't remember offhand if this is exactly it, but it's something like this...) RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere --target_board=unix/-foo/-bar"
Re: Problem configuring uclinux toolchain
On 7/9/10 3:22 PM, Anthony Green wrote: Hi Maxim, Recent changes to config.gcc are preventing me from building a moxie-uclinux toolchain. Anthony, What is the error the build process is failing on? Thanks, -- Maxim Kuvyrkov CodeSourcery ma...@codesourcery.com (650) 331-3385 x724
Re: How to pass a pathlist in RUNTESTFLAGS?
On 9 July 2010 16:55, Doug Semler wrote: > On Fri, Jul 9, 2010 at 9:12 AM, IainS > wrote: >> Hi, >> >> I want to do this: >> >> RUNTESTFLAGS="--target_board=unix/-foo/-bar/--sysroot=/path/to/somewhere " >> >> I've tried escaping the path with \ ' inverting the " and ' .. all to no >> avail .. >> >> what gets passed is -foo -bar --sysroot= -mpath -mto -msomewhere .. >> >> google hasn't helped.. >> >> anyone know what incantation I've missed? >> cheers, >> Iain >> > > IIRC i needed something like (can't remember offhand if this is > exactly it, but it's something like this...) > > RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere > --target_board=unix/-foo/-bar" > Please, once you find out, add this info to http://gcc.gnu.org/wiki/Testing_GCC Cheers, Manuel.
Re: How to pass a pathlist in RUNTESTFLAGS?
On 9 Jul 2010, at 17:28, Manuel López-Ibáñez wrote: On 9 July 2010 16:55, Doug Semler wrote: On Fri, Jul 9, 2010 at 9:12 AM, IainS > wrote: Hi, I want to do this: RUNTESTFLAGS="--target_board=unix/-foo/-bar/--sysroot=/path/to/ somewhere " I've tried escaping the path with \ ' inverting the " and ' .. all to no avail .. what gets passed is -foo -bar --sysroot= -mpath -mto -msomewhere .. google hasn't helped.. anyone know what incantation I've missed? cheers, Iain IIRC i needed something like (can't remember offhand if this is exactly it, but it's something like this...) RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere --target_board=unix/-foo/-bar" Please, once you find out, add this info to http://gcc.gnu.org/wiki/Testing_GCC I really must sign up ... ;-) FWIW: RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere --target_board=unix/-foo/-bar" does work but maybe: RUNTESTFLAGS="CFLAGS_FOR_TARGET='$CFLAGS_FOR_TARGET --sysroot=/path/ to/somewhere' --target_board=unix/-foo/-bar" is safer? -- CFLAGS_FOR_TARGET could already be set, I guess. both work in the context I needed. thanks, Iain
The Linux binutils 2.20.51.0.10 is released
This is the beta release of binutils 2.20.51.0.10 for Linux, which is
based on binutils 2010 0707 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.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.bfd will be installed as ld. You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.
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.10 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.20.51.0.9:
1. Update from binutils 2010 0707.
2. Support AVX Programming Reference (June, 2010)
3. Add --compress-debug-sections support to assembler, disassembler and
readelf.
4. Fix a linker crash due to unintialized field in a structure.
5. Fix an x86 assembler crash with Intel syntax and invalid GOTPCREL.
PR 11732.
6. Enable SOM support for any hosts.
7. Improve gold.
8. Improve VMS support.
9. Improve arm support.
10. Improve mips support.
11. Improve RX support.
12. Improve TI C6X support.
13. Improve ppc support.
14. Remove maxq support.
Changes from binutils 2.20.51.0.8:
1. Update from binutils 2010 0526.
2. Implement SHF_EXCLUDE support for ELF targets. PR 11600.
3. Restore "call|jmp [xtrn]" in x86 assembler. PR 11535.
4. Properly handle ".equ symbol, reg + NUM" in x86 Intel syntax in x86
assembler. PR 11509.
5. Correct cross linker installation. PR 11510.
6: Remove relocation against discarded sections for relocatable link.
PR 11542.
7. Add a linker warning if value of SEGMENT_START isn't multiple of
maximum page size. PR 11628.
8. Improve x86 disassembler on unknown opcodes.
9. Avoid linker crash. PR 11583.
10. Support SH FDPIC.
11. Remove the leading underscore in symbol names from PE/x86-64.
12. Improve ELF overlap linker support.
13. Improve altmacro support in assembler.
14. Improve gold.
15. Improve VMS support.
16. Improve COFF support.
17. Improve arm support.
18. Improve hppa support.
19. Improve L1OM support.
20. Improve mips support.
21. Improve TI C6X support.
22. Improve ppc support.
Changes from binutils 2.20.51.0.7:
1. Update from binutils 2010 0
Re: Problem configuring uclinux toolchain
On 7/9/2010 11:59 AM, Maxim Kuvyrkov wrote: On 7/9/10 3:22 PM, Anthony Green wrote: Hi Maxim, Recent changes to config.gcc are preventing me from building a moxie-uclinux toolchain. Anthony, What is the error the build process is failing on? Here are the details: Without OPTION_ANDROID=0: ../../../gcc/gcc/c-family/c-cppbuiltin.c: In function ‘c_cpp_builtins’: ../../../gcc/gcc/c-family/c-cppbuiltin.c:841: error: ‘OPTION_ANDROID’ undeclared (first use in this function) ../../../gcc/gcc/c-family/c-cppbuiltin.c:841: error: (Each undeclared identifier is reported only once ../../../gcc/gcc/c-family/c-cppbuiltin.c:841: error: for each function it appears in.) Without LIBC_BIONIC=3: ../../../gcc/gcc/builtins.c: In function ‘expand_builtin_cexpi’: ../../../gcc/gcc/builtins.c:2430: error: ‘LIBC_BIONIC’ undeclared (first use in this function) ../../../gcc/gcc/builtins.c:2430: error: (Each undeclared identifier is reported only once ../../../gcc/gcc/builtins.c:2430: error: for each function it appears in.) Without LIBC_UCLIBC=2: options.c:1705: error: ‘LIBC_UCLIBC’ undeclared here (not in a function) options.c:5593: warning: missing initializer options.c:5593: warning: (near initialization for ‘cl_options[768].var_value’) Without LIBC_GLIBC=1: ../../../gcc/gcc/builtins.def: In function ‘c_define_builtins’: ../../../gcc/gcc/builtins.def:178: error: ‘LIBC_GLIBC’ undeclared (first use in this function) ../../../gcc/gcc/builtins.def:178: error: (Each undeclared identifier is reported only once ../../../gcc/gcc/builtins.def:178: error: for each function it appears in.) Building and testing the moxie-uclinux toolchain with the HEAD of GCC is very simple: $ git clone git://github.com/atgreen/moxiedev $ cd moxiedev/gcc $ ../scripts/fix-svn.sh $ ./contrib/gcc_update $ cd .. $ PATH=`pwd`/root/usr/bin:$PATH $ ant build Thanks, AG
Re: Problem configuring uclinux toolchain
On 7/9/2010 4:44 PM, Anthony Green wrote: Building and testing the moxie-uclinux toolchain with the HEAD of GCC is very simple: $ git clone git://github.com/atgreen/moxiedev $ cd moxiedev/gcc $ ../scripts/fix-svn.sh $ ./contrib/gcc_update $ cd .. $ PATH=`pwd`/root/usr/bin:$PATH $ ant build Of course.. the should be "export PATH=`pwd`/root/usr/bin:$PATH". Not strictly necessary for many versions of ant, but some of them are broken. AG
Re: Two debug entries for one local variables, is it a bug in GCC or GDB
Your bug was not a real bug, AFAICT.
At least the debug info you have shown in
http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html is not wrong.
Certainly, two DIES were unnecessary, but the way it did it was not broken.
Note that one of them is marked as DW_AT_declaration, specifying that
is where the declaration of that variable occurred.
The other is a definition.
They happen to be at the same line, so it's pointless to create two
DIE's, but it's not broken.
In this case, the debug information asmwarrior is showing is clearly broken.
I suspect GCC is splitting the variable somehow, because if you
notice, templateArgument is given different memory locations in both
blocks.
On Fri, Jul 9, 2010 at 1:58 AM, Nenad Vukicevic wrote:
> I reported something similar back in January:
>
> http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html
>
> As I recall, GCC creates duplicates.
>
> Nenad
>
> On 7/8/10 7:33 PM, asmwarrior wrote:
>>
>> I have post this message to both GCC and GDB, because I'm not sure it is
>> a bug in GDB or GCC.
>> Hi, I have just find two dwarf debug entries for one local variables.
>>
>> For example, the sample code is just like:
>>
>> -
>>
>> wxString ParserThread::ReadAncestorList()
>> {
>>
>> wxString ccc;
>> wxString templateArgument;
>> wxString aaa;
>> aaa = m_Tokenizer.GetToken(); // eat ":"
>> templateArgument = aaa;
>> while (!TestDestroy())
>> {
>>
>> //Peek the next token
>> wxString next = m_Tokenizer.PeekToken();
>>
>> if (next.IsEmpty()
>> || next==ParserConsts::opbrace
>> || next==ParserConsts::semicolon ) // here, we are at the end
>> of ancestor list
>> {
>> break;
>> }
>> else if (next==ParserConsts::lt) // class AAA : BBB< int,
>> float>
>> {
>> wxString arg = SkipAngleBraces();
>> if(!arg.IsEmpty()) // find a matching<>
>> {
>> templateArgument<> }
>> else
>> {
>> TRACE(_T("Not Matching<> find. Error!!!") );
>> }
>> }
>> ...
>> ---
>>
>> But I found that GDG can show the wxString aaa correctly, but wxString
>> templateArgument incorrectly.
>>
>> I have just check the debug information in the object file.
>> and found that there are two entries for local variable
>> "argumentTemplate", but only one entry for "aaa".
>>
>>
>> <2><40a9f>: Abbrev Number: 182 (DW_TAG_variable)
>> <40aa1> DW_AT_name : (indirect string, offset: 0x1095):
>> templateArgument
>> <40aa5> DW_AT_decl_file : 19
>> <40aa6> DW_AT_decl_line : 2593
>> <40aa8> DW_AT_type :<0xd168>
>> <40aac> DW_AT_accessibility: 3 (private)
>> <40aad> DW_AT_location : 2 byte block: 53 6 (DW_OP_reg3;
>> DW_OP_deref)
>> <2><40ab0>: Abbrev Number: 164 (DW_TAG_lexical_block)
>> <40ab2> DW_AT_ranges : 0x168
>> <3><40ab6>: Abbrev Number: 165 (DW_TAG_variable)
>> <40ab8> DW_AT_name : ccc
>> <40abc> DW_AT_decl_file : 19
>> <40abd> DW_AT_decl_line : 2592
>> <40abf> DW_AT_type :<0xd168>
>> <40ac3> DW_AT_location : 2 byte block: 91 50 (DW_OP_fbreg: -48)
>> <3><40ac6>: Abbrev Number: 179 (DW_TAG_variable)
>> <40ac8> DW_AT_name : (indirect string, offset: 0x1095):
>> templateArgument
>> <40acc> DW_AT_decl_file : 19
>> <40acd> DW_AT_decl_line : 2593
>> <40acf> DW_AT_type :<0xd168>
>> <40ad3> DW_AT_location : 2 byte block: 91 4c (DW_OP_fbreg: -52)
>> <3><40ad6>: Abbrev Number: 165 (DW_TAG_variable)
>> <40ad8> DW_AT_name : aaa
>> <40adc> DW_AT_decl_file : 19
>> <40add> DW_AT_decl_line : 2594
>> <40adf> DW_AT_type :<0xd168>
>> <40ae3> DW_AT_location : 2 byte block: 91 48 (DW_OP_fbreg: -56)
>> <3><40ae6>: Abbrev Number: 170 (DW_TAG_lexical_block)
>>
>>
>> --
>> Also, you can see the screen shot in my Codeblocks forums' post:
>>
>> http://forums.codeblocks.org/index.php/topic,12873.msg86906.html#msg86906
>>
>>
>> So, my question is:
>>
>> Is this a bug in GCC or GDB? ( I have just test the MinGW GCC 4.5 and
>> MinGW 4.4.4, they get the same result)
>>
>>
>> Thanks
>>
>> Asmwarrior (ollydbg from codeblocks' forum)
>>
>
warnings as errors in gcc/gcc/config/i386/i386.c
Is anyone seeing this issue on other targets? On x86_64-apple-darwin10,
with the patch...
Index: Makefile.in
===
--- Makefile.in (revision 162030)
+++ Makefile.in (working copy)
@@ -235,6 +235,7 @@
POSTSTAGE1_CXX_EXPORT = \
CXX="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/g++$(exeext) \
-B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \
+ -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
-I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
-I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
-I$$s/libstdc++-v3/libsupc++ \
applied so that the --static-libstdc++ works in tree on darwin, I have
gotten the --enable-build-with-cxx bootstrap to progress to a later point
at which it fails with...
/Users/howarth/work/./prev-gcc/g++ -B/Users/howarth/work/./prev-gcc/
-B/Users/howarth/dist/x86_64-apple-darwin10.4.0/bin/ -nostdinc++
-B/Users/howarth/work/prev-x86_64-apple-darwin10.4.0/libstdc++-v3/src/.libs
-I/Users/howarth/work/prev-x86_64-apple-darwin10.4.0/libstdc++-v3/include/x86_64-apple-darwin10.4.0
-I/Users/howarth/work/prev-x86_64-apple-darwin10.4.0/libstdc++-v3/include
-I/Users/howarth/gcc/libstdc++-v3/libsupc++
-L/Users/howarth/work/prev-x86_64-apple-darwin10.4.0/libstdc++-v3/src/.libs -c
-g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/sw/include -I/sw/include -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include
-I/sw/include -DCLOOG_PPL_BACKEND -I/sw/include -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/sw/include -I/sw/include -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include
-I/sw/include -DCLOOG_PPL_BACKEND ../../gcc/gcc/config/host-darwin.c
In file included from ../../gcc/gcc/config/i386/i386.c:31581:0:
../../gcc/gcc/config/i386/i386.c: In function ‘tree_node*
ix86_vectorize_builtin_vec_perm(tree, tree_node**)’:
../../gcc/gcc/config/i386/i386.c:30005:30: error: ‘fcode’ is used uninitialized
in this function [-Werror=uninitialized]
The offending code in gcc/config/i386/i386.c appears to be...
static tree
ix86_vectorize_builtin_vec_perm (tree vec_type, tree *mask_type)
{
tree itype = TREE_TYPE (vec_type);
bool u = TYPE_UNSIGNED (itype);
enum machine_mode vmode = TYPE_MODE (vec_type);
enum ix86_builtins fcode = fcode; /* Silence bogus warning. */
bool ok = TARGET_SSE2;
Also, I don't seem able to suppress this build failure with...
../gcc/configure --prefix=/Users/howarth/dist --enable-languages=c,c++
--enable-build-with-cxx --with-gmp=/sw --with-libiconv-prefix=/sw
--with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-checking=release --disable-werror
Is that expected behavior in current gcc trunk?
Jack
