[Bug fortran/39314] -ffpe-trap=invalid gives no FPE for acos(-5.0)

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-02-27 09:01 ---
On x86_64-unknown-linux-gnu I *do* get the ICE when I compile with -ffast-math
-mfpmath=387. Cf. http://gcc.gnu.org/ml/fortran/2008-11/msg00250.html.


-- 


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

[Bug fortran/39314] -ffpe-trap=invalid gives no FPE for acos(-5.0)

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2009-02-27 09:13 ---
Note that the problem also appears for log, while it does not for acosh and
atanh:

real :: x = -5.0

! FPE is not thrown
print *, log(x)
print *, log10(x)
print *, acos(x)
print *, asin(x)

! FPE is thrown
!print *, sqrt(x)
!print *, atanh(x)
!print *, acosh(x)

end 


-- 


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

[Bug ada/38832] Main program runs fine but hangs on exit when linked with Ada shared lib

[oliver dot kellogg at eads dot com]

--- Comment #2 from oliver dot kellogg at eads dot com  2009-02-27 09:28 
---
FWIW, pressing Ctrl-C in gdb when the program blocks shows following trace:

Program received signal SIGINT, Interrupt.
0x0805bbd1 in system.soft_links.task_lock_nt () at s-soflin.adb:295
295procedure Task_Lock_NT is
(gdb) bt
#0  0x0805bbd1 in system.soft_links.task_lock_nt () at s-soflin.adb:295
#1  0x08053104 in system.file_io.close (file_ptr=0xbfffea7c, =2) at
s-fileio.adb:220
#2  0x080532db in system.file_io.finalize (v=(prev => 0x0, next => 0x8076b60))
at s-fileio.adb:379
#3  0x0805461f in system.finalization_implementation.finalize_list
(l=0x8076b94)
at s-finimp.adb:361
#4  0x080546d9 in system.finalization_implementation.finalize_global_list () at
s-finimp.adb:327
#5  0x0804ad12 in main (argc=1, argv=(system.address) 0xbfffed54,
envp=(system.address) 0xbfffed5c) at
/home/kellogg/ada/shared_lib/testuser/b~appl_main.adb:188
#6  0xb7ea2fe0 in __libc_start_main () from /lib/libc.so.6
#7  0x0804a951 in _start ()


-- 


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

[Bug ada/39172] libada parsing of multilib options

[schwab at suse dot de]

--- Comment #10 from schwab at suse dot de  2009-02-27 09:57 ---
Fixed.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

[pluto at agmk dot net]

--- Comment #21 from pluto at agmk dot net  2009-02-27 10:29 ---
(In reply to comment #20)
> Same issue.  Only possible fix is to not apply TBAA pruning to escaped
> symbols, which will - well - basically disable TBAA.  Testcase:

waht about this testcase?
the bug is marked as fixed but warnings are still present?

> inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
> 
> struct Y {
>   Y() {}
>   int i;
> };
> 
> struct X {
>   X() {}
>   void construct(const Y& y)
>   {
> new (&m_data[0]) Y(y);
>   }
>   template 
>   Y& get() { return reinterpret_cast(m_data); }
>   bool initialized;
>   char m_data[sizeof (Y)];
> };
> 
> X x;
> 
> void bar(const X&);
> void foo(Y& y)
> {
>   x.get() = y;
>   x.initialized = true;
>   bar(x);
> }
> 

t.cpp: In member function 'Y& X::get() [with T = Y]':
t.cpp:25:   instantiated from here
t.cpp:15: warning: dereferencing type-punned pointer will break strict-aliasing
rules
t.cpp: In function 'void foo(Y&)':
t.cpp:25: warning: dereferencing pointer '' does break
strict-aliasing rules
t.cpp:25: note: initialized from here


-- 


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

[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

[rguenther at suse dot de]

--- Comment #22 from rguenther at suse dot de  2009-02-27 10:33 ---
Subject: Re:  [4.4 regression] warnings from -isystem
 headers strikes back.

On Fri, 27 Feb 2009, pluto at agmk dot net wrote:

> --- Comment #21 from pluto at agmk dot net  2009-02-27 10:29 ---
> (In reply to comment #20)
> > Same issue.  Only possible fix is to not apply TBAA pruning to escaped
> > symbols, which will - well - basically disable TBAA.  Testcase:
> 
> waht about this testcase?
> the bug is marked as fixed but warnings are still present?

The original reported problem is gone.  The testcase below is unfixable.

> > inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
> > 
> > struct Y {
> >   Y() {}
> >   int i;
> > };
> > 
> > struct X {
> >   X() {}
> >   void construct(const Y& y)
> >   {
> > new (&m_data[0]) Y(y);
> >   }
> >   template 
> >   Y& get() { return reinterpret_cast(m_data); }
> >   bool initialized;
> >   char m_data[sizeof (Y)];
> > };
> > 
> > X x;
> > 
> > void bar(const X&);
> > void foo(Y& y)
> > {
> >   x.get() = y;
> >   x.initialized = true;
> >   bar(x);
> > }
> > 
> 
> t.cpp: In member function 'Y& X::get() [with T = Y]':
> t.cpp:25:   instantiated from here
> t.cpp:15: warning: dereferencing type-punned pointer will break 
> strict-aliasing
> rules
> t.cpp: In function 'void foo(Y&)':
> t.cpp:25: warning: dereferencing pointer '' does break
> strict-aliasing rules
> t.cpp:25: note: initialized from here
> 
> 
> 


-- 


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

[Bug fortran/39309] [4.4 Regression] .mod file versioning causes error instead of overwritting the file

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-02-27 10:47 ---
FIXED on the trunk.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/39314] -ffpe-trap=invalid gives no FPE for acos(-5.0)

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2009-02-27 10:49 ---
> Note that the problem also appears for log, while it does not for acosh and
> atanh:

If it works with some but not all libm routines, it sounds more like a GLIBC
than like a GCC problem.


-- 


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

[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

[pluto at agmk dot net]

--- Comment #23 from pluto at agmk dot net  2009-02-27 11:04 ---
(In reply to comment #22)

> The original reported problem is gone.  The testcase below is unfixable.

so what users can do now?
the -isystem feature doesn't work as expected with this unfixable diagnostics.


-- 


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

[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

[rguenth at gcc dot gnu dot org]

--- Comment #24 from rguenth at gcc dot gnu dot org  2009-02-27 11:07 
---
The user can use -Wno-strict-aliasing.


-- 


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

[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

[pluto at agmk dot net]

--- Comment #25 from pluto at agmk dot net  2009-02-27 11:22 ---
(In reply to comment #24)
> The user can use -Wno-strict-aliasing.
> 

naturally, but -O2 turns on -fstrict-aliasing, so using strict-aliasing
without warnings about aliasing violations is a bit horrible :)


-- 


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

[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.

[rguenther at suse dot de]

--- Comment #26 from rguenther at suse dot de  2009-02-27 12:04 ---
Subject: Re:  [4.4 regression] warnings from -isystem
 headers strikes back.

On Fri, 27 Feb 2009, pluto at agmk dot net wrote:

> --- Comment #25 from pluto at agmk dot net  2009-02-27 11:22 ---
> (In reply to comment #24)
> > The user can use -Wno-strict-aliasing.
> > 
> 
> naturally, but -O2 turns on -fstrict-aliasing, so using strict-aliasing
> without warnings about aliasing violations is a bit horrible :)

On IRC we agreed that turning strict-aliasing warnings off for 
system-headers is not a good idea.

So -Wno-strict-aliasing is the only thing I can offer.

Richard.


-- 


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

[Bug fortran/39314] -ffpe-trap=invalid gives no FPE for acos(-5.0)

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2009-02-27 13:15 ---
(In reply to comment #8)
> If it works with some but not all libm routines, it sounds more like a GLIBC
> than like a GCC problem.

Can someone reproduce this with C code?


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu dot org]

--- Comment #11 from joel at gcc dot gnu dot org  2009-02-27 16:24 ---
Laurent.. what Makefile magic is needed to select this file on sh Ada targets
and not on others?


-- 


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

[Bug target/34299] [avr] ICE on function attribute syntax for main()

[aesok at gcc dot gnu dot org]

--- Comment #12 from aesok at gcc dot gnu dot org  2009-02-27 16:25 ---
2007-04-05  Anatoly Sokolov 

PR target/25448
* config/avr/avr.c (avr_handle_fndecl_attribute): Use the
DECL_ASSEMBLER_NAME, not the DECL_NAME.


-- 


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

[Bug ada/38349] Error Building Ada (h8300)

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2009-02-27 16:26 ---
Ping.. still broken

gcc (GCC) 4.4.0 20090226 (experimental) [trunk revision 144455]


-- 


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

[Bug ada/38349] Error Building Ada (h8300)

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2009-02-27 16:28 ---
Laurent.. would it make sense to have a "low memory" alternate version of the
file in question and swap it in on some targets like the sh2e issue?


-- 


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

[Bug middle-end/39308] ICE when compiling with -O[s123] -floop-interchange

[spop at gcc dot gnu dot org]

--- Comment #14 from spop at gcc dot gnu dot org  2009-02-27 16:42 ---
Subject: Bug 39308

Author: spop
Date: Fri Feb 27 16:42:38 2009
New Revision: 144470

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144470
Log:
2009-02-27  Sebastian Pop  

PR middle-end/39308
* graphite.c (graphite_loop_normal_form): Do not call 
number_of_iterations_exit from a gcc_assert.


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


-- 


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

[Bug middle-end/39308] ICE when compiling with -O[s123] -floop-interchange

[spop at gcc dot gnu dot org]

--- Comment #15 from spop at gcc dot gnu dot org  2009-02-27 16:43 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug ada/38349] Error Building Ada (h8300)

[laurent at guerby dot net]

--- Comment #4 from laurent at guerby dot net  2009-02-27 17:42 ---
First you need to find out which stack_size works on your target.

An obvious patch would be something like that:

Default_Env_Stack_Size : constant Size_Type := Size_Type'Min (8_192_000,
Size_Type'Last / 1024 );

Otherwise since the only used of Default_Env_Stack_Size is s-stchop.adb I think
replacing the constant by a function would be acceptable, then you could
customize the return value it in s-parame-rtems.adb.


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

--- Comment #12 from laurent at guerby dot net  2009-02-27 17:50 ---
There is no need for Makefile magic here, this is a bug in s-scaval.adb logic.

As I said this file is used for only one ACATS test and one specific and not
widely used feature, so for the purpose of testing RTEMS you can just replace
unconditionally s-scaval.adb by the empty version you won't loose anything
important.


-- 


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

[Bug fortran/39318] New: internal compiler error: verify_stmts failed

[deji_aking at yahoo dot ca]

The attached code produce an ICE (below) with cuurent trunk when the compiler
option includes all of '-fno-second-underscore -fexceptions -O3'. The code
compiles fine with gfortran-4.3.2.

..
[d...@logos gemclim33]$ gfc -c -m64 -fPIC -fcray-pointer -fconvert=big-endian
-fopenmp -fno-second-underscore -fexceptions -O3 adw_trajsp.f
adw_trajsp.f: In function ‘adw_trajsp_.omp_fn.0’:
adw_trajsp.f:459: error: Dead STMT in EH table
D.3244_455 = __builtin_sqrtf (D.3243_454);

adw_trajsp.f:459: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
..


-- 
   Summary: internal compiler error: verify_stmts failed
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deji_aking at yahoo dot ca


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

[Bug fortran/39318] internal compiler error: verify_stmts failed

[deji_aking at yahoo dot ca]

--- Comment #1 from deji_aking at yahoo dot ca  2009-02-27 18:03 ---
Created an attachment (id=17371)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17371&action=view)
Fortran file that produce the ICE


-- 


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

[Bug fortran/39318] internal compiler error: verify_stmts failed

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2009-02-27 18:24 ---
Confirmed oni686-apple-darwin9 with

gfc -c -fcray-pointer -fexceptions -O2 -ftree-vectorize adw_trajsp.f


-- 


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

[Bug c++/39319] New: sigsegv occurs when an exception handler rethrows an excpetion and tries to return from the catch

[phamorsky at yahoo dot com]

The sample program fails to run on Linux x86_64.  
I'm using ...
  gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8)
... and compiling with command line ...
  g++ -Os catch.cpp -o catch.exe

=== Program Output ===
./catch.exe 
file = catch.cpp
Segmentation fault

=== SAMPLE Program ===
#include 
#include 
#include 

void MyExceptionHandler(const char* p_file)
{
try 
{
throw;
}
catch (std::exception& stdexc) 
{
std::cerr << "file = " << p_file << std::endl;
}
}

int main(int argc, char** argv)
{
try 
{
throw std::runtime_error("Throw some error, this should get caught.");
}
catch(...)
{
MyExceptionHandler(__FILE__);
}

printf("RETURNED SAFELY\n");
return 0;
}


-- 
   Summary: sigsegv occurs when an exception handler rethrows an
excpetion and tries to return from the catch
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phamorsky at yahoo dot com


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

[Bug c++/39319] sigsegv occurs when an exception handler rethrows an excpetion and tries to return from the catch

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-27 18:31 ---
3.4.6 is old and 3.4.x to 4.1.x are no longer maintained.This is most
likely a duplicate of bug 26530.


-- 


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

[Bug ada/38832] Main program runs fine but hangs on exit when linked with Ada shared lib

[oliver dot kellogg at eads dot com]

--- Comment #3 from oliver dot kellogg at eads dot com  2009-02-27 18:42 
---
Expanding on comment #2, there seems to be an endless loop around
s-fileio.adb:377ff.

376   Fptr1 := Open_Files;
377   while Fptr1 /= null loop
378  Fptr2 := Fptr1.Next;
379  Close (Fptr1'Access);
380  Fptr1 := Fptr2;
381   end loop;

Setting a breakpoint at 376,
Breakpoint 1, system.file_io.finalize (v=(prev => 0x0, next => 0x8078b60)) at
s-fileio.adb:376
376   Fptr1 := Open_Files;
(gdb) n
377   while Fptr1 /= null loop
(gdb) p Fptr1
$28 = (access system.file_control_block.afcb) 0x8078a60
(gdb) p Fptr1.next
$29 = (access system.file_control_block.afcb) 0x8078a00
(gdb) p Fptr1.next.next
$30 = (access system.file_control_block.afcb) 0x80789a0
(gdb) p Fptr1.next.next.next
$31 = (access system.file_control_block.afcb) 0x8078a60
(gdb) p Fptr1.next.next.next.next
$32 = (access system.file_control_block.afcb) 0x8078a00
(gdb) p Fptr1.next.next.next.next.next
$33 = (access system.file_control_block.afcb) 0x80789a0

.. and so on, indefinitely, where
(gdb) p Fptr1.name.all
$34 = "*stderr["00"]"
(gdb) p Fptr1.next.name.all
$35 = "*stdout["00"]"
(gdb) p Fptr1.next.next.name.all
$36 = "*stdin["00"]"


-- 


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

[Bug middle-end/39318] internal compiler error: verify_stmts failed

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-02-27 19:03 ---
Forgot to say that it is a [4.4 Regression].


-- 


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

[Bug target/39320] New: Regression: ICE: : in gen_add2_insn, at optabs.c:4733

[joel at gcc dot gnu dot org]

This occurred during the build.  I would expect it to happen on m32c-elf also.

$ /home/joel/test-gcc/b-gcc1-m32c/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-m32c/./gcc/ --version
xgcc (GCC) 4.4.0 20090226 (experimental) [trunk revision 144455]


/home/joel/test-gcc/install/m32c-rtems4.10/include -isystem
/home/joel/test-gcc/install/m32c-rtems4.10/sys-include -c -DHAVE_CONFIG_H -g
-O2-mcpu=m32cm  -I. -I/home/joel/test-gcc/gcc-svn/libiberty/../include  -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
/home/joel/test-gcc/gcc-svn/libiberty/strdup.c -o strdup.o
/home/joel/test-gcc/gcc-svn/libiberty/random.c: In function 'srandom':
/home/joel/test-gcc/gcc-svn/libiberty/random.c:243: internal compiler error: in
gen_add2_insn, at optabs.c:4733
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: Regression: ICE: : in gen_add2_insn, at optabs.c:4733
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: m32c-rtems


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

[Bug debug/39267] gdb testusite regressions

[hubicka at gcc dot gnu dot org]

--- Comment #1 from hubicka at gcc dot gnu dot org  2009-02-27 19:49 ---
Subject: Bug 39267

Author: hubicka
Date: Fri Feb 27 19:49:42 2009
New Revision: 144474

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144474
Log:
PR debug/39267
* tree.h (TREE_PROTECTED): Fix comment.
(BLOCK_HANDLER_BLOCK): Remove.
(struct tree_block): Remove handler_block add body_block.
(inlined_function_outer_scope_p): New.
(is_body_block): Remove.
* dbxout.c (dbxout_block): Remove BLOCK_HANDLER_BLOCK.
* dwarf2out.c (is_inlined_entry_point): Remove.
(add_high_low_attributes): Use inlined_function_outer_scope_p.
(gen_block_die): Use is_inlined_entry_point check; remove body block
code.
* langhooks.h (struct lang_hooks): Remove no_bodu_blocks.
* gimplify.c (gimplify_expr): Gimplify body blocks.
* tree-ssa-live.c (remove_unused_scope_block_p): Allow removing wrapper
block
with multiple subblocks.
(dump_scope_block): Prettier output; dump more flags and info.
(dump_scope_blocks): New.
(remove_unused_locals): Use dump_scope_blocks.
* tree-flow.h (dump_scope_blocks): Declare.
* tree-cfg.c (execute_build_cfg): Dump scope blocks.
* stmt.c (is_body_block): Remove.
* tree-inline.c (remap_block): Copy BODY_BLOCK info.
* langhooks-def.h (LANG_HOOKS_NO_BODY_BLOCKS): Remove.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-objc-common.h
trunk/gcc/dbxout.c
trunk/gcc/dwarf2out.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.h
trunk/gcc/stmt.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree.h


-- 


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

[Bug middle-end/39318] internal compiler error: verify_stmts failed

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2009-02-27 19:59 ---
Reduced test:

  subroutine adw_trajsp ( F_lon, F_lat, F_x, F_y, F_z,
 %F_u, F_v, F_dt,i0,in,j0,jn)
  implicit none
  real F_lon(*),F_lat(*),F_x(*),F_y(*),F_z(*),F_u(*),F_v(*),F_dt
  integer i0,in,j0,jn
  integer n, ij, nij,vnij, i,j,k
  real*8 xsin(i0:in,j0:jn)
!$omp parallel do private(xsin)
 do j=j0,jn
 do i=i0,in
xsin(i,j) = sqrt( F_u(n) ** 2 + F_v(n) ** 2 ) * F_dt
 end do
 end do
!$omp end parallel do
  return
  end

ibook-dhum] f90/bug% gfc -c -fopenmp -fexceptions -O2 -ftree-vectorize
adw_trajsp_red.f
adw_trajsp_red.f: In function 'adw_trajsp_.omp_fn.0':
adw_trajsp_red.f:8: error: Dead STMT in EH table
D.1679_46 = __builtin_sqrtf (D.1678_45);

adw_trajsp_red.f:8: internal compiler error: verify_stmts failed


-- 


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

[Bug c++/39321] New: G++ remove cv qualifiers from typedefs during template instantiation

[dodji at gcc dot gnu dot org]

The following program should compile, but current g++ from trunk compiles it.

Please read the comments in the code:

~=~

template
struct do_typedef
{
  typedef T type;
};


template struct is_function;

// Let's name this template partial specialization #1
template
struct is_function< T ()>
{ 
};

template struct is_member_func;

template
struct is_member_func
{
  //[1] okay, the following line should not compile. Here is why.  
  //After the type substitution that happens at instantiation time,
  //the value of the argument that matches the T parameter is
  //'void () () const'.
  //In that context, the result of the substitution of T in the expression
  //do_typedef::type _should_ be 'void () () const' as well.
  //So will be the argument of the is_function template.
  //'void () () const' is not compatible with 'T ()', so the  
  //partial template specialization #1 should be instantiated.
  //So we should get a compilation error.
  is_function::type> t;
};


struct A;

// Should not compile because of the comment [1] above.
is_member_func t;
~=~

What happens is that during the type substitution of
do_typedef::type, g++ removes the const qualifier from the 'void () ()
const' function. And that is a bug.

I'll attach below a patch that fixes it.


-- 
   Summary: G++ remove cv qualifiers from typedefs during template
instantiation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dodji at gcc dot gnu dot org


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

[Bug c++/39321] G++ remove cv qualifiers from typedefs during template instantiation

[dodji at gcc dot gnu dot org]

--- Comment #1 from dodji at gcc dot gnu dot org  2009-02-27 20:06 ---
Created an attachment (id=17372)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17372&action=view)
Don't remove cv quals from typedefs during type substitution


-- 


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

[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const

[dodji at gcc dot gnu dot org]

--- Comment #2 from dodji at gcc dot gnu dot org  2009-02-27 20:08 ---
I have filed bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39321 that
describes the gcc bug. It also has a patch that should fix it.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |libstdc++


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

[Bug tree-optimization/39129] The meaning of 'BB' in "too many BBs in loop"

[lanurmi at iki dot fi]

--- Comment #3 from lanurmi at iki dot fi  2009-02-27 20:15 ---
Well yes, the meaning of basic block is not self-explanatory either.  But at
least it is a much better search term than just 'BB'.  And if someone comes up
with something even better, I'm certainly not against it.


-- 


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

[Bug target/39320] Regression: ICE: : in gen_add2_insn, at optabs.c:4733

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-27 20:25 ---


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


-- 

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

[Bug target/39182] ICE in gen_add2_insn, at optabs.c:4884

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-02-27 20:25 ---
*** Bug 39320 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c/36839] struct with only anonymous unions plus flexible array member

[vegard dot nossum at gmail dot com]

--- Comment #3 from vegard dot nossum at gmail dot com  2009-02-27 20:27 
---
I'm hitting this as well :-(

[veg...@damson ~/programming 0]
$ cat flexible-array-empty-struct.c 
struct x {
union {
int x;
};

int array[];
};

[veg...@damson ~/programming 0]
$ gcc -c flexible-array-empty-struct.c 
flexible-array-empty-struct.c:6: error: flexible array member in otherwise
empty struct

[veg...@damson ~/programming 1]
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) 


-- 

vegard dot nossum at gmail dot com changed:

   What|Removed |Added

 CC||vegard dot nossum at gmail
   ||dot com


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

[Bug c/36839] struct with only anonymous unions plus flexible array member

[vegard dot nossum at gmail dot com]

--- Comment #4 from vegard dot nossum at gmail dot com  2009-02-27 20:32 
---
Workaround:

Install an empty dummy member between the union and the array, like this:

struct x {
union {
int x;
};

int _dummy[0]; // workaround

int array[];
};


-- 


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

[Bug c/36839] struct with only anonymous unions plus flexible array member

[joseph at codesourcery dot com]

--- Comment #5 from joseph at codesourcery dot com  2009-02-27 20:58 ---
Subject: Re:  struct with only anonymous unions plus flexible
 array member

Anonymous unions are outside the scope of C99, so this issue is purely 
about what is most useful for GNU C right now.

However, there have been discussions of including some form of anonymous 
structs and unions in C1x, and if that goes in we'd want to follow 
whatever that may say about whether this is valid (along with other 
aspects of anonymous structs/unions - hopefully C1x would follow C++).


-- 


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

[Bug middle-end/39322] New: [4.4 regression] Bogus aliasing warning

[reichelt at gcc dot gnu dot org]

A IMHO the trunk issues a bogus warning for the following code snippet
when compiling it with "-O2 -Wall" using the C++ frontend:

==
int foo()
{
  char a[10];
  int i = *(int*)&a[4];
  int j = *(int*)(a+4);
  return i+j;
}
==

bug.cc: In function 'int foo()':
bug.cc:4: warning: dereferencing type-punned pointer will break strict-aliasing
rules

Interestingly, the warning is given only for line 4, but not line 5.
Also the C frontend is not affected.

If there's wrong alias info involved, this might lead to wrong-code bugs.


-- 
   Summary: [4.4 regression] Bogus aliasing warning
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/39322] [4.4 regression] Bogus aliasing warning

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/39322] Bogus aliasing warning

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-27 22:23 ---
Actually this is not a bogus aliasing warning at all.  You are accessing a
character type as an int which is an aliasing violation.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4 regression] Bogus  |Bogus aliasing warning
   |aliasing warning|


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

[Bug middle-end/39322] Bogus aliasing warning

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.4.0   |---


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

[Bug middle-end/39322] Bogus aliasing warning

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-02-27 22:25 ---
We should give a warning on both lines.


-- 


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

[Bug middle-end/39322] Missed aliasing warning

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-02-27 22:37 ---
The FE warning code doesn't warn for *((int *) &a + 4) because it doesn't
recognize the form.  This is what we get in both cases from the C frontend
and in the second case from the C++ frontend.

The PTA warning code doesn't trigger here because we do not prune a from
the points-to sets.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-27 22:37:30
   date||
Summary|Bogus aliasing warning  |Missed aliasing warning


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

[Bug middle-end/39322] Missed aliasing warning

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-02-27 22:52 ---
Related a little bit to bug 39117 or at least for the PTA side of things.


-- 


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

[Bug target/39323] New: MAX_OFILE_ALIGNMENT in elfos.h is too big

[hjl dot tools at gmail dot com]

struct tree_decl_common has

unsigned int align : 24;

And the maximum alignment we support is 1 << 23 bits (1 << 20 bytes). However,
config/elfos.h has

/* The biggest alignment supported by ELF in bits. 32-bit ELF 
   supports section alignment up to (0x8000 * 8), while 
   64-bit ELF supports (0x8000 * 8). If this macro 
   is not defined, the default is the largest alignment supported 
   by 32-bit ELF and representable on a 32-bit host. Use this
   macro to limit the alignment which can be specified using
   the `__attribute__ ((aligned (N)))' construct.  */
#ifndef MAX_OFILE_ALIGNMENT
#define MAX_OFILE_ALIGNMENT (((unsigned int) 1 << 28) * 8)
#endif

If we ask for alignment greater than 1 << 20 bytes, we won't
get any warnings:

[...@gnu-17 gcc]$  cat x.c
int foo __attribute__ ((aligned(1 << 21))) =  20;
int bar __attribute__ ((aligned(1 << 20))) =  20;
[...@gnu-17 gcc]$ ./xgcc -B./ -S x.i 
[...@gnu-17 gcc]$ cat x.s
.file   "x.i"
.globl foo
.data
.type   foo, @object
.size   foo, 4
foo:
.long   20
.globl bar
.align 1048576
.type   bar, @object
.size   bar, 4
bar:
.long   20


-- 
   Summary: MAX_OFILE_ALIGNMENT in elfos.h is too big
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug testsuite/38526] WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2009-02-27 23:40 ---
If this is still a problem, please try the patch at

  http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01496.html

I'd rather not make changes like that so late in the release cycle but I'll do
it if it's needed and not just cosmetic.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug target/39323] MAX_OFILE_ALIGNMENT in elfos.h is too big

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/39315] Unaligned move used on aligned stack variable

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-02-28 00:03 ---
Created an attachment (id=17373)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17373&action=view)
A new patch

This patch may work better.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #17368|0   |1
is obsolete||


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

[Bug c/39323] MAX_OFILE_ALIGNMENT in elfos.h is too big

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-02-28 00:12 ---
Shouldn't handle_aligned_attribute check alignment overflow?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Component|target  |c


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

[Bug testsuite/37578] Testsuite cannot tell systems with REAL(10) and REAL(16) apart

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2009-02-28 00:25 ---
The GCC testsuite supports effective-target keywords which can be used anywhere
that target lists are used; see the internals manual about Test Directives.

Define an effective-target keyword xxx via check_effective_target_xxx in
gcc/testsuite/lib/target-supports.exp.


-- 


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

[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning

[jamborm at gcc dot gnu dot org]

--- Comment #12 from jamborm at gcc dot gnu dot org  2009-02-28 00:30 
---
I have just posted a patch to fix this issue on the 4.3 branch to the
mailing list:

http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01245.html


-- 


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

[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

[skunk at iskunk dot org]

--- Comment #16 from skunk at iskunk dot org  2009-02-28 00:41 ---
Building 4.3.3 fails with

/usr/home/cport/tmp/bash ./libtool --tag=CXX --mode=compile
/usr/home/cport/build/gcc-4.3.3-build-test/./gcc/xgcc -shared-libgcc
-B/usr/home/cport/build/gcc-4.3.3-build-test/./gcc -nostdinc++
-L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src
-L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src/.libs
-B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/bin/
-B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/lib/ -isystem
/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/include -isystem
/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/sys-include -DHAVE_CONFIG_H -I.
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava -I./include -I./gcj 
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava -Iinclude
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/include
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/include -Iclasspath/include
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/native/fdlibm
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../boehm-gc/include
-I../boehm-gc/include  -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/.././libjava/../gcc
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../zlib
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../libffi/include -I../libffi/include
 -fno-rtti -fnon-call-exceptions -pthread -fdollars-in-identifiers
-Wswitch-enum -D_FILE_OFFSET_BITS=64 -mieee -Wextra -Wall -D_GNU_SOURCE
-DPREFIX="\"/usr/home/cport/tmp/GCC\""
-DTOOLEXECLIBDIR="\"/usr/home/cport/tmp/GCC/lib/gcc/alphaev56-dec-osf4.0g/4.3.3\""
-DJAVA_HOME="\"/usr/home/cport/tmp/GCC\""
-DBOOT_CLASS_PATH="\"/usr/home/cport/tmp/GCC/share/java/libgcj-4.3.3.jar\""
-DJAVA_EXT_DIRS="\"/usr/home/cport/tmp/GCC/share/java/ext\""
-DGCJ_ENDORSED_DIRS="\"/usr/home/cport/tmp/GCC/share/java/gcj-endorsed\""
-DGCJ_VERSIONED_LIBDIR="\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9\""
-DPATH_SEPARATOR="\":\"" -DECJ_JAR_FILE="\"\""
-DLIBGCJ_DEFAULT_DATABASE="\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9/classmap.db\""
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"gcj-4.3.3-9/classmap.db\"" -O2 -g   
-mieee -c -o java/net/natVMNetworkInterface.lo
java/net/natVMNetworkInterface.cc
libtool: compile:  /usr/home/cport/build/gcc-4.3.3-build-test/./gcc/xgcc
-shared-libgcc -B/usr/home/cport/build/gcc-4.3.3-build-test/./gcc -nostdinc++
-L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src
-L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src/.libs
-B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/bin/
-B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/lib/ -isystem
/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/include -isystem
/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/sys-include -DHAVE_CONFIG_H -I.
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava -I./include -I./gcj
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava -Iinclude
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/include
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/include -Iclasspath/include
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/native/fdlibm
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../boehm-gc/include
-I../boehm-gc/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/.././libjava/../gcc
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../zlib
-I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../libffi/include -I../libffi/include
-fno-rtti -fnon-call-exceptions -pthread -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -mieee -Wextra -Wall -D_GNU_SOURCE
-DPREFIX=\"/usr/home/cport/tmp/GCC\"
-DTOOLEXECLIBDIR=\"/usr/home/cport/tmp/GCC/lib/gcc/alphaev56-dec-osf4.0g/4.3.3\"
-DJAVA_HOME=\"/usr/home/cport/tmp/GCC\"
-DBOOT_CLASS_PATH=\"/usr/home/cport/tmp/GCC/share/java/libgcj-4.3.3.jar\"
-DJAVA_EXT_DIRS=\"/usr/home/cport/tmp/GCC/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/usr/home/cport/tmp/GCC/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9\"
-DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\"
-DLIBGCJ_DEFAULT_DATABASE=\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.3.3-9/classmap.db\" -O2 -g -mieee
-c java/net/natVMNetworkInterface.cc  -DPIC -o java/net/natVMNetworkInterface.o
In file included from java/net/natVMNetworkInterface.cc:35:
/usr/include/net/if.h:144: error: expected ';' before '}' token
/usr/include/net/if.h:144: error: expected `;' before '}' token
gmake[3]: *** [java/net/natVMNetworkInterface.lo] Error 1
gmake[3]: Leaving directory
`/mnt/scratch/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libjava'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/mnt/scratch/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/mnt/scratch/build/gcc-4.3.3-build-test'

[Bug driver/39293] -save-temps does not follow the -o option and instead puts the temp file in the current directory

[meissner at linux dot vnet dot ibm dot com]

--- Comment #3 from meissner at linux dot vnet dot ibm dot com  2009-02-28 
01:01 ---
Created an attachment (id=17374)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17374&action=view)
This patch fixes -save-temps so that it puts the temp file in the output
directory rather than the current directory


-- 


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

[Bug middle-end/39315] Unaligned move used on aligned stack variable

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-02-28 02:03 ---
Created an attachment (id=17375)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17375&action=view)
An updated patch

When align == 0, we should align variable to STACK_BOUNDARY.


-- 


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

[Bug target/39291] _Unwind_Backtrace fails.

[dannysmith at users dot sourceforge dot net]

--- Comment #4 from dannysmith at users dot sourceforge dot net  2009-02-28 
02:38 ---
Created an attachment (id=17376)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17376&action=view)
testcase executable built on mingw32 

testcase executable built on mingw32 attached


-- 


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

[Bug testsuite/38526] WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2009-02-28 
03:12 ---
Subject: Re:  WARNING: Could not compile gcc.dg/compat/struct-layout-1
generator

> If this is still a problem, please try the patch at
> 
>   http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01496.html

Yes, this is still a problem on darwin.  The patch fixes the PR.

> I'd rather not make changes like that so late in the release cycle but I'll do
> it if it's needed and not just cosmetic.

I would say the issue is more than cosmetic, but testsuite issues aren't
crucial unless the test results are misleading.

Dave


-- 


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

[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64

[rob1weld at aol dot com]

--- Comment #5 from rob1weld at aol dot com  2009-02-28 03:53 ---
(In reply to comment #4)
> In addition to the lack of "-L..." this is also a 'spec' issue :
> ...

The issue with the spec file is caused by this in the Makefile.in:

# Dump a specs file to make -B./ read these specs over installed ones.
$(SPECS): xgcc$(exeext)
$(GCC_FOR_TARGET) -dumpspecs > tmp-specs
mv tmp-specs $(SPECS)



Debian's supplied gcc 4.3 is built androgynous:

# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 


# gcc -dumpspecs | head -2
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*}  %{Wa,*:%*} %{m32:--32}
%{m64:--64}



We need to check that the host-compiler's "spec" is correct and fix it.


Here is some pseudo-code:

if ' gcc -dumpspecs | grep \{m32:--32 | grep \{m64:--64 ' then # not correct
  if test x`(hostname || uname -n) 2>/dev/null | sed 1q` == "xopensolaris" ;
then
if 'isainfo -k' = 'i386' then 
  gcc -dumpspecs | sed 2s/m32:--32/!m32:--32/1p
fi
if 'isainfo -k' = 'amd_64' | 'x86_64' then 
  gcc -dumpspecs | sed 2s/m64:--64/!m64:--64/1p
fi
  else # Not OpenSolaris' uname
if 'uname -m' = 'i386' then 
  gcc -dumpspecs | sed 2s/m32:--32/!m32:--32/1p
fi
if 'uname -m' = 'amd_64' | 'x86_64' then 
  gcc -dumpspecs | sed 2s/m64:--64/!m64:--64/1p
fi
  fi
fi


Rob



-- 


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