[Bug target/39457] [power7-meissner] unable to find a register to spill in class 'LINK_OR_CTR_REGS'
--- Comment #5 from gnu at the-meissners dot org 2009-03-18 12:48 --- Subject: Re: New: [power7-meissner] unable to find a register to spill in class 'LINK_OR_CTR_REGS' If possible, please send mail on power7 to meiss...@linux.vnet.ibm.com. I don't read mail on my home account (g...@the-meissners.org) as frequently as I do on the work email. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39457
[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names
--- Comment #15 from gnu at the-meissners dot org 2009-01-13 23:13 --- I suspect this needs to be solved in gcc.c with the specs handling, and you probably need something to quote the white space in filename, so that it doesn't break the file into separate arguments. Only some alpha and mips port use ASM_FINAL_SPEC which calls mips-tfile. I must admit that when I wrote mips-tfile as a quick hack in 1990 to get around the problem of having to use the MIPS assembler which provided no debug inteferface until a MIPS port of GAS was done, that the hack would still be in use 18 years later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4605
[Bug libstdc++/38421] New: libstdc++-v3/include/tr1/ell_integral.tcc contains __ea identifier
The SPU port is adding support for named address spaces, and will be adding the __ea keyword as a type qualifier. At the moment, the named address support is for C only, but at some point in the future, it might be desirable to add named address support to C++ as well. If C++ support is added, then the libstdc++-v3/include/tr1/ell_integral.tcc file needs to be changed to not use the __ea identifier. -- Summary: libstdc++-v3/include/tr1/ell_integral.tcc contains __ea identifier Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at the-meissners dot org GCC build triplet: x86_64-gnu-linux GCC host triplet: x86_64-gnu-linux GCC target triplet: spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38421
[Bug c/38416] c-parser.c puts pragma_kind as a 7 bit field, when 8 will generate better code
--- Comment #1 from gnu at the-meissners dot org 2008-12-05 19:17 --- Created an attachment (id=16833) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16833&action=view) Trivial patch to fix the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38416
[Bug c/38416] New: c-parser.c puts pragma_kind as a 7 bit field, when 8 will generate better code
I was modifying the named address support to add the named address keywords via
the C keyword tables rather than via a target hook, and I noticed the c_token
structure has pragma_kind as a 7 bit field. All of the previous bit fields are
8 bits in size, and next field is a tree, so we are not saving any space by
declaring the field to be 7 bits instead of 8, which would allow byte
loads/stores to be used to access the field. Here is the declaration.
typedef struct c_token GTY (())
{
/* The kind of token. */
ENUM_BITFIELD (cpp_ttype) type : 8;
/* If this token is a CPP_NAME, this value indicates whether also
declared as some kind of type. Otherwise, it is C_ID_NONE. */
ENUM_BITFIELD (c_id_kind) id_kind : 8;
/* If this token is a keyword, this value indicates which keyword.
Otherwise, this value is RID_MAX. */
ENUM_BITFIELD (rid) keyword : 8;
/* If this token is a CPP_PRAGMA, this indicates the pragma that
was seen. Otherwise it is PRAGMA_NONE. */
ENUM_BITFIELD (pragma_kind) pragma_kind : 7;
/* The value associated with this token, if any. */
tree value;
/* The location at which this token was found. */
location_t location;
} c_token;
--
Summary: c-parser.c puts pragma_kind as a 7 bit field, when 8
will generate better code
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at the-meissners dot org
GCC build triplet: x86_64-gnu-linux
GCC host triplet: x86_64-gnu-linux
GCC target triplet: x86_64-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38416
[Bug testsuite/38025] [4.4 Regression] gcc.target/spu/intrinsics-1.c test fails
--- Comment #4 from gnu at the-meissners dot org 2008-12-02 23:26 --- Patch applied to tree on November 5th. -- gnu at the-meissners dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38025
[Bug target/38025] New: gcc.target/spu/intrinsics-1.c test fails
The testsuite gcc.target/spu/intrinsics-1.c fails with a compilation error: /home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c: In function f: /home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:12: error: parameter list does not match a valid signature for spu_cmpgt() /home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:13: warning: passing argument 2 of __builtin_spu_cmpgt_11 makes integer from pointer without a cast /home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:13: note: expected int but argument is of type int * /home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:14: error: parameter list does not match a valid signature for spu_cmpgt() /home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:16: note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts /home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:16: error: incompatible types when assigning to type int __vector__ from type unsigned int __vector__ -- Summary: gcc.target/spu/intrinsics-1.c test fails Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at the-meissners dot org GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38025
[Bug target/37841] New: SPU compiler is not complaint with the ABI
Functions with more than 72 arguments, pass char/short arguments 73 and higher in the wrong position in the quadword stored on the stack. This is due to the char/short not being at offset 0 of the word (char/short are stored in the bottom of the first int in the quadword). -- Summary: SPU compiler is not complaint with the ABI Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at the-meissners dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37841
[Bug target/36936] [4.4 Regression]: Revision 138075 breaks cmove
--- Comment #5 from gnu at the-meissners dot org 2008-07-25 18:08 ---
Subject: Re: [4.4 Regression]: Revision 138075 breaks
cmove
On Fri, Jul 25, 2008 at 05:15:17PM -, hjl dot tools at gmail dot com wrote:
>
>
> --- Comment #3 from hjl dot tools at gmail dot com 2008-07-25 17:15
> ---
> (In reply to comment #2)
> >
> > However, that would break using attribute((option("arch=i386"))) to turn off
> > cmoves. I suspect the patch needs to be reworked.
> >
>
> Does revision 138075 include a testcase for this?
No, but I was trying to explain what the motativation for the line was.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36936
[Bug target/36936] [4.4 Regression]: Revision 138075 breaks cmove
--- Comment #2 from gnu at the-meissners dot org 2008-07-25 16:45 ---
Subject: Re: [4.4 Regression]: Revision 138075 breaks
cmove
On Fri, Jul 25, 2008 at 03:36:51PM -, hjl dot tools at gmail dot com wrote:
>
>
> --- Comment #1 from hjl dot tools at gmail dot com 2008-07-25 15:36
> ---
> I believe this bug was introduced by
>
> @@ -2743,11 +3118,13 @@ override_options (void)
>&& !(target_flags & MASK_ACCUMULATE_OUTGOING_ARGS))
> {
>if (target_flags_explicit & MASK_ACCUMULATE_OUTGOING_ARGS)
> - warning (0, "stack probing requires -maccumulate-outgoing-args "
> -"for correctness");
> + warning (0, "stack probing requires %saccumulate-outgoing-args%s "
> +"for correctness", prefix, suffix);
>target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS;
> }
>
> + TARGET_CMOVE = 0;
> +
>/* For sane SSE instruction set generation we need fcomi instruction.
> It is safe to enable all CMOVE instructions. */
>if (TARGET_SSE)
However, that would break using attribute((option("arch=i386"))) to turn off
cmoves. I suspect the patch needs to be reworked.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36936
[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #20 from gnu at the-meissners dot org 2008-07-24 20:21 --- Subject: Re: [4.4 Regression]: Gcc failed to bootstrap On Thu, Jul 24, 2008 at 08:14:35PM -, hjl dot tools at gmail dot com wrote: > > > --- Comment #19 from hjl dot tools at gmail dot com 2008-07-24 20:14 > --- > (In reply to comment #18) > > Subject: Re: [4.4 Regression]: Gcc failed to bootstrap > > > > Yes, I came to the same conclusion when trying a bootstrap. This patch > > adds a > > new SECONDARY_OVERRIDE_OPTION to be run in the recursive case, and defined > > it > > in the ia64. > > > > Don't we also need it for i386 to handle > > /* When scheduling description is not available, disable scheduler pass > so it won't slow down the compilation and make x87 code slower. */ > if (!TARGET_SCHEDULE) > flag_schedule_insns_after_reload = flag_schedule_insns = 0; You are right those should be added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #18 from gnu at the-meissners dot org 2008-07-24 20:11 ---
Subject: Re: [4.4 Regression]: Gcc failed to bootstrap
On Thu, Jul 24, 2008 at 07:33:01PM -, hjl dot tools at gmail dot com wrote:
>
>
> --- Comment #17 from hjl dot tools at gmail dot com 2008-07-24 19:32
> ---
> (In reply to comment #16)
> > I haven't done a bootstrap built yet, but could you try this patch on the
> > ia-64? When I try it via a cross compiler, it works fine, but I wonder
> > whether
> > random ports will do weird things (like leak memory) if OVERRIDE_OPTIONS is
> > run
> > a second time. I suspect we may need a macro that says whether it is safe
> > to
> > run OVERRIDE_OPTIONS a second time.
> >
> > 2008-07-24 Michael Meissner <[EMAIL PROTECTED]>
> >
> > * opts.c (decode_options): Rerun OVERRIDE_OPTIONS when being run a
> > second time to allow the backend to override the default options.
> >
>
> Taking a look at override_options in i386.c, I am not sure
> running it more than once is a good idea.
Yes, I came to the same conclusion when trying a bootstrap. This patch adds a
new SECONDARY_OVERRIDE_OPTION to be run in the recursive case, and defined it
in the ia64.
2008-07-24 Michael Meissner <[EMAIL PROTECTED]>
* opts.c (decode_options): Run SECONDARY_OVERRIDE_OPTIONS if it is
defined when being run a second time to allow the backend to
override the default options.
* config/ia64/ia64.h (SECONDARY_OVERRIDE_OPTIONS): Define to be
the same as OVERRIDE_OPTIONS.
* doc/tm.texi (SECONDARY_OVERRIDE_OPTIONS): Document.
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 138117)
+++ gcc/doc/tm.texi (working copy)
@@ -814,6 +814,12 @@ Don't use this macro to turn on various
@option{-O}. That is what @code{OPTIMIZATION_OPTIONS} is for.
@end defmac
[EMAIL PROTECTED] SECONDARY_OVERRIDE_OPTIONS
+This is similar to @code{OVERRIDE_OPTIONS} but it is run after the
+compiler processes the @code{optimize}, @code{hot}, or @code{cold}
+attributes to change the optimization options.
[EMAIL PROTECTED] defmac
+
@defmac C_COMMON_OVERRIDE_OPTIONS
This is similar to @code{OVERRIDE_OPTIONS} but is only used in the C
language frontends (C, Objective-C, C++, Objective-C++) and so can be
Index: gcc/opts.c
===
--- gcc/opts.c (revision 138117)
+++ gcc/opts.c (working copy)
@@ -1066,6 +1066,12 @@ decode_options (unsigned int argc, const
flag_unwind_tables = targetm.unwind_tables_default;
}
+#ifdef SECONDARY_OVERRIDE_OPTIONS
+ /* Some machines may reject certain combinations of options. */
+ if (! first_time_p)
+SECONDARY_OVERRIDE_OPTIONS;
+#endif
+
#ifdef OPTIMIZATION_OPTIONS
/* Allow default optimizations to be specified on a per-machine basis. */
OPTIMIZATION_OPTIONS (optimize, optimize_size);
Index: gcc/config/ia64/ia64.h
===
--- gcc/config/ia64/ia64.h (revision 138117)
+++ gcc/config/ia64/ia64.h (working copy)
@@ -121,6 +121,11 @@ extern enum processor_type ia64_tune;
#define OVERRIDE_OPTIONS ia64_override_options ()
+/* Like OVERRIDE_OPTIONS, but run after the optimize, hot, or cold attributes
+ are processed. */
+
+#define SECONDARY_OVERRIDE_OPTIONS ia64_override_options ()
+
/* Some machines may desire to change what optimizations are performed for
various optimization levels. This macro, if defined, is executed once just
after the optimization level is determined and before the remainder of the
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #16 from gnu at the-meissners dot org 2008-07-24 19:19 --- Subject: Re: [4.4 Regression]: Gcc failed to bootstrap On Thu, Jul 24, 2008 at 05:49:02PM -, hjl dot tools at gmail dot com wrote: > > > --- Comment #15 from hjl dot tools at gmail dot com 2008-07-24 17:49 > --- > I don't think the middle-end should change optimization options > which have been overridden by the backend. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. I haven't done a bootstrap built yet, but could you try this patch on the ia-64? When I try it via a cross compiler, it works fine, but I wonder whether random ports will do weird things (like leak memory) if OVERRIDE_OPTIONS is run a second time. I suspect we may need a macro that says whether it is safe to run OVERRIDE_OPTIONS a second time. 2008-07-24 Michael Meissner <[EMAIL PROTECTED]> * opts.c (decode_options): Rerun OVERRIDE_OPTIONS when being run a second time to allow the backend to override the default options. Index: gcc/opts.c === --- gcc/opts.c (revision 138117) +++ gcc/opts.c (working copy) @@ -1066,6 +1066,12 @@ decode_options (unsigned int argc, const flag_unwind_tables = targetm.unwind_tables_default; } +#ifdef OVERRIDE_OPTIONS + /* Some machines may reject certain combinations of options. */ + if (! first_time_p) +OVERRIDE_OPTIONS; +#endif + #ifdef OPTIMIZATION_OPTIONS /* Allow default optimizations to be specified on a per-machine basis. */ OPTIMIZATION_OPTIONS (optimize, optimize_size); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
[Bug bootstrap/36918] [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c
--- Comment #5 from gnu at the-meissners dot org 2008-07-24 18:49 --- Subject: Re: [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c On Thu, Jul 24, 2008 at 06:36:20PM -, andreast at gcc dot gnu dot org wrote: > > > --- Comment #3 from andreast at gcc dot gnu dot org 2008-07-24 18:36 > --- > I bootstrapped choice 1. No regressions. > > I also prefer to save space where possible. So I'd like to avoid choice 3. > > Can we also use 255 or 127 as value for DEFAULT_PCC_STRUCT_RETURN? Just to echo what I said in IRC for bugzilla, right now you can use 255 or 127. Using 127 is perhaps better in case the default is changed to use signed bytes in the future, and 127 will work either way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36918
[Bug bootstrap/36918] [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c
--- Comment #2 from gnu at the-meissners dot org 2008-07-24 18:26 --- Subject: Re: [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c On Thu, Jul 24, 2008 at 05:21:10PM -, ro at gcc dot gnu dot org wrote: > > > --- Comment #1 from ro at gcc dot gnu dot org 2008-07-24 17:21 --- > Michael, could you have a look? This seems to have been introduced by this > change: > > 2008-07-23 Michael Meissner <[EMAIL PROTECTED]> > Karthik Kumar <[EMAIL PROTECTED]> > [...] > * optc-gen.awk: Add support for TargetSave to allow a back end to > declare new fields that need to be saved when using function > specific options. Include flags.h and target.h in the options.c > source. Add support for Save to indicate which options can be set > for individual functions. Generate cl_optimize_save, > cl_optimize_restore, cl_optimize_print, cl_target_option_save, > cl_target_option_restore, cl_target_option_print functions to > allow functions to use different optimization or target options. > > and sparc-sun-solaris2.10 is primary platform for 4.4. > > > -- > > ro at gcc dot gnu dot org changed: > >What|Removed |Added > ------------------------ > CC||gnu at the-meissners dot org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36918 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. This is due to DEFAULT_PCC_STRUCT_RETURN being defined as -1. The code to store and restore optimization options is trying to use smaller amount of space, and so it stores the flag values into an unsigned byte instead of an int. The code in question is doing an assert to make sure that the value is in range, so that when the value is restored, it get the same value. Three possible solutions exist: 1) In sparc.h change DEFAULT_PCC_STRUCT_RETURN to be 2 instead of -1; 2) Change the default space to be signed bytes instead of unsigned; 3) Save ints instead of bytes and don't try to save space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36918
[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #10 from gnu at the-meissners dot org 2008-07-23 19:06 --- Subject: Re: [4.4 Regression]: Gcc failed to bootstrap On Wed, Jul 23, 2008 at 01:46:30PM -, hjl dot tools at gmail dot com wrote: > > > --- Comment #4 from hjl dot tools at gmail dot com 2008-07-23 13:46 > --- > (In reply to comment #3) > > The problem on Fedora 9/x86-64 may be due to FILE is undeclared in > > > > extern void cl_optimization_print (FILE *, int, struct cl_optimization *); > > extern void cl_target_option_print (FILE *, int, struct cl_target_option *); > > > > in options.h. > > > > It happens when building libobjc. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. I checked in the patch as revision 138091. Sorry about the breakage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
[Bug bootstrap/36907] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #6 from gnu at the-meissners dot org 2008-07-23 15:22 ---
Subject: Re: [4.4 Regression]: Gcc failed to bootstrap
On Wed, Jul 23, 2008 at 01:46:30PM -, hjl dot tools at gmail dot com wrote:
>
>
> --- Comment #4 from hjl dot tools at gmail dot com 2008-07-23 13:46
> ---
> (In reply to comment #3)
> > The problem on Fedora 9/x86-64 may be due to FILE is undeclared in
> >
> > extern void cl_optimization_print (FILE *, int, struct cl_optimization *);
> > extern void cl_target_option_print (FILE *, int, struct cl_target_option *);
> >
> > in options.h.
> >
>
> It happens when building libobjc.
I didn't have objective c, java, or ADA on the system. I'm going to kick off a
build shortly with the following patch to see if it allows objc to build:
Index: gcc/optc-gen.awk
===
--- gcc/optc-gen.awk(revision 138086)
+++ gcc/optc-gen.awk(working copy)
@@ -225,7 +225,7 @@ for (i = 0; i < n_opts; i++) {
print "};"
print "";
-print "#if !defined(GCC_DRIVER) && !defined(IN_LIBGCC2)"
+print "#if !defined(GCC_DRIVER) && !defined(IN_LIBGCC2) &&
!defined(IN_TARGET_LIBS)"
print "";
print "/* Save optimization variables into a structure. */"
print "void";
Index: gcc/opth-gen.awk
===
--- gcc/opth-gen.awk(revision 138086)
+++ gcc/opth-gen.awk(working copy)
@@ -95,7 +95,7 @@ print ""
# Also, order the structure so that pointer fields occur first, then int
# fields, and then char fields to provide the best packing.
-print "#if !defined(GCC_DRIVER) && !defined(IN_LIBGCC2)"
+print "#if !defined(GCC_DRIVER) && !defined(IN_LIBGCC2) &&
!defined(IN_TARGET_LIBS)"
print ""
print "/* Structure to save/restore optimization and target specific options.
*/";
print "struct cl_optimization GTY(())";
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
[Bug tree-optimization/36436] -ftree-vrp -O1 -msse5 -ftree-vectorize leads to segfault during garbage collection
--- Comment #1 from gnu at the-meissners dot org 2008-06-04 19:36 --- Created an attachment (id=15719) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15719&action=view) Preprocessed source code that shows the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36436
[Bug tree-optimization/36436] New: -ftree-vrp -O1 -msse5 -ftree-vectorize leads to segfault during garbage collection
If I compile the attached preprocessed file with -O1 -msse5 -ftree-vectorize -ftree-vrp (or -O3), the compiler does a segmentation fault while garbage collecting. If I use the -fno-tree-vrp switch, the program compiles fine, even with -O3. (gdb) r -O1 -msse5 -ftree-vectorize -ftree-vrp sse5.i Starting program: /data-gold1/fsf-build/trunk/gcc/cc1 -O1 -msse5 -ftree-vectorize -ftree-vrp sse5.i vprintf getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar fputc_unlocked putc_unlocked putchar_unlocked feof_unlocked ferror_unlocked atof atoi atol atoll gnu_dev_major gnu_dev_minor gnu_dev_makedev __strcspn_c1 __strcspn_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3 __strpbrk_c2 __strpbrk_c3 __strtok_r_1c __strsep_1c __strsep_2c __strsep_3c _mm_empty _m_empty _mm_cvtsi32_si64 _m_from_int _m_from_int64 _mm_cvtsi64_m64 _mm_cvtsi64x_si64 _mm_set_pi64x _mm_cvtsi64_si32 _m_to_int _m_to_int64 _mm_cvtm64_si64 _mm_cvtsi64_si64x _mm_packs_pi16 _m_packsswb _mm_packs_pi32 _m_packssdw _mm_packs_pu16 _m_packuswb _mm_unpackhi_pi8 _m_punpckhbw _mm_unpackhi_pi16 _m_punpckhwd _mm_unpackhi_pi32 _m_punpckhdq _mm_unpacklo_pi8 _m_punpcklbw _mm_unpacklo_pi16 _m_punpcklwd _mm_unpacklo_pi32 _m_punpckldq _mm_add_pi8 _m_paddb _mm_add_pi16 _m_paddw _mm_add_pi32 _m_paddd _mm_add_si64 _mm_adds_pi8 _m_paddsb _mm_adds_pi16 _m_paddsw _mm_adds_pu8 _m_paddusb _mm_adds_pu16 _m_paddusw _mm_sub_pi8 _m_psubb _mm_sub_pi16 _m_psubw _mm_sub_pi32 _m_psubd _mm_sub_si64 _mm_subs_pi8 _m_psubsb _mm_subs_pi16 _m_psubsw _mm_subs_pu8 _m_psubusb _mm_subs_pu16 _m_psubusw _mm_madd_pi16 _m_pmaddwd _mm_mulhi_pi16 _m_pmulhw _mm_mullo_pi16 _m_pmullw _mm_sll_pi16 _m_psllw _mm_slli_pi16 _m_psllwi _mm_sll_pi32 _m_pslld _mm_slli_pi32 _m_pslldi _mm_sll_si64 _m_psllq _mm_slli_si64 _m_psllqi _mm_sra_pi16 _m_psraw _mm_srai_pi16 _m_psrawi _mm_sra_pi32 _m_psrad _mm_srai_pi32 _m_psradi _mm_srl_pi16 _m_psrlw _mm_srli_pi16 _m_psrlwi _mm_srl_pi32 _m_psrld _mm_srli_pi32 _m_psrldi _mm_srl_si64 _m_psrlq _mm_srli_si64 _m_psrlqi _mm_and_si64 _m_pand _mm_andnot_si64 _m_pandn _mm_or_si64 _m_por _mm_xor_si64 _m_pxor _mm_cmpeq_pi8 _m_pcmpeqb _mm_cmpgt_pi8 _m_pcmpgtb _mm_cmpeq_pi16 _m_pcmpeqw _mm_cmpgt_pi16 _m_pcmpgtw _mm_cmpeq_pi32 _m_pcmpeqd _mm_cmpgt_pi32 _m_pcmpgtd _mm_setzero_si64 _mm_set_pi32 _mm_set_pi16 _mm_set_pi8 _mm_setr_pi32 _mm_setr_pi16 _mm_setr_pi8 _mm_set1_pi32 _mm_set1_pi16 _mm_set1_pi8 _mm_malloc _mm_free _mm_setzero_ps _mm_add_ss _mm_sub_ss _mm_mul_ss _mm_div_ss _mm_sqrt_ss _mm_rcp_ss _mm_rsqrt_ss _mm_min_ss _mm_max_ss _mm_add_ps _mm_sub_ps _mm_mul_ps _mm_div_ps _mm_sqrt_ps _mm_rcp_ps _mm_rsqrt_ps _mm_min_ps _mm_max_ps _mm_and_ps _mm_andnot_ps _mm_or_ps _mm_xor_ps _mm_cmpeq_ss _mm_cmplt_ss _mm_cmple_ss _mm_cmpgt_ss _mm_cmpge_ss _mm_cmpneq_ss _mm_cmpnlt_ss _mm_cmpnle_ss _mm_cmpngt_ss _mm_cmpnge_ss _mm_cmpord_ss _mm_cmpunord_ss _mm_cmpeq_ps _mm_cmplt_ps _mm_cmple_ps _mm_cmpgt_ps _mm_cmpge_ps _mm_cmpneq_ps _mm_cmpnlt_ps _mm_cmpnle_ps _mm_cmpngt_ps _mm_cmpnge_ps _mm_cmpord_ps _mm_cmpunord_ps _mm_comieq_ss _mm_comilt_ss _mm_comile_ss _mm_comigt_ss _mm_comige_ss _mm_comineq_ss _mm_ucomieq_ss _mm_ucomilt_ss _mm_ucomile_ss _mm_ucomigt_ss _mm_ucomige_ss _mm_ucomineq_ss _mm_cvtss_si32 _mm_cvt_ss2si _mm_cvtss_si64 _mm_cvtss_si64x _mm_cvtps_pi32 _mm_cvt_ps2pi _mm_cvttss_si32 _mm_cvtt_ss2si _mm_cvttss_si64 _mm_cvttss_si64x _mm_cvttps_pi32 _mm_cvtt_ps2pi _mm_cvtsi32_ss _mm_cvt_si2ss _mm_cvtsi64_ss _mm_cvtsi64x_ss _mm_cvtpi32_ps _mm_cvt_pi2ps _mm_cvtpi16_ps _mm_cvtpu16_ps _mm_cvtpi8_ps _mm_cvtpu8_ps _mm_cvtpi32x2_ps _mm_cvtps_pi16 _mm_cvtps_pi8 _mm_shuffle_ps _mm_unpackhi_ps _mm_unpacklo_ps _mm_loadh_pi _mm_storeh_pi _mm_movehl_ps _mm_movelh_ps _mm_loadl_pi _mm_storel_pi _mm_movemask_ps _mm_getcsr _MM_GET_EXCEPTION_STATE _MM_GET_EXCEPTION_MASK _MM_GET_ROUNDING_MODE _MM_GET_FLUSH_ZERO_MODE _mm_setcsr _MM_SET_EXCEPTION_STATE _MM_SET_EXCEPTION_MASK _MM_SET_ROUNDING_MODE _MM_SET_FLUSH_ZERO_MODE _mm_set_ss _mm_set1_ps _mm_set_ps1 _mm_load_ss _mm_load1_ps _mm_load_ps1 _mm_load_ps _mm_loadu_ps _mm_loadr_ps _mm_set_ps _mm_setr_ps _mm_store_ss _mm_cvtss_f32 _mm_store_ps _mm_storeu_ps _mm_store1_ps _mm_store_ps1 _mm_storer_ps _mm_move_ss _mm_extract_pi16 _m_pextrw _mm_insert_pi16 _m_pinsrw _mm_max_pi16 _m_pmaxsw _mm_max_pu8 _m_pmaxub _mm_min_pi16 _m_pminsw _mm_min_pu8 _m_pminub _mm_movemask_pi8 _m_pmovmskb _mm_mulhi_pu16 _m_pmulhuw _mm_shuffle_pi16 _m_pshufw _mm_maskmove_si64 _m_maskmovq _mm_avg_pu8 _m_pavgb _mm_avg_pu16 _m_pavgw _mm_sad_pu8 _m_psadbw _mm_prefetch _mm_stream_pi _mm_stream_ps _mm_sfence _mm_pause _mm_set_sd _mm_set1_pd _mm_set_pd1 _mm_set_pd _mm_setr_pd _mm_setzero_pd _mm_move_sd _mm_load_pd _mm_loadu_pd _mm_load1_pd _mm_load_sd _mm_load_pd1 _mm_loadr_pd _mm_store_pd _mm_storeu_pd _mm_store_sd _mm_cvtsd_f64 _mm_storel_pd _mm_storeh_pd _mm_store1_pd _mm_store_pd1 _mm_storer_pd _mm_cvtsi128_si32 _mm_cvtsi128_si64 _mm_cvtsi128_si64x _mm_add_pd _mm_add_sd _mm_sub_pd _mm_sub_sd _mm_mul_pd _mm_mul_sd _mm_div_pd _mm_div_sd _mm_sqrt_pd _mm_sqrt_sd _mm_min_pd _mm_min_sd _mm_m
[Bug target/36224] vec_widen_smult_{hi,lo}_v4si generates pmuludq instruction
--- Comment #1 from gnu at the-meissners dot org 2008-05-12 20:00 --- Created an attachment (id=15631) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15631&action=view) Test case for bug 36224 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36224
[Bug target/36224] New: vec_widen_smult_{hi,lo}_v4si generates pmuludq instruction
The vec_widen_smult_{hi,lo}_v4si functions are incorrect, in that they generate
the pmuludq instruction, which does a 32x32->64 unsigned multiply. For
example, multiplying -13 * 15 = gives 64424509245 with the current code, when
it should give -195.
The sse5 instructions pmacsdqh and pmacsdql could do this instruction, but not
anything in the standard sse2 set.
--
Summary: vec_widen_smult_{hi,lo}_v4si generates pmuludq
instruction
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at the-meissners dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36224
[Bug regression/36039] -ftree-vectorize aborts on simple integer multiply vectorization
--- Comment #1 from gnu at the-meissners dot org 2008-04-24 21:49 --- Created an attachment (id=15528) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15528&action=view) This is the test case that fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36039
[Bug regression/36039] New: -ftree-vectorize aborts on simple integer multiply vectorization
=OPTAB_LIB_WIDEN) at
/proj/gcc/fsf-src/gcc-4_2-branch/gcc/optabs.c:1156
(gdb) c
Continuing.
Breakpoint 3, expand_simple_binop (mode=V2SImode, code=VEC_SELECT,
op0=0x2f777ae0, op1=0x2f76c640, target=0x0, unsignedp=1,
methods=OPTAB_LIB_WIDEN) at /proj/gcc/fsf-src/gcc-4_2-branch/gcc/optabs.c:1156
(gdb) print op0
$4 = (rtx) 0x2f777ae0
(gdb) pr
(reg:V4SI 87)
(gdb) print op1
$5 = (rtx) 0x2f76c640
(gdb) pr
(parallel [
(const_int 0 [0x0])
(const_int 2 [0x2])
])
(gdb) print code
$6 = VEC_SELECT
(gdb) print binop
$7 = (optab) 0x0
(gdb) whatis code_to_optab
type = optab [125]
(gdb) print/x code
$8 = 0x0
(gdb) up
#1 0x0055fa7d in force_operand (value=0x2f773660, target=0x0) at
/proj/gcc/fsf-src/gcc-4_2-branch/gcc/expr.c:6084
--
Summary: -ftree-vectorize aborts on simple integer multiply
vectorization
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at the-meissners dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36039
[Bug target/22599] ICE with invalid asm usage
--- Additional Comments From gnu at the-meissners dot org 2005-07-22 03:54 --- I forgot to mention, the patch was against the mainline, sources current as of July 20th. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22599
[Bug rtl-optimization/17692] gcc -O hangs on glnxa64
--- Additional Comments From gnu at the-meissners dot org 2005-07-06 21:46 --- I compiled the sample on 3.3.6, and it did appear to hang. The memory usage wasn't that much, so it doesn't look like page faulting itself to death. The last phase that dumps its output with -da is 18.life, and 19.combine is empty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17692
[Bug rtl-optimization/17692] gcc -O hangs on glnxa64
--- Additional Comments From gnu at the-meissners dot org 2005-07-06 20:59
---
3.4.4 compiles the file fine on a machine with 2 gigabytes of local memory. It
may be that the machine you were using is thrashing itself to death.
4.0.0 and 4.0.1-20050702 both give the following error:
gcc_glnxa64_hang.c: In function â:
gcc_glnxa64_hang.c:164: error: could not split insn
(insn:TI 676 664 759 (parallel [
(set (reg:DF 21 xmm0 [orig:59 t2$1 ] [59])
(if_then_else:DF (ungt:DF (reg:DF 21 xmm0 [orig:59 t2$1 ] [59])
(reg:DF 21 xmm0 [orig:58 t2$0 ] [58]))
(reg:DF 21 xmm0 [orig:59 t2$1 ] [59])
(reg:DF 21 xmm0 [orig:58 t2$0 ] [58])))
(clobber (reg:V2DF 22 xmm1))
]) 662 {*movdfcc_1_sse} (nil)
(expr_list:REG_UNUSED (reg:V2DF 22 xmm1)
(nil)))
gcc_glnxa64_hang.c:164: internal compiler error: in final_scan_insn, at
final.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
It is fixed on the mainline (checked on July 6th).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17692
[Bug target/15397] [g77] c float function called from fortran gives wrong result
--- Additional Comments From gnu at the-meissners dot org 2005-07-06 19:22 --- FWIW, I tried this with the 4.0 compiler on an AMD64 system, and it doesn't fail with gfortran. I did bring over the 3.4.4 release, and tried it with g77, and it failed as reported. It passed if I used -m32 with the traditional x86 calling sequence. If I link the 3.4.4 fortran object with the 4.0.0 C object, it fails. If I link the 4.0.0 fortran with the 3.4.4 C object, it passes. Looking at the code for -O1, between 3.4.4 and 4.0.0, I see, the 4.0.0 generates: callfunct2_ movss %xmm0, 12(%rsp) and the 3.4.4 fortran generates: callfunct2_ cvtsd2ss%xmm0, %xmm0 movss %xmm0, 16(%rsp) Ie, g77 is expecting float values to be returned as a double, and then doing the conversion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15397
