[Bug c/42300] Having LIBRARY_PATH set but with null contents, makes gcc read ./specs

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-12-06 08:59 ---
specs files are no longer generated by default.


-- 


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

[Bug debug/42299] [4.5 Regression] another verify_ssa failure with -g -O2

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |debug
   Keywords||ice-on-valid-code
Summary|another verify_ssa failure  |[4.5 Regression] another
   |with -g -O2 |verify_ssa failure with -g -
   ||O2
   Target Milestone|--- |4.5.0


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

[Bug fortran/32957] C/Fortran interoperability and -fdefault-integer-8

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-12-06 10:52 ---
If I apply the following patch:

--- c_loc_tests_2.f03   2009-11-25 18:17:45.0 +0100
+++ c_loc_tests_2_db_1.f03  2009-12-06 11:43:31.0 +0100
@@ -44,13 +44,13 @@ contains
   end subroutine test0

   subroutine test1() bind(c)
-integer, target, dimension(100) :: int_array_tar
+integer(c_int), target, dimension(100) :: int_array_tar
 type(c_ptr) :: my_c_ptr_1 = c_null_ptr
 type(c_ptr) :: my_c_ptr_2 = c_null_ptr

-int_array_tar = 100
+int_array_tar = 100_c_int
 my_c_ptr_1 = c_loc(int_array_tar)
-if(test_array_address(my_c_ptr_1, 100) .ne. 1) then
+if(test_array_address(my_c_ptr_1, 100_c_int) .ne. 1) then
call abort()
 end if
   end subroutine test1

the test passes with -fdefault-integer-8. Note that

gfc -fdefault-integer-8 c_loc_tests_2_db_1.f03 c_loc_tests_2_funcs.c

gives a warning:

cc1: warning: command line option "-fdefault-integer-8" is valid for Fortran
but not for C

Although such warning can be trapped by adding in gcc/testsuite/lib/prune.exp
lines such that

 regsub -all "(^|\n)cc1: warning: command line option .-fwhole-file. is
valid for Fortran but not for C" $text "" text

it would be better to change the gfortran script to not pass gfortran options
to other languages.

If there is any interest in updating the interoperability tests to works with
-fdefault-*-8, I can comb the testsuite.


-- 


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

[Bug preprocessor/41943] include search path composition is bogus

[ktietz at gcc dot gnu dot org]

--- Comment #6 from ktietz at gcc dot gnu dot org  2009-12-06 11:47 ---
By rethinking this issue I came to the point that this would lead to pretty
havy incompatibilities between -pc-mingw32 and -w64-mingw32. Also it would
disallow to use the default /usr/local prefix for installtion without setting
up a sysroot.
So I think to change gcc.c here is the better variant and fixes both venture
targets here. As win32 paths are pretty unique for native windows targets, I
think this patch here is minimal intrusive for *nix targets.

Index: gcc/gcc/gcc.c
===
--- gcc.orig/gcc/gcc.c  2009-11-26 17:37:26.0 +0100
+++ gcc/gcc/gcc.c   2009-12-06 12:37:38.21319 +0100
@@ -2900,8 +2900,11 @@
 {
   if (!IS_ABSOLUTE_PATH (prefix))
 fatal ("system path '%s' is not absolute", prefix);
-
-  if (target_system_root)
+  if (target_system_root
+#if HAVE_DOS_BASED_FILE_SYSTEM == 1
+  && (!prefix[0] || prefix[1] != ':')
+#endif
+ )
 {
   if (target_sysroot_suffix)
  prefix = concat (target_sysroot_suffix, prefix, NULL);

I tested this patch and it seems to do what you expects it should do.

Cheers,
Kai


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ktietz at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-11-29 20:47:06 |2009-12-06 11:47:02
   date||


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

[Bug fortran/41866] Wrong standard in docs for ISO_FORTRAN_ENV

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2009-12-06 12:18 ---
r148317 | burnus | 2009-06-09 19:21:45 +0200 (Tue, 09 Jun 2009) | 9 lines

2009-06-09  Tobias Burnus  

[...]
* intrinsic.texi (ISO_FORTRAN_ENV): Document INT{8,16,32,64} and
REAL{32,64,128}.

Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/22201] Parameter description strings should all start with a capital letter

[goeran at uddeborg dot se]

--- Comment #4 from goeran at uddeborg dot se  2009-12-06 12:43 ---
Looks good in po file for 4.5-b20091203


-- 

goeran at uddeborg dot se changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug c++/29917] %s substituted with actual words can not be translated correctly (op_error)

[goeran at uddeborg dot se]

--- Comment #4 from goeran at uddeborg dot se  2009-12-06 12:44 ---
Looks good in po file for 4.5-b20091203


-- 

goeran at uddeborg dot se changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug objc/29200] %s substituted with "methods"/"selectors" can't be properly translated

[goeran at uddeborg dot se]

--- Comment #5 from goeran at uddeborg dot se  2009-12-06 12:47 ---
Looks good in po file for 4.5-b20091203


-- 

goeran at uddeborg dot se changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug c++/34836] Parts of sentences substituted for %s can not be translated

[goeran at uddeborg dot se]

--- Comment #3 from goeran at uddeborg dot se  2009-12-06 12:52 ---
Looks good in po file for 4.5-b20091203


-- 

goeran at uddeborg dot se changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug fortran/40904] Documentation: Description for COUNT is wrong

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2009-12-06 12:59 ---
Subject: Bug 40904

Author: dfranke
Date: Sun Dec  6 12:59:46 2009
New Revision: 155022

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155022
Log:
2009-12-06  Daniel Franke  

PR fortran/40904
* intrinsics.texi: Fixed description of COUNT.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi


-- 


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

[Bug fortran/40904] Documentation: Description for COUNT is wrong

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-12-06 13:00 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math

[irar at il dot ibm dot com]

--- Comment #3 from irar at il dot ibm dot com  2009-12-06 13:25 ---
On powerpc64-suse-linux with current trunk calculix failed after a couple of
minutes with
-O3  -maltivec -ffast-math
-O3  -maltivec -ffast-math -fno-tree-vectorize
-O2  -maltivec -ffast-math
-O1  -maltivec -ffast-math

It is currently running for about an hour with
-O0  -maltivec -ffast-math

Ira


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[pault at gcc dot gnu dot org]

--- Comment #13 from pault at gcc dot gnu dot org  2009-12-06 13:32 ---
(In reply to comment #11)

> However, I fail to see why. Paul, do you have an idea?
> 

I have loaded fortran-dev and this PR onto my laptop - I'm on the road again
this week.

I'll see if I have anything to offer.  In the mean time, there are various
problems associated with vtables that I would like to deal with

Cheers

Paul


-- 


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

[Bug fortran/42309] New: Problem with a pointer array passed to a subroutine

[gilbert dot scott at easynet dot co dot uk]

$ uname -a
Linux localhost.localdomain 2.6.29.4-167.fc11.i686.PAE #1 SMP Wed May 27
17:28:22 EDT 2009 i686 i686 i386 GNU/Linux
$ /usr/local/gfortran/bin/gfortran --version
GNU Fortran (GCC) 4.5.0 20091205 (experimental) [trunk revision 155016]
$ cat x.f95
PROGRAM X
TYPE T
   INTEGER :: I
END TYPE T
TYPE(T), TARGET :: T1(3)
INTEGER, POINTER :: P(:)

T1(1)%I = 1
T1(2)%I = 2
T1(3)%I = 3
P => T1%I
CALL Z(P)
PRINT *, T1%I

CONTAINS

SUBROUTINE Z(Q)
INTEGER, POINTER :: Q(:)
Q(1) = 999
END SUBROUTINE Z

END PROGRAM X

$ /usr/local/gfortran/bin/gfortran -o x x.f95
$ ./x
   1 999   3

!! The output is wrong.
I am expecting this output:
 999   2   3


-- 
   Summary: Problem with a pointer array passed to a subroutine
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gilbert dot scott at easynet dot co dot uk
  GCC host triplet: 4.5.0


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

--- Comment #20 from dominiq at lps dot ens dot fr  2009-12-06 14:56 ---
With the patch in comment #19, the test in comment #14 no longer gives ICEs. 

However I noticed that several invalid cases are not detected (a and b in
data_init_(scalar|array|matrix)_invalid, and c and d in
data_init_(array|matrix)_invalid). 

Only f and h in data_init_(array|matrix)_invalid. give the two occurrences for
the duplicates (after having changed the dimensions of h in
data_init_matrix_invalid).

When isolated, e in data_init_(array|matrix)_invalid and g
data_init_matrix_invalid give ICEs in output_constructor_regular_field, at
varasm.c:4773 (neither ICE nor error when there is another initialization
giving itself an error).

Finally i and j  in data_init_(array|matrix)_invalid triggered the second and
first ICE respectively.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

--- Comment #21 from dominiq at lps dot ens dot fr  2009-12-06 14:58 ---
Note that comment #20 confirms comment #12.


-- 


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

[Bug fortran/42309] Problem with a pointer array passed to a subroutine

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2009-12-06 15:00 
---
using Q(0) puts the 999 in the first position.  We have an off by one error
here.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-06 15:00:54
   date||


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

[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector

[dfranke at gcc dot gnu dot org]

--- Comment #19 from dfranke at gcc dot gnu dot org  2009-12-06 15:07 
---
Unassigning myself.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|dfranke at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug fortran/41869] ICE segfault when reading module file

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2009-12-06 15:18 ---
Slightly reduced testcase:

module fox_m_fsys_array_str
contains
  pure function str_vs(vs) result(s)
character, dimension(:), intent(in) :: vs
character(len=size(vs)) :: s
  end function str_vs
  pure function vs_str(s) result(vs)
character(len=*), intent(in) :: s
character, dimension(len(s)) :: vs
  end function vs_str
end module fox_m_fsys_array_str
module fox_m_fsys_format
  private
  interface str
module procedure  str_logical_array
  end interface str
  interface len
module procedure str_logical_array_len
  end interface
  public :: str
contains
  pure integer function str_logical_array_len(la)
logical, dimension(:), intent(in)   :: la
  end function str_logical_array_len
  pure function str_logical_array(la) result(s)
logical, dimension(:), intent(in)   :: la
character(len=len(la)) :: s
  end function str_logical_array
  pure logical function checkFmt(fmt)
character(len=*), intent(in) :: fmt
checkFmt = len(fmt) > 0
  end function checkFmt
end module fox_m_fsys_format
module FoX_dom
  use fox_m_fsys_format
  use fox_m_fsys_array_str
end module FoX_dom


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-06 15:18:49
   date||


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

[Bug fortran/37829] ICE Incorrect name mangling with iso_c_binding

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2009-12-06 15:40 
---
More descriptive summary. Low priority.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4
Summary|ICE in resolve_symbol   |ICE Incorrect name mangling
   ||with iso_c_binding


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

[Bug java/42143] gcj creates "dummy" variables

[kurt at roeckx dot be]

--- Comment #1 from kurt at roeckx dot be  2009-12-06 16:03 ---
Can someone please take a look at this?


-- 


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

[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release

[ghazi at gcc dot gnu dot org]

--- Comment #8 from ghazi at gcc dot gnu dot org  2009-12-06 16:11 ---
Subject: Bug 40302

Author: ghazi
Date: Sun Dec  6 16:11:06 2009
New Revision: 155023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155023
Log:
PR middle-end/30447
PR middle-end/30789
PR other/40302

* configure.ac: Require MPC.
* configure: Regenerate.
gcc:
* doc/install.texi: Document MPC is required.


Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi


-- 


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

[Bug middle-end/30789] complex folding inexact

[ghazi at gcc dot gnu dot org]

--- Comment #12 from ghazi at gcc dot gnu dot org  2009-12-06 16:11 ---
Subject: Bug 30789

Author: ghazi
Date: Sun Dec  6 16:11:06 2009
New Revision: 155023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155023
Log:
PR middle-end/30447
PR middle-end/30789
PR other/40302

* configure.ac: Require MPC.
* configure: Regenerate.
gcc:
* doc/install.texi: Document MPC is required.


Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi


-- 


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

[Bug middle-end/30447] Evaluate complex math functions at compile-time

[ghazi at gcc dot gnu dot org]

--- Comment #12 from ghazi at gcc dot gnu dot org  2009-12-06 16:11 ---
Subject: Bug 30447

Author: ghazi
Date: Sun Dec  6 16:11:06 2009
New Revision: 155023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155023
Log:
PR middle-end/30447
PR middle-end/30789
PR other/40302

* configure.ac: Require MPC.
* configure: Regenerate.
gcc:
* doc/install.texi: Document MPC is required.


Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi


-- 


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

[Bug testsuite/35939] maxloc_bounds_[457].f90 fail with -fdefault-integer-8

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-12-06 16:19 ---
> It would be (slightly) preferable if the test case didn't contain any
> kind=4 or kind=8 specification.  I wrote them, but I can't remember why
> I put the kind=xxx in there.

This PR seems to have been fixed along this line. Before I close it, does
someone remenber when?


-- 


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

[Bug c/42310] New: ICE on converting target-dependent PSImode variable

[lyudalev at gmail dot com]

The exact version of GCC: 4.4.1 

The system type: Linux version 2.6.9-67.EL (Red Hat 3.4.6-8)

The options given when GCC was configured/built: ../../gcc/configure
--target=testtarget --prefix=/usr/local/testtarget --enable-target-optspace
--enable-checking --disable-nls --enable-languages=c,c++
Thread model: single

The complete command line that triggers the bug: testtarget-gcc -c loop.c

I'm trying to define a nonstandard type for 12-bit scalar variables based on a
target-dependent PSI mode.

In my backend's testtarget-modes.def I have:
  PARTIAL_INT_MODE (SI);

In my backend's testtarget_init_builtins() function (TARGET_INIT_BUILTINS) I
have the following:
  /* Create builtin type for 12-bit integer numbers (partial int) */
  tree t = make_unsigned_type (9);
  (*lang_hooks.types.register_builtin_type) (t, "mybit12_t");
  SET_TYPE_MODE (t, PSImode);

the compiler output:
testtarget-gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See  for instructions.

The resulting gcc compiler crashes (ICE) when it tries to convert any integer
into my new type.
I tried to debug it and what I see is that it goes back and forth until the
stack is exhausted between two functions: convert and convert_to_integer:

#0  convert_to_integer (type=0xb7eb20d0, expr=0xb7e3caf0) at
../../../gcc/gcc/convert.c:389
#1  0x08079974 in convert (type=0xb7eb20d0, expr=0xb7e3caf0) at
../../../gcc/gcc/c-convert.c:101
#2  0x08080edc in convert_and_check (type=0xb7eb20d0, expr=0xb7e3caf0) at
../../../gcc/gcc/c-common.c:1812
#3  0x08068c5c in convert_for_assignment (type=0xb7eb20d0, rhs=0xb7e3caf0,
errtype=ic_assign, fundecl=0x0, function=0x0, parmnum=0) at
../../../gcc/gcc/c-typeck.c:4212
#4  0x080720b6 in build_modify_expr (location=1619, lhs=0xb7ec,
modifycode=NOP_EXPR, rhs=0xb7e3caf0) at ../../../gcc/gcc/c-typeck.c:3948
#5  0x080a984c in c_parser_expr_no_commas (parser=0xb7ebe0fc, after=0x0) at
../../../gcc/gcc/c-parser.c:4421
#6  0x080a9914 in c_parser_expression (parser=0xb7e3caf0) at
../../../gcc/gcc/c-parser.c:5664
#7  0x080af9fd in c_parser_for_statement (parser=0xb7ebe0fc) at
../../../gcc/gcc/c-parser.c:4101
#8  0x080a63de in c_parser_statement_after_labels (parser=0xb7ebe0fc) at
../../../gcc/gcc/c-parser.c:3700
#9  0x080a71b5 in c_parser_compound_statement_nostart (parser=0xb7ebe0fc) at
../../../gcc/gcc/c-parser.c:3470
#10 0x080aec1b in c_parser_compound_statement (parser=0xb7ebe0fc) at
../../../gcc/gcc/c-parser.c:3318
#11 0x080af1e7 in c_parser_declaration_or_fndef (parser=0xb7ebe0fc, fndef_ok=1
'\001', empty_ok=1 '\001', nested=0 '\0', start_attr_ok=Variable
"start_attr_ok" is not available.
) at ../../../gcc/gcc/c-parser.c:1307
#12 0x080b0e95 in c_parser_external_declaration (parser=0xb7ebe0fc) at
../../../gcc/gcc/c-parser.c:1076
#13 0x080b1c79 in c_parse_file () at ../../../gcc/gcc/c-parser.c:979
#14 0x0809af6c in c_common_parse_file (set_yydebug=0) at
../../../gcc/gcc/c-opts.c:1252
#15 0x0832a409 in toplev_main (argc=12, argv=0xbff91014) at
../../../gcc/gcc/toplev.c:970
#16 0x080bddb7 in main (argc=12, argv=0xbff91014) at ../../../gcc/gcc/main.c:35

The preprocessed file that triggers the bug:
int main (int argc, char *argv[]) {
  mybit12_t i;
  for (i = 0; i < 20; i++)
printf ("%d", i);
  return 0;
}


-- 
   Summary: ICE on converting target-dependent PSImode variable
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lyudalev at gmail dot com


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

[Bug fortran/40196] F2003: Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-12-06 16:59 ---
Type parameter inquiries are also mentioned in PR29962, comment #10.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
OtherBugsDependingO||20585, 29962
  nThis||


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

[Bug java/42311] New: Cross build fails because native gcj needed to build ecjx

[bugtrack at roumenpetrov dot info]

+++ This bug was initially created as a clone of Bug #30591 +++

> ecjx is a java program used as part of the gcj compilation process.  Because 
> it is written in java and > runs on the host, it needs a host version of gcj 
> to build it.
> 
> Here is the error I am getting:
> 
> make[3]: *** [ecjx] Error 127
> make[3]: Leaving directory 
> `/home/daney/gccsvn/mipsel-trunk/mipsel-linux/libjava'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory 
> `/home/daney/gccsvn/mipsel-trunk/mipsel-linux/libjava'
> make[1]: *** [all-target-libjava] Error 2
> make[1]: Leaving directory `/home/daney/gccsvn/mipsel-trunk'
> make: *** [all] Error 2
> 
> There seem to be two ways to fix this:
> 
> 1) In a cross build, build a complete gcc/g++/gcj in build-i686-pc-linux-gnu 
> along with fixincldes and > libiberty.
> 
> 2) Have configure check for a good version of gcj that is already installed 
> and use that

Bug #30591 is closed by the reason from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30591#c6 .

I would like to clone issue as cross build obj ecjx don't work in my case:
The part of .../gcc/Makefile is:
build=i486-pc-linux-gnu
host=i486-pc-linux-gnu
target=i486-pc-mingw32

The part of ../i486-mingw32/libjava/Makefile
build_triplet = i486-pc-linux-gnu
host_triplet = i486-pc-mingw32
target_triplet = i486-pc-mingw32


It seems to me ecjx can't be build as part of libjava build process:
- build of ecjx.o
/build/gcc-i486-mingw32/./gcc/xgcc  -c -o ecjx.o
../../../src/gcc-4.4.0/libjava/ecjx.cc ...
- build of executable :
i486-pc-linux-gcj -o ecjx.exe  ecjx.o
make: i486-pc-linux-gcj: Command not found

So far so good but may native compiler is :
/usr/bin/gcj with symlink to
/usr/bin/i486-slackware-linux-gcj
So the first problem is why is not peeked correct compiler ? Note that C, C++,
Fortran builds just fine.

Next lets create a symlink to "missing" gcj compiler:
# cd /usr/bin; ln -s gcj i486-pc-linux-gc
$ make ecjx.exe
i486-pc-linux-gcj -o ecjx.exe ...  ecjx.o
ecjx.o: file not recognized: File format not recognized
collect2: ld returned 1 exit status

And this is expected as :
$ file ecjx.o
ecjx.o: 80386 COFF executable not stripped - version 30821


-- 
   Summary: Cross build fails because native gcj needed to build
ecjx
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugtrack at roumenpetrov dot info
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-mingw32


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

[Bug c/42310] ICE on converting target-dependent PSImode variable

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2009-12-06 18:03 ---
Do not report bugs in modified versions of GCC here (for example,
versions with a target you have added).  Bug reports must be reproducible
using GCC built from unmodified FSF sources, without needing any
patches (which in this case you have not provided) applied.  If you think
there is a bug which is latent with all targets supported in the FSF
sources, send a patch with detailed explanation to gcc-patches.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/40850] double free in nested types with allocatable components

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2009-12-06 18:15 ---
Reduced testcase:

  type t1
integer, allocatable :: d1(:)
  end type t1
  type t2
type(t1), allocatable :: d2(:)
  end type t2
  type(t2) :: a, b

  a = new2( (/ new1((/1,1/)) /) )
  b = new2( (/ a%d2 , a%d2 /) )

contains
  pure type(t1) function new1(d1)
integer, intent(in) :: d1(:)
allocate(new1%d1(size(d1)))
new1%d1 = d1
  end function
  pure type(t2) function new2(d2)
type(t1), intent(in) :: d2(:)
allocate(new2%d2(size(d2)))
new2%d2 = d2
  end function
end

The dump still has about 800 lines - somewhat hard to tell what's going on.
Adding PaulT as CC.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org, pault at gcc dot gnu
   ||dot org
   Last reconfirmed|2009-07-25 07:32:47 |2009-12-06 18:15:24
   date||
Summary|"double free or corruption" |double free in nested types
   |returning derived types with|with allocatable components
   |allocatable components  |


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

[Bug fortran/41720] GNU Fortran fails configure test during build process

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-12-06 18:25 ---
(In reply to comment #1)
> >gfortran: Internal error: Segmentation Fault (program f951)
> 
> That normally means the version of GMP/MPFR you have installed are broken.

Any news here?


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug c/42312] New: config/mep/mep.c:2856: (error) Uninitialized variable: frame_size

[dcb314 at hotmail dot com]

I just ran the most excellent tool cppcheck, from sourceforge,
over the gcc source code. It said

config/mep/mep.c:2856: (error) Uninitialized variable: frame_size

I have checked the source code and I agree with cppcheck.

The source code is

  int frame_size;
  int really_need_stack_frame = frame_size;

which is fine as far as it goes, no problem in copying rubbish
from one place in the stack to another, but the next use of local
variable really_need_stack_frame is

really_need_stack_frame |= mep_assign_save_slots (reg_save_size);

which could lead to problems. Suggest initialise local variable
really_need_stack_frame to something else, perhaps zero would suffice.


-- 
   Summary: config/mep/mep.c:2856: (error) Uninitialized variable:
frame_size
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/42251] [4.5 Regression] failure detecting constant integral expression

[rwgk at yahoo dot com]

--- Comment #2 from rwgk at yahoo dot com  2009-12-06 19:18 ---
With a binary search in the svn history I found that the change below lead to
the regression.
I believe it is a major problem. Could someone confirm it?
I think it should be a P1.


r154768 | dodji | 2009-11-30 01:58:20 -0800 (Mon, 30 Nov 2009) | 9 lines

Fix PR c++/42069

gcc/cp/ChangeLog:
PR c++/42069
* pt.c (convert_template_argument): Strip typedefs from SCOPE_REFs.

gcc/testsuite/ChangeLog:
PR c++/42069
* g++.dg/template/typedef23.C: New test.



-- 


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

[Bug c++/42251] [4.5 Regression] failure detecting constant integral expression

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-12-06 19:35 
---
Let's CC Dodji...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu dot org


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

[Bug preprocessor/41943] include search path composition is bogus

[ktietz at gcc dot gnu dot org]

--- Comment #7 from ktietz at gcc dot gnu dot org  2009-12-06 20:01 ---
Well, this patch doesn't hurt in gcc.c, but doesn't solve the issue. Sorry for
posting this. incpath.c is the location to investigate in.

Kai


-- 


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

[Bug testsuite/42313] New: FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

[howarth at nitro dot med dot uc dot edu]

On i686-apple-darwin we are failing the testcase...

FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p

gcc-4 -v
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin10/4.5.0/lto-wrapper
Target: i686-apple-darwin10
Configured with: ../gcc-4.5-20091205/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --with-arch=nocona --with-tune=generic
--build=i686-apple-darwin10 --host=i686-apple-darwin10
--target=i686-apple-darwin10
Thread model: posix
gcc version 4.5.0 20091205 (experimental) (GCC)


-- 
   Summary: FAIL: gcc.target/i386/builtin-unreachable.c scan-
assembler-not %e[bs]p on i686 darwin
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: i686-apple-darwin*
  GCC host triplet: i686-apple-darwin*
GCC target triplet: i686-apple-darwin*


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

[Bug testsuite/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2009-12-06 
20:12 ---
Created an attachment (id=19242)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19242&action=view)
preprocessed source forgcc.target/i386/builtin-unreachable.c on
i686-apple-darwin10


-- 


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

[Bug testsuite/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-12-06 
20:13 ---
Created an attachment (id=19243)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19243&action=view)
assembly file for gcc.target/i386/builtin-unreachable.c on i686-apple-darwin10

Generated with...

/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20091205/gcc-4.5-20091205/gcc/testsuite/gcc.target/i386/builtin-unreachable.c
-O2 -fomit-frame-pointer --save-temps -S -o builtin-unreachable.s


-- 


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

[Bug testsuite/42314] New: FAIL: gcc.target/i386/funcspec-9.c scan-assembler vfmaddss

[howarth at nitro dot med dot uc dot edu]

On i686-apple-darwin*, we are failing...

FAIL: gcc.target/i386/funcspec-9.c scan-assembler vfmaddss

This also appears to be failing on linux as well...

http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00605.html

gcc-4 -v
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin10/4.5.0/lto-wrapper
Target: i686-apple-darwin10
Configured with: ../gcc-4.5-20091205/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --with-arch=nocona --with-tune=generic
--build=i686-apple-darwin10 --host=i686-apple-darwin10
--target=i686-apple-darwin10
Thread model: posix
gcc version 4.5.0 20091205 (experimental) (GCC)


-- 
   Summary: FAIL: gcc.target/i386/funcspec-9.c scan-assembler
vfmaddss
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: i686-apple-darwin*
  GCC host triplet: i686-apple-darwin*
GCC target triplet: i686-apple-darwin*


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

[Bug testsuite/42314] FAIL: gcc.target/i386/funcspec-9.c scan-assembler vfmaddss

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2009-12-06 
20:25 ---
Interestingly...

/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20091205/gcc-4.5-20091205/gcc/testsuite/gcc.target/i386/funcspec-9.c
-O2 -march=k8 -mfpmath=sse -msse2 --save-temps -S -o funcspec-9.s

produces the warning...

/sw/src/fink.build/gcc45-4.4.999-20091205/gcc-4.5-20091205/gcc/testsuite/gcc.target/i386/funcspec-9.c:15:2:
warning: #warning "__FMA4__ should have be defined after #pragma GCC target."


-- 


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

[Bug testsuite/42314] FAIL: gcc.target/i386/funcspec-9.c scan-assembler vfmaddss

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-12-06 
20:26 ---
Created an attachment (id=19244)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19244&action=view)
preprocessed source for gcc.target/i386/funcspec-9.c on i686-apple-darwin10


-- 


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

[Bug testsuite/42314] FAIL: gcc.target/i386/funcspec-9.c scan-assembler vfmaddss

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2009-12-06 
20:27 ---
Created an attachment (id=19245)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19245&action=view)
assembly file for gcc.target/i386/funcspec-9.c on i686-apple-darwin10

/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20091205/gcc-4.5-20091205/gcc/testsuite/gcc.target/i386/funcspec-9.c
  -O2 -march=k8 -mfpmath=sse -msse2 -S  -o funcspec-9.s


-- 


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

[Bug c++/42315] New: [4.3/4.4/4.5 Regression] ICE with invalid array initializer

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.1.2:


extern int x[];

int i = x[0];

int x[] = 0;


bug.cc:5:11: error: initializer fails to determine size of 'x'
bug.cc: In function 'void __static_initialization_and_destruction_0(int, int)':
bug.cc:3:12: internal compiler error: tree check: expected array_type, have
error_mark in array_ref_low_bound, at expr.c:6205
Please submit a full bug report, [etc.]


-- 
   Summary: [4.3/4.4/4.5 Regression] ICE with invalid array
initializer
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
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=42315

[Bug c++/42315] [4.3/4.4/4.5 Regression] ICE with invalid array initializer

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.5


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

[Bug debug/42288] please emit empty .debug_aranges section

[rth at gcc dot gnu dot org]

--- Comment #1 from rth at gcc dot gnu dot org  2009-12-06 22:31 ---
Reasonable.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-06 22:31:12
   date||


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

[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components

[janus at gcc dot gnu dot org]

--- Comment #17 from janus at gcc dot gnu dot org  2009-12-06 22:57 ---
Subject: Bug 41478

Author: janus
Date: Sun Dec  6 22:57:13 2009
New Revision: 155024

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155024
Log:
libgfortran/
2009-12-06  Janus Weil  

PR fortran/41478
PR fortran/42268
* intrinsics/pack_generic.c (pack): Add safety checks for the case that
'vector' is NULL.


gcc/testsuite/
2009-12-06  Janus Weil  

PR fortran/41478
PR fortran/42268
* gfortran.dg/intrinsic_pack_5.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_pack_5.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/pack_generic.c


-- 


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

[Bug fortran/42268] [4.4/4.5 Regression] derived type segfault with pack

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-12-06 22:57 ---
Subject: Bug 42268

Author: janus
Date: Sun Dec  6 22:57:13 2009
New Revision: 155024

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155024
Log:
libgfortran/
2009-12-06  Janus Weil  

PR fortran/41478
PR fortran/42268
* intrinsics/pack_generic.c (pack): Add safety checks for the case that
'vector' is NULL.


gcc/testsuite/
2009-12-06  Janus Weil  

PR fortran/41478
PR fortran/42268
* gfortran.dg/intrinsic_pack_5.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_pack_5.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/pack_generic.c


-- 


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

[Bug fortran/42268] [4.4/4.5 Regression] derived type segfault with pack

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-12-06 22:59 ---
Fixed on trunk with r155024. Will commit to 4.4 in a few days.


-- 


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

[Bug debug/42234] [4.5 Regression] internal compiler error: verify_ssa failed

[rth at gcc dot gnu dot org]

--- Comment #4 from rth at gcc dot gnu dot org  2009-12-07 00:00 ---
Subject: Bug 42234

Author: rth
Date: Sun Dec  6 23:59:52 2009
New Revision: 155025

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155025
Log:
PR debug/42234
* tree-ssa-dom.c (degenerate_phi_result): Check for NULL phi
argument earlier.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr42234.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c


-- 


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

[Bug debug/42234] [4.5 Regression] internal compiler error: verify_ssa failed

[rth at gcc dot gnu dot org]

--- Comment #5 from rth at gcc dot gnu dot org  2009-12-07 00:53 ---
Fixed.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/42316] New: `builddir-single/libiberty/pic/libiberty.a': No such file or directory

[iwamatsu at nigauri dot org]

`builddir-single/libiberty/pic/libiberty.a': No such file or directory
Because sh doesn't set PICFLAG=-fPIC on libiberty/configure.


-- 
   Summary:   `builddir-single/libiberty/pic/libiberty.a': No such
file or directory
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iwamatsu at nigauri dot org
 GCC build triplet: sh4-linux-gnu
  GCC host triplet: sh4-linux-gnu
GCC target triplet: sh4-linux-gnu


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

[Bug c/42316] `builddir-single/libiberty/pic/libiberty.a': No such file or directory

[iwamatsu at nigauri dot org]

--- Comment #1 from iwamatsu at nigauri dot org  2009-12-07 01:08 ---
Created an attachment (id=19246)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19246&action=view)
patch of revise this problem

We can revise this problem with this patch.  


-- 


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

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[jvdelisle at gcc dot gnu dot org]

--- Comment #17 from jvdelisle at gcc dot gnu dot org  2009-12-07 01:35 
---
I found the thread on this:

http://www.rhinocerus.net/forum/lang-fortran/585916-printing-64-bit-binary-number-gfortran-4-1-2-a.html

Richard Maine says:

" from the thread
> program test_acos
>
> implicit none
> real*8 :: x
> integer*8 :: i
> equivalence (i,x)
> i = z'3FE826E143045DBE'
> x = acos(x)
> write(*,1400) x
> 1400 format(B64)
> end program test_acos

> Fortran runtime error: Expected INTEGER for item 2 in formatted
> transfer, got REAL

That is correct. The B edit descriptor is only for integers.

> However, when I asked to print a 16-digit HEX by changing line 9 to
> 1400 format(Z16)
> it worked.

That is a nonstandard feature, probably for compatibility with some
existing codes that used a similar extension from before when the Z edit
descriptor was added to the standard. The standard only allows the Z
edit descriptor for integers, just like the B edit descriptor.

> How can I print the value of x at the end in binary?

Use the TRANSFER intrinsic to transfer the bits in x to integer type
before printing. Alternatively, you could use an equivalence. Such use
of equivalence is technically nonstandard, but that's a pretty fine
point of nitpicking; it will work. The TRANSFER solution is fully
standard conforming.

I note as an aside that your line

> i = z'3FE826E143045DBE'

also violates the standard. The standard allows hex constants only in
*VERY* limited contexts. In fact, for f95, it is allowed only in a DATA
statement; f2003 adds a few other places, but not many and not this one.

Although this usage is moderately common extension, the provision of the
standard that it violates is a constraint. This means that the compiler
is required to be able to diagnose the usage. Did you use the compiler's
option to check for violations of the standard. If not, I suggest doing
so. If you did and the compiler still did not complaint, than that would
count as a compiler bug and should be so reported."


-- 


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

[Bug debug/42288] please emit empty .debug_aranges section

[rth at gcc dot gnu dot org]

--- Comment #2 from rth at gcc dot gnu dot org  2009-12-07 02:04 ---
To be sure, you're keying off having *some* aranges entry with a reference
to a given CU in the debug_info section?  So:

Contents of the .debug_aranges section:

  Length:   28
  Version:  2
  Offset into .debug_info:  0x0
  Pointer Size: 8
  Segment Size: 0

AddressLength
  

is exactly what you're looking for?


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug middle-end/42303] Shift left as wide as mode is expanded into RTL as shift

[rth at gcc dot gnu dot org]

--- Comment #1 from rth at gcc dot gnu dot org  2009-12-07 02:35 ---
Shift by >= mode size is undefined at the C language level.
With -Wall, you'll get a warning for that.

At the gimple level, I'm pretty sure we leave it alone, since
we don't really know what else to do with it.

At the rtl level, it's controlled by SHIFT_COUNT_TRUNCATED.
On very few systems is a large shift actually evaluated to zero;
most will evaluate it as "x = y << (count & (bitsizeof(y)-1))".


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/42316] [SH] `builddir-single/libiberty/pic/libiberty.a': No such file or directory

[kkojima at gcc dot gnu dot org]

--- Comment #2 from kkojima at gcc dot gnu dot org  2009-12-07 02:37 ---
The patch in #1 looks OK to me, though we are in stage4 now
and the issue doesn't seem a regression in a strict sense.
The patch should be added to the queue for 4.6.  When the trunk
is reopened for such a change, could you please send the second
hunk of the patch with a libiberty/ChangeLog entry like as

* configure.ac (PICFLAG): Use -fPIC on SH hosts.
* configure: Regenerate.

to gcc-patches list?  The first hunk of the diff for configure
isn't required because that file is the generated one.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |target
 Ever Confirmed|0   |1
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-12-07 02:37:21
   date||
Summary|  `builddir-|[SH] `builddir-
   |single/libiberty/pic/libiber|single/libiberty/pic/libiber
   |ty.a': No such file or  |ty.a': No such file or
   |directory   |directory


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

[Bug middle-end/41674] [4.5 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main

[danglin at gcc dot gnu dot org]

--- Comment #7 from danglin at gcc dot gnu dot org  2009-12-07 02:55 ---
The failures still occur on hppa2.0w-hp-hpux11.11.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   GCC host triplet|hppa2.0w-hp-hpux11.11,  |hppa2.0w-hp-hpux11.11
   |hppa64-hp-hpux11.11 |
 GCC target triplet|hppa2.0w-hp-hpux11.11,  |hppa2.0w-hp-hpux11.11
   |hppa64-hp-hpux11.11 |
 Resolution|FIXED   |


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

[Bug c++/42251] [4.5 Regression] failure detecting constant integral expression

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-07 07:53:24
   date||


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

[Bug java/42276] When creating cross-gcj compiler, libjvm gets installed in system library paths

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-12-07 07:56 ---
Please send patches to the appropriate patches list and not attach it to the
bug report.


-- 


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