[Bug fortran/28167] New: ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)
Here's another ICE, probably related to temporary character arrays:
gfcbug34.f90: In function 'MAIN__':
gfcbug34.f90:1: internal compiler error: in fold_binary, at fold-const.c:8239
It dies on:
call foo ( (/ (' ',i=1,m) /) )
Testcase attached.
Cheers,
-ha
--
Summary: ICE: in fold_binary, at fold-const.c:8239 (temporary
character array?)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anlauf at gmx dot de
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28167
[Bug fortran/28167] ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)
--- Comment #1 from anlauf at gmx dot de 2006-06-26 07:53 --- Created an attachment (id=11755) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11755&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28167
[Bug fortran/28167] ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-26 08:24 --- Confirmed. We end up in gfc_trans_create_temp_array size = fold_build2 (MULT_EXPR, gfc_array_index_type, size, TYPE_SIZE_UNIT (gfc_get_element_type (type))); with type being a record type 'struct array1_unknown', so TYPE_SIZE_UNIT (gfc_get_element_type (type)) returns zero. gfc_get_element_type (type) returns charD.14[1:] (!??), so maybe the fix is to use TYPE_SIZE_UNIT (TREE_TYPE (... ))) here. (This doesn't fix it, we also pass size == 0 to the MULT_EXPR, so we'll end up with a size of zero here) So maybe the bug is that size and nelem are both zero... who knows ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-06-26 08:24:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28167
[Bug tree-optimization/28144] floating point constant -> byte/char/short conversion is wrong for java
--- Comment #2 from aph at gcc dot gnu dot org 2006-06-26 09:45 --- Thank you for this patch. It seems to be a patch for the core constant folding code. Would it not be more appropriate to do this in the Java front end's function convert() (in java/typeck.c) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144
[Bug tree-optimization/28144] floating point constant -> byte/char/short conversion is wrong for java
--- Comment #3 from joern dot rennecke at st dot com 2006-06-26 11:19 --- Subject: Re: floating point constant -> byte/char/short conversion is wrong for java aph at gcc dot gnu dot org wrote: >--- Comment #2 from aph at gcc dot gnu dot org 2006-06-26 09:45 --- >Thank you for this patch. > >It seems to be a patch for the core constant folding code. Would it not be >more >appropriate to do this in the Java front end's function convert() (in >java/typeck.c) ? > > The current implementation has been patched allegedly for the benefit of java, with the side effect of giving different results between -O0 and -O1 for some (unspecified or undefined) conversions for C/C++. Having user bugs masked by -O0 makes debugging harder, so this is a quality of implementation issue. The proposed patch would also address this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144
[Bug c++/28169] New: Tertiary operator: object creation and initialization
This is totally unexpected (for me atleast
) behaviour I encountered in C++. I
was using g++ version 3.4.2 (DevC++)
class Base{
public:
Base() { cout << "Base ctor..." << endl; }
virtual ~Base() { cout << "~Base called..." << endl; }
virtual void Show() const
{
cout << "Base show called..." << endl;
}
};
class Derived: public Base{
public:
Derived() { cout << "Derived ctor..." << endl; }
~Derived() { cout << "~Derived called..." << endl; }
virtual void Show() const
{
cout << "Derived show called..." << endl;
}
};
Now I used the tertiary operator to create the objects of derived and base.
Following is the piece of code which does this
{
bool bFlag = false;
const Base& ref = (bFlag)? Base(): Derived();
ref.Show();
}
This code works as expected when the value of "bFlag" is true but the whole
problem come when the value of bFlag is false
Output
Base ctor...
Derived ctor...
~Derived called...
~Base called...
Base show called...
~Base called...
So you might notice that the destructor of Derived class is being called before
the function Sow is called. And more over the Show function called is of Base
instead of Derived
.i.e. Instead of Derived's object Base's object is created..
Extract from the C++ standard!!!
=> if the second and third operand have different types, and either has
(possibly cv-qualified) class type, an attempt is made to convert each of those
operands to the type of the other. The process for determining whether an
operand expression E1 of type T1 can be converted to match an operand
expression E2 of type T2 is defined as follows:
.. if E1 and E2 have class type, and the underlying class types are the same
or one is a base class of the other: E1 can be converted to match E2 if the
class of T2 is the same type as, or a base class of, the class of T1, and the
cv-qualification of T2 is the same cv-qualification as, or a greater
cvqualification than, the cv-qualification of T1. If the conversion is applied,
E1 is changed to an rvalue of type T2 that still refers to the original source
class object (or the appropriate subobject thereof). [Note: that is, no copy is
made.]
..
Using this process, it is determined whether the second operand can be
converted to match the third operand, and whether the third operand can be
converted to match the second operand. If both can be converted, or one can be
converted but the conversion is ambiguous, the program is ill-formed. If
neither can be converted, the operands are left unchanged and further checking
is performed as described below. If exactly one conversion is possible, that
conversion is applied to the chosen operand and the converted operand is used
in place of the original operand for the remainder of this section.
Opinion
Therefore, it is clear that a conversion is taking place but it is also made
clear that no copy is made "E1 is changed to an rvalue of type T2 that still
refers to the original source class object (or the appropriate subobject
thereof). [Note: that is, no copy is made.]"
. Therefore in the above example a
copy of "Base" is made instead of refering to "Derived" class object (can be
confirmed by checking the call to Show function). Which I think is a bug in
gcc.
--
Summary: Tertiary operator: object creation and initialization
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joseph dot rajesh at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28169
[Bug middle-end/28075] [4.1 Regression] inliner introduces unnecessary type conversions
--- Comment #7 from danglin at gcc dot gnu dot org 2006-06-26 13:45 --- This test is still failing on hppa64-hp-hpux11.11. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug middle-end/28075] [4.1 Regression] inliner introduces unnecessary type conversions
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-26 13:47 --- Subject: Re: [4.1 Regression] inliner introduces unnecessary type conversions Attached dump. Dave --- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-26 13:47 --- Created an attachment (id=11757) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11757&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug middle-end/26991] Target Help Seg Fault.
--- Comment #2 from corsepiu at gcc dot gnu dot org 2006-06-26 14:34 --- # m68k-rtems4.7-gcc --target-help Target specific options: cc1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. # m68k-rtems4.7-gcc --target-help -v Using built-in specs. Target: m68k-rtems4.7 Configured with: ../gcc-4.1.1/configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=m68k-rtems4.7 --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: single gcc version 4.1.1 /usr/libexec/gcc/m68k-rtems4.7/4.1.1/cc1 -quiet -v help-dummy -quiet -dumpbase help-dummy -auxbase help-dummy -version --target-help -o /tmp/cclQfte8.s Target specific options: cc1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- corsepiu at gcc dot gnu dot org changed: What|Removed |Added CC||corsepiu at gcc dot gnu dot ||org Known to fail||4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #21 from whaley at cs dot utsa dot edu 2006-06-26 15:03 --- Uros, Thanks for the reply; I think some confusion has set in (see below) :) >And the results are a bit suprising (this is the exact output of your test): Note that you are running the opposite of my test case: SSE vs SSE rather than x87 vs x87. This whole bug report is about x87 performance. You can get more detail on why I want x87 in my messages above, particularly comment #11, but single precision is indeed the place where SSE cannot compete with the x87 unit. To see it, put the flags back the way I had them in the attachment, and you'll see that gcc 3 is much faster. Also, you should find in single precision that the x87 unit soundly beats the SSE unit (unlike double precision, where the gcc 3's x87 unit is only slightly faster than the best SSE code). I think the x87 will win even using gcc 4 for both compilations, even though gcc 4's x87 support is crippled by its new register allocation scheme. So, let me say what I think is going on here, and you can correct me if I've gotten it wrong. I think in this last timing you think you've found an exception to the problem, but have forgotten we want to look at the x87 (which is the fastest method in this case anyway). Try it with my original flags (essentially, throw '-mfpmath=387' instead of the sse flags), and you should see that this gives far better performance using gcc 3 than any use of scalar sse. I think even gcc 4 will be better using its de-optimized x87 code, because x87 is inherently better than scalar sse on these platforms. There is only one machine that likes the gcc 4's new x87 register usage pattern of all the ones I've tested, and that is the CoreDue. The issue is in x87 register usage: Gcc 4 saves a register, and does the FMUL from memory rather than first loading the value to the fpstack, and on at least the PentiumPRO, Pentium III, Pentium 4e, Pentium-D, Athlon-64 X2 and Opteron, that drops your x87 (which is your best) performance significantly. Note that given gcc 3's register usage, I think a simple peephole step can transform it to gcc 4's, if you want to maintain that usage for CoreDuo. Unfortunately, going the other way requires an additional register, and the load plays with your stack operands, so it is easier to keep gcc 3's way as the default, and peephole to gcc 4's when on a machine that likes that usage (currently, only the Core). Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug middle-end/28075] [4.1 Regression] inliner introduces unnecessary type conversions
--- Comment #10 from pinskia at gmail dot com 2006-06-26 16:02 --- Subject: Re: [4.1 Regression] inliner introduces unnecessary type conversions On Jun 26, 2006, at 6:45 AM, danglin at gcc dot gnu dot org wrote: > > > --- Comment #7 from danglin at gcc dot gnu dot org 2006-06-26 > 13:45 --- > This test is still failing on hppa64-hp-hpux11.11. Yes the test has a simple problem of also matching the type even without the "()", I have a fix but I have not applied it yet. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
[Bug middle-end/26991] Target Help Seg Fault.
--- Comment #3 from corsepiu at gcc dot gnu dot org 2006-06-26 16:41
---
Traceback:
Program received signal SIGSEGV, Segmentation fault.
print_filtered_help (flag=4194304) at ../../gcc-4.1.1/gcc/opts.c:1301
(gdb) where
#0 print_filtered_help (flag=4194304) at ../../gcc-4.1.1/gcc/opts.c:1301
#1 0x081f61d7 in decode_options (argc=13, argv=0xbfc6fc34) at
../../gcc-4.1.1/gcc/opts.c:738
#2 0x08243b08 in toplev_main (argc=13, argv=0xbfc6fc34) at
../../gcc-4.1.1/gcc/toplev.c:1975
#3 0x080978f2 in main (argc=0, argv=0x1f9) at ../../gcc-4.1.1/gcc/main.c:35
#4 0x00b68724 in __libc_start_main () from /lib/libc.so.6
#5 0x08049ad1 in _start ()
The offending code is this (From gcc-4.1.1/gcc/opts.c):
1293 const char *help, *opt, *tab;
1294 static char *printed;
1295
1296 if (flag == CL_COMMON || flag == CL_TARGET)
1297 {
1298 filter = flag;
1299 if (!printed)
1300 printed = xmalloc (cl_options_count);
1301 memset (printed, 0, cl_options_count);
1302 }
=> the SEGFAULT occurs in memset.
Could it be, "static char* printed" should be initialized = 0?
I.e. static char* printed = 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
Re: [Bug middle-end/26991] Target Help Seg Fault.
On Jun 26, 2006, at 9:41 AM, corsepiu at gcc dot gnu dot org wrote: --- Comment #3 from corsepiu at gcc dot gnu dot org 2006-06-26 16:41 --- Traceback: => the SEGFAULT occurs in memset. Could it be, "static char* printed" should be initialized = 0? Looks like reload is storing to cl_options_count :). There was a 4.2 bug about this, somehow it got exposed for 4.1.x now. -- Pinski
[Bug middle-end/26991] Target Help Seg Fault.
--- Comment #4 from pinskia at physics dot uc dot edu 2006-06-26 16:46 --- Subject: Re: Target Help Seg Fault. On Jun 26, 2006, at 9:41 AM, corsepiu at gcc dot gnu dot org wrote: > > > --- Comment #3 from corsepiu at gcc dot gnu dot org 2006-06-26 > 16:41 --- > Traceback: > > => the SEGFAULT occurs in memset. > > Could it be, "static char* printed" should be initialized = 0? Looks like reload is storing to cl_options_count :). There was a 4.2 bug about this, somehow it got exposed for 4.1.x now. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug middle-end/26991] [4.1 Regression] Target Help Seg Fault.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 GCC target triplet||i686-linux-gnu Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-06-26 16:47:30 date|| Summary|Target Help Seg Fault. |[4.1 Regression] Target Help ||Seg Fault. Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug middle-end/26991] [4.1 Regression] Target Help Seg Fault.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-26 16:48 --- PR 25636 was the 4.2.0 bug and the patch there should fix it if someone backports it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25636 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug middle-end/26991] [4.1 Regression] Target Help Seg Fault.
--- Comment #6 from corsepiu at gcc dot gnu dot org 2006-06-26 17:01 --- (In reply to comment #5) > PR 25636 was the 4.2.0 bug and the patch there should fix it if someone > backports it. For the record, the compiler exposing this is FC5's gcc-4.1.1-1.fc5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug middle-end/26991] [4.1 Regression] Target Help Seg Fault.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-26 17:06 --- (In reply to comment #6) > For the record, the compiler exposing this is FC5's gcc-4.1.1-1.fc5 For the record, that is not a FSF release so it should be reported directly to Redhat. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
--- Comment #1 from tromey at gcc dot gnu dot org 2006-06-26 17:22 --- Does the JDK's javah put that "_" into the generated header? I suspect that you are seeing a problem with the C compiler, not a problem with JNI header generation. In particular I think that "_", most likely, should be added by the C compiler and not added to the header. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug c++/28169] Tertiary operator: object creation and initialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-26 18:16 --- Here is what is happening currently with GCC: Base ctor... Derived ctor... Base copy ctor... ~Derived called... ~Base called... Base show called... ~Base called... So you missed the copy constructor, now I don't know if this is correct or not yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28169
[Bug c++/28169] Tertiary operator: object creation and initialization
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-26 18:18 --- Note ICC produces: Base ctor... Derived ctor... ~Derived called... ~Base called... Base show called... which might be just as bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28169
[Bug regression/28170] New: Wrong result after swap byte in one word when compiled in 64-bit mode
A simple byte swap routine gets the wrong result when compiled with -m64 and either -O1, -O2, -O3 or -Os. [EMAIL PROTECTED]:~> /opt/biarch/gcc41-base/bin/gcc -O1 -m64 badswap.c [EMAIL PROTECTED]:~> ./a.out Before: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 Result: 0x88 0x77 0x66 0x55 0x44 0x77 0x22 0x11 Expected: 0x88 0x77 0x66 0x55 0x44 0x33 0x22 0x11 Notice the third to last byte in "Result" is 0x77 when it should be 0x33. This works with -O0 and with gcc 3.4 or earlier versions. -- Summary: Wrong result after swap byte in one word when compiled in 64-bit mode Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bergner at vnet dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug regression/28170] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #1 from bergner at vnet dot ibm dot com 2006-06-26 18:42 --- Created an attachment (id=11758) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11758&action=view) Simple test case to show the problem. The bad code generation is in change_byte_order(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug regression/28170] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #2 from bergner at vnet dot ibm dot com 2006-06-26 18:44 --- Forgot to mention this fails on both the 4.1 branch and mainline. It does work with 3.4 and earlier versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug ada/28171] New: FAIL: cd5003h
RUN cd5003h /home/dave/gcc-4.2/objdir/gcc/xgcc -c -B/home/dave/gcc-4.2/objdir/gcc/ -gnatws - O2 -I/home/dave/gcc-4.2/objdir/gcc/testsuite/ada/acats/support cd5003h.adb /home/dave/gcc-4.2/objdir/gcc/xgcc -c -B/home/dave/gcc-4.2/objdir/gcc/ -gnatws - O2 -I/home/dave/gcc-4.2/objdir/gcc/testsuite/ada/acats/support cd5003h_pack3.adb /home/dave/gcc-4.2/objdir/gcc/xgcc -c -I./ -B/home/dave/gcc-4.2/objdir/gcc/ -gna tws -O2 -I/home/dave/gcc-4.2/objdir/gcc/testsuite/ada/acats/support -I- /home/da ve/gcc-4.2/objdir/gcc/testsuite/ada/acats/support/spprt13.ads /home/dave/gcc-4.2/objdir/gcc/xgcc -c -I./ -B/home/dave/gcc-4.2/objdir/gcc/ -gna tws -O2 -I/home/dave/gcc-4.2/objdir/gcc/testsuite/ada/acats/support -I- /home/da ve/gcc-4.2/objdir/gcc/testsuite/ada/acats/support/fcndecl.ads gnatbind -aO./ -I/home/dave/gcc-4.2/objdir/gcc/testsuite/ada/acats/support -I- - x cd5003h.ali gnatlink cd5003h.ali --GCC=/home/dave/gcc-4.2/objdir/gcc/xgcc -B/home/dave/gcc-4 .2/objdir/gcc/ /home/dave/gcc-4.2/gcc/gcc/testsuite/ada/acats/run_all.sh: line 16: /home/dave/g cc-4.2/objdir/gcc/testsuite/ada/acats/tests/cd/cd5003h/cd5003h: No such file or directory FAIL: cd5003h /home/dave/opt/gnu/bin/ld: b~cd5003h.o: No such file: No such file or directory collect2: ld returned 1 exit status gnatlink: cannot call /home/dave/gcc-4.2/objdir/gcc/xgcc gnatmake: *** link failed. The above fail doesn't occur all the time. This is what I see in tests/cd/cd5003h: [EMAIL PROTECTED]:~/gcc-4.2/objdir/gcc/testsuite/ada/acats/tests/cd/cd5003h$ ll total 52 -rw-r--r-- 1 dave users 8572 Jun 26 02:22 b~cd5003h.adb -rw-r--r-- 1 dave users 12313 Jun 26 02:22 b~cd5003h.ads -rw-r--r-- 1 dave users 177 Jun 26 02:22 cd5003h.adb -rw-r--r-- 1 dave users 170 Jun 26 02:22 cd5003h.log -rw-r--r-- 1 dave users12 Jun 26 02:22 cd5003h.lst -rw-r--r-- 1 dave users 850 Jun 26 02:22 cd5003h_pack3-pack4.adb -rw-r--r-- 1 dave users 154 Jun 26 02:22 cd5003h_pack3.adb -rw-r--r-- 1 dave users 1841 Jun 26 02:22 cd5003h_pack3.ads The log file contains: /home/dave/gcc-4.2/gcc/gcc/testsuite/ada/acats/run_all.sh: line 16: /home/dave/g cc-4.2/objdir/gcc/testsuite/ada/acats/tests/cd/cd5003h/cd5003h: No such file or directory -- Summary: FAIL: cd5003h Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28171
[Bug regression/28170] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #3 from bergner at vnet dot ibm dot com 2006-06-26 18:49 --- Janis performed a regression hunt on mainline and identified this patch as the start of the test failure: r83568 | dje | 2004-06-23 21:19:00 + (Wed, 23 Jun 2004) | 7 lines * config/rs6000/rs6000.c (rs6000_use_dfa_pipeline_interface): Delete. (TARGET_SCHED_USE_DFA_PIPELINE_INTERFACE): Redefine a hook_int_void_1. (insvdi_rshift_rlwimi_p): New function. * config/rs6000/rs6000.md (insvdi_internal2/3): New patterns. (extendsfdf2): Convert to define_insn_and_split. * config/rs6000/rs6000-protos.h (insvdi_rshift_rlwimi_p): Prototype. http://gcc.gnu.org/viewcvs?view=rev&rev=83568 -- bergner at vnet dot ibm dot com changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug rtl-optimization/28170] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #4 from dje at gcc dot gnu dot org 2006-06-26 18:51 --- This appears to be a problem in the insvdi_internal2 and insvdi_internal3 combiner patterns. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-26 18:51:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|rtl-optimization|target Summary|Wrong result after swap byte|[4.1/4.2 Regression] Wrong |in one word when compiled in|result after swap byte in |64-bit mode |one word when compiled in ||64-bit mode Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/27363] ARM gcc 4.1 optimization bug
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-06-26 18:54 --- One thing we have is some extra virtual operands from CCP: before: : mask_5 = &old; v_7 = mask_6; # SFT.2_33 = V_MAY_DEF ; *mask_5 = *v_7; mask_8 = mask_6; v_10 = v_9; i_11 = 0; goto (); after: : mask_5 = &old; v_7 = mask_6; # SFT.2 = V_MUST_DEF ; # VUSE ; old = *v_7; mask_8 = mask_6; v_10 = v_9; i_11 = 0; goto (); all of the SFT.2 are actually the same tree object. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug middle-end/24427] missing optimization opportunity with binary operators
--- Comment #5 from ramana dot radhakrishnan at codito dot com 2006-06-26
19:13 ---
This should be reopened. A related testcase shows a regression from 3.4.6 to
4.1.1 for m68k-elf shows a regression . combine used to take care of this in
3.4.6 . A backport of the patch is ready with me. If its allowed, I'll put it
up .
This is the test case .
#include
int i;
int main (void)
{
if ( ((i & ~1) | 1) != ( i | 1))
printf ("abc");
}
3.4.6 generated
.file "fail.c"
.text
.align 2
.globl foo
.type foo, @function
foo:
link.w %a6,#0
unlk %a6
rts
.size foo, .-foo
.comm i,4,2
.ident "GCC: (GNU) 3.4.6"
4.1.2 pre-release generates
.file "fail.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "abc"
.text
.align 2
.globl main
.type main, @function
main:
link.w %fp,#0
move.l %d2,-(%sp)
move.l i,%d1
moveq #-2,%d0
and.l %d1,%d0
moveq #1,%d2
or.l %d2,%d0
or.l %d2,%d1
cmp.l %d0,%d1
jbeq .L5
pea .LC0
jbsr printf
addq.l #4,%sp
.L5:
move.l -4(%fp),%d2
unlk %fp
rts
.size main, .-main
.comm i,4,2
.ident "GCC: (GNU) 4.1.2 20060623 (prerelease)"
--
ramana dot radhakrishnan at codito dot com changed:
What|Removed |Added
CC||ramana dot radhakrishnan at
||codito dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24427
[Bug fortran/28172] New: alternate return in contained procedure segfaults
[EMAIL PROTECTED]:~> cat t.f90 program blubb call otherini(*998) stop 998 stop contains subroutine init call otherini(*999) return 999 stop end subroutine init end program blubb [EMAIL PROTECTED]:~> ~/src/gcc/build/stage3-gcc/f951 t.f90 MAIN__ init t.f90:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED]:~> ~/src/gcc/build/stage3-gcc/f951 --version GNU F95 version 4.2.0 20060618 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.2.0 20060618 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 [EMAIL PROTECTED]:~> Note that it seems necessary that the subroutine be called both from the program and the contained procedure. -- Summary: alternate return in contained procedure segfaults Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28172
[Bug regression/28173] New: 4.1.1 misses constant folding .
A performance regression from 3.4.6 to 4.1.1 for m68k-elf.
combine used to take care of this in 3.4.6 .
A backport of the patch for Bug #24427 works . If its allowed, I'll put it up
.
This is the test case .
#include
int i;
int main (void)
{
if ( ((i & ~1) | 1) != ( i | 1))
printf ("abc");
}
3.4.6 generated
.file "fail.c"
.text
.align 2
.globl foo
.type foo, @function
foo:
link.w %a6,#0
unlk %a6
rts
.size foo, .-foo
.comm i,4,2
.ident "GCC: (GNU) 3.4.6"
4.1.2 pre-release generates
.file "fail.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "abc"
.text
.align 2
.globl main
.type main, @function
main:
link.w %fp,#0
move.l %d2,-(%sp)
move.l i,%d1
moveq #-2,%d0
and.l %d1,%d0
moveq #1,%d2
or.l %d2,%d0
or.l %d2,%d1
cmp.l %d0,%d1
jbeq .L5
pea .LC0
jbsr printf
addq.l #4,%sp
.L5:
move.l -4(%fp),%d2
unlk %fp
rts
.size main, .-main
.comm i,4,2
.ident "GCC: (GNU) 4.1.2 20060623 (prerelease)"
--
Summary: 4.1.1 misses constant folding .
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot radhakrishnan at codito dot com
GCC host triplet: i686-linux
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28173
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-26 20:10 --- As an aside, I think we should produce two lwbrx instead and then combine them for the double word (or ldbrx which only exists on Cell as far as I know) But that is not here or there for this problem right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug middle-end/28160] Bogus "size of array 'foo' is too large" error with -mms-bitfields
--- Comment #1 from seongbae dot park at gmail dot com 2006-06-26 20:46
---
I belive this is a bug in stor-layout.c:place_field() around line 10503
bitpos is calculated as bit_offset of rli->prev_field + type size.
However, the prev_field is not really the immediately previous field but the
first field of the consecutive same-sized fields.
Hence, in this case:
struct S
{
long long d:23;
int e:32;
int f:32;
} a;
rli->prev_field is "d" when "field" is f.
The correct fix should calculate the bitpos as
rli->bitpos + type size.
--
seongbae dot park at gmail dot com changed:
What|Removed |Added
CC||seongbae dot park at gmail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28160
[Bug middle-end/28160] Bogus "size of array 'foo' is too large" error with -mms-bitfields
--- Comment #2 from seongbae dot park at gmail dot com 2006-06-26 20:47 --- Oops. Mu previous comment is misplaced. It should have been on PR28161. Please ignore it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28160
[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields
--- Comment #1 from seongbae dot park at gmail dot com 2006-06-26 20:47
---
I belive this is a bug in stor-layout.c:place_field() around line 10503
bitpos is calculated as bit_offset of rli->prev_field + type size.
However, the prev_field is not really the immediately previous field but the
first field of the consecutive same-sized fields.
Hence, in this case:
struct S
{
long long d:23;
int e:32;
int f:32;
} a;
rli->prev_field is "d" when "field" is f.
The correct fix should calculate the bitpos as
rli->bitpos + type size.
--
seongbae dot park at gmail dot com changed:
What|Removed |Added
CC||seongbae dot park at gmail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28161
[Bug fortran/28174] New: Corruption of multiple character arrays when passing array sections
Here's a very strange example of data corruption when passing a character array section in the form call foo (a(:)(7:11)) to a subroutine even if the parameter is declared as INTENT(IN). Furthermore, even another array gets corrupted which is intended to hold a copy. See testcase for details. Cheers, -ha -- Summary: Corruption of multiple character arrays when passing array sections Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28174
[Bug fortran/28174] Corruption of multiple character arrays when passing array sections
--- Comment #1 from anlauf at gmx dot de 2006-06-26 20:58 --- Created an attachment (id=11759) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11759&action=view) Testcase Output of testcase: Before foo: a(1)=abc def ghij a(2)=klm nop qrst b(1)=abc def ghij b(2)=klm nop qrst In foo: c(1)=f ghi After foo: a(1)=abc d a(2)=klm n b(1)=abc d b(2)=klm n Bug: array a corrupted in subroutine call! Bug: array b corrupted in subroutine call! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28174
[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
--- Comment #2 from bcmpinc at hotmail dot com 2006-06-26 21:01 --- (In reply to comment #1) > Does the JDK's javah put that "_" into the generated header? No, JDK's javah creates a header equivalent to the header created by 'gcjh -jni'. > I suspect that you are seeing a problem with the C compiler, not a problem > with JNI header generation. I tried compiling with JDK's jni-headers and the javah-header. It still needs the "_" prepended. > In particular I think that "_", most likely, should be added by the C > compiler and not added to the header. I think you're right, but it's strange that the C compiler should recognize that it's compiling a native java function. Most exported non-java functions don't have a "_" prepended, even if they're in a library containing a lot of java functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug middle-end/28160] Bogus "size of array 'foo' is too large" error with -mms-bitfields
--- Comment #3 from seongbae dot park at gmail dot com 2006-06-26 21:08 --- The immediate cause of the problem is in stor-layout.c:place_field(): 1118 if (DECL_SIZE (field) != NULL 1119 && host_integerp (TYPE_SIZE (TREE_TYPE (field)), 0) 1120 && host_integerp (DECL_SIZE (field), 0)) 1121 rli->remaining_in_alignment 1122 = tree_low_cst (TYPE_SIZE (TREE_TYPE(field)), 1) 1123 - tree_low_cst (DECL_SIZE (field), 1); For the field "d", remiaining_in_alignment becomes negative after line 1121-1123 - because the DECL_SIZE is larger than TYPE_SIZE for "d". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28160
[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields
--- Comment #2 from seongbae dot park at gmail dot com 2006-06-26 21:10
---
More specifically:
1048 if (rli->remaining_in_alignment < bitsize)
1049 {
1050 /* out of bits; bump up to next 'word'. */
1051 rli->offset = DECL_FIELD_OFFSET (rli->prev_field);
1052 rli->bitpos
1053 = size_binop (PLUS_EXPR, TYPE_SIZE (type),
1054 DECL_FIELD_BIT_OFFSET
(rli->prev_field));
1055 rli->prev_field = field;
1056 rli->remaining_in_alignment
1057 = tree_low_cst (TYPE_SIZE (type), 1);
1058 }
The third operand of size_binop() of size_binop() at line 1053-1054
should be rli->bitpos.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28161
[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-06-26 21:21 --- I think you may be running into a compiler (MSVC vs GNUC) difference between handling of __stdcall (==JNICALL) symbols. For a function void __stdcall foo (int), both MSVC and GNUC generate an assembler name of '[EMAIL PROTECTED]'. The underscore is prefix to all assembler names, the @4 is unique to stdcall MSVC uses the name '[EMAIL PROTECTED]' in the dll export table when exporting from a dll, but '[EMAIL PROTECTED]' when exporting from a staticly linked object. GNUC uses '[EMAIL PROTECTED]' in both. If you look in info for binutils, under dlltool, you will see --ext-prefix-alias Add aliases with . That might help. However, I don't think that similar is supported by ld. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug c++/28114] [4.0/4.1 regression] ICE with struct definition in argument of template function
--- Comment #4 from sje at gcc dot gnu dot org 2006-06-26 21:25 --- Subject: Bug 28114 Author: sje Date: Mon Jun 26 21:25:23 2006 New Revision: 115025 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115025 Log: PR c++/28114 * g++.dg/other/pr28114.C: New. Added: trunk/gcc/testsuite/g++.dg/other/pr28114.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28114
[Bug c++/27369] [4.1/4.2 Regression] tree check ICE when attribute externally_visible used
--- Comment #10 from jason at gcc dot gnu dot org 2006-06-26 21:50 --- The bug is that handle_externally_visible adds the second decl to cgraph_nodes and then duplicate_decls discards it without removing it from cgraph_nodes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
[Bug c++/27424] [4.0/4.1/4.2 regression] Valid template-template-parameter rejected
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-05-05 15:30:07 |2006-06-26 22:16:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27424
[Bug c++/27578] [4.2 Regression] ICE with attribute on a pointer in a function prototype
--- Comment #9 from jason at gcc dot gnu dot org 2006-06-26 22:21 --- Is this still broken? I can't reproduce it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27578
[Bug c++/27578] [4.2 Regression] ICE with attribute on a pointer in a function prototype
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-26 22:24 --- Fixed by the patch which fixed PR 27648. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27578
[Bug c++/27768] [4.1/4.2 regression] wrong-code with vectors
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-05-30 16:06:59 |2006-06-26 22:24:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-06-26 22:26 --- (In reply to comment #3) > I think you may be running into a compiler (MSVC vs GNUC) difference between > handling of __stdcall (==JNICALL) symbols. Um, and this should all be taken care of by the #ifdef WIN32 code in jni.cc:_Jv_LookupJNIMethod Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug middle-end/28160] Bogus "size of array 'foo' is too large" error with -mms-bitfields
--- Comment #4 from kkojima at gcc dot gnu dot org 2006-06-26 22:42 ---
Thanks for your comment. Perhaps one solution would be to handle
such bit fields with excessive sizes as the case of "no remaining
bits in alignment". I'm testing the appended patch which changes
lines you've pointed out.
--- ORIG/trunk/gcc/stor-layout.c2006-06-13 09:06:36.0 +0900
+++ LOCAL/trunk/gcc/stor-layout.c 2006-06-26 16:43:12.0 +0900
@@ -1047,17 +1047,20 @@ place_field (record_layout_info rli, tre
if (rli->remaining_in_alignment < bitsize)
{
+ HOST_WIDE_INT typesize = tree_low_cst (TYPE_SIZE (type), 1);
+
/* out of bits; bump up to next 'word'. */
- rli->offset = DECL_FIELD_OFFSET (rli->prev_field);
rli->bitpos
- = size_binop (PLUS_EXPR, TYPE_SIZE (type),
- DECL_FIELD_BIT_OFFSET (rli->prev_field));
+ = size_binop (PLUS_EXPR, rli->bitpos,
+ bitsize_int (rli->remaining_in_alignment));
rli->prev_field = field;
- rli->remaining_in_alignment
- = tree_low_cst (TYPE_SIZE (type), 1);
+ if (typesize < bitsize)
+ rli->remaining_in_alignment = 0;
+ else
+ rli->remaining_in_alignment = typesize - bitsize;
}
-
- rli->remaining_in_alignment -= bitsize;
+ else
+ rli->remaining_in_alignment -= bitsize;
}
else
{
@@ -1119,9 +1121,16 @@ place_field (record_layout_info rli, tre
if (DECL_SIZE (field) != NULL
&& host_integerp (TYPE_SIZE (TREE_TYPE (field)), 0)
&& host_integerp (DECL_SIZE (field), 0))
- rli->remaining_in_alignment
- = tree_low_cst (TYPE_SIZE (TREE_TYPE(field)), 1)
- - tree_low_cst (DECL_SIZE (field), 1);
+ {
+ HOST_WIDE_INT bitsize = tree_low_cst (DECL_SIZE (field), 1);
+ HOST_WIDE_INT typesize
+ = tree_low_cst (TYPE_SIZE (TREE_TYPE (field)), 1);
+
+ if (typesize < bitsize)
+ rli->remaining_in_alignment = 0;
+ else
+ rli->remaining_in_alignment = typesize - bitsize;
+ }
/* Now align (conventionally) for the new type. */
type_align = TYPE_ALIGN (TREE_TYPE (field));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28160
[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-06-26 23:10 ---
GDB says that TREE_TYPE of a.d is the 32-bit integer and its
DECL_BIT_FIELD_TYPE is 64-bit when place_field processes a.e.
place_field uses the size of TREE_TYPE of the previous bit filed
when deciding whether a bit field to be packed with the previous
one or not. It seems that this makes the ms-bitfiled code
confused. The appended patch is to make place_field use
DECL_BIT_FIELD_TYPE of the previous bit field instead of
TREE_TYPE when comparing the size of consecutive bit fields.
It works for the above testcase, though the thorough tests are
needed.
--- ORIG/trunk/gcc/stor-layout.c2006-06-13 09:06:36.0 +0900
+++ LOCAL/trunk/gcc/stor-layout.c 2006-06-26 16:44:31.0 +0900
@@ -1022,6 +1022,7 @@ place_field (record_layout_info rli, tre
if (targetm.ms_bitfield_layout_p (rli->t))
{
tree prev_saved = rli->prev_field;
+ tree prev_type = prev_saved ? DECL_BIT_FIELD_TYPE (prev_saved) : NULL;
/* This is a bitfield if it exists. */
if (rli->prev_field)
@@ -1037,8 +1038,7 @@ place_field (record_layout_info rli, tre
&& !integer_zerop (DECL_SIZE (rli->prev_field))
&& host_integerp (DECL_SIZE (rli->prev_field), 0)
&& host_integerp (TYPE_SIZE (type), 0)
- && simple_cst_equal (TYPE_SIZE (type),
- TYPE_SIZE (TREE_TYPE (rli->prev_field
+ && simple_cst_equal (TYPE_SIZE (type), TYPE_SIZE (prev_type)))
{
/* We're in the middle of a run of equal type size fields; make
sure we realign if we run out of bits. (Not decl size,
@@ -1105,8 +1108,7 @@ place_field (record_layout_info rli, tre
if (!DECL_BIT_FIELD_TYPE (field)
|| (prev_saved != NULL
- ? !simple_cst_equal (TYPE_SIZE (type),
- TYPE_SIZE (TREE_TYPE (prev_saved)))
+ ? !simple_cst_equal (TYPE_SIZE (type), TYPE_SIZE (prev_type))
: !integer_zerop (DECL_SIZE (field)) ))
{
/* Never smaller than a byte for compatibility. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28161
[Bug ada/28171] ACATS: cd5003h intermitent fail
--- Comment #1 from laurent at guerby dot net 2006-06-26 23:28 --- Yep, that's what I got on Linux on various tests from time to time. No other explanation than process/file OS races. Do you run make check on a SMP box? -- laurent at guerby dot net changed: What|Removed |Added Summary|FAIL: cd5003h |ACATS: cd5003h intermitent ||fail http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28171
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 fail
--- Comment #19 from laurent at guerby dot net 2006-06-26 23:33 --- Richard Kenner: > > Looks like the same bug that Gigi doesn't currently use VIEW_CONVERT_EXPR > > for this type of Unchecked_Conversion. So already on my plate. Was a patch written for that at AdaCore? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields
--- Comment #4 from seongbae dot park at gmail dot com 2006-06-26 23:41 --- You're correct -I've overlooked the type mismatch. One question though is the local variable "type" of place_field() is TREE_TYPE (field), not DECL_BIT_FIELD_TYPE (field). I'm not familiar with gcc type system to know which is correct but it doesn't look consistent as it is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28161
[Bug ada/28171] ACATS: cd5003h intermitent fail
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-26 23:45 --- Subject: Re: ACATS: cd5003h intermitent fail > --- Comment #1 from laurent at guerby dot net 2006-06-26 23:28 --- > Yep, that's what I got on Linux on various tests from time to time. No other > explanation than process/file OS races. > > Do you run make check on a SMP box? Yes, this was on a SMP box. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28171
[Bug libgcj/28175] New: libgcj install tree should be relocatable
Ideally, libgcj's install tree would be relocatable. Currently though, there are places where we hard-code full paths, such as the -rpath values in gij. It would be nice if someone went through all such references and turned them into relative paths. On Linux-based systems one could use /proc/self/exe to look up the bin prefix. Other platforms would require their own tricks. -- Summary: libgcj install tree should be relocatable Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fitzsim at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28175
[Bug middle-end/28161] Wrong bit field layout with -mms-bitfields
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-06-27 00:28 --- Although I'm also not familiar with these materials, when place_field is called for a.d, gdb says that (gdb) call debug_tree (field) unit size align 64 symtab 0 alias set -1 precision 64 min max > external nonlocal bit-field nonaddressable decl_3 decl_4 VOID file tiny.cc line 3 size constant invariant 23> user align 64 offset_align 1 context attributes chain > but when it's called for a.e (gdb) call debug_tree (rli->prev_field) unit size align 32 symtab 0 alias set -1 precision 23 min max > external nonlocal bit-field nonaddressable decl_3 decl_4 DI file tiny.cc line 3 size constant invariant 23> unit size constant invariant 3> user align 64 offset_align 128 offset constant invariant 0> bit offset constant invariant 0> bit_field_type unit size align 64 symtab 0 alias set -1 precision 64 min max > context attributes chain > i.e. DECL_BIT_FIELD_TYPE is added in processing. I guess that this is the reason for the use of TREE_TYPE (field) for not yet processed fields and non ms-bitfield case. gcc allocates 32-bit for a.d without -mms-bitfield. OTOH, ms-bitfield code see the previous and already processed field and should allocate 64-bit for a.d. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28161
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #6 from dje at gcc dot gnu dot org 2006-06-27 01:34 --- rs6000.c:insvdi_rshift_rlwimi_p() is wrong, specifically the lines checking the shift count. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #7 from dje at gcc dot gnu dot org 2006-06-27 01:40 --- I think the correct test is something like Index: rs6000.c === --- rs6000.c(revision 115003) +++ rs6000.c(working copy) @@ -9794,8 +9794,8 @@ && INTVAL (startop) > 32 && (INTVAL (sizeop) + INTVAL (startop) < 64) && (INTVAL (sizeop) + INTVAL (startop) > 33) - && (INTVAL (sizeop) + INTVAL (startop) + INTVAL (shiftop) < 96) - && (INTVAL (sizeop) + INTVAL (startop) + INTVAL (shiftop) >= 64) + && (INTVAL (sizeop) + INTVAL (startop) + INTVAL (shiftop) < 64) + && (INTVAL (sizeop) + INTVAL (startop) + INTVAL (shiftop) >=32) && (64 - (INTVAL (shiftop) & 63)) >= INTVAL (sizeop)) return 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #8 from amodra at bigpond dot net dot au 2006-06-27 01:41
---
I think insvdi_rshift_rlwimi_p is totally broken. It should look something
like the following to match the capabilities of rlwimi according to my reading
of the powerpc architecture specification.
/* Return 1 if operands will generate valid arguments to the rlwimi
instruction for insert with right shift in 64-bit mode. */
int
insvdi_rshift_rlwimi_p (rtx sizeop, rtx startop, rtx shiftop)
{
/* The field that we insert into must start in the low word. */
if (INTVAL (startop) < 32 || INTVAL (startop) >= 64)
return 0;
/* And it must end there too. */
if (INTVAL (sizeop) < 0 || INTVAL (sizeop) + INTVAL (startop) >= 64)
return 0;
/* The value we are inserting must also come from the low word.
Since the sign bit isn't in the low word, we don't need to worry
about ashiftrt vs. lshiftrt. */
if (INTVAL (shiftop) + INTVAL (sizeop) >= 32)
return 0;
return 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug fortran/28176] New: FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/ mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /mnt/gnu/gcc/gcc/gcc/testsuite/ gfortran.dg/actual_array_constructor_1.f90 -O0 -pedantic-errors -L/mnt/gnu/ gcc/objdir/hppa64-hp-hpux11.00/./libgfortran/.libs -L/mnt/gnu/gcc/objdir/hppa64- hp-hpux11.00/./libgfortran/.libs -L/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.00/./lib iberty -lm -o ./actual_array_constructor_1.exe(timeout = 300) /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90: In fu nction 'redirect_':^M /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:21: in ternal compiler error: Segmentation fault^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M compiler exited with status 1 output is: /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90: In fu nction 'redirect_':^M /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:21: in ternal compiler error: Segmentation fault^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (test for excess errors) Excess errors: /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:21: in ternal compiler error: Segmentation fault WARNING: gfortran.dg/actual_array_constructor_1.f90 -O0 compilation failed to produce executable # /opt/gnu64/bin/gdb ../../f951 GNU gdb 6.4.50.20051209-cvs Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa64-hp-hpux11.11"... (gdb) r `cat xx.sh` Starting program: /mnt/gnu/gcc/objdir/gcc/f951 `cat xx.sh` Detaching after fork from child process 1902. GNU F95 version 4.2.0 20060626 (experimental) (hppa64-hp-hpux11.00) compiled by GNU C version 4.2.0 20060626 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal SIGSEGV, Segmentation fault. aggregate_value_p (exp=0x0, fntype=0x0) at ../../gcc/gcc/function.c:1750 1750 tree type = (TYPE_P (exp)) ? exp : TREE_TYPE (exp); (gdb) bt #0 aggregate_value_p (exp=0x0, fntype=0x0) at ../../gcc/gcc/function.c:1750 #1 0x40284214 in emit_library_call_value_1 (retval=0, orgfun=0x83fffed5d8c0, value=0x0, fn_type=, outmode=VOIDmode, nargs=, p=0x83fffeff2038) at ../../gcc/gcc/calls.c:3312 #2 0x40284958 in emit_library_call_value (orgfun=0x0, value=0x8, fn_type=2640219, outmode=CCmode, nargs=128) at ../../gcc/gcc/calls.c:3967 #3 0x403d60d0 in expand_binop (mode=TImode, binoptab=, op0=0x83fffedd8be0, op1=0x83fffedd8ba0, target=, unsignedp=0, methods=) at ../../gcc/gcc/optabs.c:1888 #4 0x402f5768 in expand_mult (mode=TImode, op0=, op1=0x83fffedd8ba0, target=0x83fffedd8b80, unsignedp=1) at ../../gcc/gcc/expmed.c:3227 #5 0x40305d18 in expand_expr_real_1 (exp=, target=0x83fffedd8b80, tmode=, modifier=, alt_rtl=0x83fffeff1948) at ../../gcc/gcc/expr.c:8145 #6 0x4030ebc0 in expand_expr_real (exp=0x83fffedf4288, target=0x83fffedd8b80, tmode=TImode, modifier=EXPAND_NORMAL, alt_rtl=0x83fffeff1948) at ../../gcc/gcc/expr.c:6690 #7 0x40315ae4 in store_expr (exp=0x83fffedf4288, target=0x83fffedd8b80, call_param_p=0) at ../../gcc/gcc/expr.c:4370 ---Type to continue, or q to quit--- #8 0x40300384 in expand_assignment (to=0x83fffedfbd10, from=) at ../../gcc/gcc/expr.c:4249 #9 0x403061a4 in expand_expr_real_1 (exp=, target=, tmode=, modifier=, alt_rtl=0x0) at ../../gcc/gcc/expr.c:8587 #10 0x4030ea88 in expand_expr_real (exp=0x83fffedf4c18, target=0x83fffed5a400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:6684 #11 0x4044b584 in expand_expr_stmt (exp=0x0) at expr.h:493 #12 0x4049a5d8 in expand_gimple_basic_block (bb=0x83fffedfe258) at ../../gcc/gcc/cfgexpand.c:1368 #13 0x4049bb4c in tree_expand_cfg () at ../../gcc/gcc/cfgexpand.c:1634 #14 0x40495394 in execute_one_pass (pass=0x80010001b728) at ../../gcc/gcc/passes.c:864 #15 0x404956b0 in execute_pass_list (pass=0x80010001b728) at ../../gcc/gcc/passes.c:911 #16 0x401e129c in tree_rest_of_compilation (fndecl=0x83fffedefe00) at ../../gcc/gcc/tree-optimize.c:418 #17 0x40
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #9 from amodra at bigpond dot net dot au 2006-06-27 01:47 --- Uh, that should be "INTVAL (sizeop) <= 0". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug fortran/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #1 from danglin at gcc dot gnu dot org 2006-06-27 01:53 --- FAIL: gfortran.dg/actual_array_substr_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/actual_array_substr_1.f90 -O0 (test for excess errors) WARNING: gfortran.dg/actual_array_substr_1.f90 -O0 compilation failed to produ ce executable fails in the some way. I guessing but probably the following also fail in the same way: FAIL: gfortran.dg/auto_char_pointer_array_result_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/auto_char_pointer_array_result_1.f90 -O0 (test for excess er rors) WARNING: gfortran.dg/auto_char_pointer_array_result_1.f90 -O0 compilation fail ed to produce executable FAIL: gfortran.dg/auto_pointer_array_result_1.f90 -O0 (internal compiler error ) FAIL: gfortran.dg/auto_pointer_array_result_1.f90 -O0 (test for excess errors) WARNING: gfortran.dg/auto_pointer_array_result_1.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/character_array_constructor_1.f90 -O0 (internal compiler err or) FAIL: gfortran.dg/character_array_constructor_1.f90 -O0 (test for excess error s) WARNING: gfortran.dg/character_array_constructor_1.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/pr15324.f90 -O0 (internal compiler error) FAIL: gfortran.dg/pr15324.f90 -O0 (test for excess errors) WARNING: gfortran.dg/pr15324.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/pr17612.f90 -O0 (internal compiler error) FAIL: gfortran.dg/pr17612.f90 -O0 (test for excess errors) WARNING: gfortran.dg/pr17612.f90 -O0 compilation failed to produce executable FAIL: gfortran.fortran-torture/execute/pr19269-1.f90, -O0 (internal compiler e rror) FAIL: gfortran.fortran-torture/execute/strarray_3.f90, -O0 (internal compiler error) FAIL: gfortran.fortran-torture/execute/strarray_4.f90, -O0 (internal compiler error) These fails are related to the libgomp fails noted in PR fortran/27885. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176
[Bug libstdc++/26211] [DR 342] basic_istream::tellg, seekg are unformatted input functions
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26211
[Bug other/28177] New: [meta-bug] GCC 4.3 pending patches
This metabug is used to track all the patches which have been written during Stage 3 of GCC 4.2 but do not qualify for that stage, and are waiting for Stage 1 of GCC 4.3 to be applied. Please, do not attacch the patches to this bug. Open a new bug report, and mark it as "blocking" this metabug (this metabug will "depend" on the new bug report). -- Summary: [meta-bug] GCC 4.3 pending patches Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: meta-bug Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org BugsThisDependsOn: 24429 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28177
[Bug other/28177] [meta-bug] GCC 4.3 pending patches
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-27 02:47 --- I know there are some C inlining changes and dwarf2/3 speeds up waiting for stage1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28177
[Bug other/23111] [meta-bug] GCC 4.2 pending patches
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-27 02:48 --- We are now in stage3 which means all of the features have been applied so this can be closed. I filed a 4.3 meta-bug as PR 28177. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23111
[Bug other/28177] [meta-bug] GCC 4.3 pending patches
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28177
[Bug other/28177] [meta-bug] GCC 4.3 pending patches
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-27 02:50:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28177
[Bug gcov/profile/23334] FIXME in coverage.c: use build_constructor directly
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-27 02:51 --- This has been fixed on the LTO branch by Kazu and IIRC they are preapproved for stage1 of 4.3 so marking this as blocking PR 28177, the meta-bug for 4.3 patches. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org OtherBugsDependingO||28177 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23334
[Bug target/27883] [4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #4 from wilson at gcc dot gnu dot org 2006-06-27 03:02 ---
This only fails for --enable-checking builds, which is the default for
mainline, but not release branches. I was able to reproduce this with gcc-4.0,
but not gcc-3.4. The difference between the two is that gcc-4.0 has the
__builtin_copysign support, which emits the RTL that triggers the error. The
error has probably been latent for a while.
The insn that causes the problem is
(jump_insn 99 98 113 15 (set (pc)
(if_then_else (ge:SI (subreg:SI (reg:DF 32 $f0) 4)
(const_int 0 [0x0]))
(label_ref 101)
(pc))) 261 {*branch_zerosi} (insn_list:REG_DEP_TRUE 94 (nil))
(expr_list:REG_DEAD (reg:SI 33 $f1)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil
On a 32-bit mips target, DFmode $f0 is a register pair $f0/$f1, so technically
this is correct. There is a corresponding REG_UNUSED for $f0 on the insn that
sets (reg:DF 32 $f0).
However, flow doesn't track individual regs in subregs, it only tracks the
whole subreg. Note that mark_used_reg ignores subregs. So when we execute the
second life pass, we end up with
(jump_insn 98 97 112 17 (set (pc)
(if_then_else (ge (subreg:SI (reg:DF 32 $f0) 4)
(const_int 0 [0x0]))
(label_ref 100)
(pc))) 271 {*branch_ordersi} (insn_list:REG_DEP_TRUE 93 (nil))
(expr_list:REG_DEAD (reg:DF 32 $f0)
(expr_list:REG_DEAD (reg:SI 33 $f1)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)
Note that we now have two overlapping REG_DEAD notes plus an overlapping
REG_UNUSED note on a previous insn. When sched runs, it deletes both REG_DEAD
notes, but only readds one, resulting in the abort for a REG_DEAD note
consistency problem.
A subreg of a hard register is normally not allowed, but it is created in this
case because CANNOT_CHANGE_CLASS_MODE is defined, and HARD_REGNO_MODE_OK says
that an SImode $f1 is not OK. The result is that simplify_subreg doesn't
simplify this. The other part is that register_operand says it is OK.
Eventually, this gets fixed by reload.
Fixing combine to get this right looks complicated. Combine has to know that
the register was used inside a subreg, and then figure out that the subreg
wasn't simplified because of CANNOT_CHANGE_CLASS_MODE, etc.
I think a simpler solution here is to note that the life2 pass would have
worked correctly if it deleted all prior REG_UNUSED/REG_DEAD notes before it
started. Incidentally, the comments for the life2 pass say it was explicitly
added to fix REG_UNUSED/REG_DEAD problems with distribute_notes in combine, so
it was apparently added to fix a related problem. It just isn't working the
way it was originally intended.
It is curious that life2 is running immediately before sched, instead of
immediately after combine. If we ran it immediately after combine, we could
get rid of the REG_DEAD/REG_UNUSED support in distribute_notes, which is
probably the most complicated, and most buggy, part of combine. This would
also speed up the compiler a little bit.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
CC||wilson at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-27 03:02:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 fail
--- Comment #20 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-06-27 03:03 --- Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 fail > > > Looks like the same bug that Gigi doesn't currently use VIEW_CONVERT_EXPR > > > for this type of Unchecked_Conversion. So already on my plate. > > Was a patch written for that at AdaCore? Yes, but only on Friday and it hasn't been tested yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-checking Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 Summary|[4.2 regression] in |[4.0/4.1/4.2 regression] in |schedule_insns, at sched- |schedule_insns, at sched- |rgn.c:3038 on mips |rgn.c:3038 on mips Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
--- Comment #5 from tromey at gcc dot gnu dot org 2006-06-27 03:20 --- Yeah, jni.cc handles the lookup side of things. The declaration side of things in user JNI code should be handled by jni_md.h. It has a bunch of win32-specific code which boils down to: #define JNIIMPORT__declspec(dllimport) #define JNIEXPORT__declspec(dllexport) #define JNICALL __stdcall It might be handy to see a small preprocessed source file. Perhaps you're picking up the wrong jni.h, jni_md.h, or perhaps the logic in jni_md.h is broken somehow. Oops, I just looked at your version... jni_md.h is not in 3.4. In 3.4 the same logic appears, only it is in jni.h. It is possible that we fixed some bugs in this area since 3.4. I don't remember. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug c++/28169] Tertiary operator: object creation and initialization
--- Comment #3 from joseph dot rajesh at gmail dot com 2006-06-27 04:09 --- No I haven't missed the copy constructor... I checked the working with copy constructor also... I know g++ is doing a conversion and making a copy of type "Base" (Using Base copy constructor)... that's why the final object is of type "Base" and the temporary "Derived" class object is thus deleted... And the standard says that a copy should not be made instead of it should refer the original object. Because finaly I should get a Base class reference to the derived class object, which is not happening in g++... -- joseph dot rajesh at gmail dot com changed: What|Removed |Added CC||joseph dot rajesh at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28169
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #22 from uros at kss-loka dot si 2006-06-27 05:49 --- (In reply to comment #21) > Note that you are running the opposite of my test case: SSE vs SSE rather than > x87 vs x87. This whole bug report is about x87 performance. You can get more > detail on why I want x87 in my messages above, particularly comment #11, but > single precision is indeed the place where SSE cannot compete with the x87 > unit. To see it, put the flags back the way I had them in the attachment, and > you'll see that gcc 3 is much faster. Also, you should find in single Hm, these are x87 results: /usr/local.uros/gcc34/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -DTYPE=float -c mmbench.c /usr/local.uros/gcc34/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c sgemm_atlas.c /usr/local.uros/gcc34/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -o xsmm_gcc mmbench.o sgemm_atlas.o rm -f *.o /usr/local.uros/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -DTYPE=float -c mmbench.c /usr/local.uros/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c sgemm_atlas.c /usr/local.uros/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -o xsmm_gc4 mmbench.o sgemm_atlas.o rm -f *.o echo "GCC 3.x single performance:" GCC 3.x single performance: ./xsmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.141 3072.00 echo "GCC 4.x single performance:" GCC 4.x single performance: ./xsmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.143 3029.92 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug middle-end/24929] long long shift/mask operations should be better optimized
--- Comment #4 from ian at airs dot com 2006-06-27 06:05 --- With my current version of the lower-subreg patch, I get this with -O2 -momit-leaf-frame-pointer: f: movl16(%esp), %eax movl4(%esp), %ecx movl8(%esp), %edx shrl$16, %eax andl$255, %eax shldl $8, %ecx, %edx sall$8, %ecx orl %ecx, %eax ret which may be optimal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24929
