[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
The 4.8 version of the patch bootstrapped/regtested fine on both s390x-linux
and s390-linux, both configured with --with-arch=z10 --with-tune=zEC12.
Andreas, could you please bootstrap/regtest some 4.9 version of the patch?

[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer

[amodra at gmail dot com]

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

--- Comment #9 from Alan Modra  ---
Once upon a time I understood this code quite well, but it's been a while since
I looked at it in detail, and I'd forgotten that inout gets split to separate
input and output operands if a register is allowed.

So the code isn't wrong, but there was no need to do anything special for
inout.  I'll commit a cleanup as obvious.

[Bug c++/58569] Compilation error when a class contains multiple std::function

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
We badly need a reduced testcase for this. The issue doesn't seem to involve
std::function in a fundamental way, seems more about using
std::is_convertible inside foo.

Adding Daniel in CC, in case he wants to help for the reduction...

[Bug target/58587] Bootstrap error with ada with -mcpu=power7

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-01
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/33911] attribute deprecated vs. templates

[eraman at google dot com]

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

Easwaran Raman  changed:

   What|Removed |Added

 CC||eraman at google dot com

--- Comment #10 from Easwaran Raman  ---
For template member functions, is concatenating the parsed attributes to
prefix_attributes and passing them to grokfield a valid fix? This patch works
for a small test case I have and I wonder if this is correct:

Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c(revision 202261)
+++ gcc/cp/parser.c(working copy)
@@ -16489,7 +16489,7 @@ cp_parser_init_declarator (cp_parser* parser,
   decl = grokfield (declarator, decl_specifiers,
 initializer, !is_non_constant_init,
 /*asmspec=*/NULL_TREE,
-prefix_attributes);
+chainon (prefix_attributes, attributes));
   if (decl && TREE_CODE (decl) == FUNCTION_DECL)
 cp_parser_save_default_args (parser, decl);
 }

[Bug c/55570] [4.7/4.8 regression] Undefined variable in alignment compiler directive causes compiler segfault

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dbruening at acm dot org

--- Comment #8 from Andrew Pinski  ---
*** Bug 58588 has been marked as a duplicate of this bug. ***

[Bug c/58588] "internal compiler error: Segmentation fault" from aligned attribute with undefined token for size

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
A dup of bug 55570.

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

[Bug c/58588] New: "internal compiler error: Segmentation fault" from aligned attribute with undefined token for size

[dbruening at acm dot org]

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

Bug ID: 58588
   Summary: "internal compiler error: Segmentation fault" from
aligned attribute with undefined token for size
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dbruening at acm dot org
  Host: Fedora 17
Target: x86_64-redhat-linux
 Build: gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)

Created attachment 30942
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30942&action=edit
"Preprocessed source stored into /tmp/ccmaOY7z.out file, please attach this to
your bugreport."

This one-line file reproduces the problem:

int __attribute__ ((aligned (UNDEFINED_VALUE))) foo;

It results in "internal compiler error: Segmentation fault" as shown below:

% gcc -v -save-temps -c gcc-crash.c 
Using built-in specs.
COLLECT_GCC=gcc
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 --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--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-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1 -E -quiet -v gcc-crash.c
-mtune=generic -march=x86-64 -fpch-preprocess -o gcc-crash.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1 -fpreprocessed gcc-crash.i
-quiet -dumpbase gcc-crash.c -mtune=generic -march=x86-64 -auxbase gcc-crash
-version -o gcc-crash.s
GNU C (GCC) version 4.7.2 20120921 (Red Hat 4.7.2-2) (x86_64-redhat-linux)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.7.2 20120921 (Red Hat 4.7.2-2) (x86_64-redhat-linux)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1ddc7c1a4fba2159f711c3e228ac3970
gcc-crash.c:1:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccmaOY7z.out file, please attach this to
your bugreport.

% cat /tmp/ccmaOY7z.out
// /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1 -fpreprocessed gcc-crash.i
-quiet -dumpbase gcc-crash.c -mtune=generic -march=x86-64 -auxbase gcc-crash
-version -o - -frandom-seed=0
# 1 "gcc-crash.c"
# 1 ""
# 1 "gcc-crash.c"
int __attribute__ ((aligned (UNDEFINED_VALUE))) foo;

% cat gcc-crash.i
# 1 "gcc-crash.c"
# 1 ""
# 1 "gcc-crash.c"
int __attribute__ ((aligned (UNDEFINED_VALUE))) foo;


I do not have access to a more recent gcc so I'm not sure whether this has been
fixed since 4.7.2.

[Bug target/58587] Bootstrap error with ada with -mcpu=power7

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 30941
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30941&action=edit
pr58587.tar.bz2

I've tried to create a C small reproducer from scratch, but just using TImode
seems to work, reload decides to put the extra large constant into memory, and
similarly say:
typedef int TI __attribute__((mode (TI)));
void
foo (void)
{
  asm volatile ("" : : "v" (((TI) 0x7fffUL) << 4));
}

[Bug target/58587] New: Bootstrap error with ada with -mcpu=power7

[jakub at gcc dot gnu.org]

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

Bug ID: 58587
   Summary: Bootstrap error with ada with -mcpu=power7
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: meissner at gcc dot gnu.org

Trying to bootstrap gcc (4.8-RH, but reproduced also with the trunk) with
a ppc64 compiler configured --with-cpu=power7 ICEs during stage1 while par.adb
is being compiled at -O0.
Reproduced even with a cross-compiler from x86_64-linux, will attach a tarball
with all the required files.

../gnat1 -I. -gnatwa -quiet -nostdinc -m64 -gnatpg -gnatwns -mtune=power7
-mcpu=power7 par.adb -o /tmp/par.s
par.adb: In function ‘Par’:
par.adb:1604:5: error: insn does not satisfy its constraints:
(insn 1505 719 1504 (set (reg:TI 77 0)
(const_double -16 [0xfff0] 7 [0x7] 0 [0] 0 [0]))
par.adb:1509 721 {*vsx_movti_64bit}
 (nil))
+===GNAT BUG DETECTED==+
| 4.9.0 20130927 (experimental) (powerpc64-linux) GCC error:   |
| in extract_constrain_insn_cached, at recog.c:2076|
| Error detected around par.adb:1604:5 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

[Bug fortran/58586] New: ICE with derived type with a polymorphic allocatable component passed by value

[vladimir.fuka at gmail dot com]

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

Bug ID: 58586
   Summary: ICE with derived type with a polymorphic allocatable
component passed by value
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com

> gfortran -c ice3.f90
ice3.f90: In function ‘sub’:
ice3.f90:29:0: internal compiler error: Segmentation fault
call add(b())
 ^
0x87dfdf crash_signal
../../gcc-4.8-20130425/gcc/toplev.c:332
0x5b19b0 structure_alloc_comps
../../gcc-4.8-20130425/gcc/fortran/trans-array.c:7440
0x5c97ca gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc-4.8-20130425/gcc/fortran/trans-expr.c:4621
0x5ede84 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc-4.8-20130425/gcc/fortran/trans-stmt.c:406
0x5a7761 trans_code
../../gcc-4.8-20130425/gcc/fortran/trans.c:1500
0x5c4a02 gfc_generate_function_code(gfc_namespace*)
../../gcc-4.8-20130425/gcc/fortran/trans-decl.c:5397
0x568770 translate_all_program_units
../../gcc-4.8-20130425/gcc/fortran/parse.c:4474
0x568770 gfc_parse_file()
../../gcc-4.8-20130425/gcc/fortran/parse.c:4688
0x5a3a85 gfc_be_parse_file
../../gcc-4.8-20130425/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

module mod

  type,abstract :: a
  end type

  type :: b
 class(a),allocatable :: a
  end type

  interface b
module procedure b_init
  end interface

contains

  subroutine add(c)
type(b),value :: c
  end subroutine

  function b_init() result(res)
type(b) :: res
  end function

end module mod

subroutine  sub
   use mod

   call add(b())

end subroutine  sub

[Bug middle-end/58585] New: [4.9 Regression] ICE in ipa with virtual inheritance

[reichelt at gcc dot gnu.org]

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

Bug ID: 58585
   Summary: [4.9 Regression] ICE in ipa with virtual inheritance
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following valid code snippet triggers an ICE on trunk when compiled with
"-O2 -fPIC":


struct A
{
  virtual void foo() {}
  void bar();
};
void A::bar() { foo(); }

struct B : virtual A
{
  virtual void foo() {}
  char c;
};

struct C : virtual B
{
  C();
};
C::C() { bar(); }


bug.cc:18:17: internal compiler error: in ipa_get_indirect_edge_target_1, at
ipa-cp.c:1570
 C::C() { bar(); }
 ^
0xf46f8d ipa_get_indirect_edge_target_1
../../gcc/gcc/ipa-cp.c:1569
0x9958fe estimate_edge_devirt_benefit
../../gcc/gcc/ipa-inline-analysis.c:2783
0x9958fe estimate_edge_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:2815
0x9958fe estimate_calls_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:2868
0x996a72 estimate_node_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:2955
0x999046 do_estimate_edge_size(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3498
0x99918c estimate_edge_size
../../gcc/gcc/ipa-inline.h:275
0x99918c estimate_edge_growth
../../gcc/gcc/ipa-inline.h:287
0x99918c do_estimate_growth_1
../../gcc/gcc/ipa-inline-analysis.c:3609
0x8004de cgraph_for_node_and_aliases(cgraph_node*, bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/gcc/cgraph.c:2156
0x999617 do_estimate_growth(cgraph_node*)
../../gcc/gcc/ipa-inline-analysis.c:3623
0xf5513d estimate_growth
../../gcc/gcc/ipa-inline.h:262
0xf5513d inline_small_functions
../../gcc/gcc/ipa-inline.c:1549
0xf5513d ipa_inline
../../gcc/gcc/ipa-inline.c:2009
0xf5513d execute
../../gcc/gcc/ipa-inline.c:2379
Please submit a full bug report, [etc.]

The regression appeared between 4.9.0-20130922 and 4.9.0-20130926.

[Bug c++/58584] [c++11] ICE with invalid argument for alignas

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
Please don't use anymore -std=c++0x, it's legacy, supported only for backward
compatibility.

[Bug fortran/58579] Memory allocation fails when calling character-valued function

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Completely untested draft patch

--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -2355,11 +2355,13 @@ gfc_conv_string_tmp (gfc_se * se, tree type, tree len)
 {
   /* Allocate a temporary to hold the result.  */
   var = gfc_create_var (type, "pstr");
+  tmp = TYPE_SIZE_UNIT (get_element_type (type));
+  tmp = fold_build2_loc (input_location, MULT_EXPR, size_type_node,
+   fold_convert (size_type_node, len),
+   fold_convert (size_type_node, tmp));
   tmp = gfc_call_malloc (&se->pre, type,
 fold_build2_loc (input_location, MULT_EXPR,
- TREE_TYPE (len), len,
- fold_convert (TREE_TYPE (len),
-   TYPE_SIZE
(type;
+ size_type_node, len, tmp);
   gfc_add_modify (&se->pre, var, tmp);

   /* Free the temporary afterwards.  */

[Bug fortran/58579] Memory allocation fails when calling character-valued function

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||burnus at gcc dot gnu.org
  Known to fail||4.8.1, 4.9.0

--- Comment #1 from Tobias Burnus  ---
The generated code (-fdump-tree-original) looks odd:

   D.1887 = &i;
   D.1888 = *D.1887;
   D.1890 = MAX_EXPR  * 64;
   D.1891 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
D.1890, 1>);

Why is there the multiplication by 64? We have a kind=1 character, i.e. one
should have multiplied by 1 (byte). Random guess: That's the bit size of a
pointer.

(That it fails with that multiplication is clear: gfortran uses a (signed)
32bit variable for the string length - and 33554432 * 64 == 2**31 - but
(2**31-1) is the largest positive 32bit integer.)

[Bug c++/58584] New: [c++11] ICE with invalid argument for alignas

[reichelt at gcc dot gnu.org]

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

Bug ID: 58584
   Summary: [c++11] ICE with invalid argument for alignas
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet (compiled with "-std=c++0x") triggers an ICE
since GCC 4.8.0 (when alignas was introduced):


struct A
{
  int i alignas(this);
};


bug.cc:3:17: error: invalid use of 'this' at top level
   int i alignas(this);
 ^
bug.cc:3:17: internal compiler error: tree check: expected tree_list, have
error_mark in cp_check_const_attributes, at cp/decl2.c:1325
0xcd8a0a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9176
0x6110cb tree_check
../../gcc/gcc/tree.h:2609
0x6110cb cp_check_const_attributes
../../gcc/gcc/cp/decl2.c:1325
0x6110cb cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/cp/decl2.c:1351
0x6161b7 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:989
0x636a92 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20084
0x6376ce cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19630
0x6376ce cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18885
0x63a070 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19101
0x63a070 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14080
0x64f549 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11328
0x6535d9 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10918
0x6555e0 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10867
0x65e5ee cp_parser_declaration
../../gcc/gcc/cp/parser.c:10764
0x65d35a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x65ec36 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ec36 c_parse_file()
../../gcc/gcc/cp/parser.c:28898
0x772143 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]

A template version of the code crashes in a different place:


template struct A
{
  int i alignas(this);
};


neu50B.cc:3:17: error: invalid use of 'this' at top level
   int i alignas(this);
 ^
neu50B.cc:3:17: internal compiler error: tree check: expected tree_list, have
error_mark in get_attribute_name, at attribs.c:659
0xcd8a0a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9176
0x72a595 tree_check
../../gcc/gcc/tree.h:2819
0x72a595 get_attribute_name(tree_node const*)
../../gcc/gcc/attribs.c:659
0x610d23 is_late_template_attribute
../../gcc/gcc/cp/decl2.c:1120
0x610d23 splice_template_attributes
../../gcc/gcc/cp/decl2.c:1200
0x610d23 save_template_attributes
../../gcc/gcc/cp/decl2.c:1221
0x610d23 cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/cp/decl2.c:1348
0x6161b7 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:989
0x636a92 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20084
0x6376ce cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19630
0x6376ce cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18885
0x63a070 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19101
0x63a070 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14080
0x64f549 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11328
0x653bb3 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:22578
0x656990 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:22454
0x65e789 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10728
0x65d35a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x65ec36 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ec36 c_parse_file()
../../gcc/gcc/cp/parser.c:28898
Please submit a full bug report, [etc.]

[Bug middle-end/58564] [4.7 Regression] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] possible
   |possible wrong code bug at  |wrong code bug at -O0
   |-O0 |

--- Comment #12 from Jakub Jelinek  ---
Should be fixed for 4.8.2+ so far.

[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep 30 20:17:07 2013
New Revision: 203044

URL: http://gcc.gnu.org/viewcvs?rev=203044&root=gcc&view=rev
Log:
PR middle-end/58564
* fold-const.c (tree_unary_nonnegative_warnv_p): Use
INTEGRAL_TYPE_P (t) instead of TREE_CODE (t) == INTEGER_TYPE.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c

[Bug c++/58583] New: [c++11] ICE with invalid non-static data member initialization in template

[reichelt at gcc dot gnu.org]

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

Bug ID: 58583
   Summary: [c++11] ICE with invalid non-static data member
initialization in template
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet (compiled with "-std=c++0x") is wrongly
accepted since GCC 4.7.0 (when non-static data member initializers were
introduced):

==
template struct A
{
  A* p = new A;
};
==

Even instantiating A<0> doesn't produce an error.
However, without template the code is rejected correctly.

A slightly modified code snippet triggers an ICE:

==
struct B
{
  template struct A
  {
A* p = new A<0>;
  };
};
==

bug.cc: In constructor 'constexpr B::A<0>::A()':
bug.cc:3:26: internal compiler error: in tsubst_copy, at cp/pt.c:12810
   template struct A
  ^
0x5bbd53 tsubst_copy
../../gcc/gcc/cp/pt.c:12810
0x59aa12 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14855
0x69636c perform_member_init
../../gcc/gcc/cp/init.c:538
0x69636c emit_mem_initializers(tree_node*)
../../gcc/gcc/cp/init.c:1093
0x6a0a2e synthesize_method(tree_node*)
../../gcc/gcc/cp/method.c:796
0x617659 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4714
0x54889b build_over_call
../../gcc/gcc/cp/call.c:7116
0x54477e build_new_method_call_1
../../gcc/gcc/cp/call.c:7813
0x54477e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7883
0x5456f2 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7440
0x699086 build_new_1
../../gcc/gcc/cp/init.c:2761
0x699086 build_new(vec**, tree_node*, tree_node*,
vec**, int, int)
../../gcc/gcc/cp/init.c:3001
0x645ad2 cp_parser_new_expression
../../gcc/gcc/cp/parser.c:7139
0x646097 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:6910
0x646b4f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7701
0x64700f cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7937
0x647466 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7987
0x647466 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8197
0x648a36 cp_parser_late_parse_one_default_arg
../../gcc/gcc/cp/parser.c:23055
0x637c35 cp_parser_late_parsing_nsdmi
../../gcc/gcc/cp/parser.c:23109
Please submit a full bug report, [etc.]

[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep 30 20:16:14 2013
New Revision: 203043

URL: http://gcc.gnu.org/viewcvs?rev=203043&root=gcc&view=rev
Log:
PR middle-end/58564
* fold-const.c (fold_ternary_loc): For A < 0 :  : 0
optimization, punt if sign_bit_p looked through any zero extension.

* gcc.c-torture/execute/pr58564.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr58564.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/fold-const.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep 30 20:15:20 2013
New Revision: 203042

URL: http://gcc.gnu.org/viewcvs?rev=203042&root=gcc&view=rev
Log:
PR middle-end/58564
* fold-const.c (fold_ternary_loc): For A < 0 :  : 0
optimization, punt if sign_bit_p looked through any zero extension.

* gcc.c-torture/execute/pr58564.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr58564.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/58582] New: [c++11] ICE defining and instantiating deleted template function

[reichelt at gcc dot gnu.org]

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

Bug ID: 58582
   Summary: [c++11] ICE defining and instantiating deleted
template function
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet (compiled with "-std=c++0x") triggers an ICE
since GCC 4.4.0 (when deleted functions were introduced):


struct A
{
  template void foo() = delete;
};

template void A::foo() { int i; }

template void A::foo<0>();


bug.cc:6:20: error: redefinition of 'void A::foo()'
 template void A::foo() { int i; }
^
bug.cc:3:22: note: 'void A::foo()' previously declared here
   template void foo() = delete;
  ^
bug.cc: In instantiation of 'void A::foo() [with int  = 0]':
bug.cc:8:25:   required from here
bug.cc:6:36: internal compiler error: in add_stmt, at cp/semantics.c:386
 template void A::foo() { int i; }
^
0x6ae530 add_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:386
0x5a43ac tsubst_expr
../../gcc/gcc/cp/pt.c:13289
0x5a1cdf instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19391
0x5de5ff instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19492
0x619766 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4060
Please submit a full bug report, [etc.]


A slightly modified example (just leave out "int i;") crashes in a different
place:


struct A
{
  template void foo() = delete;
};

template void A::foo() {}

template void A::foo<0>();


bug.cc:6:20: error: redefinition of 'void A::foo()'
 template void A::foo() {}
^
bug.cc:3:22: note: 'void A::foo()' previously declared here
   template void foo() = delete;
  ^
bug.cc: In instantiation of 'void A::foo() [with int  = 0]':
bug.cc:8:25:   required from here
bug.cc:6:30: internal compiler error: in finish_function, at cp/decl.c:13810
 template void A::foo() {}
  ^
0x56ab15 finish_function(int)
../../gcc/gcc/cp/decl.c:13810
0x5a1d18 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19402
0x5de5ff instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19492
0x619766 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4060
Please submit a full bug report, [etc.]

[Bug c++/58581] New: [4.7/4.8/4.9 Regression] [c++11] ICE with no-throw specification in deleted function

[reichelt at gcc dot gnu.org]

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

Bug ID: 58581
   Summary: [4.7/4.8/4.9 Regression] [c++11] ICE with no-throw
specification in deleted function
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet (compiled with "std=c++0x") triggers an ICE
since GCC 4.7.0:

===
template int foo(T) noexcept(T()) = delete;

int i = foo(0);
===

bug.cc:3:14: error: use of deleted function 'int foo(T) [with T = int]'
 int i = foo(0);
  ^
bug.cc:1:26: note: declared here
 template int foo(T) noexcept(T()) = delete;
  ^
bug.cc:3:14: internal compiler error: in nothrow_spec_p, at cp/except.c:1265
 int i = foo(0);
  ^
0x68b5fa nothrow_spec_p(tree_node const*)
../../gcc/gcc/cp/except.c:1265
0x534afb set_flags_from_callee(tree_node*)
../../gcc/gcc/cp/call.c:327
0x534c79 build_call_a(tree_node*, int, tree_node**)
../../gcc/gcc/cp/call.c:359
0x536856 build_cxx_call(tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7168
0x548739 build_over_call
../../gcc/gcc/cp/call.c:7152
0x54a371 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/gcc/cp/call.c:3917
0x6b6c3e finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2257
0x643626 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6009
0x645f6d cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7009
0x646b4f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7701
0x64700f cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7937
0x647466 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7987
0x647466 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8197
0x65313e cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16520
0x65377f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10986
0x6555e0 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10867
0x65e5ee cp_parser_declaration
../../gcc/gcc/cp/parser.c:10764
0x65d35a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x65ec36 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ec36 c_parse_file()
../../gcc/gcc/cp/parser.c:28898
Please submit a full bug report, [etc.]

[Bug c++/58563] [4.9 Regression] [c++11] ICE calling invalid destructor

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
(In reply to Marek Polacek from comment #2)
> Does not ICE for me with 4.7/4.8, but with trunk it does.

I guess this does not apply, please ignore.  Should be reproducible even with
4.7/4.8.

[Bug c++/58563] [4.9 Regression] [c++11] ICE calling invalid destructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Seems easy.

[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #30 from Paolo Carlini  ---
Fixed for 4.7.4/4.8.2/4.9.0.

[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44

[paolo at gcc dot gnu.org]

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

--- Comment #29 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Sep 30 17:43:05 2013
New Revision: 203037

URL: http://gcc.gnu.org/viewcvs?rev=203037&root=gcc&view=rev
Log:
2013-09-30  Chris Jefferson  

PR libstdc++/58437
* include/bits/stl_algo.h (__move_median_first): Rename to
__move_median_to_first, change to take an addition argument.
(__unguarded_partition_pivot): Adjust.
* testsuite/performance/25_algorithms/sort.cc: New.
* testsuite/performance/25_algorithms/sort_heap.cc: Likewise.
* testsuite/performance/25_algorithms/stable_sort.cc: Likewise.

Added:
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/performance/25_algorithms/sort.cc
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/performance/25_algorithms/sort_heap.cc
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/performance/25_algorithms/stable_sort.cc
Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/bits/stl_algo.h

[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44

[paolo at gcc dot gnu.org]

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

--- Comment #28 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Sep 30 17:42:52 2013
New Revision: 203036

URL: http://gcc.gnu.org/viewcvs?rev=203036&root=gcc&view=rev
Log:
2013-09-30  Chris Jefferson  

PR libstdc++/58437
* include/bits/stl_algo.h (__move_median_first): Rename to
__move_median_to_first, change to take an addition argument.
(__unguarded_partition_pivot): Adjust.
* testsuite/performance/25_algorithms/sort.cc: New.
* testsuite/performance/25_algorithms/sort_heap.cc: Likewise.
* testsuite/performance/25_algorithms/stable_sort.cc: Likewise.

Added:
   
branches/gcc-4_8-branch/libstdc++-v3/testsuite/performance/25_algorithms/sort.cc
   
branches/gcc-4_8-branch/libstdc++-v3/testsuite/performance/25_algorithms/sort_heap.cc
   
branches/gcc-4_8-branch/libstdc++-v3/testsuite/performance/25_algorithms/stable_sort.cc
Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/include/bits/stl_algo.h

[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44

[paolo at gcc dot gnu.org]

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

--- Comment #27 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Sep 30 17:42:31 2013
New Revision: 203035

URL: http://gcc.gnu.org/viewcvs?rev=203035&root=gcc&view=rev
Log:
2013-09-30  Chris Jefferson  

PR libstdc++/58437
* include/bits/stl_algo.h (__move_median_first): Rename to
__move_median_to_first, change to take an addition argument.
(__unguarded_partition_pivot): Adjust.
* testsuite/performance/25_algorithms/sort.cc: New.
* testsuite/performance/25_algorithms/sort_heap.cc: Likewise.
* testsuite/performance/25_algorithms/stable_sort.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/performance/25_algorithms/sort.cc
trunk/libstdc++-v3/testsuite/performance/25_algorithms/sort_heap.cc
trunk/libstdc++-v3/testsuite/performance/25_algorithms/stable_sort.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
Yes, threading is rotating the loop in "interesting" ways -- I was going to
look at that independently of the correctness issue. 

One of the things I've noticed as I've been laying down some infrastructure for
the FSA optimization is much of the work Zdenek did to prevent threading
through loop headers and such isn't working as well as we'd like.

[Bug rtl-optimization/58322] similar simple code produces different (and non-optimal) result

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-30
  Known to work||4.6.2
 Ever confirmed|0   |1
  Known to fail||4.7.2, 4.8.1

--- Comment #1 from Georg-Johann Lay  ---
Confirmed.

test1 should use direct addressing.

With addresses < 0x60 that can use IN/OUT everything is fine; the indirect
addressing starts with adresses >= 0x60:

== Code ==

#define UCSR0B (*(volatile unsigned char*) 0x60)

void test1 (void)
{
UCSR0B |= 1;
}

void test2 (char flag)
{
if (flag)
UCSR0B |= 1;
}


== Command Line ==

$ avr-gcc bug.c -S -Os -mmcu=atmega8 -v

Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.8 --enable-languages=c,c++ --disable-nls
--disable-shared --with-dwarf2
Thread model: single
gcc version 4.8.0 20130306 (experimental) (GCC)

[Bug other/58578] [4.9 Regression] mpfr tasinh test doesn't terminate when built with trunk for ARM

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
I suspect this was introduced with r197527

[Bug other/58578] [4.9 Regression] mpfr tasinh test doesn't terminate when built with trunk for ARM

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-09-30
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
Please can you add the output of gcc -v that was used when compiling this test.

[Bug preprocessor/58580] [4.8/4.9 Regression] preprocessor goes OOM with warning for zero literals

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2
Summary|preprocessor goes OOM with  |[4.8/4.9 Regression]
   |warning for zero literals   |preprocessor goes OOM with
   ||warning for zero literals

--- Comment #1 from Richard Biener  ---
Works with 4.7.

[Bug preprocessor/58580] New: preprocessor goes OOM with warning for zero literals

[rguenth at gcc dot gnu.org]

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

Bug ID: 58580
   Summary: preprocessor goes OOM with warning for zero literals
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

Created attachment 30940
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30940&action=edit
testcase

> g++-4.8  -E test.cpp 
# 1 "test.cpp"
# 1 ""
# 1 "test.cpp"
test.cpp:1:1: warning: null character(s) preserved in literal [enabled by
default]
 "
 ^
test.cpp:2:1: warning: null character(s) preserved in literal [enabled by
default]
""
test.cpp:3:1: warning: null character(s) preserved in literal [enabled by
default]
""
test.cpp:4:1: warning: null character(s) preserved in literal [enabled by
default]
""

cc1plus: out of memory allocating 1677721600 bytes after a total of 405504
bytes

use a suitable ulimit -v to force the error.

[Bug fortran/58579] New: Memory allocation fails when calling character-valued function

[apbartok at gmail dot com]

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

Bug ID: 58579
   Summary: Memory allocation fails when calling character-valued
function
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: apbartok at gmail dot com

This is a problem I found with gfortran 4.6.3, 4.7.3, 4.8.0 on

$ uname -a
Linux 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
$ gfortran -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gfortran-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.0-3ubuntu3~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.0 (Ubuntu/Linaro 4.8.0-3ubuntu3~12.04)

and gfortran 4.7.3 on

$ uname -a
Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012;
root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.3/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-4.7.3/configure --prefix=/opt/local
--build=x86_64-apple-darwin11
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc47 --includedir=/opt/local/include/gcc47
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.7 --with-libiconv-prefix=/opt/local
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.7 --with-gxx-include-dir=/opt/local/include/gcc47/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl
--disable-cloog-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --disable-ppl-version-check
--with-pkgversion='MacPorts gcc47 4.7.3_1'
Thread model: posix
gcc version 4.7.3 (MacPorts gcc47 4.7.3_1)

I don't think this is a simple stack issue:
$ ulimit -a
core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 128297
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) unlimited
cpu time   (seconds, -t) unlimited
max user processes  (-u) 128297
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

The following test case runs fine
$ echo "33554431" | ./a.out

but this one fails
$ echo "33554432" | ./a.out
Operating system error: Cannot allocate memory
Memory allocation failed

compilation:
$ gfortran -g -Wall -Wextra -fno-strict-aliasing -fwrapv -fcheck=all
-fdump-core -fbacktrace test_char_array.f95
(without the "-f" options the code simply returns a segmentation fault.)

code:
$ cat test_char_array.f95
program test_char

   implicit none
   integer :: i

   read*, i
   print*, trim(test(i))

   contains

  function test(i)
 integer, intent(in) :: i
 character(len=i) :: test

 test(1:1) = "A"
  endfunction test

endprogram test_char

Many thanks in advance.
Albert

[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Note that I can't test this easily on the trunk, the partition I have access to
has just 2 CPUs and 1GB of RAM, bootstrap/regtest would be very slow if it
worked at all, but am testing the 4.8 version of the patch (via a build system
scratch build).

[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 30939
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30939&action=edit
gcc48-pr58574.patch

Yeah, perhaps.  I'm attaching 4.8 version of the patch, which wasn't using
tablejump_p at all.  The patch also contains a testcase (which should be added
to the 4.9 version of the patch too).

[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass

[krebbel at gcc dot gnu.org]

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

--- Comment #7 from Andreas Krebbel  ---
Created attachment 30938
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30938&action=edit
Alternate fix - v2

Since tablejump_p is checking for JUMP_P anyway we could move the check even
outside the jump insn check.

I've also changed s390_split_branches to exit early for table jumps.

Untested so far.

[Bug tree-optimization/58577] [4.9 Regression] Capacita regresses with 202619

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Richard Biener  ---
It is.

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

[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||Ganesh.Gopalasubramanian@am
   ||d.com

--- Comment #7 from Richard Biener  ---
*** Bug 58577 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/58577] [4.9 Regression] Capacita regresses with 202619

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Let's see if it is fixed by the fixes for PR58553 and PR58554.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenth at gcc dot gnu.org]

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

Bug 58553 depends on bug 58554, which changed state.

Bug 58554 Summary: [4.9 Regression] Revision 202619 causes runtime failure in 
CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 30 12:22:00 2013
New Revision: 203031

URL: http://gcc.gnu.org/viewcvs?rev=203031&root=gcc&view=rev
Log:
2013-09-30  Richard Biener  

PR tree-optimization/58554
* tree-loop-distribution.c (classify_partition): Require unconditionally
executed stores for memcpy and memset recognition.
(tree_loop_distribution): Calculate dominance info.

* gcc.dg/torture/pr58554.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr58554.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[jjcogliati-r1 at yahoo dot com]

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

Joshua Cogliati  changed:

   What|Removed |Added

  Attachment #30913|0   |1
is obsolete||

--- Comment #20 from Joshua Cogliati  ---
Created attachment 30937
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30937&action=edit
Patch to add -Wfloat-conversion option against trunk

Added one more changed needed to get it to compile (which only occured if I did
an rm -Rf in the build directry, the make bootstrap didn't catch the libcpp
warning found.)  

The only thing I have left is to possibly modify the test scripts (to use
-Wfloat-conversion instead of -Wconversion for the relevant tests) and
recompile against the current trunk.

[Bug other/58578] New: mpfr tasinh test doesn't terminate when built with trunk for ARM

[kuganv at linaro dot org]

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

Bug ID: 58578
   Summary: mpfr tasinh test doesn't terminate when built with
trunk for ARM
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kuganv at linaro dot org

Created attachment 30936
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30936&action=edit
preprocessed testcase

mpfr tasinh 3.1.1. does not produce correct code for optimization level -O1 and
above. Preprocessed ouput for a reduced testcase is attached. For the reduced
testcase, if-condition at line 45 (original source) is evaluated true whereas
it is not when compiled with -O1 and run. This can be easily verified with gdb.

gcc version 4.9.0 20130922 (experimental)

[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass

[krebbel at gcc dot gnu.org]

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

--- Comment #6 from Andreas Krebbel  ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 30935 [details]
> Alternate fix
> 
> Another possibility.  If the check is there really just to prevent handling
> tablejumps, I wonder why we can't do the tablejump handling first and only
> if it didn't do anything, handle all other jumps.

I agree with that patch. Since tablejump_p is available it is easier to read
the other way around.

Thanks!

[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass

[krebbel at gcc dot gnu.org]

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

--- Comment #5 from Andreas Krebbel  ---
Thanks for tracking this down!

(In reply to Jakub Jelinek from comment #2)
> I'd say the bug is in s390_chunkify_start:
>   if (GET_CODE (pat) == PARALLEL && XVECLEN (pat, 0) > 2)
> pat = XVECEXP (pat, 0, 0);
> Dunno what exactly the > 2 condition has been added for, JUMP_INSNs with

The more complex loop jumps might have more than 2 I think.

> PARALLEL with XVECLEN (pat, 0) == 2 are:
> 1) casesi_jump
> 2) *cmp_and_br_signed_, *cmp_and_br_unsigned_,
> *icmp_and_br_signed_, *icmp_and_br_unsigned_
> 3) *ccraw_to_int
> I can understand why you wouldn't want to handle 1) in there, and supposedly
> 3) should be split before machine reorg or worst case at the start of it. 
> But 2), this case, it looks wrong not to do anything here.
> 
> Note that similar condition is in s390_split_branches, no idea what do you
> want to do there.  But perhaps TARGET_Z10 implies TARGET_ZARCH and thus
> s390_split_branches would be never called.

Exactly.

[Bug tree-optimization/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
This wrong-code stopped occurring on trunk with r201251, and on 4.8 branch with
r202388 (PR57521).  The latter is a backport of trunk's r202019 (PR57521), and
applying that to trunk @ r201250 also fixes the wrong-code.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Testcase that also fails on x86_64:

#define MAX_LENGTH 96
#define SEQUENCE_LENGTH 31

static struct {
  char buf[MAX_LENGTH + 1];
} u1, u2;

extern void abort (void);

int main ()
{
  int i;
  char c;

  u1.buf[0] = '\0';
  for (i = 0, c = 'A'; i < MAX_LENGTH; i++, c++)
{
  u1.buf[i] = 'a';
  if (c >= 'A' + SEQUENCE_LENGTH)
c = 'A';
  u2.buf[i] = c;
}
  if (u1.buf[MAX_LENGTH] != '\0')
abort ();

  return 0;
}

jump threading rotates the loop in interesting ways.

[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 30935
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30935&action=edit
Alternate fix

Another possibility.  If the check is there really just to prevent handling
tablejumps, I wonder why we can't do the tablejump handling first and only if
it didn't do anything, handle all other jumps.

[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 30934
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30934&action=edit
Possible fix

Possible fix.

[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I'd say the bug is in s390_chunkify_start:
  if (GET_CODE (pat) == PARALLEL && XVECLEN (pat, 0) > 2)
pat = XVECEXP (pat, 0, 0);
Dunno what exactly the > 2 condition has been added for, JUMP_INSNs with
PARALLEL with XVECLEN (pat, 0) == 2 are:
1) casesi_jump
2) *cmp_and_br_signed_, *cmp_and_br_unsigned_,
*icmp_and_br_signed_, *icmp_and_br_unsigned_
3) *ccraw_to_int
I can understand why you wouldn't want to handle 1) in there, and supposedly
3) should be split before machine reorg or worst case at the start of it.  But
2), this case, it looks wrong not to do anything here.

Note that similar condition is in s390_split_branches, no idea what do you want
to do there.  But perhaps TARGET_Z10 implies TARGET_ZARCH and thus
s390_split_branches would be never called.

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-30
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Thus confirmed.

[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Ok, this one shows that pattern detection does not consider conditionally
executed stores properly.  I have a fix.

[Bug tree-optimization/58556] [4.9 Regression] gen-vect-26.c / gen-vect-28.c regression merging from r202839 to r202981

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|arc-elf32   |arc-elf32, arm-none-eabi
 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Also appears on arm.

[Bug sanitizer/58543] Invalid unpoisoning of stack redzones on ARM

[y.gribov at samsung dot com]

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

--- Comment #5 from Yury Gribov  ---
> I guess you mean *un*poison here.

Right you are!

> My understanding is that in the loop above, we are setting the memory
> pointed to by frame_shadow_base + { 0, 4, 8, 12, 16} to zero.
>
> And in the code below, we are preparing to set the memory pointed to by
> frame_shadow_base + {24, 28} to zero.

Exactly.

>   add  r3, r4, #24   ; r3 gets invalid value here

> Why is r3 invalid?  It's being set to #24,
> so that the strb r2, [r3] below writes a zero byte to [r4,#24].

Not really - it's set to #40 because r4 was changed to #16 inside the loop

> Would it be possible that you file it
> so that I can understand better what is going on?

Sure - simply compile the attached repro with `-O0 -fsanitize-address'. But
note that you need to use ARM target because x86 does not trigger this bug
(most probably because it uses different code path in asan_clear_shadow).

-Y

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c++ |middle-end
   Target Milestone|--- |4.9.0
Summary|Floating point exception in |[4.9 Regression] Floating
   |want_inline_self_recursive_ |point exception in
   |call_p  |want_inline_self_recursive_
   ||call_p

[Bug tree-optimization/58556] [4.9 Regression] gen-vect-26.c / gen-vect-28.c regression merging from r202839 to r202981

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-30
 CC||xinliangli at gmail dot com
   Target Milestone|--- |4.9.0
Summary|gen-vect-26.c / |[4.9 Regression]
   |gen-vect-28.c regression|gen-vect-26.c /
   |merging from r202839 to |gen-vect-28.c regression
   |r202981 |merging from r202839 to
   ||r202981
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The test uses -O2 -ftree-vectorize which has changed allowed peeling.

[Bug tree-optimization/58570] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0
Summary|wrong code at -Os and above |[4.9 Regression] wrong code
   |on x86_64-linux-gnu (both   |at -Os and above on
   |32-bit and 64-bit modes)|x86_64-linux-gnu (both
   ||32-bit and 64-bit modes)

[Bug c++/58568] [4.8/4.9 Regression] [c++11] ICE with lambda in invalid template variable definition

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug c++/58567] [4.8/4.9 Regression] ICE with invalid loop variable in template using openmp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug sanitizer/58543] Invalid unpoisoning of stack redzones on ARM

[dodji at seketeli dot org]

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

--- Comment #4 from dodji at seketeli dot org  ---
Thank you for reporting this bug.

Please find my comments below,


"y.gribov at samsung dot com"  a écrit:

> Prologue seems to poison words at frame_shadow_base + { 0, 4, 8, 12, 16, 24,
> 28}:

Right.

>
>   add  r4, r3, #536870912
>   ldr  r3, .L3+8
>   str  r3, [r4]
>   ldr  r3, .L3+12
>   str  r3, [r4, #4]
>   ldr  r3, .L3+16
>   str  r3, [r4, #8]
>   ldr  r3, .L3+20
>   str  r3, [r4, #12]
>   ldr  r3, .L3+16
>   str  r3, [r4, #16]
>   ldr  r3, .L3+20
>   str  r3, [r4, #24]
>   ldr  r3, .L3+24
>   str  r3, [r4, #28]
>
> Whereas epilogue poisons frame_shadow_base + { 0, 4, 8, 12, 16, 40, 44}:

I guess you mean *un*poison here.

>   add  r3, r4, #20
> .L1:
>   mov  r2, #0
>   str  r2, [r4]
>   add  r4, r4, #4
>   cmp  r4, r3
>   bcc  .L1

My understanding is that in the loop above, we are setting the memory
pointed to by frame_shadow_base + { 0, 4, 8, 12, 16} to zero.

And in the code below, we are preparing to set the memory pointed to by
frame_shadow_base + {24, 28} to zero.

>   add  r3, r4, #24   ; r3 gets invalid value here

Why is r3 invalid?  It's being set to #24, so that the strb r2, [r3]
below writes a zero byte to [r4,#24].

Or what am I missing?

>   mov  r2, #0
>   strb  r2, [r3]
>   add  r3, r3, #1
>   mov  r2, #0
>   strb  r2, [r3]
>   add  r3, r3, #1
>   mov  r2, #0
>   strb  r2, [r3]
>   add  r3, r3, #1
>   mov  r2, #0
>   strb  r2, [r3]
>   add  r3, r3, #1
>   mov  r2, #0
>   strb  r2, [r3]
>   add  r3, r3, #1
>   mov  r2, #0
>   strb  r2, [r3]
>   add  r3, r3, #1
>   mov  r2, #0
>   strb  r2, [r3]
>   add  r3, r3, #1
>   mov  r2, #0
>   strb  r2, [r3]
>
> This causes some shadow bytes to remain set after function returns. Those may
> trigger incorrect Asan errors later.

I am guessing that you have a short and self contained example of an
asan error that is caused by a wrong epilogue.  Would it be possible
that you file it so that I can understand better what is going on?

Thanks.

[Bug bootstrap/58572] [4.9 regression] make install uses -Wno-narrowing with system compiler which does not know about it

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/58577] [4.9 Regression] Capacita regresses with 202619

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-09-30
  Component|rtl-optimization|tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
Summary|Capacita regresses with |[4.9 Regression] Capacita
   |202619  |regresses with 202619
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 30933
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30933&action=edit
gcc49-pr58564-nonnegative.patch

Actually, teaching fold that it should fold that < 0 into 0 is easy, just needs
making some checks less strict (they were considering only INTEGER_TYPE,
forgetting about BOOLEAN_TYPE or ENUMERAL_TYPE which IMHO can be handled the
same).  This latter patch I'm obviously not going to propose for the older
branches.

[Bug libstdc++/53631] [C++11] is unimplemented

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||galens at capaccess dot org

--- Comment #16 from Jonathan Wakely  ---
*** Bug 58576 has been marked as a duplicate of this bug. ***

[Bug libstdc++/58576] std::regex_match() reports mismatched braces on a valid regex

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
 doesn't work in GCC 4.8

Your test works with the GCC trunk, where the work to implement regex is being
done.

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

[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Created attachment 30932
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30932&action=edit
gcc49-pr58564.patch

Untested fix.

Note, this patch doesn't attempt to fold the zero extension of something < 0
into 0 resp. side-effects of something, 0, because I think we are generally
trying to move away from adding further new stuff to fold-const.c, and rather
should improve GIMPLE optimizations.

[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses

[amker.cheng at gmail dot com]

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

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #15 from bin.cheng  ---
There must be another scenario for the example, and in this case example:

int test_0 (char* p, int c)
{
  int r = 0;
  r += *p++;
  r += *p++;
  r += *p++;
  return r;
}

should be translated into sth like:
  //...
  ldrb [rx]
  ldrb [rx+1]
  ldrb [rx+2]
  add rx, rx, #3
  //...
This way all loads are independent and can be issued on super scalar machine. 
Actuall for targets like arm which supports post-increment constant (other than
size of memory access), it can be further changed into:
  //...
  ldrb [rx], #3
  ldrb [rx-2]
  ldrb [rx-1]
  //...
For now auto-increment pass can't do this optimization.  I once have a patch
for this but benchmark shows the case is not common.

This case is common especially after loop unrolling and rtl passes deliberately
break down long dependence of RX, which I think is right.

[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`

[nickc at redhat dot com]

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

--- Comment #3 from Nick Clifton  ---
Hi Ilya,

  I have now checked my patches in.  If you use the latest (development) FSF
sources for GCC and the binutils you should see that correct parsing of the
-mmcu command line option and the correct display of the MSP430 architecture
variant.

Cheers
  Nick

[Bug c++/58560] [4.7/4.8/4.9 Regression] [c++11] ICE with auto in typedef

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[4.9 Regression] [c++11]|[4.7/4.8/4.9 Regression]
   |ICE with auto in typedef|[c++11] ICE with auto in
   ||typedef

--- Comment #2 from Marek Polacek  ---
Oops, sorry, --enable-checking=release crept in.

[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|c   |middle-end
   Target Milestone|--- |4.7.4
Summary|possible wrong code bug at  |[4.7/4.8/4.9 Regression]
   |-O0 |possible wrong code bug at
   ||-O0

--- Comment #6 from Jakub Jelinek  ---
I think the bug is in the
  /* A < 0 ?  : 0 is simply (A & ).  */
  if (TREE_CODE (arg0) == LT_EXPR
  && integer_zerop (TREE_OPERAND (arg0, 1))
  && integer_zerop (op2)
  && (tem = sign_bit_p (TREE_OPERAND (arg0, 0), arg1)))
...
transformation in fold_ternary_loc or sign_bit_p or combination thereof.
We get here with arg0 ((int) (d == &c && a != 1)) < 0, arg1 1U and arg2 0U,
sign_bit_p (surprisingly) looks through zero extensions (of bool to int)
and returns (d == &c && a != 1) and we incorrectly fold it as
(d == &c && a != 1) & 1.

[Bug c++/58560] [4.9 Regression] [c++11] ICE with auto in typedef

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-30
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.9 Regression] [c++11]
   |[c++11] ICE with auto in|ICE with auto in typedef
   |typedef |
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
This doesn't ICE for me with latest 4.7/4.8.  But trunk ICEs.

[Bug c++/58561] [4.8/4.9 Regression] [c++11] ICE using declaration of function with auto in return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-30
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
Summary|[c++11] ICE using   |[4.8/4.9 Regression]
   |declaration of function |[c++11] ICE using
   |with auto in return type|declaration of function
   ||with auto in return type
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Started with r185768.

[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Mine.

[Bug tree-optimization/58553] New fail in PASS->FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-09-30
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
Mine.  Jeff, the niter code returns the number of latch executions, so adding
one is correct if the memset happens before the latch (the code doesn't try
to distinguish both cases but it now has to, after I removed the restriction
of distributing only exactly loops with a single basic block).

I'll fix it.

[Bug tree-optimization/58552] [4.9 Regression] -fcompare-debug failure

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/58532] [4.9 Regression] bootstrap failure with BOOT_CFLAGS="-g -O3"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/58532] [4.9 Regression] bootstrap failure with BOOT_CFLAGS="-g -O3"

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 30 07:44:46 2013
New Revision: 203024

URL: http://gcc.gnu.org/viewcvs?rev=203024&root=gcc&view=rev
Log:
2013-09-30  Richard Biener  

PR middle-end/58532
* tree-cfg.c (make_abnormal_goto_edges): Skip debug statements
before looking for setjmp-like calls.

* g++.dg/torture/pr58552.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr58552.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug libstdc++/58576] std::regex_match() reports mismatched braces on a valid regex

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
[:alnum:] only matches the six characters ":almnu".  If you want to match any
letter or digit you have to write [[:alnum:]].

[Bug c++/58563] [4.9 Regression] [c++11] ICE calling invalid destructor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-30
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|[c++11] ICE calling invalid |[4.9 Regression] [c++11]
   |destructor  |ICE calling invalid
   ||destructor
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Does not ICE for me with 4.7/4.8, but with trunk it does.

[Bug rtl-optimization/58577] New: Capacita regresses with 202619

[Ganesh.Gopalasubramanian at amd dot com]

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

Bug ID: 58577
   Summary: Capacita regresses with 202619
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Ganesh.Gopalasubramanian at amd dot com
CC: rguenther at suse dot de

capactia from pb11 (polyhedron) regresses with revision 202619.

The opensuse polyhedron runs shows this.
(REF:http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt)

130916.99962 7.01 15.45 74.94 40.86 8.82 16.19 4.89 99.45 
130917.86399 7.76 15.45 44.48 -1.00 9.09 16.16 4.97 10805.10

Execution log shows a string of NaNs


Calculating G
 Transforming G
 Starting Bi-CGSTAB, for accuracy 1e-6,   N= 1048576
 |r|/|y| =   9.09707323E-02
 |r|/|y| =   9.78626590E-03
 |r|/|y| =   7.68897077E-03
 |r|/|y| =   1.48448779E-03
 |r|/|y| =   2.01700241E-04


Capacita run built with GCC49 trunk gives out the following output.


Calculating G
 Transforming G
 Starting Bi-CGSTAB, for accuracy 1e-6,   N= 1048576
 |r|/|y| =  NaN
 |r|/|y| =  NaN
 |r|/|y| =  NaN
 |r|/|y| =  NaN
 |r|/|y| =  NaN

[Bug rtl-optimization/55190] [SH] ivopts causes loop setup bloat

[amker.cheng at gmail dot com]

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

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #3 from bin.cheng  ---
ARM can benefit from doloop structure too, but it is implemented in different
way. ARM backend defines special addsi_compare pattern and let combine pass
combine decrement and comparison instruction, thus saving the comparison
instruction.

IVOPT can be improved to select two iv candidates for the example loop, with
auto-increment one for the memory access and decrement one for loop exit check.
 This is especially good for target supports both doloop and auto-increment
instructions like ARM and SH.

BUT most hand-written loops have incremental basic iv, so IVOPT depends on
previous pass ivcanon to rewrite it into decremental iv, like below:

for (i = 0; i < 100; i++)
  //loop body

>
for (i = 100; i > 0; i--)
  //modified loop body

Unfortunately, ivcanon pass only do such loop transformation for loop which
iterates constant number times.

It seems difficult for RTL loop passes to revert decision made by IVOPT, so I
think it should be done in GIMPLE IVOPT. I will give it a try.

Thanks.

[Bug c++/58567] [4.8/4.9 Regression] ICE with invalid loop variable in template using openmp

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-30
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r188939.