[Bug tree-optimization/35431] [4.1/4.2 regression] ICE with complex integer, invalid gimple

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-04-02 07:15 ---
Also fixed on the 4.3 branch.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE
   |with complex integer,   |with complex integer,
   |invalid gimple  |invalid gimple


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

[Bug tree-optimization/35431] [4.1/4.2 regression] ICE with complex integer, invalid gimple

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-04-02 07:16 ---
Subject: Bug 35431

Author: pinskia
Date: Wed Apr  2 07:15:19 2008
New Revision: 133822

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133822
Log:
2008-03-31  Andrew Pinski  <[EMAIL PROTECTED]>

PR tree-opt/35431
* tree-ssa-phiopt.c (conditional_replacement): Return early for
complex types.

2008-03-31  Andrew Pinski  <[EMAIL PROTECTED]>

PR tree-opt/35431
* gcc.c-torture/compile/pr35431.c: New testcase.



Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr35431.c
  - copied unchanged from r133749,
trunk/gcc/testsuite/gcc.c-torture/compile/pr35431.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-phiopt.c


-- 


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

[Bug c++/33878] Pure virtual method body omitted from template

[herwig at gdsys dot de]

--- Comment #11 from herwig at gdsys dot de  2008-04-02 07:17 ---
(In reply to comment #10)
> Yes. Since the class declaration must be visible from the place where you 
> call this function, and since then also the function's definition 
> (=implementation) is visible, the template should be instantiated at the 
> place where you call the member function. Is this not the case?

No, it is not. And that's because this pure virtual method never gets called
explicitly.

I think the compiler is taking an illegal shortcut in assuming a pure virtual
template method never gets called. When deriving a class from the template, the
vtable is built and it surely has a slot for pvMethod() because it's a virtual
method. So the template is (fully?) instantiated at the point, where I derive
from it. See the following example:

template
class TBase
{
public:
virtual void pvMethod() = 0;
virtual void vMethod();
};

template
void TBase::pvMethod()
{
}

template
void TBase::vMethod()
{
}

class TDerived :
public TBase
{
public:
void pvMethod();
};

void TDerived::pvMethod()
{
}

int main(int argc, char** argv)
{
return 0;
}

There is no instance of TDerived whatsoever. But looking at the binary reveals
there is even a TBase::vMethod():

[EMAIL PROTECTED]:~/Programming$ g++ -O0 -Wall test.cpp -o test && objdump -t 
test |
c++filt | grep '\(TBase\|TDerived\)'
08048474 g F .text  0005  TDerived::pvMethod()
08048570  wO .rodata000a  typeinfo name for
TDerived
0804857c  wO .rodata000c  typeinfo for TDerived
08048560  wO .rodata0010  vtable for TDerived
08048590  wO .rodata0012  typeinfo name for
TBase
08048494  wF .text  0005  TBase::vMethod()
08048588  wO .rodata0008  typeinfo for
TBase

Now, in my opinion there must be a TBase::pvMethod(), because
(a) it is legal to specify a fallback implementation,
(b) the slot is surely there, and
(c) as we found out, there is no workaround for it.

Perhaps (c) is a false conclusion because you or I missed something, or (a) is
wrong concerning templates, but nevertheless it's annoying that there's no
clean solution for it. In my code I solved it by making the pure virtual method
virtual only. But now there has been at least one occasion where I forgot to
provide an implementation in a derived class...

If you think my reasoning is right, would you mind reopening the bug?

Best regards,
Björn!


-- 


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

[Bug tree-optimization/35429] [4.1/4.2/ regression] ICE with complex arithmetic

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-04-02 07:19 ---
Fixed also on the 4.3 branch.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2/ regression] ICE
   |with complex arithmetic |with complex arithmetic


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

[Bug tree-optimization/35429] [4.1/4.2/ regression] ICE with complex arithmetic

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-04-02 07:19 ---
Subject: Bug 35429

Author: pinskia
Date: Wed Apr  2 07:19:01 2008
New Revision: 133823

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133823
Log:
2008-04-02  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/35429
* fold-const.c (fold_truthop): Check for integeral types when folding
a == 0 && b == 0 and a != 0 || b != 0 .

2008-04-02  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/35429
* gcc.c-torture/compile/complex-5.c: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/complex-5.c
  - copied unchanged from r133631,
trunk/gcc/testsuite/gcc.c-torture/compile/complex-5.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug ada/35796] New: Order of progenitors in interface composition: segfault when initializing object of class-wide type.

[prog at msobczak dot com]

Note: This bug *can* be related to 35791 (they can have the same source).

procedure A is

   type Base_1 is interface;
   type Base_2 is interface;
   type Middle is interface and Base_1 and Base_2;

   type Derived is new Middle with null record;

   function Make_Derived return Derived is
   begin

  return Derived' (others => <>);

  -- alternatively:
  -- return (null record);

   end Make_Derived;

   D : Base_2'Class := Make_Derived;

begin
   null;
end;

The program compiles fine, but crashes with segmentation fault at runtime
(after a couple of seconds).

Note: The type of variable D names the second progenitor in the definition of
Middle interface. Aftr changing it to Base_1 (or changing the order of
progenitors in the definition of Middle) the program works fine.


-- 
   Summary: Order of progenitors in interface composition: segfault
when initializing object of class-wide type.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prog at msobczak dot com


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[laurent at guerby dot net]

--- Comment #27 from laurent at guerby dot net  2008-04-02 07:36 ---
My guess is that Initialize_TCB you wrote for RTEMS (s-taprop-rtems) does not
set success to True for some reason:

   procedure Initialize_ATCB
...
  STPO.Initialize_TCB (T, Success); --- here call into RTEMS specific code

  if not Success then
 return;
  end if;

  T.Common.Parent := Parent;
  T.Common.Base_Priority := Base_Priority;
  T.Common.Current_Priority := 0;    < here comes the zero

To look for variables under gdb try "set lang c", and "info local", "info arg",
you'll get strange names but you should be able to print.


-- 


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

[Bug fortran/35154] Unable to reference symbols in Fortran COMMON due to .stabs format

[george at gcc dot gnu dot org]

--- Comment #1 from george at gcc dot gnu dot org  2008-04-02 08:01 ---
Fixed in rev 133800 1 April 2008


-- 

george at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/23057] Fortran common blocks are not described with DW_TAG_common_block

[george at gcc dot gnu dot org]

--- Comment #6 from george at gcc dot gnu dot org  2008-04-02 08:08 ---
Fixed in rev 133800, 1 April 2008


-- 

george at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/35797] New: Compiler does not recognize faulty warnings starting with -Wno-

[Keller at hlrs dot de]

The gcc and g++ of trunk (svn r133789) has a problem with detecting faulty
warnings such was -Wno-this-does-not-exist.

E.g. it seems to pass on -Wno-long-double options down to, like with:
int main()
{
  return 0;
}
DOES NOT fail with gcc -c -g -Wno-long-double main.c
but DOES fail with gcc -c -g -Wno-long-double -Wstrict-prototypes main.c
main.c:2: warning: function declaration isn't a prototype
cc1: error: unrecognized command line option "-Wno-long-double"

This however works again, if -Wstrict-prototype does not trigger again:
[EMAIL PROTECTED]:~/C> cat main.c
int main (void)
{
  return 0;
}
[EMAIL PROTECTED]:~/C> gcc -c -g -Wno-long-double -Wstrict-prototypes main.c
[EMAIL PROTECTED]:~/C>

This triggers, e.g. in configure-scripts, that try to detect warnings such as
-Wno-long-double: Succeeding at first, they fail every test in compilation
later on.


-- 
   Summary: Compiler does not recognize faulty warnings starting
with -Wno-
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Keller at hlrs dot de
 GCC build triplet: i586-suse-linux-gnu
  GCC host triplet: i586-suse-linux-gnu
GCC target triplet: i586-suse-linux-gnu


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

[Bug middle-end/35797] Compiler does not recognize faulty warnings starting with -Wno-

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-02 08:33 ---
I think this is expected behavior now, see PR 28322.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |middle-end


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

[Bug middle-end/35797] Compiler does not recognize faulty warnings starting with -Wno-

[Keller at hlrs dot de]

--- Comment #2 from Keller at hlrs dot de  2008-04-02 09:35 ---
(In reply to comment #1)
> I think this is expected behavior now, see PR 28322.

Thanks Andrew. So the fix to trigger another warning was correct and is the
preferred method for configure-scripts...


-- 


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

[Bug tree-optimization/35795] [4.4 Regression] Revision 133787 breaks ia64

[hubicka at ucw dot cz]

--- Comment #3 from hubicka at ucw dot cz  2008-04-02 09:35 ---
Subject: Re:   New: [4.4 Regression] Revision 133787 breaks ia64

Hi,
I've added the assert to check that we don't initialize RTL world twice
without freeing it first (and thus that we don't leak memory).  This
seems to be the case.  Naively, something like this should fix it.
I am building a cross and will try to reproduce it.

Index: config/ia64/ia64.c
===
*** config/ia64/ia64.c  (revision 133785)
--- config/ia64/ia64.c  (working copy)
*** ia64_output_mi_thunk (FILE *file, tree t
*** 9694,9699 
--- 9694,9700 
final_start_function (insn, file, 1);
final (insn, file, 1);
final_end_function ();
+   free_after_compilation (cfun);

reload_completed = 0;
epilogue_completed = 0;


-- 


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

[Bug rtl-optimization/35542] fwprop only propagates one operand

[bonzini at gcc dot gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2008-04-02 09:57 ---
Subject: Bug 35542

Author: bonzini
Date: Wed Apr  2 09:56:17 2008
New Revision: 133829

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133829
Log:
2008-04-02  Andy Hutchinson <[EMAIL PROTECTED]>

PR rtl-optimization/35542
* fwprop.c (forward_propagate_and_simplify): Replace
loc_reg_mentioned_in_p with reg_mentioned_p.

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


-- 


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

[Bug rtl-optimization/35281] [4.3/4.4 Regression] multiply with 0 generated for 64*32->64

[bonzini at gnu dot org]

--- Comment #14 from bonzini at gnu dot org  2008-04-02 09:57 ---
committed to trunk as 133828


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand

[bonzini at gnu dot org]

--- Comment #3 from bonzini at gnu dot org  2008-04-02 09:57 ---
committed to trunk, will backport to 4.3 in due time (causes regressions for
AVR)


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
  Known to fail||4.3.0
  Known to work||4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-04-02 09:57:10
   date||
Summary|fwprop only propagates one  |[4.3 Regression] fwprop only
   |operand |propagates one operand


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #35 from bonzini at gnu dot org  2008-04-02 10:08 ---
the infinite loop is fixed, don't know if the second bug remains.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gcc dot gnu dot org]

--- Comment #36 from bonzini at gnu dot org  2008-04-02 10:08 ---
Subject: Bug 35752

Author: bonzini
Date: Wed Apr  2 10:07:58 2008
New Revision: 133832

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133832
Log:
2008-04-02  Paolo Bonzini  <[EMAIL PROTECTED]>

PR bootstrap/35752
* Makefile.in (objdir): Set it here.
* configure.ac: Not here.  Find dynamic linker characteristics.
* exec-tool.in: Use them.
* aclocal.m4: Regenerate.
* configure: Regenerate.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/aclocal.m4
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/exec-tool.in


-- 


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

[Bug rtl-optimization/35281] [4.3 Regression] multiply with 0 generated for 64*32->64

[bonzini at gnu dot org]

--- Comment #15 from bonzini at gnu dot org  2008-04-02 11:24 ---
oops, still on 4.3


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Known to work|4.1.2 4.2.3 |4.1.2 4.2.3 4.4.0
 Resolution|FIXED   |
Summary|[4.3/4.4 Regression]|[4.3 Regression] multiply
   |multiply with 0 generated   |with 0 generated for 64*32-
   |for 64*32->64   |>64


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

[Bug tree-optimization/35787] [4.4 Regression]: Revision 133680 breaks 447.dealII

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-04-02 11:29 ---
Should be fixed now.  Please re-open with the requested information if not.


-- 

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=35787

[Bug ada/35284] Branch to 0x0 from Ada run-time

[laurent at guerby dot net]

--- Comment #28 from laurent at guerby dot net  2008-04-02 11:44 ---
I did not notice that s-taprop for rtems was the posix version

   procedure Initialize_TCB (Self_ID : Task_Id; Succeeded : out Boolean) is
  Mutex_Attr : aliased pthread_mutexattr_t;
  Result : Interfaces.C.int;
  Cond_Attr  : aliased pthread_condattr_t;

   begin
...

 if Result /= 0 then
Succeeded := False;
return;
 end if;
...
  if Result = 0 then
 Succeeded := True;
  else
 if not Single_Lock then
Result := pthread_mutex_destroy (Self_ID.Common.LL.L'Access);
pragma Assert (Result = 0);
 end if;

 Succeeded := False;
  end if;
...

So it's now just a matter of finding which posix call in there fails.


-- 


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

[Bug c/35798] New: Segmentation Fault launched when compiling with optimization level>0 -O1, -O2, ...

[bankhacker at gmail dot com]

#include 

#define N 50
void test(void) {
static char *array=NULL;
int i;

if (array==NULL) {
array=calloc(N, sizeof(char));
array[0]=0;
for(i=1;i0 -O1, -O2,
...:
> "C:\Dev-Cpp\bin\gcc.exe" "segfault.c" -o "segfault.exe" -O3 
> -I"C:\Dev-Cpp\include" -L"C:\Dev-Cpp\lib"
segfault.c: In function `test':
segfault.c:16: internal compiler error: Segmentation fault
Please submit a full bug report, with preprocessed source if appropriate.
See http://www.mingw.org/bugs.shtml> for instructions.

OS version: Windows XP SP2 32-bits
gcc version: 3.4.2 (mingw-special)
ld version: GNU ld version 2.15.91 20040904
mingw version: 3.7
build environment: Dev-C++ v4.9.9.2
No MSYS
mingw-runtime version: 3.7
w32api version: 3.2

> "C:\Dev-Cpp\bin\gcc.exe" -v
Reading specs from C:/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable
-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared
--e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x
--enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)

> "C:\Dev-Cpp\bin\ld" -v
GNU ld version 2.15.91 20040904

> Compiled with Dev-C++ v4.9.9.2

I am not sure if this bug is the same that was reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791

Just in case, I am going to report it:
http://gcc.gnu.org/bugzilla/enter_bug.cgi

I have try to reproduce the bug under Linux, but I couldn't, at least compiling
with gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1) ...

It might be only a gcc 3.4.x bug ...
**/


-- 
   Summary: Segmentation Fault launched when compiling with
optimization level>0 -O1, -O2, ...
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bankhacker at gmail dot com
 GCC build triplet: "C:\Dev-Cpp\bin\gcc.exe" "segfault.c" -o "segfault.exe"
-O3 -I"C
  GCC host triplet: Windows XP SP2 32-bits
GCC target triplet: segfault.c


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

[Bug tree-optimization/14495] [tree-ssa] Propagate range info into a switch statement

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-04-02 12:52 ---
Subject: Bug 14495

Author: rguenth
Date: Wed Apr  2 12:51:37 2008
New Revision: 133834

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133834
Log:
2008-04-02  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/14495
* tree-vrp.c (vrp_visit_cond_stmt): Do not handle
SWITCH_EXPR here ...
(vrp_visit_switch_stmt): ... but here (new function).
(find_case_label_index): New helper function.
(vrp_visit_stmt): Dispatch to vrp_visit_switch_stmt.

* gcc.dg/tree-ssa/vrp40.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp40.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[Bug tree-optimization/14495] [tree-ssa] Propagate range info into a switch statement

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-04-02 12:54 ---
Subject: Bug 14495

Author: rguenth
Date: Wed Apr  2 12:54:08 2008
New Revision: 133835

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133835
Log:
2008-04-02  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/14495
PR tree-optimization/34793
* tree-vrp.c (struct switch_update): New structure.
(to_remove_edges, to_update_switch_stmts): New VECs.
(simplify_switch_using_ranges): New function.  Remove not taken
case labels and edges.
(simplify_stmt_using_ranges): Call it.
(identify_jump_threads): Mark edges we have queued for removal
so we don't thread them.
(execute_vrp): Remove edges queued for removal, update SWITCH_STMT
case label vector.
* tree-cfg.c (group_case_labels): Deal with missing default label.
(tree_verify_flow_info): Allow missing default label.
* stmt.c (emit_case_bit_tests): Deal with NULL default_label.
(emit_case_nodes): Likewise.
(expand_case): Do not rely on the default label to be present.
* expr.c (try_casesi): Deal with NULL default_label.
(do_tablejump): Likewise.

* gcc.dg/tree-ssa/vrp41.c: New testcase.
* gcc.dg/tree-ssa/vrp42.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp41.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp42.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-vrp.c


-- 


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

[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2008-04-02 12:54 
---
Subject: Bug 34793

Author: rguenth
Date: Wed Apr  2 12:54:08 2008
New Revision: 133835

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133835
Log:
2008-04-02  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/14495
PR tree-optimization/34793
* tree-vrp.c (struct switch_update): New structure.
(to_remove_edges, to_update_switch_stmts): New VECs.
(simplify_switch_using_ranges): New function.  Remove not taken
case labels and edges.
(simplify_stmt_using_ranges): Call it.
(identify_jump_threads): Mark edges we have queued for removal
so we don't thread them.
(execute_vrp): Remove edges queued for removal, update SWITCH_STMT
case label vector.
* tree-cfg.c (group_case_labels): Deal with missing default label.
(tree_verify_flow_info): Allow missing default label.
* stmt.c (emit_case_bit_tests): Deal with NULL default_label.
(emit_case_nodes): Likewise.
(expand_case): Do not rely on the default label to be present.
* expr.c (try_casesi): Deal with NULL default_label.
(do_tablejump): Likewise.

* gcc.dg/tree-ssa/vrp41.c: New testcase.
* gcc.dg/tree-ssa/vrp42.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp41.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp42.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-vrp.c


-- 


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

[Bug tree-optimization/14495] [tree-ssa] Propagate range info into a switch statement

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-02 12:55 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2008-04-02 12:56 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/35798] Segmentation Fault launched when compiling with optimization level>0 -O1, -O2, ...

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-02 12:57 ---
Please try with a still maintained GCC version, which would be at least 4.2.3.

Thanks.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/35419] [4.3/4.4 Regression] bfin libgcc build error

[bernds_cb1 at t-online dot de]

--- Comment #1 from bernds_cb1 at t-online dot de  2008-04-02 13:17 ---
We don't support a bfin-linux-gnu target.  Does any of bfin-elf, bfin-uclinux
or bfin-linux-uclibc work for you?


-- 


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

[Bug c++/35799] New: GCC uses inheritance information it doesn't yet know

[peter at empeg dot com]

In the following code (condensed from a real example where Fnord was
boost::intrusive_ptr), the call to the Fnord constructor in function make_fnord
only succeeds because Aubergine is derived from Base. But GCC doesn't "know"
that Aubergine is derived from Base until after it's seen make_fnord. (And
make_fnord itself isn't templated in any way, so this isn't a
delayed-instantiation thing, although similar examples where Fnord isn't
templated do successfully produce an error.) GCC 2.95.3 gave an error on this
code, but GCC 4.1.2, 4.2.3, and 4.3.0 accept it (even with
-fno-unit-at-a-time). Shouldn't it be an error?

template 
class Fnord
{
public:
explicit Fnord(T* p) { intrusive_ptr_add_ref(p); }
};

class Base
{
};

void intrusive_ptr_add_ref(Base*);

class Aubergine;

Fnord make_fnord(Aubergine *p)
{
return Fnord(p);
}

class Aubergine: public Base
{
};

GCC 2.95.3's error:
wtf.cpp: In method `Fnord::Fnord(Aubergine *)':
wtf.cpp:18:   instantiated from here
wtf.cpp:5: type `Base' is not a base type for type `Aubergine'

gcc -v on the 4.3.0 which fails to give an error:
Using built-in specs.
Target: x86_64-linux
Configured with: ../gcc-4.3.0/configure --prefix=/usr --enable-shared
--enable-languages=c,c++ --enable-threads --enable-__cxa_atexit
--with-system-zlib --disable-multilib x86_64-linux
Thread model: posix
gcc version 4.3.0 (GCC)


-- 
   Summary: GCC uses inheritance information it doesn't yet know
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter at empeg dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug c++/33878] Pure virtual method body omitted from template

[bangerth at math dot tamu dot edu]

--- Comment #12 from bangerth at math dot tamu dot edu  2008-04-02 13:31 
---
Subject: Re:  Pure virtual method body omitted from template


> No, it is not. And that's because this pure virtual method never gets called
> explicitly.

The point I meant to make but failed is: a pure virtual method can *only* 
*ever* be called explicitly. It can't be called through the vtable because 
there can be no objects of the type of this pure class, only of derived 
classes, and in the vtables of this derived class the slot for this 
virtual function is filled by another function (because the derived class, 
to be instantiated, must have overwritten the pure function).

So, yes, I'm not surprised that the object file you produce from your 
testcase doesn't contain pvMethod. But that's not a problem because in it 
nobody ever calls this function. What I want to see is a testcase in which 
this function *should* be there because it is, somehow, called or 
otherwise required.

Does this make sense?

W.

-
Wolfgang Bangerthemail:[EMAIL PROTECTED]
 www: http://www.math.tamu.edu/~bangerth/


-- 


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

[Bug middle-end/35800] New: [4.4 Regression]: Revision 133835 failed to compile binutils

[hjl dot tools at gmail dot com]

Stage 1 compiler from revision 133835 failed to compile binutils:

[EMAIL PROTECTED] binutils]$ 
/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/xgcc
-B/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/
-B/usr/gcc-4.4/x86_64-unknown-linux-gnu/bin/ -DHAVE_CONFIG_H -I.
-I/export/gnu/src/tools/tools/binutils -I. -I.
-I/export/gnu/src/tools/tools/binutils -I../bfd
-I/export/gnu/src/tools/tools/binutils/../bfd
-I/export/gnu/src/tools/tools/binutils/../include
-DLOCALEDIR="\"/usr/gcc-4.4/share/locale\""
-Dbin_dummy_emulation=bin_vanilla_emulation   -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror -g -O2 -c
/export/gnu/src/tools/tools/binutils/stabs.c
/export/gnu/src/tools/tools/binutils/stabs.c: In function ‘stab_find_type’:
/export/gnu/src/tools/tools/binutils/stabs.c:3318: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program received signal SIGSEGV, Segmentation fault.
0x005c3b09 in mark_jump_label_1 (x=0x0, insn=0x0, in_mem=0 '\0', 
is_target=1 '\001') at /export/gnu/src/tools/tools/gcc/jump.c:989
989   RTX_CODE code = GET_CODE (x);
Missing separate debuginfos, use: debuginfo-install glibc.x86_64
(gdb) bt
#0  0x005c3b09 in mark_jump_label_1 (x=0x0, insn=0x0, in_mem=0 '\0', 
is_target=1 '\001') at /export/gnu/src/tools/tools/gcc/jump.c:989
#1  0x005c3db0 in mark_jump_label_1 (x=0x2b86d6b0, 
insn=0x2b8a1cd0, in_mem=0 '\0', is_target=1 '\001')
at /export/gnu/src/tools/tools/gcc/jump.c:1087
#2  0x005c3aea in mark_jump_label (x=0x2b86d6b0, 
insn=0x2b8a1cd0, in_mem=0)
at /export/gnu/src/tools/tools/gcc/jump.c:976
#3  0x005c27a3 in mark_all_labels (f=0x2b4330c0)
at /export/gnu/src/tools/tools/gcc/jump.c:196
#4  0x005c2587 in rebuild_jump_labels (f=0x2b4330c0)
at /export/gnu/src/tools/tools/gcc/jump.c:86
#5  0x00a65513 in tree_expand_cfg ()
at /export/gnu/src/tools/tools/gcc/cfgexpand.c:1923
#6  0x006060f1 in execute_one_pass (pass=0x102a260)
at /export/gnu/src/tools/tools/gcc/passes.c:1127
#7  0x00606249 in execute_pass_list (pass=0x102a260)
at /export/gnu/src/tools/tools/gcc/passes.c:1180
#8  0x006fcbd8 in tree_rest_of_compilation (fndecl=0x2af87820)
at /export/gnu/src/tools/tools/gcc/tree-optimize.c:420
#9  0x0085c758 in cgraph_expand_function (node=0x2b0d3d00)
at /export/gnu/src/tools/tools/gcc/cgraphunit.c:1157
#10 0x0085c908 in cgraph_expand_all_functions ()
---Type  to continue, or q  to quit--- q
 at /export/gnu/src/toolQuit

Revision 133718 is OK.


-- 
   Summary: [4.4 Regression]: Revision 133835 failed to compile
binutils
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-04-02 13:46 ---
Created an attachment (id=15410)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15410&action=view)
A testcase

[EMAIL PROTECTED] binutils]$ 
/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/xgcc
-B/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/ -O2 -S stabs.i 
/export/gnu/src/tools/tools/binutils/stabs.c: In function ‘stab_find_type’:
/export/gnu/src/tools/tools/binutils/stabs.c:3318: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] binutils]$ 


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[oblivian at users dot sourceforge dot net]

--- Comment #37 from oblivian at users dot sourceforge dot net  2008-04-02 
13:47 ---
(In reply to comment #35)
> the infinite loop is fixed, don't know if the second bug remains.
> 
Yes and no, It fixes the compilation so that ld no longer gets into a loop, but
the installed compiler is still not working due to the missing search paths.

This bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
explored the issue of using sysroot for native builds and it appears the
consensus is not to support retargeted compilers anymore for native builds, and
that the sysroot framework should be used even though some people are still
stating that it is for cross compiling only.

I'll be opening a new bug on the sysroot problems I'm having with 4.3 since it
appears no one has tried a combined gcc + binutils bootstrap with sysroot (or
at least I can't find a bug on it in gcc bugzilla).

Thanks for all the help.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-02 13:50 ---
This is likely caused by http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00059.html.

Reducing.


-- 

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 |2008-04-02 13:50:06
   date||


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

[Bug bootstrap/35801] New: [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on
powerpc-apple-darwin9:

...
libtool: compile:  /opt/gcc/darwin_buildw/./gcc/xgcc -shared-libgcc
-B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/powerpc-apple-darwin9
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include
-I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2 -c
../../../../gcc-4.4-work/libstdc++-v3/src/stdexcept.cc  -fno-common -DPIC -o
.libs/stdexcept.o
libtool: compile:  /opt/gcc/darwin_buildw/./gcc/xgcc -shared-libgcc
-B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/powerpc-apple-darwin9
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include
-I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2 -c
../../../../gcc-4.4-work/libstdc++-v3/src/stdexcept.cc -o stdexcept.o
>/dev/null 2>&1
/bin/sh ../libtool --tag CXX --mode=compile /opt/gcc/darwin_buildw/./gcc/xgcc
-shared-libgcc -B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include 
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/powerpc-apple-darwin9
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include
-I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++  -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once 
-ffunction-sections -fdata-sections  -g -O2   
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/backward
-Wno-deprecated -c ../../../../gcc-4.4-work/libstdc++-v3/src/strstream.cc
libtool: compile:  /opt/gcc/darwin_buildw/./gcc/xgcc -shared-libgcc
-B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/powerpc-apple-darwin9
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include
-I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/backward
-Wno-deprecated -c ../../../../gcc-4.4-work/libstdc++-v3/src/strstream.cc 
-fno-common -DPIC -o .libs/strstream.o
../../../../gcc-4.4-work/libstdc++-v3/src/strstream.cc: In destructor 'virtual
std::ostrstream::~ostrstream()':
../../../../gcc-4.4-work/libstdc++-v3/src/strstream.cc:374: internal compiler
error: in prepare_function_start, at function.c:3940
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [strstream.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libstdc++-v3] Error 2
make: *** [all] Error 2

Still fails at revision 133833.


-- 
   Summary: [4.4 Regression]: At revision 133817, bootstrap fails at
libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin9
  GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9


http://gcc.

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #38 from bonzini at gnu dot org  2008-04-02 13:59 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> I'll be opening a new bug on the sysroot problems I'm having with 4.3 since it
> appears no one has tried a combined gcc + binutils bootstrap with sysroot (or
> at least I can't find a bug on it in gcc bugzilla).

Ok, CC me on that bug.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-04-02 14:00 ---
(In reply to comment #2)
> This is likely caused by http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00059.html.
> 
> Reducing.
> 

http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00059.html

is revision 133835. Revision 133834 passed the failed point.


-- 


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

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[bonzini at gnu dot org]

--- Comment #11 from bonzini at gnu dot org  2008-04-02 14:08 ---
Carlos, I think Greg has a point here:

> the problem is that xgcc thinks it is a relocated compiler when it 
> runs from $objdir eg: when building libgcc* and other target libs, when in
> actual fact, it is not really a true relocated compiler at all.

Looking at http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html it seems to me that
setenv GCC_EXEC_PREFIX "$GCC_EXEC_PREFIX" is always needed when we run in the
build directory.  This is easier said than done -- for example adding a
--exec-prefix option to the driver is not possible because gcc_exec_prefix is
set much earlier than at option-processing time.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug c/35802] New: MIPS64: Unable to find a register to spill in class ‘V1_REG’

[aurelien at aurel32 dot net]

I am getting a very strange ICE on a mips system when building with -mabi=n32
or -mabi=64:

testcase.i: In function ‘_IO_vfscanf_internal’:
testcase.i:2857: error: unable to find a register to spill in class
‘V1_REG’
testcase.i:2857: error: this is the insn:
(insn 1286 1241 1243 106 testcase.i:577 (set (reg:SI 19 $19 [3464])
(unspec:SI [
(const_int 0 [0x0])
] 28)) 460 {tls_get_tp_si} (expr_list:REG_EQUIV (unspec:SI [
(const_int 0 [0x0])
] 28)
(nil)))
testcase.i:2857: confused by earlier errors, bailing out

This is when trying to build glibc 2.7, file vfscanf.c. The strange part appear
when trying to reduce the testcase. I noticed that removing struct declarations
that are not use elsewhere in the file make the problem disappear. That's why
the reduced testcase is still big.

I'll attach two testcase, one unreduced, and one reduced.

With the unreduced testcase, it is possible to trigger the bug with -mabi=n32
or -mabi=64 with -O2 or -O3.

On reduce testcase, the bug is triggered exclusively with -mabi=n32 and -O2.

This is the command I used to build the file:
/usr/bin/gcc-4.3 -c -O2 -fgnu89-inline -std=gnu99 -mabi=n32 testcase-min.i


-- 
   Summary: MIPS64: Unable to find a register to spill in class
‘V1_REG’
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aurelien at aurel32 dot net
 GCC build triplet: mips64el-unknown-linux-gnu
  GCC host triplet: mips64el-unknown-linux-gnu
GCC target triplet: mips64el-unknown-linux-gnu


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

[Bug c/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[aurelien at aurel32 dot net]

--- Comment #1 from aurelien at aurel32 dot net  2008-04-02 14:13 ---
Created an attachment (id=15411)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15411&action=view)
unreduced testcase


-- 


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

[Bug c/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[aurelien at aurel32 dot net]

--- Comment #2 from aurelien at aurel32 dot net  2008-04-02 14:13 ---
Created an attachment (id=15412)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15412&action=view)
reduced testcase


-- 


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

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[ghazi at gcc dot gnu dot org]

--- Comment #17 from ghazi at gcc dot gnu dot org  2008-04-02 14:18 ---
I see the same issue on x86_64 debian linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00085.html

Removing hppa tags since it's debian-specific, not hppa.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi 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=31413

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[oblivian at users dot sourceforge dot net]

--- Comment #39 from oblivian at users dot sourceforge dot net  2008-04-02 
14:19 ---
Created an attachment (id=15413)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15413&action=view)
Optional way to fix ld relink problems

Just for completeness, here is the fix the Ralf was suggesting.  I tried this
out and it seems to work as well.


-- 


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[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
  Component|bootstrap   |target
   Target Milestone|--- |4.4.0


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-02 14:25 ---
This is thunk related, most likely forgot a free function.


-- 


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

[Bug tree-optimization/35795] [4.4 Regression] Revision 133787 breaks ia64

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2008-04-02 14:31 ---
I think PR35801 is the same problem on powerpc-apple-darwin9.


-- 


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-04-02 14:34 ---
I think it is another manifestation of PR35795.


-- 


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

[Bug c/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[aurelien at aurel32 dot net]

--- Comment #3 from aurelien at aurel32 dot net  2008-04-02 14:15 ---
Also please note that the same problem exists on mips
(mips64-unknown-linux-gnu).


-- 

aurelien at aurel32 dot net changed:

   What|Removed |Added

  Known to fail||4.3.0
  Known to work||4.2.3


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

[Bug libstdc++/20451] Missing po files in multilib systems

[ghazi at gcc dot gnu dot org]

--- Comment #4 from ghazi at gcc dot gnu dot org  2008-04-02 14:59 ---
Problem still occurs on 4.1 branch:
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00083.html

I'll try backporting the patch from 4.2.x and see if it still works.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #29 from joel at gcc dot gnu dot org  2008-04-02 15:08 ---
I have spent the morning debugging at the assembly level and I am nearly 100%
positive %ebx is getting corrupted.  It is correct before the call to   

STPO.Initialize_TCB (T, Success);

at s-taskin.adb and 0x0 upon return. There are ~2000 lines in the qemu.log 
between the two points so I have some reduction. 

I grep'ed the RTEMS source for references to ebx and I didn't see any which
were not in ISR or context switch code.  I did a run with no IO or interrupts
and got the same result.  At this point, I am looking for some subroutine that
isn't preserving ebx properly.


(In reply to comment #28)
> I did not notice that s-taprop for rtems was the posix version
> 
>procedure Initialize_TCB (Self_ID : Task_Id; Succeeded : out Boolean) is
>   Mutex_Attr : aliased pthread_mutexattr_t;
>   Result : Interfaces.C.int;
>   Cond_Attr  : aliased pthread_condattr_t;
> 
>begin
> ...
> 
>  if Result /= 0 then
> Succeeded := False;
> return;
>  end if;
> ...
>   if Result = 0 then
>  Succeeded := True;
>   else
>  if not Single_Lock then
> Result := pthread_mutex_destroy (Self_ID.Common.LL.L'Access);
> pragma Assert (Result = 0);
>  end if;
> 
>  Succeeded := False;
>   end if;
> ...
> 
> So it's now just a matter of finding which posix call in there fails.
> 


-- 


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

[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2008-04-02 15:21 
---
(In reply to comment #3)
> committed to trunk, will backport to 4.3 in due time (causes regressions for
> AVR)
> 

Could you list what fails?
Thanks!


-- 


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

[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2008-04-02 15:25 ---
I meant that this is a patch that is scheduled for backporting to 4.3, because
it fixes regressions on AVR.

The text between parentheses should have been "bug causes regressions for AVR".
 Sorry.


-- 


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

[Bug middle-end/35803] New: still can't get rid of phony compare patterns - cbranch* / cstore* patterns miss their goal

[amylaar at gcc dot gnu dot org]

Gcc has traditionally used the concept of a compare operation that stores
a comparison result in CC0 or a register, and then can be used with arbitrary
comparison operators to compare it against zero to make a decision for
a branch, store flag, or conditional move instruction.
Since often the actual comparison instructions work differently, a number of
ports need to stash away the comparison operands when they pretend to emit
a comparison, and then emit the actual comparison later when its result is
used.
cbranch* / cstore* patterns had the promise to get rid of this bogosity,
however, they are still don;t deliver.
The only way to have a conditional move is to first perform a comparison, and
then have the the actual move depende on the comparison result.  Thus, if
the architecture has conditional move, a comparison patterns are needed, even
if the targets compare operations are ill-matched, compare patterns have to be
defined, thus disabling cbranch* / cstore* patterns.


-- 
   Summary: still can't get rid of phony compare patterns - cbranch*
/ cstore* patterns miss their goal
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org


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

[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand

[hutchinsonandy at aim dot com]

--- Comment #6 from hutchinsonandy at aim dot com  2008-04-02 15:44 ---
Subject: Re:  [4.3 Regression] fwprop only propagates
 one operand

Eric,

it's difficult to give you a specfic example as the propagation is very 
sensitive to generated code. I found this looking at other AVR bugs and 
discovered it was not working. (I'll  look up that example latter for 
you).

It not an obvious thing as other (good) changes due to DF merge, 
re-arrange code enough to obscure the omission. But the result is an 
extra move or redundant instruction here and there.

(its also not at all specfic to AVR)

Andy





-Original Message-
From: eric dot weddington at atmel dot com <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Wed, 2 Apr 2008 10:21 am
Subject: [Bug rtl-optimization/35542] [4.3 Regression] fwprop only 
propagates one operand




--- Comment #4 from eric dot weddington at atmel dot com  
2008-04-02 15:21
---
(In reply to comment #3)
> committed to trunk, will backport to 4.3 in due time (causes 
regressions for
> AVR)
>

Could you list what fails?
Thanks!


--


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

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-02 15:49 ---
Created an attachment (id=15414)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15414&action=view)
reduced testcase

Reduced testcase, fails with -O -ftree-vrp -fno-inline.

Program received signal SIGSEGV, Segmentation fault.
0x0075e3e4 in mark_jump_label_1 (x=0x0, insn=0x0, in_mem=0 '\0', 
is_target=1 '\001') at /space/rguenther/src/svn/trunk/gcc/jump.c:989
989   RTX_CODE code = GET_CODE (x);

#0  0x0075e3e4 in mark_jump_label_1 (x=0x0, insn=0x0, in_mem=0 '\0', 
is_target=1 '\001') at /space/rguenther/src/svn/trunk/gcc/jump.c:989
#1  0x0075e7f7 in mark_jump_label_1 (x=0x2b658e3e1f10, 
insn=0x2b658eccd960, in_mem=0 '\0', is_target=1 '\001')
at /space/rguenther/src/svn/trunk/gcc/jump.c:1087
#2  0x0075e3c5 in mark_jump_label (x=0x2b658e3e1f10, 
insn=0x2b658eccd960, in_mem=0)
at /space/rguenther/src/svn/trunk/gcc/jump.c:976
#3  0x0075cf52 in mark_all_labels (f=0x2b658ecd6600)
at /space/rguenther/src/svn/trunk/gcc/jump.c:196
#4  0x0075ccf3 in rebuild_jump_labels (f=0x2b658ecd6600)
at /space/rguenther/src/svn/trunk/gcc/jump.c:86
#5  0x00de7232 in tree_expand_cfg ()

(I have to run now.)


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-04-02 15:53 ---
So we have

(addr_vec:DI [
(nil)
(label_ref:DI 26)
(label_ref:DI 26)
(label_ref:DI 26)
(label_ref:DI 26)
...


-- 


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

[Bug c++/33878] Pure virtual method body omitted from template

[herwig at gdsys dot de]

--- Comment #13 from herwig at gdsys dot de  2008-04-02 16:07 ---
(In reply to comment #12)
> The point I meant to make but failed is: a pure virtual method can *only* 
> *ever* be called explicitly. It can't be called through the vtable because 
> there can be no objects of the type of this pure class, only of derived 
> classes, and in the vtables of this derived class the slot for this 
> virtual function is filled by another function (because the derived class, 
> to be instantiated, must have overwritten the pure function).

You are absolutely right as long as there is no multithreading and no dangling
pointer. Sure. The thing is: If it's called, something bad has occured and I
want to catch it let's say for a backtrace at this point. Or I take it
deliberately into account and let it perform a no-op.

When searching for an example, I came across this link:

http://www.artima.com/forums/flat.jsp?forum=226&thread=196881#270009

This post is the exact description of the problem I initially ran into. Even to
proposed solution is part of what I've done to prevent the call.

> So, yes, I'm not surprised that the object file you produce from your 
> testcase doesn't contain pvMethod. But that's not a problem because in it 
> nobody ever calls this function. What I want to see is a testcase in which 
> this function *should* be there because it is, somehow, called or 
> otherwise required.

Okay, here it is, the faulty code: ;)

#include 
#include 

using namespace std;

template
class TBase
{
public:
~TBase();
virtual void pvMethod() = 0;
};

template
TBase::~TBase()
{
sleep(2);
}

template
void TBase::pvMethod()
{
cerr << "Error" << endl;
}

class TDerived :
public TBase
{
public:
void pvMethod();
};

void TDerived::pvMethod()
{
cout << "OK" << endl;
}

int startThread(pthread_t* handle, void* (*entry)(void*), void* arg)
{
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, true);

int res = pthread_create(handle, &attr, entry, arg);

pthread_attr_destroy(&attr);

return res;
}

void* thread(void* arg)
{
TDerived** typed_arg = (TDerived**)arg;
TDerived* obj = *typed_arg;
sleep(1);
delete obj;
*typed_arg = 0;
return 0;
}

int main(int argc, char** argv)
{
TDerived* obj = new TDerived;
pthread_t thread_handle;
startThread(&thread_handle, &thread, &obj);

for (int i = 0; i < 5; ++i) {
if (!obj) {
break;
}
obj->pvMethod();
sleep(1);
}

return 0;
}

[EMAIL PROTECTED]:~/Programming$ g++ -O0 -Wall -lpthread test.cpp -o test && 
./test
OK
OK
pure virtual method called
terminate called without an active exception
Abgebrochen

> Does this make sense?

The standard says "A pure virtual function need be defined only if explicitly
called with the qualified-id syntax (5.1)." in 10.4.2, so it's perfectly legal
to omit the pvMethod(). But there is a discrepancy between templates and normal
classes:

* For normal classes the method is generated, even if not used. GCC developers
decided to do more than the standard requires, and they must have reasons to do
so. Here you have a choice.

* For templates the method is not generated, and we've discussed why. It's due
to the template function emission rules: Not called, not emitted. But there is
also the shortcut rule when deriving: Cannot be called, not emitted. That is
what you explained. Thus here you have no choice.

Honestly, wouldn't you also like to have the choice?

Best,
Björn!

--
Dipl.-Ing. Björn A. Herwig
Guntermann & Drunck GmbH Systementwicklung 
Dortmunder Str. 4a 
D-57234 Wilnsdorf - Germany 
Tel: +49 (0) 27 39 / 89 01 - 100  Fax: +49 (0) 27 39 / 89 01 - 120 
E-Mail: mailto:[EMAIL PROTECTED] Web: www.gdsys.de
--
Geschäftsführer:
Udo Guntermann - Martin Drunck - Reiner Ruelmann - Klaus Tocke
HRB 2884, Amtsgericht Siegen
USt.-Id.-Nr. DE 126575222 - Steuer-Nr. 342 / 5835 / 1041


-- 


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

[Bug bootstrap/35804] New: Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

Hello,

This bug is a continuation from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532. It appears that native
retargeting of the compiler is not supported in the 4.3/4.4 series in favor of
the sysroot option.  When trying to build a pass 1 compiler with combined gcc
and binutils in a single directory, sysroot seems to be appending an extra
sysroot prefix in the linker during libgcc linking.

The current build setup I'm trying is to install in order to the sysroot
directory of /tools:

Linux headers
glibc-pass-1 full compile with native toolchain so that crt files exist.
bootstrap gcc+binutils toolchain against new glibc.

I have tried configuring the gcc+binutils toolchain with the following three
sets of options and it still has the same problem:

configue --prefix=/tools/usr \
 --with-sysroot=/tools \
 --with-pic \
 --disable-nls \
 --disable-libmudflap \
 --disable-libssp \
 --enable-languages=c \
 --enable-checking=release \
 --disable-werror \
 --enable-bootstrap

configue --prefix=/tools/usr \
 --with-sysroot=/tools \
 --with-build-sysroot=/tools \
 --with-pic \
 --disable-nls \
 --disable-libmudflap \
 --disable-libssp \
 --enable-languages=c \
 --enable-checking=release \
 --disable-werror \
 --enable-bootstrap

configue --prefix=/usr \
 --with-sysroot=/tools \
 --with-build-sysroot=/tools \
 --with-pic \
 --disable-nls \
 --disable-libmudflap \
 --disable-libssp \
 --enable-languages=c \
 --enable-checking=release \
 --disable-werror \
 --enable-bootstrap

And building with:
LDFLAGS_FOR_TARGET="--sysroot=/tools" CPPFLAGS_FOR_TARGET="--sysroot=/tools"
make

Everything compiles up to stage 1 libgcc which errors out on the final link
command with the linker error of:
/media/disk-3/build/tools/toolchain-pass-1/build/gcc/../ld/ld-new: cannot find
/tools/lib/libc.so.6 inside /tools

Unfortunately, /tools/lib/libc.so.6 exists and if I create a link to /tools
inside of the tools directory (recursive symlink) the link will complete and
continue to stage 2

I'm pretty sure I shouldn't have to create a link to . for this to work
properly .


-- 
   Summary: Bootstrap of combined gcc + binutils, with --enable-
shared, with sysroot fails
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oblivian at users dot sourceforge dot net
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-04-02 16:20 ---
Heh, I was testing with -m32 and -m64 on 4.3 branch (but that was
--enable-checking=release default) and on the trunk just -m64.  Can reproduce
now.

This seems to be NRV that is creating non-GIMPLE by replacing GIMPLE regs with
 which needs to live in memory.

The following patch cures this, though I'm not sure if it can actually
pessimize code:

--- tree-nrv.c.jj   2008-03-19 14:18:00.0 +0100
+++ tree-nrv.c  2008-04-02 18:11:14.0 +0200
@@ -1,5 +1,5 @@
 /* Language independent return value optimizations
-   Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.

 This file is part of GCC.

@@ -115,6 +115,11 @@ tree_nrv (void)
   if (!aggregate_value_p (result, current_function_decl))
 return 0;

+  /* If a GIMPLE type is returned in memory, finalize_nrv_r might create
+ non-GIMPLE.  */
+  if (is_gimple_reg_type (result_type))
+return 0;
+
   /* Look through each block for assignments to the RESULT_DECL.  */
   FOR_EACH_BB (bb)
 {

The idea is that if found var isn't really an aggregate, but gimple reg, then
1) nvr might create non-GIMPLE as say x = x + 32; can be valid, while 
=  + 32; where  is aggregate_value_p and thus
needs_to_live_in_memory is true for it is invalid GIMPLE (without -fmudflap
just no pass verified that) 2) the replacement might tie hands of the RTL
passes - without the nrv replacement it works with pseudos, but with the nrv
replacement
it suddenly needs to be MEM in all the operations on it.


-- 


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

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-02 16:23 ---
Sounds like you should be using --build-sysroot= and not set LDFLAGS_FOR_TARGET
and CPPFLAGS_FOR_TARGET .


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

--- Comment #2 from oblivian at users dot sourceforge dot net  2008-04-02 
16:26 ---
(In reply to comment #1)
> Sounds like you should be using --build-sysroot= and not set 
> LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .
> 
You mean configure with just --with-build-sysroot and not --with-sysroot and
remove LD/CPP FLAGS_FOR_TARGET from make?


-- 


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

[Bug tree-optimization/35795] [4.4 Regression] Revision 133787 breaks ia64

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-04-02 16:42 ---
(In reply to comment #3)
> Subject: Re:   New: [4.4 Regression] Revision 133787 breaks ia64
> 
> Hi,
> I've added the assert to check that we don't initialize RTL world twice
> without freeing it first (and thus that we don't leak memory).  This
> seems to be the case.  Naively, something like this should fix it.
> I am building a cross and will try to reproduce it.
> 
> Index: config/ia64/ia64.c
> ===
> *** config/ia64/ia64.c  (revision 133785)
> --- config/ia64/ia64.c  (working copy)
> *** ia64_output_mi_thunk (FILE *file, tree t
> *** 9694,9699 
> --- 9694,9700 
> final_start_function (insn, file, 1);
> final (insn, file, 1);
> final_end_function ();
> +   free_after_compilation (cfun);
> 
> reload_completed = 0;
> epilogue_completed = 0;
> 

This patch works.


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[laurent at guerby dot net]

--- Comment #30 from laurent at guerby dot net  2008-04-02 16:44 ---
Did you look at what happens in Initialize_TCB to the variable Success ?


-- 


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

[Bug tree-optimization/35805] New: [ira] error in start_allocno_priorities, at ira-color.c:1806

[mstein dot lists at googlemail dot com]

Hi,
gcc  930523-1.c -c -fira -O1 -m32
fails with
930523-1.c: In function 'f':
930523-1.c:54: internal compiler error: in start_allocno_priorities, at
ira-color.c:1806
Please submit a full bug report,

rev: 133765


-- 
   Summary: [ira] error in start_allocno_priorities, at ira-
color.c:1806
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein dot lists at googlemail dot com
GCC target triplet: i386


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

[Bug target/35664] unable to find a register to spill in class 'FP_REGS' (sparc-linux)

[mstein dot lists at googlemail dot com]

--- Comment #2 from mstein dot lists at googlemail dot com  2008-04-02 
16:55 ---
Fails in trunk (133803) too


-- 

mstein dot lists at googlemail dot com changed:

   What|Removed |Added

 CC||davem at redhat dot com,
   ||jakub at redhat dot com


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

[Bug target/35735] error in default_secondary_reload, at targhooks.c:649

[mstein dot lists at googlemail dot com]

--- Comment #2 from mstein dot lists at googlemail dot com  2008-04-02 
17:02 ---
Seems to work again in rev 133774


-- 

mstein dot lists at googlemail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug c++/33878] Pure virtual method body omitted from template

[yuriry at gmail dot com]

--- Comment #14 from yuriry at gmail dot com  2008-04-02 17:15 ---
Hi Björn

My question is slightly off topic but I am really interested in the purpose of
defining a template class where a template parameter is not used.  Why would
you need this?

Regards,
Yuri

template
class TBase
{
public:
~TBase();
virtual void pvMethod() = 0;
};


-- 


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

[Bug c++/35741] [4.2/4.3/4.4 regression] ICE with offsetof and references

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-04-02 17:17 ---
IMNSHO this is invalid.
[lib.support.types]/5 says the first argument must be a POD structure or POD
union, but struct A isn't POD structure because of the reference in it.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code


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

[Bug bootstrap/35216] Out of memory building java

[pogma at gcc dot gnu dot org]

--- Comment #2 from pogma at gcc dot gnu dot org  2008-04-02 17:37 ---
Subject: Bug 35216

Author: pogma
Date: Wed Apr  2 17:36:41 2008
New Revision: 133842

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133842
Log:
PR bootstrap/35216
* scripts/makemake.tcl: Replace org/omg build with build of all its
subpackages.
* sources.am: Regenerate.
* Makefile.in: Regenerate.


Modified:
trunk/libjava/ChangeLog
trunk/libjava/Makefile.in
trunk/libjava/scripts/makemake.tcl
trunk/libjava/sources.am


-- 


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

[Bug c++/33878] Pure virtual method body omitted from template

[fang at csl dot cornell dot edu]

--- Comment #15 from fang at csl dot cornell dot edu  2008-04-02 17:38 
---
Unused template parameters can be used when you want to intentionally subtype a
base type with different flavors that are incompatible with each other, using
compile-time checking to prevent accidental cross-contamination, for instance.  


-- 


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

[Bug bootstrap/35216] Out of memory building java

[pogma at gcc dot gnu dot org]

--- Comment #3 from pogma at gcc dot gnu dot org  2008-04-02 17:44 ---
Fixed in r133842


-- 

pogma at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/35806] New: Object code is bigger at -Os than at -O2

[mstein dot lists at googlemail dot com]

Hi,
the code below compiles to 60 byte when using -Os
and 4 byte when using -O2.

This is just one example of many from the test suite: 

extern void f(char *const *);
void g (char **o)
{
  static const char *const multilib_exclusions_raw[] = { 0 };
  const char *const *q = multilib_exclusions_raw;

  f (o);
  while (*q++)
f (o);
}


-- 
   Summary: Object code is bigger at -Os than at -O2
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein dot lists at googlemail dot com
GCC target triplet: arm-elf


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

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2008-04-02 17:52 ---
Subject: Re:  Bootstrap of combined gcc + binutils, with
 --enable-shared, with sysroot fails

On Wed, 2 Apr 2008, pinskia at gcc dot gnu dot org wrote:

> Sounds like you should be using --build-sysroot= and not set 
> LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .

My experience is that you do need to set LDFLAGS_FOR_TARGET and 
CPPFLAGS_FOR_TARGET to include the --sysroot option if you're configuring 
with a build sysroot.  (This is a bug: --with-build-sysroot should cause 
the right --sysroot option to be used automatically when compiling and 
linking runtime libraries.)


-- 


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

[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |target
   Target Milestone|--- |4.4.0


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

[Bug c++/33878] Pure virtual method body omitted from template

[yuriry at gmail dot com]

--- Comment #16 from yuriry at gmail dot com  2008-04-02 17:58 ---
Thanks for the reply, David!  But now I have more questions than I had before
:-)

I'm not sure if this thread is the right place to go into details on this
topic.  If you know any other place to move this discussion, please let me
know.

What do you mean by "different flavors that are incompatible with each other"?
Could you tell a little more about "accidental cross-contamination"?

Giving a short example for each question would help a lot :-)

Thanks in advance,
Yuri


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2008-04-02 18:06 ---
Created an attachment (id=15415)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15415&action=view)
another reduced testcase, -O2

I see attachment #2 there, but as long as I did a reduction too, here's
another, a wee bit smaller and no extra warnings at -W -Wall -Wextra. This
fails at -O2 both for native x86_64 as well as cris-elf, just like the original
stabs.i testcase.  FWIW, the same bug causes failure to build
newlib/libc/stdlib/dtoa.c for cris-elf, but that .i doesn't trig the bug for
x86_64.


-- 


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

[Bug c++/33878] Pure virtual method body omitted from template

[bangerth at math dot tamu dot edu]

--- Comment #17 from bangerth at math dot tamu dot edu  2008-04-02 18:31 
---
Subject: Re:  Pure virtual method body omitted from template


On Wednesday 02 April 2008 12:15:53 yuriry at gmail dot com wrote:
> My question is slightly off topic but I am really interested in the purpose
> of defining a template class where a template parameter is not used.  Why
> would you need this?

The class in this example is a stripped-down version for the purpose of 
exposition. In practice, of course, most of the time one would use the 
template argument somehow.

W.

-
Wolfgang Bangerthemail:[EMAIL PROTECTED]
 www: http://www.math.tamu.edu/~bangerth/


-- 


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-04-02 18:32 ---
Borrowed from pr35795, the following patch seems to work:

--- ../_gcc_clean/gcc/config/rs6000/rs6000.c2008-03-29 23:59:15.0
+0100
+++ ../gcc-4.4-work/gcc/config/rs6000/rs6000.c  2008-04-02 20:03:18.0
+0200
@@ -17124,6 +17124,7 @@
   final_start_function (insn, file, 1);
   final (insn, file, 1);
   final_end_function ();
+  free_after_compilation (cfun);

   reload_completed = 0;
   epilogue_completed = 0;

(now building libgfortran).


-- 


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

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[vmakarov at redhat dot com]

--- Comment #1 from vmakarov at redhat dot com  2008-04-02 18:34 ---
I've just fixed it on ira branch.  The problem was in an assert requiring
nonzero number of references for an allocno.  I permitted to have zero number
of references.

I've just realized that such situations are possible in a region but something
is wrong with this particular case.  The pseudo-register 69 lives at the
start/end of each basic block there is no such pseduo-register in RTL.  It is
removed in ce2.  Either the live info was not updated or something wrong with
the updating itself.

Therefore I am not closing IRA and I am adding Ken to the list.  I think the
problem can be reproduced on the mainline because I've merged the trunk into
the branch recently.


-- 

vmakarov at redhat dot com changed:

   What|Removed |Added

 CC||Kenneth dot Zadeck at
   ||NaturalBridge dot com


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

[Bug c++/33878] Pure virtual method body omitted from template

[bangerth at math dot tamu dot edu]

--- Comment #18 from bangerth at math dot tamu dot edu  2008-04-02 18:34 
---
Subject: Re:  Pure virtual method body omitted from template


> You are absolutely right as long as there is no multithreading and no
> dangling pointer. Sure. The thing is: If it's called, something bad has
> occured

I see your point, but in a case like this you are working outside what the 
standard says (it would call the program erroneous and its 
actions 'undefined'). The compiler's job being to translate what the standard 
describes, you can't rely on any such behavior.


> * For templates the method is not generated, and we've discussed why. It's
> due to the template function emission rules: Not called, not emitted. But
> there is also the shortcut rule when deriving: Cannot be called, not
> emitted. That is what you explained. Thus here you have no choice.

You can instantiate explicitly if you want this.

By the way, there is also a rule somewhere in the standard that says that only 
those templates must be instantiated that are actually needed; in other 
words, the compiler cannot instantiate more functions just because someone 
may want it to be there -- the functions must actually be *needed* for the 
program to work correctly.

W.

-
Wolfgang Bangerthemail:[EMAIL PROTECTED]
 www: http://www.math.tamu.edu/~bangerth/


-- 


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

[Bug c++/35741] [4.2/4.3/4.4 regression] ICE with offsetof and references

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-30 20:54:22 |2008-04-02 19:03:11
   date||


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

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[carlos at codesourcery dot com]

--- Comment #12 from carlos at codesourcery dot com  2008-04-02 19:20 
---
Paolo,

What's the test-case?


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2008-04-02 19:56 ---
It's not just about creating a properly filled (or handling the NULLs in the)
addr_vec after generating the tablejump or casesi: for machines with casesi,
passing a NULL default_label (operand[4]; fifth operand) is...unexpected. 
While this could be pushed from the middle-end to the target domain by defining
the NULL default label as a valid case that the target casesi pattern must
handle (hard to do without casesi being a define_expand), I think it'd be
better to just pass any label as default_label any at the try_casesi call.

Here's a related minor optimization opportunity for casesi: if default_label is
set to the last case label, the max index / the range and the table size, can
be shrunk by one.


-- 


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

[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-04-02 20:01 ---
spu-elf also fails the same way.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|hppa2.0w-hp-hpux11.11   |
   GCC host triplet|hppa2.0w-hp-hpux11.11   |
 GCC target triplet|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11, spu-
   ||elf


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

[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-04-02 20:17 ---
Hm, yeah.  The trick of course is to not emit the jump to the default label. 
For
the tablejump case it may be easiest to just use any other label.  I'll see if
that works.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2008-04-02 20:23 ---
(In reply to comment #8)
> Hm, yeah.  The trick of course is to not emit the jump to the default label. 
> For
> the tablejump case it may be easiest to just use any other label.  I'll see if
> that works.
> 

Can we add a run-time testcase to make sure that the result is correct?


-- 


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

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[bonzini at gnu dot org]

--- Comment #13 from bonzini at gnu dot org  2008-04-02 20:27 ---
Subject: Re:  Native GCC no longer searches $prefix/lib for startfiles when run
from $objdir

>  What's the test-case?

I'm talking of Greg's setting.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-02 20:50 
---
Ah, the following

  /* Index jumptables from zero for suitable values of
 minval to avoid a subtraction.  */
  if (! optimize_size
  && compare_tree_int (minval, 0) > 0
  && compare_tree_int (minval, 3) < 0)
{
  minval = build_int_cst (index_type, 0);
  range = maxval;
}

relies on the created hole be filled by the default_label - but that is
NULL here.  So, the following looks like the right fix here:

Index: stmt.c
===
--- stmt.c  (revision 133848)
+++ stmt.c  (working copy)
@@ -2566,11 +2566,15 @@ expand_case (tree exp)
  = gen_rtx_LABEL_REF (Pmode, label_rtx (n->code_label));
}

- /* Fill in the gaps with the default.  */
- if (default_label)
-   for (i = 0; i < ncases; i++)
- if (labelvec[i] == 0)
-   labelvec[i] = gen_rtx_LABEL_REF (Pmode, default_label);
+ /* Fill in the gaps with the default.  We may have gaps at
+the beginning if we tried to avoid the minval subtraction,
+so substitute some label even if the default label was
+deemed unreachable.  */
+ if (!default_label)
+   default_label = label_rtx (case_list->code_label);
+ for (i = 0; i < ncases; i++)
+   if (labelvec[i] == 0)
+ labelvec[i] = gen_rtx_LABEL_REF (Pmode, default_label);

  /* Output the table.  */
  emit_label (table_label);


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-04-02 20:56 
---
For now I have a compile-time testcase - I'll try to transform it into a
runtime one.


-- 


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

[Bug target/35806] Object code is bigger at -Os than at -O2

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-02 21:18 ---
This is because we don't run PRE at -Os, as PRE usually increases code-size.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #12 from hp at gcc dot gnu dot org  2008-04-02 21:43 ---
In reply to comment #10)
> relies on the created hole be filled by the default_label - but that is
> NULL here.  So, the following looks like the right fix here:
> 
> Index: stmt.c

That's too late; it's not enough for casesi targets for the reason I outline in
comment #7.


-- 


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

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[carlos at codesourcery dot com]

--- Comment #14 from carlos at codesourcery dot com  2008-04-02 21:52 
---
Using the sysroot flags is the solution for Greg's scenario. In fact I would
say it makes his job easier.

I'm looking for a test case that doesn't mangle GCC's configure files, and is
broken with no easy alternative.

Do we have one?


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2008-04-02 22:07 
---
Created an attachment (id=15416)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15416&action=view)
patch

Patch in comment #10 passed bootstrap & regtest on x86_64-unknown-linux-gnu,
the
attached patch should also fix comment #7, testing is in progess.  If anyone
beats me on it the patch is ok for trunk.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2008-04-02 22:10 
---
The fallback_label parm of try_casesi needs ATTRIBUTE_UNUSED for ! HAVE_casesi
targets.


-- 


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

[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences

[janis at gcc dot gnu dot org]

--- Comment #17 from janis at gcc dot gnu dot org  2008-04-02 22:11 ---
I tried the patch referenced in comment #16 on powerpc64-linux.  It allows
tests pr11832.c and pr33009 to pass, but adding -frtl-abstract-sequences to all
tests causes several tests to timeout on compilation, and gcc.dg/pr32912-1.c
fails at execution for -m32.  I built the C tests from SPEC CPU2000 with "-O2
-frtl-abstract-sequences" using the patched compiler and ran them with the
short test input.  A couple took a very long time to compile (try, for example,
the file toke.c in test perlbmk) and four failed at execution time: vpr and
crafty for -m32, gcc and gap for -m64.


-- 


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

[Bug target/35807] New: Compiler makes use of [std Y+1, rX] instruction without initializing r28,r29

[ruud at betaresearch dot nl]

When developing an OS for the smallest Atmels (ATtiny861/461/21)
i observed a strange effect. Sometimes, depending on the optimization
choosen by gcc, the compiler generates code which cannot be correct
(in my  view). Most of the time the code is not functional too.

The problem is that use of the instructions "std Y+1,rX" and
"ldd rX,Y+1" is made, but that de corresponding registers are
never properly initialized. The result is that the value is
stored somewhere in RAM or is retrieved from that (random?)
place. That may or may not hurt, but it seems wrong anyhow.

Below you can see an piece of code generated by GCC (v4.2.3)
 78c:   99 83   std Y+1, r25; 0x01
 78e:   46 de   rcall   .-884   ; 0x41c 
 790:   99 81   ldd r25, Y+1; 0x01
(From the methode below)
The point is nowhere in that method the registers r28 and r29 are used
neither are they set in the called methods. (see below)

In practice this effect indeed results in non functional code
which can most of the time be easily circumvented by inlining
some methods or hooking some variables up to fixed registers.
GCC is then forced to alter the output somewhat and often
the error disappears.

BTW, it seems that the compiler actually meant to do something
like this:
 78c:   79 2e   mov r7, r25 ; 0x01
 78e:   46 de   rcall   .-884   ; 0x41c 
 790:   97 2d   mov r25, r7 ; 0x01
where r7 can be any free register, since if you substitute
that (in the raw hex file for example) the code turns fully
functional.

I have observed the effect also at GCC 4.2.1 and GCC 4.3.0,
although beit not with exactly the same code. The effect is
reproducible, but depends critically on the choose optimizations
and structure of the code. These are my compiler options

avr-gcc -c -save-temps -mmcu=attiny861 -mint8 -Wall -Wno-main \
  -Winline -Wundef -gdwarf-2 -Os -funsigned-char -fomit-frame-pointer \
  -fpack-struct -fshort-enums 

OK, it would take to much space to include enough details here
for you to be able to reproduce the problem. I made a zip which
can be downloaded from:
  http://www.femtoos.org/gcc_effect.zip
which should make this possible. (includes source code, and a
compiler script, you need avr-gcc 4.2.3 on your system, other
versions will no reproduce the error in this particular example)

regards,
Ruud

074e :
 74e:   08 2fmov r16, r24
 750:   c6 2emov r12, r22
 752:   7a 01movwr14, r20
 754:   0d dercall   .-998  ; 0x370 
 756:   fb ddrcall   .-1034 ; 0x34e 
 758:   5c 01movwr10, r24
 75a:   6c 2dmov r22, r12
 75c:   80 2fmov r24, r16
 75e:   09 ddrcall   .-1518 ; 0x172 
 760:   98 2fmov r25, r24
 762:   1c 14cp  r1, r12
 764:   24 f4brge.+8; 0x76e 
 766:   8c 15cp  r24, r12
 768:   08 f4brcc.+2; 0x76c 
 76a:   57 c0rjmp.+174  ; 0x81a 
 76c:   07 c0rjmp.+14   ; 0x77c 
 76e:   cc 20and r12, r12
 770:   29 f0breq.+10 ; 0x77c 
 772:   8c 2dmov r24, r12
 774:   81 95neg r24
 776:   98 17cp  r25, r24
 778:   08 f4brcc.+2; 0x77c 
 77a:   4f c0rjmp.+158  ; 0x81a 
 77c:   90 e0ldi r25, 0x00  ; 0
 77e:   10 2fmov r17, r16
 780:   1f 70andir17, 0x0F  ; 15
 782:   f0 e8ldi r31, 0x80  ; 128
 784:   df 2emov r13, r31
 786:   d1 2aor  r13, r17
 788:   6d 2dmov r22, r13
 78a:   89 2fmov r24, r25
 78c:   99 83std Y+1, r25   ; 0x01
 78e:   46 dercall   .-884  ; 0x41c 
 790:   99 81ldd r25, Y+1   ; 0x01
 792:   88 23and r24, r24
 794:   31 f0breq.+12   ; 0x7a2 
 796:   07 ffsbrsr16, 7
 798:   40 c0rjmp.+128  ; 0x81a 
 79a:   60 2fmov r22, r16
 79c:   89 2fmov r24, r25
 79e:   26 dercall   .-948  ; 0x3ec 
 7a0:   3c c0rjmp.+120  ; 0x81a 
 7a2:   9f 5fsubir25, 0xFF  ; 255
 7a4:   93 30cpi r25, 0x03  ; 3
 7a6:   09 f4brne.+2; 0x7aa 
 7a8:   77 c0rjmp.+238  ; 0x898 
 7aa:   ee cfrjmp.-36   ; 0x788 
 7ac:   f6 01movwr30, r12
 7ae:   81 81ldd r24, Z+1   ; 0x01
 7b0:   8f 7dandir24, 0xDF  ; 223
 7b2:   81 83std Z+1, r24   ; 0x01
 7b4:   e1 14cp  r14, r1
 7b6:   f1 04cpc r15, r1
 7b8:   49 f1breq.+82   ; 0x80c 
 7ba:   bd ddrcall   .-1158 ; 0x336 
 7bc:   c8 ddrcall   .-1136 ; 0x34e 
 7be:   8c 01movwr16, r24
 7c0:   f0 e0ldi r31, 0x00  ; 0
 7c2:   ef 16cp  r14, r31
 7c4:   ff efldi r31, 0xFF  ; 255
 7c6:   

[Bug target/35807] Compiler makes use of [std Y+1, rX] instruction without initializing r28,r29

[ruud at betaresearch dot nl]

--- Comment #1 from ruud at betaresearch dot nl  2008-04-02 22:28 ---
Other versions of gcc (like 4.2.1 or 4.3.0) display the
same behavior, but not on the same testcase. A separate
testcase can be made for each version if needed.

Since i cannot attach a zip file, and i don't know how otherwise to attach the
information needed to reproduce (you need all .i files and must link in order
to see the effect). please use link to download the example.


-- 

ruud at betaresearch dot nl changed:

   What|Removed |Added

  Known to fail||4.2.1 4.3.0


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

[Bug target/35807] Compiler makes use of [std Y+1, rX] instruction without initializing r28,r29

[ruud at betaresearch dot nl]

--- Comment #2 from ruud at betaresearch dot nl  2008-04-02 22:39 ---
>From  Andy H <[EMAIL PROTECTED]>
[avr-gcc-list] Incorrect code by gcc?

Not a bug

According to the sources you posted,

privQueuRequestBody

void privQueuRequestBody(uint8_t uiSlot, int8_t siFreeFilling, uint16_t
uiTicksToWait) __attribute__ ( ( naked ) );

The relevant part being "naked"

That means gcc will omit prolog - which is where stack and frame pointer are
setup.
R28/29 is the frame pointer. What you see in assembler is gcc saving the
register around a call. Depending on optimization, it may choose to do this
rather than use a register (as the register would need to be saved on the
stack).

If you use naked, you must replace all of prolog/epilog by hand. (its normal
use is for assembler only functions)


Andy


-- 

ruud at betaresearch dot nl changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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