[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-02-07 12:43 ---
There are btw a load of va-arg testcases in the testsuite and testresults on
mips-unknown-elf do not show any problems on the 4.3 or the 4.4 branch or on
trunk (as reported by Mike Stein).

Thus, please provide an executable testcase that aborts if miscompiled and
that shows the broken behavior on mips-elf with an unmodified GCC source
tree.

You can also double-check testresults on your target, specifically the
various gcc.c-torture/execute/va-arg*.c testcases - which are also a good
example on how a reproducable testcase should look like both for inclusion
in the testsuite and for reproducing and fixing this bug.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|mips-sls-dnaos  |mips-*-elf
   Keywords||wrong-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39640

[Bug libfortran/42742] Handle very large format strings correctly

[jvdelisle at gcc dot gnu dot org]

--- Comment #21 from jvdelisle at gcc dot gnu dot org  2010-02-07 13:37 
---
Closing, not needed on 4.4


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742

[Bug tree-optimization/42956] [4.4/4.5 Regression] internal compiler error: Segmentation fault with -O1

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-02-07 13:43 ---
Subject: Bug 42956

Author: rguenth
Date: Sun Feb  7 13:42:52 2010
New Revision: 156571

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156571
Log:
2010-02-07  Richard Guenther  

PR middle-end/42956
* gimplify.c (gimple_fold_indirect_ref): Avoid generating
new ARRAY_REFs on variable size element or minimal index arrays.
Complete.
* tree-ssa-loop-ivopts.c (find_interesting_uses_address): Use
gimple_fold_indirect_ref.

* gcc.c-torture/compile/pr42956.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr42956.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956

[Bug tree-optimization/42956] [4.4 Regression] internal compiler error: Segmentation fault with -O1

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-02-07 13:43 ---
Fixed for 4.5.0 sofar.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.4.3 4.5.0 |4.4.3
  Known to work|4.3.5 4.4.2 |4.3.5 4.4.2 4.5.0
Summary|[4.4/4.5 Regression]|[4.4 Regression] internal
   |internal compiler error:|compiler error: Segmentation
   |Segmentation fault with -O1 |fault with -O1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956

[Bug tree-optimization/42956] [4.4 Regression] internal compiler error: Segmentation fault with -O1

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-02-07 13:43 ---
P1 for a regression on a release branch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956

[Bug c/42993] New: simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)

[dcb314 at hotmail dot com]

I just tried to compile the Linux kernel 2.6.33-rc6 under valgrind
with the C compiler version 4.5 snapshot 20100128 and valgrind said

==2968== Conditional jump or move depends on uninitialised value(s)
==2968==at 0x7A6925: delegitimize_mem_from_attrs (simplify-rtx.c:244)
==2968==by 0x961517: ix86_delegitimize_address (i386.c:10883)
==2968==by 0x93E5F6: emit_note_insn_var_location (var-tracking.c:6515)
==2968==by 0xCB84D7: htab_traverse_noresize (hashtab.c:753)
==2968==by 0x941376: emit_notes_for_changes (var-tracking.c:6741)
==2968==by 0x946A67: vt_emit_notes (var-tracking.c:7106)
==2968==by 0x94A602: variable_tracking_main (var-tracking.c:7637)
==2968==by 0x722ECA: execute_one_pass (passes.c:1561)
==2968==by 0x723154: execute_pass_list (passes.c:1616)
==2968==by 0x723166: execute_pass_list (passes.c:1617)
==2968==by 0x723166: execute_pass_list (passes.c:1617)
==2968==by 0x818C94: tree_rest_of_compilation (tree-optimize.c:413)
==2968==

Line 244 of simplify-rtx.c is

if (bitsize != GET_MODE_BITSIZE (mode)
|| (bitpos % BITS_PER_UNIT)
|| (toffset && !host_integerp (toffset, 0)))
  decl = NULL;

Preprocessed source code attached. Flags -Os -g required.


-- 
   Summary: simplify-rtx.c:244: Conditional jump or move depends on
uninitialised value(s)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993

[Bug c/42993] simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2010-02-07 14:33 ---
Created an attachment (id=19818)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19818&action=view)
C 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993

[Bug c/42990] "warning: implicit declaration of function 'xxx' " instead of "error: ..."

[vyg84 at mail dot ru]

--- Comment #4 from vyg84 at mail dot ru  2010-02-07 14:46 ---
I think some moments should be cleared.
I used Anjuta 2.28.1.0 C console project, include file initially was only
stdio.h.

I'm not strcitly sure with what language standart my program was compiled, but
it is very likely with C99, I didn't found any standart modifying options like
"ansi" and "std=". If it is C89 (by my opinion this such "implicit
declarations" is a doubtable feature) why didn't linker showed any error
messages like "Unresolved external: 'atof'" for example. By my opinion in this
case the progrm should't be assemble at all because of its actual
unpredictability.

And why did 'atoi' worked ) ?


-- 

vyg84 at mail dot ru changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990

[Bug middle-end/42993] [4.5 Regression] simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-07 14:47 ---
Probably the same issue as PR42991.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org
  Component|c   |middle-end
Summary|simplify-rtx.c:244: |[4.5 Regression] simplify-
   |Conditional jump or move|rtx.c:244: Conditional jump
   |depends on uninitialised|or move depends on
   |value(s)|uninitialised value(s)
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993

[Bug c/42990] "warning: implicit declaration of function 'xxx' " instead of "error: ..."

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-02-07 14:49 ---
The linker didn't complain because atof is in libc which is linked in.  atoi
does work because any unprototyped function is treated as

int function();

thus the unprototyped atof results in

int atof();

which leads the compiler to insert a conversion from the presumed integer
return type to the floating-point result.  Which is what causes your
observation.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990

[Bug c/42990] "warning: implicit declaration of function 'xxx' " instead of "error: ..."

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-02-07 14:54 ---
Btw, with -std=c99 -pedantic-errors you will get an error for missing
prototypes (not so with -std=c89 or the default, which is -std=gnu89, because
as was said C89 allows unprototyped functions).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990

[Bug middle-end/42961] [4.5 regression] IRA register preferencing bug

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.4
   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42961

[Bug middle-end/42973] [4.4/4.5 regression] IRA apparently systematically making reload too busy on 2 address instructions with 3 operands

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-02-07 15:03 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.4.3 4.5.0
  Known to work||4.3.4
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 15:03:02
   date||
Summary|[4.5 regression] IRA|[4.4/4.5 regression] IRA
   |apparently systematically   |apparently systematically
   |making reload too busy on 2 |making reload too busy on 2
   |address instructions with 3 |address instructions with 3
   |operands|operands


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42973

[Bug debug/42977] [4.5 Regression] "-fcompare-debug failure" with "-O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC"

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-07 15:06 ---
Confirmed.  The difference is from scheduling:

--- t.gk.gkd2010-02-07 16:05:02.0 +0100
+++ t.gkd   2010-02-07 16:05:01.0 +0100
@@ -1900,6 +1900,9 @@
 (insn:TI# 0 0 t.C:403 (set (reg/f:SI 0 ax [389])
 (plus:SI (reg/f:SI 7 sp)
 (const_int 79 [0x4f])))# {*lea_1} (nil))
+(insn:TI# 0 0 t.C:403 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
+(reg/f:SI 0 ax [389]))# {*movsi_1} (expr_list:REG_DEAD (reg/f:SI 0 ax
[
389])
+(nil)))
 (insn:TI# 0 0 t.C:403 (set (mem/f/i:SI (plus:SI (reg/f:SI 7 sp)
 (const_int 8 [0x8])) [0 S4 A32])
 (reg/f:SI 4 si [517]))# {*movsi_1} (expr_list:REG_EQUAL (plus:SI
(reg/f
:SI 20 frame)
@@ -1911,9 +1914,6 @@
 (expr_list:REG_EQUAL (plus:SI (reg/f:SI 20 frame)
 (const_int -5 [0xfffb]))
 (nil
-(insn:TI# 0 0 t.C:403 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
-(reg/f:SI 0 ax [389]))# {*movsi_1} (expr_list:REG_DEAD (reg/f:SI 0 ax
[
389])
-(nil)))
 (call_insn:TI# 0 0 t.C:403 (parallel [
 (call (mem:QI (symbol_ref:SI
("_ZN4Glib12SignalProxy2Iv7ustringS1_E
7connectEN4sigc4slotIvNS3_3nilES5_S5_S5_EE") [flags 0x41]  ) [0 S1 A8])
 (const_int 12 [0xc]))


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 15:06:03
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977

[Bug middle-end/42988] [4.5 regression] 2 libgomp test failures

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-07 15:06 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 15:06:24
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42988

[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-02-07 15:22 ---
No, this is not really debug-expr related.  We have

struct crypto_tfm {
...
 void *__crt_ctx[] __attribute__ ((__aligned__(__alignof__(unsigned long
long;
};

and the FIELD_DECL for __crt_ctx has DECL_SIZE == 0, so get_inner_reference
on a COMPONENT_REF of __crt_ctx will leave us with *pbitsize uninitialized.

I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 15:22:59
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991

[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-02-07 15:29 ---
*** Bug 42993 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991

[Bug middle-end/42993] [4.5 Regression] simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-02-07 15:29 ---
The fix for 42991 also fixes this bug.

*** This bug has been marked as a duplicate of 42991 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993

[Bug c/42990] "warning: implicit declaration of function 'xxx' " instead of "error: ..."

[vyg84 at mail dot ru]

--- Comment #7 from vyg84 at mail dot ru  2010-02-07 17:07 ---
I agree with all above but in my case linker should raise error "unresolved
external: int atof(char* )" without having in glibc "int atof(char* )" (but
should not for "double atof(char* )"). 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990

[Bug c/42990] "warning: implicit declaration of function 'xxx' " instead of "error: ..."

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2010-02-07 17:10 ---
Except C linkage does not have that information stored anywhere :).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990

[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-02-07 17:18 ---
Subject: Bug 42991

Author: rguenth
Date: Sun Feb  7 17:18:22 2010
New Revision: 156575

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156575
Log:
2010-02-07  Richard Guenther  

PR middle-end/42991
* expr.c (get_inner_reference): Always initialize *pbitsize.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991

[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-02-07 17:18 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991

[Bug middle-end/42993] [4.5 Regression] simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)

[dcb314 at hotmail dot com]

--- Comment #4 from dcb314 at hotmail dot com  2010-02-07 18:13 ---
(In reply to comment #2)
> Probably the same issue as PR42991.

Does fixing 42991 also fix this problem ?

I suspect it might be worth checking this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993

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

[paolo at gcc dot gnu dot org]

--- Comment #9 from paolo at gcc dot gnu dot org  2010-02-07 18:37 ---
Subject: Bug 16896

Author: paolo
Date: Sun Feb  7 18:36:48 2010
New Revision: 156578

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156578
Log:
2010-02-07  Paolo Carlini  

PR libstdc++/16896
* include/bits/stl_list.h (_List_node_base::transfer): Rename
to _M_transfer.
(_List_node_base::reverse): Rename to _M_reverse.
(_List_node_base::hook): Rename to _M_hook.
(_List_node_base::unhook): Rename to _M_unhook; adjust callers.
* include/bits/list.tcc: Adjust callers.
* src/list.cc: Adjust.
* src/compatibility.cc: Likewise.
* src/compatibility-list.cc: New.
* src/compatibility-debug_list.cc: Likewise.
* src/compatibility-parallel_list.cc: Likewise.
* src/Makefile.am: Add.
* src/Makefile.in: Regenerate.
* config/abi/pre/gnu.ver: Export _M_* symbols.

* src/hash.cc: Rename to hash-aux.cc.
* src/compatibility-ldbl.cc: Adjust.
* src/compatibility-c++0x.cc: Likewise.
* src/hash_tr1.cc: Likewise.

* src/hashtable.cc: Rename to hashtable-aux.cc.
* src/hashtable_c++0x.cc: Adjust.
* src/hashtable_tr1.cc: Likewise.

* src/limits_c++0x.cc: Fold...
* src/limits.cc... here.

Added:
trunk/libstdc++-v3/src/compatibility-debug_list.cc
trunk/libstdc++-v3/src/compatibility-list.cc
trunk/libstdc++-v3/src/compatibility-parallel_list.cc
trunk/libstdc++-v3/src/hash-aux.cc
  - copied unchanged from r156570, trunk/libstdc++-v3/src/hash.cc
trunk/libstdc++-v3/src/hashtable-aux.cc
  - copied unchanged from r156570, trunk/libstdc++-v3/src/hashtable.cc
Removed:
trunk/libstdc++-v3/src/hash.cc
trunk/libstdc++-v3/src/hashtable.cc
trunk/libstdc++-v3/src/limits_c++0x.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/include/bits/list.tcc
trunk/libstdc++-v3/include/bits/stl_list.h
trunk/libstdc++-v3/src/Makefile.am
trunk/libstdc++-v3/src/Makefile.in
trunk/libstdc++-v3/src/compatibility-c++0x.cc
trunk/libstdc++-v3/src/compatibility-ldbl.cc
trunk/libstdc++-v3/src/compatibility.cc
trunk/libstdc++-v3/src/hash_tr1.cc
trunk/libstdc++-v3/src/hashtable_c++0x.cc
trunk/libstdc++-v3/src/hashtable_tr1.cc
trunk/libstdc++-v3/src/limits.cc
trunk/libstdc++-v3/src/list.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16896

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

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2010-02-07 18:37 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16896

[Bug bootstrap/42666] xgcc: Internal error: segmentation violation (program cc1)

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-02-07 18:58 ---
Have you tried building in a different directory than the source directory?
Do you have any environment variables set like CFLAGS, etc?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |bootstrap


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42666

[Bug target/42940] Building GCC C compiler for --target=m68hc12-elf ends with ICE SIGSEG

[wlodzimierz dot lipert+gcc at gmail dot com]

--- Comment #8 from wlodzimierz dot lipert+gcc at gmail dot com  2010-02-07 
19:06 ---
Hi,

I think problem may be in gcc.c do_spec_1() function,
GCC segfaults after calling do_spec() -> do_spec_2() -> do_spec_1() (seg fault
here).

Building of libgcc with DEBUG_SPECS.

/home/vlad/opt/gcc-build/./gcc/xgcc -B/home/vlad/opt/gcc-build/./gcc/
-B/home/vlad/CPU12/m68hc12-elf/bin/ -B/home/vlad/CPU12/m68hc12-elf/lib/
-isystem /home/vlad/CPU12/m68hc12-elf/include -isystem
/home/vlad/CPU12/m68hc12-elf/sys-include -O2 -g -save-temps -g -DDEBUG_SPECS
-m68hc11 -Os -mrelax  -DUSE_GAS -DIN_GCC -Dinhibit_libc -g  -DIN_LIBGCC2  -I.
-I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../../gcc/libgcc/../gcc/libgcc2.c \

Processing spec (trad_capable_cpp), which is 'cc1 -E
%{traditional|ftraditional|traditional-cpp:-traditional-cpp}'
Processing spec (cpp_options), which is '%(cpp_unique_options) %1 %{m*}
%{std*&ansi&trigraphs} %{W*&pedantic*} %{w} %{f*}
%{g*:%{!g0:%{!fno-working-directory:-fworking-directory}}} %{O*} %{undef}
%{save-temps:-fpch-preprocess}'
Processing spec (cpp_unique_options), which is '%{C|CC:%{!E:%eGCC does not
support -C or -CC without -E}} %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v}
%{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD
%{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*}
%{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}} %{remap}
%{g3|ggdb3|gstabs3|gcoff3|gxcoff3|gvms3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i
%{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP
-D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}'
Processing spec (cc1_options), which is '%{pg:%{fomit-frame-pointer:%e-pg and
-fomit-frame-pointer are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*}
%{m*} %{a*} %{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase
%b}} %{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs} %{v:-version}
%{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help}
%{--target-help:--target-help} %{--help=*:--help=%(VALUE)}
%{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*}
%{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants}
%{coverage:-fprofile-arcs -ftest-coverage}'
Processing spec (invoke_as), which is '%{!S:-o %|.s |
 as %(asm_options) %m.s %A }'
../../../../gcc/libgcc/../gcc/libgcc2.c: In function '__muldi3':
../../../../gcc/libgcc/../gcc/libgcc2.c:566: internal compiler error:
Segmentation fault


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42940

[Bug driver/42994] New: Status of using both -m32 and -m64 on the same command line

[jengelh at medozas dot de]

I noticed that combining -m32 and -m64 has different effects on different
platforms.

On sparc64:
20:06 ares:../libhugetlbfs/libhugetlbfs-2.0 > gcc -c -m32 -m64 x.c
gcc: may not use both -m32 and -m64

On x86_64:
20:11 borg:~/obs > >x.c
20:11 borg:~/obs > gcc -c -m32 -m64 x.c
(no error)

I think that this behavior should be unified across gcc's supported arches, and
I would opt for not allowing both -m32 and -m64, to detect flawed packages
(like libhugetlbfs in this case) that manually add -m64 - perhaps even in the
wrong place - based upon their arch detection heuristic (which is generally not
accurate).

The particular example point in case is rpmbuilding on SUSE where RPM_OPT_FLAGS
carries -m32 (this is correct) and libhugetlbfs's Makefile statically adds -m64
(this is incorrect). This error has not popped up earlier since combining -m32
and -m64 is unfortunately permitted on x86.


-- 
   Summary: Status of using both -m32 and -m64 on the same command
line
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jengelh at medozas dot de
 GCC build triplet: sparc64-suse-linux-gnu
  GCC host triplet: sparc64-suse-linux-gnu
GCC target triplet: sparc64-suse-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994

[Bug target/42994] Status of using both -m32 and -m64 on the same command line

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-07 19:21 ---
>I think that this behavior should be unified across gcc's supported arches, 

Why -m* means it is a target specific option?

x86_64 and powerpc64 both have the same behavior of having the last one being
the used one which is like options act like.  So really this is a sparc64 issue
only.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|driver  |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994

[Bug middle-end/42988] [4.5 regression] 2 libgomp test failures

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-02-07 19:49 ---
Subject: Bug 42988

Author: spop
Date: Sun Feb  7 19:49:06 2010
New Revision: 156582

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156582
Log:
Fix PR42988: handle unknown_dependence.

2010-02-07  Sebastian Pop  

PR middle-end/42988
* graphite-dependences.c (dependence_polyhedron): Set PDDR_KIND
to unknown_dependence.
(graphite_legal_transform_dr): Handle the unknown_dependence.
(graphite_carried_dependence_level_k): Same.

* testsuite/libgomp.graphite/force-parallel-5.c: Un-XFAILed.
* testsuite/libgomp.graphite/pr41118.c: Renamed from pr4118.

Added:
trunk/libgomp/testsuite/libgomp.graphite/pr41118.c
  - copied, changed from r156581,
trunk/libgomp/testsuite/libgomp.graphite/pr4118.c
Removed:
trunk/libgomp/testsuite/libgomp.graphite/pr4118.c
Modified:
trunk/gcc/ChangeLog.graphite
trunk/gcc/graphite-dependences.c
trunk/libgomp/ChangeLog.graphite
trunk/libgomp/testsuite/libgomp.graphite/force-parallel-5.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42988

[Bug middle-end/42988] [4.5 regression] 2 libgomp test failures

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-02-07 19:50 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42988

[Bug target/42683] gcc manpage: Description of x86 -march not clear regarding mmx

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-07 19:51 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|other   |target
 Ever Confirmed|0   |1
   Keywords||documentation
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 19:51:59
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42683

[Bug c++/42765] If the compile fails, the gch is still produced.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-07 20:01 ---


*** This bug has been marked as a duplicate of 33980 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42765

[Bug pch/33980] Precompiled header file not removed on error

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-02-07 20:01 ---
*** Bug 42765 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||JamesMikeDuPont at
   ||googlemail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980

[Bug pch/33980] Precompiled header file not removed on error

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-02-07 20:02 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|Linux OpenSuse 10.3 |
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:02:23
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980

[Bug middle-end/42688] gcc 4.3.3 with -O2 thinks a often non-zero expression is always zero

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-02-07 20:04 ---
You can gzip the preprocessed source if needed.  Also It might be the case we
are jump threading in one case and not in the other which causes the zero
expression to show up and that causes glibc's headers to produce the warning
...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42688

[Bug target/42778] Superfluous stack management code is generated

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-07 20:09 ---
Confirmed, a target bug.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |target
 Ever Confirmed|0   |1
   GCC host triplet|GCC-|
   |trunk(20100107)/Cygwin/WinXP|
   |32  |
 GCC target triplet||i?86-*-*
   Keywords||missed-optimization
  Known to fail||4.3.2 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:09:31
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42778

[Bug other/42792] cc1-dummy link fails with missing tree_ and rtl_ functions

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-02-07 20:11 ---
What happens if you build in a different directory than the source directory?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42792

[Bug bootstrap/42787] Failed to "make all-target"

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-02-07 20:16 ---
That line of compiling does not make sense as it is trying to compile
gcc/config/m32r/m32r.c as a target object file while it should only be compiled
for the host machine ...

How did you configure gcc? 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|c   |bootstrap


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787

[Bug bootstrap/42827] error in building libgcc; error: 'BITS_PER_UNIT' undeclared

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-02-07 20:18 ---
How did you invoke configure and make?  What are your env variables settings
for CFLAGS, STAGE1_CFLAGS and BOOT_CFLAGS?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
 Status|UNCONFIRMED |WAITING
  Component|target  |bootstrap


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42827

[Bug lto/42826] lto1: ICE in ipcp_iterate_stage, at ipa-cp.c:759

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42826

[Bug c/42867] isfinite macro defined for 4.4.1 but not for 4.3.3

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-02-07 20:23 ---
Not a FSF GCC bug so closing.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867

[Bug java/42892] Incorrect code generated for enhanced for loop.

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-02-07 20:25 ---
Confirmed to ...


-- 

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 |2010-02-07 20:25:51
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892

[Bug java/42892] Incorrect code generated for enhanced for loop.

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-02-07 20:26 ---
Suspend.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892

[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments

[xavier dot guerin at imag dot fr]

--- Comment #6 from xavier dot guerin at imag dot fr  2010-02-07 20:28 
---
I found my issue. MIPS backend assumes that the $sp is aligned on a double word
frontier. Although my thread's stack malloc guarantee this point, my
context_init was applying a wrong mask to the final stack address. It is now
fixed.

Thank you for your help.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39640

[Bug c++/42911] [4.5 Regression] another compiler hang for -g -O2

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||compile-time-hog
Summary|another compiler hang for -g|[4.5 Regression] another
   |-O2 |compiler hang for -g -O2
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42911

[Bug tree-optimization/42720] Problematic condition simplification logic at unswitch-loops pass

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2010-02-07 20:28 
---
Confirmed.


-- 

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 |2010-02-07 20:28:09
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42720

[Bug tree-optimization/42729] [4.5 Regression] "-fcompare-debug failure" with "-O1 -fgraphite-identity"

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, wrong-
   ||code
Summary|"-fcompare-debug failure"   |[4.5 Regression] "-fcompare-
   |with "-O1 -fgraphite-   |debug failure" with "-O1 -
   |identity"   |fgraphite-identity"
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42729

[Bug debug/42918] [4.5 Regression] "-fcompare-debug failure" with "-O2 -ftracer" (2)

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, wrong-
   ||code
Summary|"-fcompare-debug failure"   |[4.5 Regression] "-fcompare-
   |with "-O2 -ftracer" (2) |debug failure" with "-O2 -
   ||ftracer" (2)
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42918

[Bug preprocessor/42921] No error with missing header and -MM

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-07 20:33 ---


*** This bug has been marked as a duplicate of 28435 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42921

[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2010-02-07 20:33 
---
*** Bug 42921 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rhansen at bbn dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435

[Bug tree-optimization/42931] [4.4/4.5 Regression] -ftree-loop-linear - valgrind warns about using uninitialized variable

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
Summary|-ftree-loop-linear -|[4.4/4.5 Regression] -ftree-
   |valgrind warns about using  |loop-linear - valgrind warns
   |uninitialized variable  |about using uninitialized
   ||variable
   Target Milestone|--- |4.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42931

[Bug tree-optimization/42916] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops -ftree-vectorize"

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-02-07 20:37 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, wrong-
   ||code
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:37:17
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42916

[Bug debug/42897] [4.5 Regression] yet another ice in verify_ssa

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:37:51
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42897

[Bug c++/42938] ICE with 4.4.2 on MIPS

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-02-07 20:38 ---
Can you attach the preprocessed source?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938

[Bug rtl-optimization/42946] [4.5 Regression] bootstrap with --enable-checking=df (or =all) fails

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-07 20:56 ---
I have an obvious patch which fixes this.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
  Component|bootstrap   |rtl-optimization
 Ever Confirmed|0   |1
   Keywords||build
   Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:56:18
   date||
Summary|bootstrap with --enable-|[4.5 Regression] bootstrap
   |checking=df (or =all) fails |with --enable-checking=df
   ||(or =all) fails
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42946

[Bug rtl-optimization/42941] -fsched-pressure -fschedule-insns - valgrind warns about using uninitialized variable

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-02-07 20:57 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42941

[Bug driver/42955] undecorated cross-compiler gcc fails to find cc1

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955

[Bug other/42966] add some indication that a warning has been converted to an error

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-02-07 20:58 ---
Confirmed.


-- 

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 |2010-02-07 20:58:38
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42966

[Bug other/42965] no "warnings being treated as errors" for individual -Werror=x options

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-02-07 20:58 ---
Confirmed.


-- 

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 |2010-02-07 20:58:50
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42965

[Bug tree-optimization/42971] GCC cannot perform partial inlining

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-07 21:01 ---
Related to PR 10474.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42971

[Bug target/42976] Illegal translation for IF operator

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
  Component|c++ |target
  GCC build triplet|avr |
   Keywords||wrong-code
Version|unknown |4.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42976

[Bug c++/42938] ICE with 4.4.2 on MIPS

[manuel dot montezelo at gmail dot com]

--- Comment #3 from manuel dot montezelo at gmail dot com  2010-02-07 21:02 
---
As I said in the report:
"Neither I nor the official developer who uploaded the package have access to
the machines to provide you the intermediate generated files to help debugging
the problem or anything, nor to test in MIPS architecture with newest GCC
versions.  All the versions of packages with their private Debian patches and
everything is available to download, of course."

By other words, this happened in the Debian farm building the binaries and we
don't have access to it, and we don't have access to any other MIPS machine. 
All the versions of the software involved is in the links provided (especially
the build log), and all the software including specific Debian patches is
available for download in Debian.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938

[Bug c++/42938] ICE with 4.4.2 on MIPS

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-02-07 21:16 ---
Then it is up to debian to upload the sources ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938

[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)

[cgd at google dot com]

--- Comment #16 from cgd at google dot com  2010-02-07 21:24 ---
(In reply to comment #15)
> *** Bug 42921 has been marked as a duplicate of this bug. ***
> 

FWIW, I actually think that's a different issue (though certainly related).

this bug was all about -MD and -MMD -- and what happens when an object file
needs to be output, but cannot be because of a missing include.

AFAICT, that bug is all about, what should the handling of -MM be vs. missing
system headers.

That having been said, I will note that with:
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

you get the results:

[...@laptop tmp]$ echo "#include " > foo.c
[...@laptop tmp]$ gcc -MM -MF foo.d foo.c && echo succeeded || echo failed
foo.c:1:28: does_not_exist.h: No such file or directory
failed
[...@laptop tmp]$ echo '#include "does_not_exist.h"' > foo.c
[...@laptop tmp]$ gcc -MM -MF foo.d foo.c && echo succeeded || echo failed
foo.c:1:28: does_not_exist.h: No such file or directory
failed

So this certainly used to behave as the submitter of 42921 expected at *some*
point.

As of 4.2.2 (the next version I have handy after 3.4.4) the first case reported
"succeeded" (and the second failed).

--cgd


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435

[Bug middle-end/42688] gcc 4.3.3 with -O2 thinks a often non-zero expression is always zero

[mnemo at minimum dot se]

--- Comment #5 from mnemo at minimum dot se  2010-02-07 21:34 ---
The gzipped output is also too big for this bugzilla instance to handle. It
should be easy for you to download the *.tar.gz from the description and just
run "gcc -E -O2" on it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42688

[Bug c++/42938] ICE with 4.4.2 on MIPS

[manuel dot montezelo at gmail dot com]

--- Comment #5 from manuel dot montezelo at gmail dot com  2010-02-07 21:37 
---
What do you mean with "provide the sources"?  I created the package, and as I
said it's available for downloading from Debian, as any package, including all
the private/Debian-specific modifications:
http://packages.debian.org/source/unstable/openscenegraph (at the bottom).

But I don't think that nobody is going to enter the Debian farm, maybe restore
the state of the machine when the building failed (related software versions),
change the commands to produce preprocessor intermediate files, and attach them
to this bug report -- if that's what you mean.

I reported the error because an ICE seems important to me, and in the hope that
it might be of interest and that maybe you have the means to get a MIPS machine
and reproduce it with our package, or at least check in the near future whether
newer releases of the compiler fix the bug.  But I also warned in the original
report that further information or testing patches from our part wouldn't be
possible in general.  It's up to you to close the report if you don't think
that it's useful.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938

[Bug bootstrap/42827] error in building libgcc; error: 'BITS_PER_UNIT' undeclared

[marekarturpenther at gmail dot com]

--- Comment #4 from marekarturpenther at gmail dot com  2010-02-07 22:07 
---
Subject: Re:  error in building libgcc; error: 'BITS_PER_UNIT' undeclared

BOOT_CFLAGS is same as CFLAGS:
-mmmx -m3dnow -msse -march=athlon-xp -mtune=athlon-xp -O2 -pipe -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DUSE_3DNOW_PREFETCH
STAGE1_CFLAGS is empty (not set)
anyway I forcing using all setuped flags by invoking make with this flags 
before make, because I using chroot environment to build gcc. I started to 
use it, when I had problem with java, but I found out it is bug in gcc.

On Sunday 07 February 2010 20:18, pinskia at gcc dot gnu dot org wrote:
> --- Comment #3 from pinskia at gcc dot gnu dot org  2010-02-07 20:18
> --- How did you invoke configure and make?  What are your env variables
> settings for CFLAGS, STAGE1_CFLAGS and BOOT_CFLAGS?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42827

[Bug target/42994] Status of using both -m32 and -m64 on the same command line

[rguenther at suse dot de]

--- Comment #2 from rguenther at suse dot de  2010-02-07 22:09 ---
Subject: Re:   New: Status of using both -m32 and -m64 on
 the same command line

On Sun, 7 Feb 2010, jengelh at medozas dot de wrote:

> I noticed that combining -m32 and -m64 has different effects on different
> platforms.
> 
> On sparc64:
> 20:06 ares:../libhugetlbfs/libhugetlbfs-2.0 > gcc -c -m32 -m64 x.c
> gcc: may not use both -m32 and -m64
> 
> On x86_64:
> 20:11 borg:~/obs > >x.c
> 20:11 borg:~/obs > gcc -c -m32 -m64 x.c
> (no error)
> 
> I think that this behavior should be unified across gcc's supported arches, 
> and
> I would opt for not allowing both -m32 and -m64, to detect flawed packages
> (like libhugetlbfs in this case) that manually add -m64 - perhaps even in the
> wrong place - based upon their arch detection heuristic (which is generally 
> not
> accurate).
> 
> The particular example point in case is rpmbuilding on SUSE where 
> RPM_OPT_FLAGS
> carries -m32 (this is correct) and libhugetlbfs's Makefile statically adds 
> -m64
> (this is incorrect). This error has not popped up earlier since combining -m32
> and -m64 is unfortunately permitted on x86.

It's never correct for RPM_OPT_FLAGS to add either -m32 or -m64.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994

[Bug bootstrap/42827] error in building libgcc; error: 'BITS_PER_UNIT' undeclared

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-02-07 22:09 ---
So I think we are miscompiling GCC with BOOT_CFLAGS set.  I don't have access
to an x86 machine which could use those CFLAGS so someone else needs to debug
this.  Can you try 4.4.3?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42827

[Bug target/42994] Status of using both -m32 and -m64 on the same command line

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2010-02-07 22:58 ---
Subject: Re:  Status of using both -m32 and -m64 on the
 same command line

On Sun, 7 Feb 2010, pinskia at gcc dot gnu dot org wrote:

> >I think that this behavior should be unified across gcc's supported arches, 
> 
> Why -m* means it is a target specific option?

It's a lot less confusing for people using GCC for multiple targets (and 
the wide range of target support is one of the major advantages of GCC) if 
when multiple targets do similar things, they do so the same way where 
possible.  Unfortunate inconsistencies include:

* The combination of -march, -mcpu and -mtune options available, and what 
-mcpu means where it is available (also, some targets have yet other 
options for specifying target processors).

* The options used for selecting endianness where applicable 
(-mbig-endian, -meb, -mb, -EB).

* Whether interrupt handlers use the "interrupt" or "interrupt_handler" 
attribute.

It's not that code using one of these options would do so in a 
cross-platform way; it's that having consistency would be beneficial to 
users doing similar things for multiple targets.

> x86_64 and powerpc64 both have the same behavior of having the last one being
> the used one which is like options act like.  So really this is a sparc64 
> issue
> only.

Yes, similar to the above there should be consistency in how options 
overriding each other work, and I describe a proposed model for this in 
 (Appendix 1) which means 
the last option specified wins in cases like this of options that are 
exact opposites.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994

[Bug middle-end/42995] New: [4.3 regression] inline-small-functions does not inline simple delegation calls

[matt at use dot net]

Using gcc 4.4.1 under Ubuntu 9.10 on amd64:

main.c:

#include "database.h"

int main()
{
  int my_id = 0;
  int result_for_my_id = get_data_for(my_id);

  switch (result_for_my_id)
  {
case 0:
  return 666;
default:
  return -1;
  }
}

database.h:
#include 

int get_data_for(int id)
{
  return rand();
}

Compiling with:
gcc -O2 main.c -o n

produces this code:
00400380 :
  400380:   48 83 ec 08 subrsp,0x8
  400384:   31 ff   xoredi,edi
  400386:   e8 e5 ff ff ff  call   400370 
  40038b:   83 f8 01cmpeax,0x1
  40038e:   19 c0   sbbeax,eax
  400390:   48 83 c4 08 addrsp,0x8
  400394:   25 9b 02 00 00  andeax,0x29b
  400399:   83 e8 01subeax,0x1
  40039c:   c3  ret
  40039d:   0f 1f 00nopDWORD PTR [rax]

Note the 3 bytes of padding after the return. I'm confused why
inline-small-functions does not inline get_data_for. I tried this experiment:
gcc -O2 -finline-functions --param max-inline-insns-auto=20 main.c -o n

which produces this code:
00400380 :
  400380:   48 83 ec 08 subrsp,0x8
  400384:   e8 27 02 00 00  call   4005b0 
  400389:   83 f8 01cmpeax,0x1
  40038c:   19 c0   sbbeax,eax
  40038e:   48 83 c4 08 addrsp,0x8
  400392:   25 9b 02 00 00  andeax,0x29b
  400397:   83 e8 01subeax,0x1
  40039a:   c3  ret
  40039b:   0f 1f 44 00 00  nopDWORD PTR [rax+rax*1+0x0]

The padding got larger, but the code is actually smaller. Shouldn't the
heuristic used for inline-small-functions have caused get_data_for() to be
inlined?

This does not appear to be a problem in GCC 4.5.20091228 or 4.3.4.


-- 
   Summary: [4.3 regression] inline-small-functions does not inline
simple delegation calls
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at use dot net
 GCC build triplet: x86_64-linux-unknown
  GCC host triplet: x86_64-linux-unknown
GCC target triplet: x86_64-linux-unknown


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42995

[Bug middle-end/42995] [4.3 regression] inline-small-functions does not inline simple delegation calls

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-07 23:03 ---
>The padding got larger,

But the alignment stayed the same. :).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42995

[Bug rtl-optimization/42946] [4.5 Regression] bootstrap with --enable-checking=df (or =all) fails

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-02-07 23:23 ---
Subject: Bug 42946

Author: pinskia
Date: Sun Feb  7 23:22:49 2010
New Revision: 156589

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156589
Log:
2010-02-07  Andrew Pinski  

PR middle-end/42946
* df-core.c (df_finish_pass): Change type of saved_flags to int.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-core.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42946

[Bug rtl-optimization/42946] [4.5 Regression] bootstrap with --enable-checking=df (or =all) fails

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-02-07 23:23 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42946

[Bug preprocessor/42921] No error with missing header and -MM

[rhansen at bbn dot com]

--- Comment #2 from rhansen at bbn dot com  2010-02-08 05:33 ---
Reopening; this is a different issue than bug 28435.

Chris Demetriou in bug 28435, comment 16 says:
> FWIW, I actually think that's a different issue (though certainly related).
>
> this bug was all about -MD and -MMD -- and what happens when an object file 
> needs to be output, but cannot be because of a missing include.
>
> AFAICT, that bug is all about, what should the handling of -MM be vs. 
> missing system headers.
>
> That having been said, I will note that with:
> gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
>
> you get the results:
>
> [...@laptop tmp]$ echo "#include " > foo.c
> [...@laptop tmp]$ gcc -MM -MF foo.d foo.c && echo succeeded || echo failed
> foo.c:1:28: does_not_exist.h: No such file or directory
> failed
> [...@laptop tmp]$ echo '#include "does_not_exist.h"' > foo.c
> [...@laptop tmp]$ gcc -MM -MF foo.d foo.c && echo succeeded || echo failed
> foo.c:1:28: does_not_exist.h: No such file or directory
> failed
>
> So this certainly used to behave as the submitter of 42921 expected at 
> *some* point.
>
> As of 4.2.2 (the next version I have handy after 3.4.4) the first case 
> reported "succeeded" (and the second failed).
>
> --cgd


-- 

rhansen at bbn dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42921

[Bug middle-end/42860] ICE in gcc-4.4.3 with graphite

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2010-02-08 05:50 ---
Works with trunk GCC 4.5 at rev. 156585.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42860

[Bug bootstrap/42827] error in building libgcc; error: 'BITS_PER_UNIT' undeclared

[marekarturpenther at gmail dot com]

--- Comment #6 from marekarturpenther at gmail dot com  2010-02-08 05:55 
---
Subject: Re:  error in building libgcc; error: 'BITS_PER_UNIT' undeclared

I can't compile it without 4.3.4, becuase depends could not be compiled by 
4.2.4.
There is another bug in all versions of gcc:
building libada (if I am not wrong), gnatmake using just gcc, even if other 
exec is forced to be used by using $CC (in my case gcc-4.2.4 with flags), and 
this effecting in not compatible *.ali files. I will find it and report, but 
not now, cause I going to work right now.

On Sunday 07 February 2010 22:09, pinskia at gcc dot gnu dot org wrote:
> --- Comment #5 from pinskia at gcc dot gnu dot org  2010-02-07 22:09
> --- So I think we are miscompiling GCC with BOOT_CFLAGS set.  I don't
> have access to an x86 machine which could use those CFLAGS so someone else
> needs to debug this.  Can you try 4.4.3?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42827

[Bug bootstrap/39395] cloog link failure with non-gcc bootstrap compiler

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-02-08 05:58 ---
This should be fixed by now.
Please open again this PR if this is still a problem.

Sebastian


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39395

[Bug other/42530] [graphite] ICE in verify_ssa when using -O -g -ffast-math -floop-parallelize-all

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-02-08 06:09 ---
Mine.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-29 05:10:35 |2010-02-08 06:09:01
   date||
Summary|ICE in verify_ssa when using|[graphite] ICE in verify_ssa
   |-O -g -ffast-math -floop-   |when using -O -g -ffast-math
   |parallelize-all |-floop-parallelize-all


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42530

[Bug middle-end/42914] [4.5 Regression][graphite] ICE with -g -ffast-math -fgraphite-identity -O2: verify_ssa failed

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2010-02-08 06:09 ---
Mine.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-02-02 13:33:02 |2010-02-08 06:09:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42914

[Bug middle-end/42914] [4.5 Regression][graphite] ICE with -g -ffast-math -fgraphite-identity -O2: verify_ssa failed

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-02-08 06:10 ---
May be a dup of PR42530.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||42530


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42914

[Bug libfortran/42742] Handle very large format strings correctly

[jvdelisle at gcc dot gnu dot org]

--- Comment #20 from jvdelisle at gcc dot gnu dot org  2010-02-07 08:00 
---
Fixed on trunk.  Will back port to 4.4 in a few days.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742

[Bug c/42990] "warning: implicit declaration of function 'xxx' " instead of "error: ..."

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-02-07 08:26 ---
C90 has implicit declarations.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990

[Bug c/42990] "warning: implicit declaration of function 'xxx' " instead of "error: ..."

[schwab at linux-m68k dot org]

--- Comment #3 from schwab at linux-m68k dot org  2010-02-07 09:15 ---
Use -Werror-implicit-function-declaration.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990

[Bug c/42991] New: cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)

[dcb314 at hotmail dot com]

I just tried to compile the Linux kernel 2.6.33-rc6 under valgrind
with the C compiler version 4.5 snapshot 20100128 and valgrind said

==17102== Conditional jump or move depends on uninitialised value(s)
==17102==at 0x56D105: expand_debug_expr (cfgexpand.c:2487)
==17102==by 0x56C912: expand_debug_expr (cfgexpand.c:2876)
==17102==by 0x570D54: gimple_expand_cfg (cfgexpand.c:2981)
==17102==by 0x722ECA: execute_one_pass (passes.c:1561)
==17102==by 0x723154: execute_pass_list (passes.c:1616)
==17102==by 0x818C94: tree_rest_of_compilation (tree-optimize.c:413)
==17102==by 0x99A420: cgraph_expand_function (cgraphunit.c:1543)
==17102==by 0x99CE44: cgraph_optimize (cgraphunit.c:1622)
==17102==by 0x99D3A4: cgraph_finalize_compilation_unit (cgraphunit.c:1093)
==17102==by 0x4B0602: c_write_global_declarations (c-decl.c:9537)
==17102==by 0x7C7AFB: toplev_main (toplev.c:1065)
==17102==by 0x6568A7C: (below main) (in /lib64/libc-2.10.1.so)
==17102==

Line 2487 of cfgexpand.c is

if (bitsize == 0)
  return NULL;

Preprocessed source code attached. Flags -Os -g required.


-- 
   Summary: cfgexpand.c:2487: Conditional jump or move depends on
uninitialised value(s)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991

[Bug c/42991] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2010-02-07 10:25 ---
Created an attachment (id=19817)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19817&action=view)
C source code


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991

[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-07 10:58 ---
Which means that likely DEBUG_DECLs do not have DECL_SIZE set properly.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org
   Keywords||wrong-debug
Summary|cfgexpand.c:2487:   |[4.5 Regression]
   |Conditional jump or move|cfgexpand.c:2487:
   |depends on uninitialised|Conditional jump or move
   |value(s)|depends on uninitialised
   ||value(s)
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991

[Bug target/42981] internal compiler error: in default_secondary_reload, at targhooks.c:660

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2010-02-07 11:17 ---
(In reply to comment #4)
> A bisection has identified this as a regression on 4.4 branch triggered by
> r147081, the fix for PR39914. The same change was committed to trunk too, but
> for some reason doesn't trigger the ICE there.

Trunk also ICEd on this test case for a while, but that was fixed by r147282,
one of several fixes to fwprop/df-problems.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42981

[Bug c++/42992] New: [C++0x] =default erases virtual declaration of a destructor.

[albrt2000 at gmail dot com]

Hello,

Following code :
#include 

struct A {
virtual ~A()=default;

};

struct B : public A {
virtual ~B() {
std::cout << "B destructor\n";
}

};

int main() {
B* b = new B;
A* pA = b;
delete pA;
return 0;
}
outputs nothing, B destructor is not called as if A destructor was not
considered as virtual.

However, following code works fine :
#include 

struct A {
virtual ~A();
};

A::~A()=default;

struct B : public A {
virtual ~B() {
std::cout << "B destructor\n";
}

};

int main() {
B* b = new B;
A* pA = b;
delete pA;
return 0;
}
It outputs "B destrucor".
Having to separate virtual declaration from default definition seems to be out
of spec.

Bug found with MinGW/gcc 4.4.1..
Compilation command :
mingw32-g++.exe -Wall -fexceptions  -Wmain -pedantic -W -g -std=c++0x -c
main.cpp -o obj\Debug\main.o
mingw32-g++.exe  -o bin\Debug\TestCpp.exe obj\Debug\main.o  

Best Regards
Albert.


-- 
   Summary: [C++0x] =default erases virtual declaration of a
destructor.
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: albrt2000 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42992

[Bug c++/42992] [C++0x] =default erases virtual declaration of a destructor.

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-02-07 11:43 
---


*** This bug has been marked as a duplicate of 42983 ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42992

[Bug c++/42983] [C++0x] Defaulted virtual destructor isn't virtual

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-02-07 11:43 
---
*** Bug 42992 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||albrt2000 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42983

[Bug target/42981] internal compiler error: in default_secondary_reload, at targhooks.c:660

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2010-02-07 11:54 ---
gcc-4.5-20100204 ICEs with -O1 -fno-forward-propagate -fPIC -mthumb on the
original test case. So r147282, which enabled fwprop at -O1, merely masked the
problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42981

[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments

[xavier dot guerin at imag dot fr]

--- Comment #4 from xavier dot guerin at imag dot fr  2010-02-07 12:32 
---
I checked GCC 4.4.2 and the issue still exists. It's extremely easy to check,
and I actually pinned the issue. I don't mind helping more (and I guess I'll
have to do it by myself anyway), but I'm completely ignorant concerning
compilation stuff.

Basically, the issue is as follows. Let's say we have this situation (note that
he behavior of function() is irrelevant) compiled for a mips32 architecture : 

int function (int n, ...)
{
…
}

int main (void)
{
  int32_t i32;
  int64_t i64_0, i64_1;

  function (3, i64_0, i32, i64_1);
  return 0;
}

## Caller behavior ##

In that case, main prepare the va_list. Right before calling function(), the
stack looks like this:

SP-40 [ X | X | X | X | n | X | upper (i64_1) | lower (i64_1) | X | RA ] SP

whereas upper (i64_0) and lower (i64_0) are stored in registers a2 and a3.
Please note that GCC inserts a bubble between  'n' and 'upper(i64_1)'. At
first, I supposed this was for double-word alignment purpose, but in my case
the address of 'upper (i64_1)' is not double-word aligned.

## Callee behavior ##

Anyhow, the callee is waiting for the following stack pattern when mashalling
the varargs: 

SP-40 [ X | X | X | X | n | upper (i64_1) | lower (i64_1) | X | X | RA ] SP

which is the same configuration but without the bubble. As  see it, the callee
code must be correct since it refers to the algorithm described in function
mips_gimplify_va_arg_expr(), line 5235 of the mips.c files, while the caller
code wrongfully inserts a bubble to correct a padding problem that does not
exit.

I think this should shed some lights on the issue I'm encountering. Maybe
somehow could tell me where I can found the va_list preparation code in the
mips.c file.

Thanks in advance for your help,
Xavier


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39640