Re: Difference in assembly

Has anybody faced with such a problem? Please do help me out. regards manmeet Manmeet Singh Johar wrote: Hello, I am building cross compilers for SPARC variant for Cygwin and MingW hosts. In the process I am faced with a very peculiar problem. For the code shown below, though I am getting same as

[Bug fortran/17941] gfortran: parser chokes on complex literal constant

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31 06:08 --- (In reply to comment #4) > fiexes the problem. s/fiexes/fixes/ -- What|Removed |Added

[Bug fortran/17941] gfortran: parser chokes on complex literal constant

--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2004-12-31 06:06 --- The patch here http://gcc.gnu.org/ml/fortran/2004-12/msg00265.html fiexes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17941

[Bug debug/19212] /tmp/ccbY7YyA.s:6435: Error: attempt to get value of unresolved symbol `__s:V151'

--- Additional Comments From danglin at gcc dot gnu dot org 2004-12-31 05:52 --- It seems that the assembler message is somewhat misleading. The problem would seem to be due to the fact that the symbol "_ZNSt6locale13_S_categoriesE" is not output in the .s but the 'V' apparently indicat

[Bug target/19211] [4.0 Regression] GNAT bug box compiling a-exexda.adb with stage1 compiler

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31 03:42 --- Patch here: . -- What|Removed |Added

[Bug debug/19212] New: /tmp/ccbY7YyA.s:6435: Error: attempt to get value of unresolved symbol `__s:V151'

/home/dave/gnu/gcc-3.3/objdir/gcc/xgcc -shared-libgcc -B/home/dave/gnu/gcc-3.3/o bjdir/gcc/ -nostdinc++ -L/home/dave/gnu/gcc-3.3/objdir/vax-ultrix/libstdc++-v3/s rc -L/home/dave/gnu/gcc-3.3/objdir/vax-ultrix/libstdc++-v3/src/.libs -B/home/dav e/opt/gnu/vax-ultrix/bin/ -B/home/dave/opt/gnu/vax-ultri

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2004-12-31 01:29 --- Subject: Re: [4.0 Regression] not using do-loop for some loops > (In reply to comment #3) > What I don't understand is why this was fine in 3.3.2 and not in 4.0.0 by the > new do-loop

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2004-12-31 00:56 --- Subject: Re: [4.0 Regression] not using do-loop for some loops > Zdenek, I have troubles understanding how such a loop can ever be infinite: > > - if wrapv, sooner or later K will rea

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31 00:54 --- (In reply to comment #3) What I don't understand is why this was fine in 3.3.2 and not in 4.0.0 by the new do-loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19210

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

--- Additional Comments From giovannibajo at libero dot it 2004-12-31 00:49 --- Zdenek, I have troubles understanding how such a loop can ever be infinite: - if wrapv, sooner or later K will reach any N (and thus, surely it will become less or equal to any given N). - if nowrapv, my un

[Bug c++/11247] -frepo fails to instantiate typeinfo

--- Additional Comments From bgreen at nas dot nasa dot gov 2004-12-31 00:14 --- I just discovered this bug still exists, in a slightly changed guise. The previously submitted code now compiles, but a minor change brings the bug right back. Attached is the new version of the code that pr

[Bug c++/19185] [3.3 only] ICE: cp_expr_size, at cp/cp-lang.c:308

--- Additional Comments From danglin at gcc dot gnu dot org 2004-12-31 00:06 --- I believe that this error occurs because vax.h defines PCC_STATIC_STRUCT_RETURN. Removing this define allows the complilation of this file to complete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=191

[Bug target/19211] [4.0 Regression] GNAT bug box compiling a-exexda.adb with stage1 compiler

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 23:40 --- Mine, I think I have a patch. -- What|Removed |Added AssignedTo|unassigned at gcc do

[Bug target/19211] [4.0 Regression] GNAT bug box compiling a-exexda.adb with stage1 compiler

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 22:47 --- This is a target problem. Confirmed. I am looking into how to fix this problem. -- What|Removed |Added --

[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

--- Additional Comments From rakdver at gcc dot gnu dot org 2004-12-30 22:28 --- Doloop optimizer believes that the loop may be infinite. There are two ways how to prove that this is not the case: 1) k is signed, and thus cannot overflow with -fno-wrapv 2) k cannot run out of the boun

[Bug ada/19211] New: GNAT bug box compiling a-exexda.adb with stage1 compiler

==+ | 4.0.0 20041230 (experimental) (powerpc-apple-darwin7.7.0) Bus error | | Error detected at a-exexda.adb:404:8 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 21:50 --- (In reply to comment #34) Actually it is because we are placing statements in the loop's latch. It is done in create_new_iv. -- What|Removed |Added --

[Bug debug/19124] [4.0 regression] gcc generates incorrect dwarf2 debug info

--- Additional Comments From hjl at lucon dot org 2004-12-30 21:01 --- insn-preds.o was compiled with stage2/xgcc -Bstage2/ -B/usr/gcc-4.0/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit- frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes - Wmissing-prototypes -pedantic -Wno

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 20:47 --- I should note that this comes from sixtrack (or rather from a fortran to C converted version of sixtrack). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19210

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

-- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Known to fail|

[Bug rtl-optimization/19210] New: [4.0 Regression] not using do-loop for some loops

Take following loop: int a[22]; void f (int n) { int k; for(k = 3;k <= n;k++) { a[k] = k; } } On the mainline we produce: L4: stw r9,0(r2) addi r9,r9,1 cmpw cr7,r3,r9 addi r2,r2,4 bge+ cr7,L4 But with 3.3.2, we use bdnz: L9: slwi r3,r

[Bug middle-end/19175] [3.4 regression] RTL checking failures on i686-pc-linux-gnu

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 20:40 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug middle-end/19175] [3.4 regression] RTL checking failures on i686-pc-linux-gnu

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-30 20:23 --- Subject: Bug 19175 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-30 20:23:29 Modified files: gcc: Change

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 18:49 --- (In reply to comment #33) > Subject: Re: [4.0 Regression] out-of ssa > causing loops to have more than one BB > > > > Now if you think that PR is a trivial case that should be caught, then, > > > sh

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

--- Additional Comments From law at redhat dot com 2004-12-30 18:39 --- Subject: Re: [4.0 Regression] out-of ssa causing loops to have more than one BB On Thu, 2004-12-30 at 17:27 +, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot

[Bug tree-optimization/19042] Complex types are not SRA all the time.

--- Additional Comments From dje at gcc dot gnu dot org 2004-12-30 17:42 --- The patch slightly improves a few SPEC testcases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 17:27 --- (In reply to comment #31) > Subject: Re: [4.0 Regression] out-of ssa > causing loops to have more than one BB > Now if you think that PR is a trivial case that should be caught, then, > show me why

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-30 16:42 --- Subject: Re: [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated On Thu, 2004-12-30 at 16:14 +, fnf at specifixinc dot com wrote: > --- Additional Comments From fnf at spec

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

--- Additional Comments From fnf at specifixinc dot com 2004-12-30 16:14 --- I tried the patch and it does generate a entry: <2>: Abbrev Number: 10 (DW_TAG_inlined_subroutine) DW_AT_abstract_origin: <5f> DW_AT_low_pc : 0x80483a1 DW_AT_high_pc : 0x80483a6 Note

[Bug rtl-optimization/19198] ICE in copyprop_hardreg_forward_1

--- Additional Comments From matt at gsicomp dot on dot ca 2004-12-30 15:28 --- Ignore the "gcc -v" that claims to be 2.95.4. That's from the wrong gcc. Here's the right info: [EMAIL PROTECTED] gcc34 -v Reading specs from /usr/local/lib/gcc/i386-portbld-freebsd4.10/3.4.4/specs Configu

[Bug libstdc++/16896] Use of non-reserved names in stl_list.h

--- Additional Comments From pcarlini at suse dot de 2004-12-30 15:16 --- *** Bug 19209 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug libstdc++/19209] [3.4/4.0 Regression] libstdc++ tempers with user name space

--- Additional Comments From pcarlini at suse dot de 2004-12-30 15:16 --- Already fixed in the v7 branch, by the way. *** This bug has been marked as a duplicate of 16896 *** -- What|Removed |Added

[Bug libstdc++/19209] [3.4/4.0 Regression] libstdc++ tempers with user name space

-- What|Removed |Added Target Milestone|4.0.0 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19209

[Bug libstdc++/19209] [3.4/4.0 Regression] libstdc++ tempers with user name space

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 15:08 --- Hmm, the problem is in _List_node_base. It was caused by: 2004-01-07 Gawain Bolton <[EMAIL PROTECTED]> * include/bits/stl_list.h: * include/bits/list.tc: * src/list.cc: Per

[Bug libstdc++/19209] [4.0 Regression] libstdc++ tempers with user name space

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 15:01 --- Confirmed, this is at least a 4.0 regression, 3.3.2 compiled this just fine. -- What|Removed |Added -

[Bug libstdc++/19209] New: libstdc++ tempers with user name space

Some uglifications are missing from current implementations of the standard library How to repeat: % cat l.C && g++ l.C #define hook 1 #define unhook 0 #include int main() { return 0; } /home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include

[Bug middle-end/19207] Suggestion for speeding up data flow analysis

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-

[Bug objc/18971] [4.0 Regression] Can't send messages to methods with arrays as parameters

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 14:51 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c++/19199] [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 14:48 --- Confirmed: < = (const Foo &) (const Foo *) &TARGET_EXPR >>> why is there a cast to int in the MIN_EXPR. This causes wrong code. -- What|Removed |Added -

[Bug c++/19200] Friend declaration misinterpreted as constructor

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 14:33 --- If this is a regression, it has to be from 2.95.3 which I don't have access to right now. Confirmed. -- What|Removed |Added

[Bug ada/19128] Bug box while building asharp

-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19128

[Bug c++/19203] [3.4/4.0 Regression] Partial ordering failure between function reference and generic const reference

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 14:29 --- : Search converges between 2004-04-01-trunk (#447) and 2004-04-10-trunk (#448). : Search converges between 2004-06-15-3.4 (#9) and 2004-06-27-3.4 (#10). -- What|Removed |

[Bug c++/19208] [3.4/4.0 Regression] Spurious error about variably modified type

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 14:27 --- Reduced testcase: template struct if_t { typedef int type; }; template struct { static const bool value = true; }; template struct bound_member_action { typedef char f[::value ? 1 : 2]; templ

[Bug tree-optimization/14705] [tree-ssa] more alias analysis needed!?

--- Additional Comments From steven at gcc dot gnu dot org 2004-12-30 14:05 --- Looks like food for DannyB. -- What|Removed |Added CC|

[Bug c++/19208] [3.4/4.0 Regression] Spurious error about variably modified type

--- Additional Comments From giovannibajo at libero dot it 2004-12-30 13:51 --- 3.4 is broken too, it's a regression from 3.3 actually. -- What|Removed |Added Known to

[Bug c++/19208] [4.0 Regression] Spurious error about variably modified type

--- Additional Comments From steven at gcc dot gnu dot org 2004-12-30 13:22 --- A regression from what? Does 3.4 accept it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19208

[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

--- Additional Comments From steven at gcc dot gnu dot org 2004-12-30 13:21 --- . -- What|Removed |Added Status|NEW |RESOLVED Re

[Bug c++/19208] [4.0 Regression] Spurious error about variably modified type

-- What|Removed |Added Severity|normal |critical Priority|P2 |P1 Target Milestone|--- |4.

[Bug c++/19208] [4.0 Regression] Spurious error about variably modified type

--- Additional Comments From giovannibajo at libero dot it 2004-12-30 13:19 --- Created an attachment (id=7845) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7845&action=view) Reduced testcase (but not minimal) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19208

[Bug c++/19208] New: [4.0 Regression] Spurious error about variably modified type

Hello, the code I will attacch shortly is a (partial) reduction from a multi-thousands line testcase from Boost which fails with 4.0. This is the link to the failure in the automatic testers: http://ln-s.net/2$N -- Summary: [4.0 Regression] Spurious error about variably modified

[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-30 13:16 --- Subject: Bug 18019 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-30 13:16:14 Modified files: gcc: ChangeLog gcc/config/i386: i

[Bug middle-end/19207] New: Suggestion for speeding up data flow analysis

This is a suggestion from item 108 of the "old PROBLEMS" file that actually still makes a lot of sense, for a change: Can speed up flow analysis by making a table saying which register is set and which registers are used by each instruction that only sets o

[Bug middle-end/19206] New: [cc0] insn-output.c should optimize sign-tests better

Item 122 from the old PROBLEMS file (no test case available): When insn-output.c turns a bit-test into a sign-test, it should see whether the condition code is already set up with that sign. -- Summary:

[Bug target/19205] New: [m68k] avoid converting INDEX to SI mode if a narrower mode suffices

Item 109 from the old PROBLEMS file (no test case available): It is desirable to avoid converting INDEX to SImode if a narrower mode suffices, as HImode does on the 68000. How can this be done? -- Summa

[Bug c++/19203] Partial ordering failure between function reference and generic const reference

--- Additional Comments From giovannibajo at libero dot it 2004-12-30 12:20 --- This is the Boost test which is failing because of this bug: http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#function- lambda_test-gcc-4-experimental-linux -- http://gcc.gnu.org/bugzilla/

[Bug target/19204] New: [m68k] pea can force reloads that cause inefficient code

Item 85 from the old PROBLEMS file (no test case available): pea can force a value to be reloaded into an areg which can make it worse than separate adding and pushing. This can only happen for adding something within addql range and it only loses if the q

[Bug c++/19203] Partial ordering failure between function reference and generic const reference

--- Additional Comments From giovannibajo at libero dot it 2004-12-30 12:19 --- Bumping priority because it affects Boost. -- What|Removed |Added Priority|P2

[Bug c++/19203] New: Partial ordering failure between function reference and generic const reference

Hello: template void foo(const A& a); template void foo(RET (&)(ARG1)); float decl(int); void bar(void) { foo(decl); } lambda.cc:12: error: call of overloaded 'foo(float (&)(int))' is

[Bug middle-end/19202] New: [cc0] Potential problem with cc_status.value2 (from old PROBLEMS)

Item 63 from the old PROBLEMS file (no test case available): Potential problem in cc_status.value2, if it ever activates itself after a two-address subtraction (which currently cannot happen). It is supposed to compare the current value of the destination

[Bug target/19201] New: [m68k] Inefficient code for array accesses (from old PROBLEMS)

Item 10 from the old PROBLEMS file (no test case available): movl a3@,a0 movl a3@(16),a1 clrb a0@(a1:l) is generated and may be worse than movl a3@,a0 addl a3@(16),a0 clrb a0@ If ordering of operands is imp

[Bug c++/18604] [3.4/4.0 Regression] Strong using lookup conflicts

--- Additional Comments From giovannibajo at libero dot it 2004-12-30 11:59 --- This affects Boost, I'm bumping the priority. -- What|Removed |Added Priority|P2

[Bug c++/19200] Friend declaration misinterpreted as constructor

-- What|Removed |Added Known to fail||4.0.0 3.4.2 3.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19200

[Bug c++/19200] New: Friend declaration misinterpreted as constructor

Hello: --- struct S { struct T{}; friend void S(T); }; --- lookup.cc:3: error: return type specification for constructor invalid lookup.cc:3: warning: member functions are implicitly friends of their class G++ thinks that the friend d

[Bug ada/19128] Bug box while building asharp

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-30 11:24 --- Subject: Bug 19128 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-30 11:24:08 Modified files: gcc/ada: ChangeLog trans.c Log message:

[Bug c++/19199] New: Wrong warning about returning a reference to a temporary

Hi, The code below produces a warning about returning a reference to a temporary when using enum types for the qMin method. It works fine when using primitive types or classes instead of enums. Fortunately it's rather easy to work around the warning :) Best regards, Lars enum Foo {

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

--- Additional Comments From bonzini at gcc dot gnu dot org 2004-12-30 10:39 --- Nope, my patch is not sufficient. I am testing a better fix, but I fear it is too invasive for 4.0. It is a variant of the often-proposed "build out of srcdir without telling the user" trick. --

[Bug objc/18971] [4.0 Regression] Can't send messages to methods with arrays as parameters

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-30 10:18 --- Subject: Bug 18971 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-30 10:18:18 Modified files: gcc/objc : ChangeLog objc-act.c gcc/tes