[Bug tree-optimization/58431] New: wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 58431
   Summary: wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
32-bit mode. 

This is a regression from 4.8.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130915 (experimental) [trunk revision 202599] (GCC) 
$ gcc-trunk -m32 -O2 small.c
$ a.out
$ gcc-4.8 -m32 -O3 small.c
$ a.out
$ gcc-trunk -m32 -O3 small.c
$ a.out
Aborted (core dumped)
$ 


---


char a, h;
int b, d, e, g, j, k;
volatile int c;
short i;

int
main ()
{
  int m = i ^= 1;
  for (b = 0; b < 1; b++)
{
  char o = m;
  g = k;
  j = j || c;
  if (a != o)
for (; d < 1; d++)
  ;
  else
{
  char *p = &h;
  *p = 1;
  for (; e; e++)
;
}
}

  if (h != 0)
__builtin_abort(); 

  return 0;
}

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
Author: burnus
Date: Mon Sep 16 06:42:02 2013
New Revision: 202609

URL: http://gcc.gnu.org/viewcvs?rev=202609&root=gcc&view=rev
Log:
2013-09-16  Tobias Burnus  

PR fortran/57697
* resolve.c (generate_component_assignments): Correctly handle
* the
case that the LHS is not allocated.

2013-09-16  Tobias Burnus  

PR fortran/57697
* gfortran.dg/defined_assignment_10.f90: Comment print
* statement.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/defined_assignment_10.f90

[Bug c++/58430] New: GCC hangs with 100% cpu core utilization during template compilation

[apiro...@manage-it.ru]

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

Bug ID: 58430
   Summary: GCC hangs with 100% cpu core utilization during
template compilation
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: apiro...@manage-it.ru

The next code leads hanging up of the compiler:

template
void test()
{
test();
test();
};

int main() 
{
test<0, 0>();
return 0;
}

[Bug target/58426] vax fails to compile gcov.c in stage1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou  ---
Use p debug_rtx(...) from within GDB instead of raw dumping RTXes...

[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start

[gang.chen at asianux dot com]

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

--- Comment #9 from Chen Gang  ---
Created attachment 30825
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30825&action=edit
Issue is within xgcc, can exclude cc1 by comparing the summary log between
gcc-4.8.0 and gcc-4.9.0.

By comparing the summary log between gcc-4.8.0 and gcc-4.9.0, the issue is
within xgcc, we can exclude cc1.

The attachment contents 3 files.

  err.diff: the gcc-4.9.0 summary log.
  correct.diff: the gcc-4.8.0 summary log.
  info.diff: my modification for gcc-4.9.0, so can print the related summary
log
   (the same modification for gcc-4.8.0)

I will continue to analyzing the details within xgcc, and also print more
related varaibles for analyzing.


Welcome any additional suggestions and completions, thanks.

[Bug target/58426] vax fails to compile gcov.c in stage1

[jbg...@lug-owl.de]

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

--- Comment #3 from Jan-Benedict Glaw  ---
Hm, the initial PLUS part looks a bit like what I ment to fix with a recent
patch. How old is your checkout? My fix was committed as r202600 /
git:3719e41cf6b9d. So I hope I didn't break something else. (This showed up in
GIT at Sun Sep 15 09:44:29 2013 +.)

For reference:

http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3719e41cf6b9d447d8e8e2971d6a459bc41853b2

--- a/gcc/config/vax/constraints.md
+++ b/gcc/config/vax/constraints.md
@@ -114,5 +114,6 @@

 (define_constraint "T"
 "@internal satisfies CONSTANT_P and, if pic is enabled, is not a
SYMBOL_REF, LABEL_REF, or CONST."
-   (ior (not (match_code "const,symbol_ref,label_ref"))
-   (match_test "!flag_pic")))
+  (and (match_test ("CONSTANT_P (op)"))
+   (ior (not (match_code "symbol_ref,label_ref,const"))
+   (match_test "!flag_pic"


As you seem to use 4.8.1, your GCC is older than my commit, so I think
backporting this patch would probably cure your problem. Give it a try!

[Bug target/58429] New: _Decimal64 support is broken on powerpc64 with the mode32 ABI (-m32 -mpowerpc64)

[vincent-gcc at vinc17 dot net]

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

Bug ID: 58429
   Summary: _Decimal64 support is broken on powerpc64 with the
mode32 ABI (-m32 -mpowerpc64)
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net

On gcc110.fsffrance.org:

$ cat ./decimal64.c
#include 
int main(void)
{
  _Decimal64 x = 1;
  if (x != x)
{
  printf ("Error!\n");
  return 1;
}
  else
{
  printf ("OK\n");
  return 0;
}
}

$ gcc -Wall -std=gnu99 -m32 -mpowerpc64 decimal64.c -o decimal64 -O
$ ./decimal64
OK
$ gcc -Wall -std=gnu99 -m32 -mpowerpc64 decimal64.c -o decimal64
$ ./decimal64
Error!

(The lack of error with -O is due to obvious optimization; a "volatile" on the
variable makes the error appear in every case.)

The problem doesn't appear with -m32 alone or -mpowerpc64 alone. Both are
needed to make it appear.

$ gcc --version
gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/58410] [4.8/4.9 Regression] Bogus uninitialized variable warning for allocatable derived type array function result

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-15
 CC||janus at gcc dot gnu.org
Summary|Bogus uninitialized |[4.8/4.9 Regression] Bogus
   |variable warning for|uninitialized variable
   |allocatable derived type|warning for allocatable
   |array function result   |derived type array function
   ||result
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
Confirmed with 4.8 and trunk. The bogus warning does not seem to appear with
4.7.3.

[Bug fortran/58355] [F03] ICE with TYPE, EXTENDS before parent TYPE defined

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
Draft patch:


Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c(revision 202599)
+++ gcc/fortran/decl.c(working copy)
@@ -7390,6 +7390,7 @@ syntax:


 /* Check a derived type that is being extended.  */
+
 static gfc_symbol*
 check_extended_derived_type (char *name)
 {
@@ -7401,14 +7402,15 @@ check_extended_derived_type (char *name)
   return NULL;
 }

+  extended = gfc_find_dt_in_generic (extended);
+
+  /* F08:C428.  */
   if (!extended)
 {
-  gfc_error ("No such symbol in TYPE definition at %C");
+  gfc_error ("Symbol '%s' at %C has not been previously defined", name);
   return NULL;
 }

-  extended = gfc_find_dt_in_generic (extended);
-
   if (extended->attr.flavor != FL_DERIVED)
 {
   gfc_error ("'%s' in EXTENDS expression at %C is not a "

[Bug sanitizer/58411] no_sanitize_undefined function attribute

[jan.sm...@alcatel-lucent.com]

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

--- Comment #3 from Jan Smets  ---
Eg, these attributes are useful too I think:

no_sanitize => disable ALL sanitize checks
sanitize -> enable ALL sanitize checks

no_sanitize_{address,undefined,vla...} => disable the specific check
sanitize_{address,undefined,vla...} => enable the specific check

Perhaps the enablers will not be used as much, but it might be useful for
people who want to instrument just one specific function.

The no_sanitize attribute could be used for sensitive code, eg, task scheduler
code, interrupt handlers where someone might choose to never instrument.

Thanks
- Jan

[Bug fortran/58425] Finalization: Segfault at runtime

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #2)
> At least with Crayftn, it seems to work (also with valgring/MALLOC_PERTURB_
> set).

Same result with pgf90 13.4-0. Additionally, I re-checked it with "ftn
-dynamic" and valgrind, which prints:
craylibs//google-perftools/src/tcmalloc.cc:632] Attempt to free invalid
pointer: 0x4084520

Thus, I close the bug as INVALID without having tried to investigate where the
bug occurs.

ALL: If you have reason to believe that it is (still) a compiler bug, feel free
to re-open the PR.

[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #12 from Jason Merrill  ---
The patches just checked in fix all the testcases that want to capture the
entire pack, but not the testcase in comment #9, which wants several different
lambdas each capturing an element of the pack.

[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  ---
Author: jason
Date: Sun Sep 15 19:34:42 2013
New Revision: 202605

URL: http://gcc.gnu.org/viewcvs?rev=202605&root=gcc&view=rev
Log:
Core DR 904
PR c++/41933
* parser.c (cp_parser_lambda_introducer): Handle variadic capture.
* lambda.c (add_capture): Handle variadic capture.
(add_default_capture, lambda_capture_field_type): Likewise.
(build_capture_proxy, register_capture_members): Likewise.
* pt.c (register_specialization): Allow FIELD_DECL.
(retrieve_specialization): Likewise.
(find_parameter_packs_r): Handle FIELD_DECL and VAR_DECL.
(tsubst_pack_expansion): Handle FIELD_DECL packs.
(gen_elem_of_pack_expansion_instantiation): Likewise.
(instantiate_class_template_1): Likewise.
(tsubst_decl, tsubst_copy): Likewise.
(tsubst_expr) [DECL_EXPR]: Handle capture proxy packs.
(tsubst_copy_and_build) [VAR_DECL]: Likewise.
* semantics.c (finish_non_static_data_member): Don't try to represent
the type of a COMPOUND_REF of a FIELD_DECL pack.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c

[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Sun Sep 15 19:34:34 2013
New Revision: 202604

URL: http://gcc.gnu.org/viewcvs?rev=202604&root=gcc&view=rev
Log:
PR c++/41933
* cp-tree.h (DECL_PACK_P): Replace FUNCTION_PARAMETER_PACK_P.
* cxx-pretty-print.c (direct_declarator): Adjust.
* decl2.c (cp_build_parm_decl): Adjust.
* pt.c (function_parameter_pack_p): Adjust.
(find_parameter_packs_r, push_template_decl_real): Adjust.
(tsubst_pack_expansion, tsubst_decl): Adjust.
(regenerate_decl_from_template, instantiate_decl): Adjust.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/pt.c

[Bug target/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mrs at gcc dot gnu.org
  Known to work||4.9.0
 Resolution|--- |FIXED
  Known to fail||4.7.0, 4.8.0

--- Comment #21 from mrs at gcc dot gnu.org  ---
Thanks for the report and the fix guys.  I'd be fine with back port, if someone
wants to develop and test it.

[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from mrs at gcc dot gnu.org  ---
Fixed.  Thanks fro the report and the fix guys.

[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

  Known to work||4.9.0

--- Comment #24 from mrs at gcc dot gnu.org  ---
Fixed.  Thanks fro the report and the fix guys.

[Bug fortran/58425] Finalization: Segfault at runtime

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
The code works when one adds a line to vortex.F90's manual_finalizer:

do while(associated(current%next))
  next => current%next ! start after break in chain
  deallocate(current)
  current=>next
  if (.not.associated(current)) exit !  ADDED
end do

Thus, at least locally, the program has a bug. The other question is whether
for the specific program, it should still work. At least with Crayftn, it seems
to work (also with valgring/MALLOC_PERTURB_ set). On the other hand, with ifort
it starts failing when MALLOC_PERTURB_ is set.

[Bug c++/58428] Compile error when declare nested class as a friend of another template class.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |normal

[Bug c++/58428] New: Compile error when declare nested class as a friend of another template class.

[ytj000 at gmail dot com]

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

Bug ID: 58428
   Summary: Compile error when declare nested class as a friend of
another template class.
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ytj000 at gmail dot com

Created attachment 30824
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30824&action=edit
broken code

OS: Archlinux x64 
Kernel: 3.10.10-1
GCC: Tried 4.8.1 and git version a5ceabb48759ee5937184d49e1773085e63f1130
command line: g++ bug.cpp

clang++ (3.3) could compile the following code successfully. However, gcc
failed to compile it and gave such error:

  bug.cpp: In instantiation of ‘class C’:
  bug.cpp:8:10:   required from here
  bug.cpp:4:28: error: no type named ‘B’ in ‘class A’
   template  class C {

--
template  class A {
  class B {};
};
template  class C {
  template  friend class A::B;
};
int main() {
  C();
}
--

[Bug bootstrap/58427] xgcc target compilation depends on installed libgcc_s.so

[rose.garcia-eggl2fk at yopmail dot com]

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

--- Comment #1 from Rose Garcia  ---
related binutils bugreport:
https://sourceware.org/bugzilla/show_bug.cgi?id=12549#c18

[Bug fortran/57696] [OOP] Defined assignment for components not used when those are ALLOCATABLE

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
See also PR 57697; the a similar needs to be also addressed when fixing this
bug, namely the case that for:
  var.foo.bar
"foo" is NULL/unallocated while "bar" appears in the defined assignment.

See also PR46897 for another missing feature.

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #10)
> The patch of comment 9 fixes most of the issues. However, some are still
> left. Cf. http://gcc.gnu.org/ml/fortran/2012-11/msg00072.html

See also PR57696. The not-supported part is currently rejected with:

  if (depth > 1)
{
  gfc_warning ("TODO: type-bound defined assignment(s) at %L not "
   "done because multiple part array references would "
   "occur in intermediate expressions.", &(*code)->loc);
  return;
}

[Bug target/58426] vax fails to compile gcov.c in stage1

[martin at netbsd dot org]

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

--- Comment #2 from Martin Husemann  ---
The more interesting XEXP(x, 0) of that rtx is the one triggering the failure:

$15 = {code = REG, mode = SImode, jump = 0, call = 0, unchanging = 0, 
  volatil = 0, in_struct = 0, used = 0, frame_related = 1, return_val = 0, 
  u = {fld = {{rt_int = 13, rt_uint = 13, 
rt_str = 0xd , rt_rtx = 0xd, 
rt_rtvec = 0xd, rt_type = TQmode, rt_addr_diff_vec_flags = {
  min_align = 13, base_after_vec = 0, min_after_vec = 0, 
  max_after_vec = 0, min_after_base = 0, max_after_base = 0, 
  offset_unsigned = 0, scale = 0}, rt_cselib = 0xd, rt_tree = 0xd, 
rt_bb = 0xd, rt_mem = 0xd, rt_reg = 0xd, rt_constant = 0xd, 
rt_cfi = 0xd}}, hwint = {13}, block_sym = {fld = {{rt_int = 13, 
  rt_uint = 13, rt_str = 0xd , 
  rt_rtx = 0xd, rt_rtvec = 0xd, rt_type = TQmode, 
  rt_addr_diff_vec_flags = {min_align = 13, base_after_vec = 0, 
min_after_vec = 0, max_after_vec = 0, min_after_base = 0, 
max_after_base = 0, offset_unsigned = 0, scale = 0}, 
  rt_cselib = 0xd, rt_tree = 0xd, rt_bb = 0xd, rt_mem = 0xd, 
  rt_reg = 0xd, rt_constant = 0xd, rt_cfi = 0xd}, {rt_int = 13, 
  rt_uint = 13, rt_str = 0xd , 
  rt_rtx = 0xd, rt_rtvec = 0xd, rt_type = TQmode, 
  rt_addr_diff_vec_flags = {min_align = 13, base_after_vec = 0, 
min_after_vec = 0, max_after_vec = 0, min_after_base = 0, 
max_after_base = 0, offset_unsigned = 0, scale = 0}, 
  rt_cselib = 0xd, rt_tree = 0xd, rt_bb = 0xd, rt_mem = 0xd, 
  rt_reg = 0xd, rt_constant = 0xd, rt_cfi = 0xd}, {rt_int = 0, 
  rt_uint = 0, rt_str = 0x0, rt_rtx = 0x0, rt_rtvec = 0x0, 
  rt_type = VOIDmode, rt_addr_diff_vec_flags = {min_align = 0, 
base_after_vec = 0, min_after_vec = 0, max_after_vec = 0, 
min_after_base = 0, max_after_base = 0, offset_unsigned = 0, 
scale = 0}, rt_cselib = 0x0, rt_tree = 0x0, rt_bb = 0x0, 
  rt_mem = 0x0, rt_reg = 0x0, rt_constant = 0x0, rt_cfi = 0x0}}, 
  block = 0x40060026, offset = 12}, rv = {cl = 1, decimal = 1, sign = 1, 
  signalling = 0, canonical = 0, uexp = 0, sig = {13, 0, 1074135078, 12, 
12}}, fv = {data = {low = 13, high = 13}, mode = VOIDmode}}}

[Bug bootstrap/58427] New: xgcc target compilation depends on installed libgcc_s.so

[rose.garcia-eggl2fk at yopmail dot com]

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

Bug ID: 58427
   Summary: xgcc target compilation depends on installed
libgcc_s.so
   Product: gcc
   Version: 4.5.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rose.garcia-eggl2fk at yopmail dot com

during target compilation (for example libssp or libstdc++) xgcc is invoked
with the usual specs:

/src/build/gcc454/gcc-4.5.4/host-x86_64-unknown-linux-gnu/gcc/xgcc
-B/src/build/gcc454/gcc-4.5.4/host-x86_64-unknown-linux-gnu/gcc/ ... conftest.c

specs:
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed -lgcc_s
--no-as-needed}%{shared-
libgcc:-lgcc_s%{!shared: -lgcc

in case binutils ld decides for some reason that libgcc_s is needed, it will
hardcode a reference to libgcc_s into DT_NEEDED.
binutils itself finds the libgcc_s.so in the -B path, and adds it, but
launching the resulting executable will fail because the *dynamic linker* has
no way of knowing that it should look for the .so in
host-x86_64-unknown-linux-gnu/gcc.

this causes the configure check for libssp and libstdc++ to fail with
"C compiler cannot create working executables".

possible solutions:
1) the spec file used by xgcc to compile target libraries should use
libgcc_eh.a instead of libgcc_s.so
2) LD_LIBRARY_PATH has to be set to host-x86_64-unknown-linux-gnu/gcc (the -B
path) so the dynamic linker can find libgcc_s.so

imo, 1) is preferable.

[Bug target/58426] vax fails to compile gcov.c in stage1

[martin at netbsd dot org]

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

--- Comment #1 from Martin Husemann  ---
The error happens here:

#1  0x002d15ca in output_addr_const (file=0x7f5b79c8, 
x=0x7f10a250, 2136701384, 2131796560) at ../../gcc-4.8.1/gcc/final.c:3877
#2  0x002d1466 in output_addr_const (file=0x7f5b79c8, 
x=0x7ecb52a0, 2136701384, 2127254176) at ../../gcc-4.8.1/gcc/final.c:3837
#3  0x00762eb4 in print_operand (file=0x7f5b79c8, x=0x7ecb52a0, 
code=0, 2136701384, 2127254176, 0)
at ../../gcc-4.8.1/gcc/config/vax/vax.c:557
#4  0x00520a05 in default_print_operand (stream=0x7f5b79c8, x=0x7ecb52a0, 
code=0, 2136701384, 2127254176, 0) at ../../gcc-4.8.1/gcc/targhooks.c:327
#5  0x002d1a04 in output_operand (x=0x7ecb52a0, code=0, 2127254176, 0)
at ../../gcc-4.8.1/gcc/final.c:3735
#6  0x002d1dcb in output_asm_insn (templ=0x9245a0 "addl3 %1,%2,%0", 
operands=0xc7fee0, 9586080, 13106912) at ../../gcc-4.8.1/gcc/final.c:3633
#7  0x002d45b1 in final_scan_insn (insn=0x7ec4ce58, file=0x7f5b79c8, 
optimize_p=1, nopeepholes=0, 
seen=0x7fffe438, 2126827096, 2136701384, 1, 0, 2147476536)
at ../../gcc-4.8.1/gcc/final.c:2931
#8  0x002d4a08 in final (first=0x7ec2d9c0, file=0x7f5b79c8, 
optimize_p=1, 2126698944, 2136701384, 1)
at ../../gcc-4.8.1/gcc/final.c:1967

and the expression passed by vax.c to output_addr_const() is:

$3 = {code = PLUS, mode = SImode, jump = 0, call = 0, unchanging = 0, 
  volatil = 0, in_struct = 0, used = 0, frame_related = 0, return_val = 0, 
  u = {fld = {{rt_int = 2131796560, rt_uint = 2131796560, 
rt_str = 0x7f10a250 "&", rt_rtx = 0x7f10a250, rt_rtvec = 0x7f10a250, 
rt_type = 2131796560, rt_addr_diff_vec_flags = {min_align = 80, 
  base_after_vec = 0, min_after_vec = 1, max_after_vec = 0, 
  min_after_base = 0, max_after_base = 0, offset_unsigned = 1, 
  scale = 16}, rt_cselib = 0x7f10a250, rt_tree = 0x7f10a250, 
rt_bb = 0x7f10a250, rt_mem = 0x7f10a250, rt_reg = 0x7f10a250, 
rt_constant = 0x7f10a250, rt_cfi = 0x7f10a250}}, hwint = {2131796560}, 
block_sym = {fld = {{rt_int = 2131796560, rt_uint = 2131796560, 
  rt_str = 0x7f10a250 "&", rt_rtx = 0x7f10a250, rt_rtvec = 0x7f10a250, 
  rt_type = 2131796560, rt_addr_diff_vec_flags = {min_align = 80, 
base_after_vec = 0, min_after_vec = 1, max_after_vec = 0, 
min_after_base = 0, max_after_base = 0, offset_unsigned = 1, 
scale = 16}, rt_cselib = 0x7f10a250, rt_tree = 0x7f10a250, 
  rt_bb = 0x7f10a250, rt_mem = 0x7f10a250, rt_reg = 0x7f10a250, 
  rt_constant = 0x7f10a250, rt_cfi = 0x7f10a250}, {
  rt_int = 2126996200, rt_uint = 2126996200, 
  rt_str = 0x7ec762e8 "\037", rt_rtx = 0x7ec762e8, 
  rt_rtvec = 0x7ec762e8, rt_type = 2126996200, 
  rt_addr_diff_vec_flags = {min_align = 232, base_after_vec = 0, 
min_after_vec = 1, max_after_vec = 0, min_after_base = 0, 
max_after_base = 0, offset_unsigned = 1, scale = 199}, 
  rt_cselib = 0x7ec762e8, rt_tree = 0x7ec762e8, rt_bb = 0x7ec762e8, 
  rt_mem = 0x7ec762e8, rt_reg = 0x7ec762e8, rt_constant = 0x7ec762e8, 
  rt_cfi = 0x7ec762e8}, {rt_int = 393266, rt_uint = 393266, 
  rt_str = 0x60032 "ded_initEjj", rt_rtx = 0x60032, 
  rt_rtvec = 0x60032, rt_type = 393266, rt_addr_diff_vec_flags = {
min_align = 50, base_after_vec = 0, min_after_vec = 0, 
max_after_vec = 0, min_after_base = 0, max_after_base = 0, 
offset_unsigned = 0, scale = 6}, rt_cselib = 0x60032, 
  rt_tree = 0x60032, rt_bb = 0x60032, rt_mem = 0x60032, 
  rt_reg = 0x60032, rt_constant = 0x60032, rt_cfi = 0x60032}}, 
  block = 0x7f10a250, offset = 2126996200}, rv = {cl = 0, decimal = 0, 
  sign = 0, signalling = 1, canonical = 0, uexp = 33309321, sig = {
2126996200, 393266, 2131796560, 2126996200, 23}}, fv = {data = {
low = 2131796560, high = 2126996200}, mode = 393266}}}

[Bug target/58426] New: vax fails to compile gcov.c in stage1

[martin at netbsd dot org]

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

Bug ID: 58426
   Summary: vax fails to compile gcov.c in stage1
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at netbsd dot org

Compilation stops with:

../../../gcc-4.8.1/libgcc/libgcov.c:827:1: internal compiler error:
output_operand: invalid expression as operand

(will dig into it and provide more info)

[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start

[gang.chen at asianux dot com]

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

--- Comment #8 from Chen Gang  ---
For gcc-4.9.0, I got summary trace for it (call stack for cc1, how many the
related loopings during calling flow), hope it may be a little useful. (I will
do the same thing for gcc-4.8.0, and compare them).

And it seems: gdb can not print the variables' value when "g++ -g -Wall
-static-libstdc++ -static-libgcc" which is effect with cc1 and xgcc.

If can let gdb print the vaiables' value, life will be a little easier (don't
need dump the related variables' values mannually).

Welcome any additional suggestions or completions.

(gdb) bt
#0  maybe_record_trace_start(rtx_def*, rtx_def*) () at
../../gcc-4.9.0/gcc/dwarf2cfi.c:2184
#1  0x006da82b in scan_trace(dw_trace_info*) () at
../../gcc-4.9.0/gcc/dwarf2cfi.c:2399
#2  0x006dadeb in create_cfi_notes() () at
../../gcc-4.9.0/gcc/dwarf2cfi.c:2557
#3  0x006db8e5 in execute_dwarf2_frame() () at
../../gcc-4.9.0/gcc/dwarf2cfi.c:2912
#4  0x006dc5e3 in (anonymous namespace)::pass_dwarf2_frame::execute()
() at ../../gcc-4.9.0/gcc/dwarf2cfi.c:3408
#5  0x00989d20 in execute_one_pass(opt_pass*) () at
../../gcc-4.9.0/gcc/passes.c:2201
#6  0x00989f41 in execute_pass_list(opt_pass*) () at
../../gcc-4.9.0/gcc/passes.c:2257
#7  0x00989f72 in execute_pass_list(opt_pass*) () at
../../gcc-4.9.0/gcc/passes.c:2258
#8  0x00989f72 in execute_pass_list(opt_pass*) () at
../../gcc-4.9.0/gcc/passes.c:2258
#9  0x0068cbbd in expand_function(cgraph_node*) () at
../../gcc-4.9.0/gcc/cgraphunit.c:1723
#10 0x0068d085 in expand_all_functions() () at
../../gcc-4.9.0/gcc/cgraphunit.c:1828
#11 0x0068d9e9 in compile() () at ../../gcc-4.9.0/gcc/cgraphunit.c:2165
#12 0x0068db62 in finalize_compilation_unit() () at
../../gcc-4.9.0/gcc/cgraphunit.c:2242
#13 0x005225ac in c_write_global_declarations() () at
../../gcc-4.9.0/gcc/c/c-decl.c:10125
#14 0x00a4c25b in compile_file() () at ../../gcc-4.9.0/gcc/toplev.c:560
#15 0x00a4e22e in do_compile() () at ../../gcc-4.9.0/gcc/toplev.c:1891
#16 0x00a4e3a3 in toplev_main(int, char**) () at
../../gcc-4.9.0/gcc/toplev.c:1969
#17 0x00e5b390 in main ()


(gdb) r -Os -mint32 -mh -fomit-frame-pointer -g /tmp/ana/namei/namei.c
Starting program: /android/src/build-gcc-h8300g/gcc/xgcc -Os -mint32 -mh
-fomit-frame-pointer -g /tmp/ana/namei/namei.c

gchen_tag: progname: xgcc, string: cc1

Detaching after fork from child process 8965.

gchen_tag: execute_pass_list: level: 1, count: 0.

gchen_tag: execute_pass_list: level: 1, count: 1.

gchen_tag: execute_pass_list: level: 1, count: 2.

gchen_tag: execute_pass_list: level: 1, count: 3.

gchen_tag: execute_pass_list: level: 1, count: 4.

gchen_tag: execute_pass_list: level: 1, count: 5.

gchen_tag: execute_pass_list: level: 1, count: 6.

gchen_tag: execute_pass_list: level: 1, count: 7.

gchen_tag: execute_pass_list: level: 1, count: 8.

gchen_tag: execute_pass_list: level: 1, count: 9.

gchen_tag: execute_pass_list: level: 1, count: 10.

gchen_tag: execute_pass_list: level: 1, count: 11.

gchen_tag: execute_pass_list: level: 1, count: 12.

gchen_tag: execute_pass_list: level: 1, count: 0.

gchen_tag: execute_pass_list: level: 1, count: 1.

gchen_tag: execute_pass_list: level: 1, count: 2.

gchen_tag: execute_pass_list: level: 1, count: 3.

gchen_tag: execute_pass_list: level: 1, count: 4.

gchen_tag: execute_pass_list: level: 1, count: 5.

gchen_tag: execute_pass_list: level: 1, count: 6.

gchen_tag: execute_pass_list: level: 2, count: 0.

gchen_tag: execute_pass_list: level: 2, count: 1.

gchen_tag: execute_pass_list: level: 2, count: 2.

gchen_tag: execute_pass_list: level: 2, count: 3.

gchen_tag: execute_pass_list: level: 2, count: 4.

gchen_tag: execute_pass_list: level: 2, count: 5.

gchen_tag: execute_pass_list: level: 2, count: 6.

gchen_tag: execute_pass_list: level: 2, count: 7.

gchen_tag: execute_pass_list: level: 2, count: 8.

gchen_tag: execute_pass_list: level: 2, count: 9.

gchen_tag: execute_pass_list: level: 2, count: 10.

gchen_tag: execute_pass_list: level: 2, count: 11.

gchen_tag: execute_pass_list: level: 2, count: 12.

gchen_tag: execute_pass_list: level: 2, count: 13.

gchen_tag: execute_pass_list: level: 2, count: 14.

gchen_tag: execute_pass_list: level: 2, count: 15.

gchen_tag: execute_pass_list: level: 2, count: 16.

gchen_tag: execute_pass_list: level: 1, count: 7.

gchen_tag: execute_pass_list: level: 1, count: 8.

gchen_tag: execute_pass_list: level: 1, count: 9.

gchen_tag: execute_pass_list: level: 1, count: 10.

gchen_tag: execute_pass_list: level: 1, count: 0.

gchen_tag: execute_pass_list: level: 2, count: 0.

gchen_tag: execute_pass_list: level: 2, count: 1.

gchen_tag: execute_pass_list: level: 2, count: 2.

gchen_tag: execute_pass_list: level: 2, count: 3.

gchen_tag: execute_pass_list: level: 2, count: 4.

gchen_tag: execute_pass_list: level: 2, count: 5.

gchen_tag

[Bug fortran/58356] ICE with finalization and type extension

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-15
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed at revision 202590.

[Bug fortran/58425] Finalization: Segfault at runtime

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Works for me:

[macbook] f90/bug% gfcc ~/test/Rouson/ssdSource/chapter05/hermetic/hermetic.F90
-c -Ofast
[macbook] f90/bug% gfcc ~/test/Rouson/ssdSource/chapter05/hermetic/vortex.F90
-c -Ofast
[macbook] f90/bug% gfcc ~/test/Rouson/ssdSource/chapter05/hermetic/main.F90
hermetic.o vortex.o -Ofast
[macbook] f90/bug% a.out
   1.   0.   0.
  0.707106769  0.707106769   0.
  -4.37113883E-08   1.   0.
 -0.707106769  0.707106769   0.
  -1.  -8.74227766E-08   0.
 -0.707106650 -0.707106888   0.
   1.19248806E-08  -1.   0.
  0.707107008 -0.707106531   0.
[macbook] f90/bug% gfcc -v
Using built-in specs.
COLLECT_GCC=gfcc
COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.9c/libexec/gcc/x86_64-apple-darwin10.8.0/4.9.0/lto-wrapper
Target: x86_64-apple-darwin10.8.0
Configured with: ../_clean/configure --prefix=/opt/gcc/gcc4.9c
--enable-languages=c,c++,fortran,objc,obj-c++,java,ada,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
Thread model: posix
gcc version 4.9.0 20130914 (experimental) [trunk revision 202590] (GCC) 

I also get the same output with -flto added or without -Ofast.

[Bug fortran/58356] ICE with finalization and type extension

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
Segfaults at:

at ../../gcc/fortran/class.c:1884
1884  if (fini->proc_tree->n.sym->attr.elemental)

The problem is that fini != NULL but fini->proc_tree == NULL. Note that:
fini->proc_sym->name is available with the name cfld

[Bug fortran/58425] New: Finalization: Segfault at runtime

[burnus at gcc dot gnu.org]

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

Bug ID: 58425
   Summary: Finalization: Segfault at runtime
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

The code at ssdSource/chapter05/hermetic of http://www.cambridge.org/rouson
fails at run-time with:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
#3  0x401169 in __vortex_module_MOD_finalize
#4  0x400D92 in __vortex_module_MOD___final_vortex_module_Vortex
#5  0x4011C9 in __vortex_module_MOD_finalize
#6  0x400D92 in __vortex_module_MOD___final_vortex_module_Vortex
#7  0x401138 in __vortex_module_MOD_manual_finalizer
#8  0x400B37 in MAIN__ at main.F90:?


It works with other compilers. (As finalization is new, it doesn't count as
regression.)

[Bug fortran/58355] [F03] ICE with TYPE, EXTENDS before parent TYPE defined

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-15
 CC||janus at gcc dot gnu.org
Summary|ICE with TYPE, EXTENDS  |[F03] ICE with TYPE,
   |before parent TYPE defined  |EXTENDS before parent TYPE
   ||defined
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed with 4.7, 4.8 and trunk. Slightly reduced test case:


module ct
  public :: t1

  type, extends(t1) :: t2
  end type

  type :: t1
  end type
end


It seems to be invalid according to C428 in F08:

R427 type-attr-spec is ABSTRACT
or access-spec
or BIND (C)
or EXTENDS ( parent-type-name )

C428 (R427) A parent-type-name shall be the name of a previously defined
extensible type (4.5.7).


Btw, leaving out the PUBLIC statement, one gets this error:

  type, extends(t1) :: t2
   1
Error: No such symbol in TYPE definition at (1)


... which is in principle correct, but a bit ill-worded.


Both variants should be rejected with the same (improved) wording.

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
Author: burnus
Date: Sun Sep 15 10:54:10 2013
New Revision: 202601

URL: http://gcc.gnu.org/viewcvs?rev=202601&root=gcc&view=rev
Log:
2013-09-15  Tobias Burnus  

PR fortran/57697
* resolve.c (generate_component_assignments): Handle unallocated
LHS with defined assignment of components.

2013-09-15  Tobias Burnus  

PR fortran/57697
* gfortran.dg/defined_assignment_10.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/defined_assignment_10.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug target/58424] New: [ARM]gcc.target/arm/pr42575.c failed on arm

[amker.cheng at gmail dot com]

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

Bug ID: 58424
   Summary: [ARM]gcc.target/arm/pr42575.c failed on arm
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker.cheng at gmail dot com

gcc is at revision r202599 and is configured as:
../gcc/configure
build=i686-linux-gnu
host=i686-linux-gnu
target=arm-none-eabi
prefix=.../trunk-orig/target/
disable-decimal-float
disable-libffi
disable-libgomp
disable-libmudflap
disable-libquadmath
disable-libssp
disable-libstdcxx-pch
disable-nls
disable-shared
disable-threads
disable-tls
with-gnu-as
with-gnu-ld
with-newlib
with-headers=yes
with-sysroot=.../trunk-orig/target/arm-none-eabi
with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
with-mode=thumb
with-arch=armv7-m
disable-multilib
enable-lto
enable-languages=c,c++,lto

The source code is:
/* { dg-options "-O2" }  */
/* Make sure RA does good job allocating registers and avoids
   unnecessary moves.  */
/* { dg-final { scan-assembler-not "mov" } } */

long long longfunc(long long x, long long y)
{
  return x * y;
}


The generated assembly is:
longfunc:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mulr3, r0, r3
push{r4, r5}
mlar1, r2, r1, r3
umullr4, r5, r0, r2
addr5, r5, r1
movr0, r4
movr1, r5
pop{r4, r5}
bxlr
.sizelongfunc, .-longfunc

But I think the case would fail for other configurations too.

[Bug target/58423] New: [ARM]ICE with shrink-wrap-sibcall.c on a15/neon/hard

[amker.cheng at gmail dot com]

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

Bug ID: 58423
   Summary: [ARM]ICE with shrink-wrap-sibcall.c on a15/neon/hard
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker.cheng at gmail dot com

GCC ICEed with shrink-wrap-sibcall.c on a15 with below command line:
./arm-none-eabi-gcc -O2 -marm -mcpu=cortex-a15 -mfpu=neon -mfloat-abi=hard
shrink-wrap-sibcall.c -S -o shrink-wrap-sibcall.S -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -g

ICE msg is:

shrink-wrap-sibcall.c: In function 'baz':
shrink-wrap-sibcall.c:26:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2218
0x82bfe41 maybe_record_trace_start
../../gcc/gcc/dwarf2cfi.c:2218
0x82c22f2 scan_trace
../../gcc/gcc/dwarf2cfi.c:2395
0x82c2a25 create_cfi_notes
../../gcc/gcc/dwarf2cfi.c:2549
0x82c2a25 execute_dwarf2_frame
../../gcc/gcc/dwarf2cfi.c:2904
0x82c2a25 execute
../../gcc/gcc/dwarf2cfi.c:3400
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


GCC is at revision r202599 and the ICE relates to a15/neon/hard-abi, no matter
how it is configured for arm.