[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245

--- Comment #5 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #4)

> 
> I see in peephole a wrong transformation:
> 
>   190: cx:SI=dx:SI
>   REG_DEAD dx:SI
>95: {cx:SI=cx:SI+[cx:SI];clobber flags:CC;}
> 
> into
> 
>   242: cx:SI=[cx:SI]
>   243: {cx:SI=cx:SI+dx:SI;clobber flags:CC;}

The pattern in question:

(define_peephole2
  [(set (match_operand:SI 0 "register_operand")
(match_operand:SI 1 "register_operand"))
   (parallel [(set (match_dup 0)
   (match_operator:SI 3 "commutative_operator"
 [(match_dup 0)
  (match_operand:SI 2 "memory_operand")]))
  (clobber (reg:CC FLAGS_REG))])]
  "REGNO (operands[0]) != REGNO (operands[1])
   && GENERAL_REGNO_P (REGNO (operands[0]))
   && GENERAL_REGNO_P (REGNO (operands[1]))"
  [(set (match_dup 0) (match_dup 4))
   (parallel [(set (match_dup 0)
   (match_op_dup 3 [(match_dup 0) (match_dup 1)]))
  (clobber (reg:CC FLAGS_REG))])]
  "operands[4] = replace_rtx (operands[2], operands[0], operands[1]);")

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147

--- Comment #20 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #16)
> I am really concerned about the rest of the base object, because
> the constructor is only called once, and only in the in_charge
> ctor.

I don't think that's a problem; the clobber only affects the as-base size of
the class, which doesn't include any virtual bases unless they are primary, and
virtual bases with data can't be primary.

[Bug c++/67687] ICE initializing constexpr member with constexpr constructor

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67687

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2015-10-19 00:00:00 |2016-3-15
 CC||msebor at gcc dot gnu.org
Summary|[c++0x][constexpr]  |ICE initializing constexpr
   |initialize constexpr member |member with constexpr
   |with constexpr constructor  |constructor
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #2 from Martin Sebor  ---
This seems to have always failed with an ICE.  Reconfirming for all supported
versions, including the top of trunk.

$ cat t.c && /build/gcc-trunk-bootstrap/gcc/xgcc -B
/build/gcc-trunk-bootstrap/gcc -S -Wall -Wextra -Wpedantic -xc++ t.c
template 
struct dimension{
template
constexpr dimension(T...t){}
};

struct accessor_base{
template
constexpr accessor_base(T...t){}
};

template 
struct accessor_mixed{

private:
static constexpr accessor_base s_args_constexpr{dimension{0}
};
};
t.c:16:79: internal compiler error: unexpected expression ‘(const
accessor_base){dimension{0}}’ of kind implicit_conv_expr
static constexpr accessor_base s_args_constexpr{dimension{0}
};
  ^
0x84e015 cxx_eval_constant_expression
/src/gcc/trunk/gcc/cp/constexpr.c:3968
0x8515d3 cxx_eval_outermost_constant_expr
/src/gcc/trunk/gcc/cp/constexpr.c:4026
0x6d47b4 store_init_value(tree_node*, tree_node*, vec**, int)
/src/gcc/trunk/gcc/cp/typeck2.c:822
0x63be15 check_initializer
/src/gcc/trunk/gcc/cp/decl.c:6155
0x65c1c8 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/src/gcc/trunk/gcc/cp/decl.c:6675
0x70bc0e grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
/src/gcc/trunk/gcc/cp/decl2.c:1036
0x758837 cp_parser_member_declaration
/src/gcc/trunk/gcc/cp/parser.c:22559
0x734128 cp_parser_member_specification_opt
/src/gcc/trunk/gcc/cp/parser.c:22108
0x734128 cp_parser_class_specifier_1
/src/gcc/trunk/gcc/cp/parser.c:21300
0x734128 cp_parser_class_specifier
/src/gcc/trunk/gcc/cp/parser.c:21536
0x734128 cp_parser_type_specifier
/src/gcc/trunk/gcc/cp/parser.c:15820
0x748f01 cp_parser_decl_specifier_seq
/src/gcc/trunk/gcc/cp/parser.c:12744
0x7573c5 cp_parser_single_declaration
/src/gcc/trunk/gcc/cp/parser.c:25703
0x75776c cp_parser_template_declaration_after_parameters
/src/gcc/trunk/gcc/cp/parser.c:25398
0x758178 cp_parser_explicit_template_declaration
/src/gcc/trunk/gcc/cp/parser.c:25630
0x758178 cp_parser_template_declaration_after_export
/src/gcc/trunk/gcc/cp/parser.c:25648
0x75f6a9 cp_parser_declaration
/src/gcc/trunk/gcc/cp/parser.c:12080
0x75ded6 cp_parser_declaration_seq_opt
/src/gcc/trunk/gcc/cp/parser.c:12010
0x75e1e8 cp_parser_translation_unit
/src/gcc/trunk/gcc/cp/parser.c:4323
0x75e1e8 c_parse_file()
/src/gcc/trunk/gcc/cp/parser.c:37394
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/70233] Missing diagnostic in array constructor, different size strings

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70233

--- Comment #3 from Jerry DeLisle  ---
Harold,

Thanks for the help and I will test

[Bug c++/66477] [constexpr] accepts-invalid with constexpr member call on non-constant reference

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66477

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Last reconfirmed|2015-06-23 00:00:00 |2016-3-15
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
The invalid test case is still accepted on trunk of 6.0 and prior
(interestingly, bug 60430 shows a an example of a valid program where a
reference is rejected in a constexpr context).

$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -xc++ z.c &&
echo SUCCESS
struct a { constexpr int size() const { return 3; } };
void f(a ) { static_assert(r.size() == 3, "error"); }
SUCCESS

[Bug c++/55004] [meta-bug] constexpr issues

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 58281, which changed state.

Bug 58281 Summary: Problem with explicitly instantiated constexpr template 
functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58281

   What|Removed |Added

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

[Bug c++/58281] Problem with explicitly instantiated constexpr template functions

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58281

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||5.4.0, 6.0
 Resolution|--- |FIXED
  Known to fail||4.8.2, 4.9.1, 5.1.0

--- Comment #2 from Martin Sebor  ---
I was able to reproduce the problem in 5.1.0 but GCC 5.x and 6.0 appear to work
fine.  I'm resolving this as fixed (test case added in r234246).

[Bug c++/58281] Problem with explicitly instantiated constexpr template functions

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58281

--- Comment #1 from Martin Sebor  ---
Author: msebor
Date: Wed Mar 16 03:00:02 2016
New Revision: 234246

URL: https://gcc.gnu.org/viewcvs?rev=234246=gcc=rev
Log:
PR c++/58281 - Problem with explicitly instantiated constexpr template
functions

gcc/testsuite/ChangeLog:
2016-03-15  Martin Sebor  

PR c++/58281
* g++.dg/cpp1y/constexpr-instantiate.C: Add new test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-instantiate.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/65908] [5 Regression] ICE: in expand_thunk, at cgraphunit.c:1700

[araruna at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908

--- Comment #18 from Arthur Rodrigues  ---
I'm using GCC 5.2.1 and the same happened to me just now.

Above is the output from `gcc -v` command:


Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--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 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)

[Bug c++/60430] static_assert and reference to const/constexpr

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60430

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|5.0 |5.3.0, 6.0

--- Comment #4 from Martin Sebor  ---
As shown in the duplicate bug 70247 the top of the trunk of 6.0 still rejects
this code.

[Bug c++/55004] [meta-bug] constexpr issues

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 70247, which changed state.

Bug 70247 Summary: constexpr error using the address of an initialized reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70247

   What|Removed |Added

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

[Bug c++/60430] static_assert and reference to const/constexpr

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60430

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
*** Bug 70247 has been marked as a duplicate of this bug. ***

[Bug c++/70247] constexpr error using the address of an initialized reference

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70247

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2016-3-15
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
I forgot to include the source code of the test case:

  const int  = 0;
  constexpr bool b0 =  == 0;

but it turns out that this is a duplicate of bug 60430.

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

[Bug c/70250] New: Compilation hangs without optimization.

[brijesh.s.singh at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70250

Bug ID: 70250
   Summary: Compilation hangs without optimization.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brijesh.s.singh at gmail dot com
  Target Milestone: ---

Following code hangs during compiling. It works with O2, O3.

#include

static int hash[(1ul<<32 - 1)];

int main() {
return 0;
}

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048

--- Comment #19 from Richard Henderson  ---
(In reply to Jiong Wang from comment #16)
> But there is a performance issue as described at
>  
>   https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00281.html
> 
>   "this patch forces register scaling expression out of memory ref, so that
>RTL CSE pass can handle common register scaling expressions"
> 
> This is particularly performance critial if a group of instructions are
> using the same "scaled register" inside hot loop. CSE can reduce redundant
> calculations.

I wish that message had been a bit more complete with the description
of the performance issue.  I must guess from this...

>   ldr dst1, [reg_base1, reg_index, #lsl 1]
>   ldr dst2, [reg_base2, reg_index, #lsl 1]
>   ldr dst3, [reg_base3, reg_index, #lsl 1]
> 
> into
> 
>   reg_index = reg_index << 1;
>   ldr dst1, [reg_base1, reg_index]
>   ldr dst2, [reg_base2, reg_index]
>   ldr dst3, [reg_base3, reg_index]

that it must have something to do with the smaller cpus, e.g. exynosm1,
based on the address cost tables.

I'll note for the record that you cannot hope to solve this with
the legitimize_address hook alone for the simple reason that it's not
called for legitimate addresses, of which (base + index * 2) is
a member.  The hook is only being called for illegitimate addresses.

To include legitimate addresses, you'd have to force out the address
components somewhere else.  Perhaps in the mov expanders, since that's
one of the very few places mem's are allowed.  You'd want to do this
only if !cse_not_expected.

OTOH, it's also the sort of thing that one would hope that CSE itself
would be able to handle.  Looking across various addresses, computing
sums of costs, and breaking out subexpressions as necessary.

[Bug c++/70246] Spurious -Wmaybe-uninitialized warnings with -O1

[michael at jarvis dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70246

--- Comment #4 from Mike Jarvis  ---
Created attachment 37984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37984=edit
An alternate source that uses a custom Complex class

OK, here is a version that rolls its own Complex class, rather than using the
standard library's complex.  I stripped out the parts of that that
aren't relevant for this, so hopefully this is small enough for you.

A possible clue is that the warning goes away if Complex is implemented in
terms of double _x and double _y (as the normal template version of
std::complex does) rather than __complex__ double _z (as the specialization
std::complex does).

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245

--- Comment #4 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #3)
> The difference between r227381 and r227382 on the testcase is:
> --- r227382-1.s1  2016-03-15 20:34:52.699640513 +0100
> +++ r227382-1.s2  2016-03-15 20:35:05.278470114 +0100
> @@ -116,7 +116,7 @@ _ZL3barP1BPi:
>   movl24(%esp), %edi
>   movl%eax, 24(%esp)
>   movl%edi, 12(%esp)
> - movl(%edx), %ecx
> + movl(%edi), %ecx
>   movl%eax, (%esp)
>   addl%edx, %ecx
>   movl%ebp, 4(%esp)
> which is the load of g->d in d's arguments, %edi at this point isn't equal
> to g, while %edx is (you can see it a few insns later, g and f are not
> modified after assignment and aren't addressable, thus they have the same
> value, and so it is actually f + f->d, in the addition it is either correct
> %edx + (%edx), or incorrect %edx + (%edi) where %edi happens to point to 0
> instead of the right 4.

I see in peephole a wrong transformation:

  190: cx:SI=dx:SI
  REG_DEAD dx:SI
   95: {cx:SI=cx:SI+[cx:SI];clobber flags:CC;}

into

  242: cx:SI=[cx:SI]
  243: {cx:SI=cx:SI+dx:SI;clobber flags:CC;}

[Bug c++/70246] Spurious -Wmaybe-uninitialized warnings with -O1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70246

--- Comment #3 from Andrew Pinski  ---
(In reply to Manuel López-Ibáñez from comment #2)
> This is too large to analyze. See https://gcc.gnu.org/bugs/minimize.html
> 
> If it cannot be minimized, then I would suggest closing this as WONTFIX
> because there are many open reports about Wuninitialized bugs with very
> short testcases available and it would be better to focus on fixing as many
> of those as possible rather than wasting time trying to analyze a very large
> testcase.

Most of it is because of std::complex rather than anything else.

[Bug c++/70246] Spurious -Wmaybe-uninitialized warnings with -O1

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70246

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
This is too large to analyze. See https://gcc.gnu.org/bugs/minimize.html

If it cannot be minimized, then I would suggest closing this as WONTFIX because
there are many open reports about Wuninitialized bugs with very short testcases
available and it would be better to focus on fixing as many of those as
possible rather than wasting time trying to analyze a very large testcase.

[Bug libfortran/69799] FAIL: gfortran.dg/coarray_allocate_3.f08 at -O1 and above

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69799

John David Anglin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from John David Anglin  ---
Fixed.

[Bug libfortran/69799] FAIL: gfortran.dg/coarray_allocate_3.f08 at -O1 and above

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69799

--- Comment #7 from John David Anglin  ---
Author: danglin
Date: Tue Mar 15 23:34:49 2016
New Revision: 234240

URL: https://gcc.gnu.org/viewcvs?rev=234240=gcc=rev
Log:
PR libfortran/69799
* gfortran.dg/coarray_allocate_5.f08: Add "-latomic" option if
libatomic_available.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray_allocate_5.f08

[Bug c/70249] print error float with printf

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70249

--- Comment #2 from Andrew Pinski  ---
-W -Wall would have detected it.

[Bug tree-optimization/63169] ivopts rewrite_uses pessimizes debug info

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63169

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
   Severity|normal  |enhancement

--- Comment #2 from Alan Modra  ---
Closing since this isn't a correctness issue, and relative to other issues with
debug info this is so minor.

[Bug rtl-optimization/54110] lower-subreg related code quality for long long function return

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54110

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #2 from Alan Modra  ---
Seems to be fixed

[Bug target/32621] undefined weak sym test broken when pic

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32621

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Alan Modra  ---
Looks to be fixed

[Bug target/26525] missed opportunity to use value in fp reg

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26525

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #6 from Alan Modra  ---
Seems to be fixed in gcc-4.9

[Bug tree-optimization/26270] missed vrp optimization with unsigned comparison

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26270

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #3 from Alan Modra  ---
Looks to be fixed all active branches

[Bug c/70249] print error float with printf

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70249

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
1234 is not a float.

[Bug c/70249] New: print error float with printf

[dr2d4 at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70249

Bug ID: 70249
   Summary: print error float with printf
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dr2d4 at live dot com
  Target Milestone: ---

Created attachment 37983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37983=edit
error printf

#include 

int
main( void )
{
  float a = 5191;

  printf("float 1: %f\n", a);
  printf("float 2: %f\n", 1234);

  return 0;
}

// result

$ ./main

float 1: 5191.00
float 2: 5191.00

[Bug rtl-optimization/47992] ICE: SIGSEGV in ira_reuse_stack_slot (ira-color.c:2887) with -fweb

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47992

--- Comment #10 from Alan Modra  ---
Author: amodra
Date: Tue Mar 15 22:05:22 2016
New Revision: 234237

URL: https://gcc.gnu.org/viewcvs?rev=234237=gcc=rev
Log:
Fix thinko in indirect_jump_optimize

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ira.c

[Bug rtl-optimization/47992] ICE: SIGSEGV in ira_reuse_stack_slot (ira-color.c:2887) with -fweb

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47992

--- Comment #9 from Alan Modra  ---
Author: amodra
Date: Tue Mar 15 22:04:54 2016
New Revision: 234236

URL: https://gcc.gnu.org/viewcvs?rev=234236=gcc=rev
Log:
Fix thinko in indirect_jump_optimize

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ira.c

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #25 from Alan Modra  ---
Author: amodra
Date: Tue Mar 15 22:05:22 2016
New Revision: 234237

URL: https://gcc.gnu.org/viewcvs?rev=234237=gcc=rev
Log:
Fix thinko in indirect_jump_optimize

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ira.c

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #24 from Alan Modra  ---
Author: amodra
Date: Tue Mar 15 22:04:54 2016
New Revision: 234236

URL: https://gcc.gnu.org/viewcvs?rev=234236=gcc=rev
Log:
Fix thinko in indirect_jump_optimize

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ira.c

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #23 from Alan Modra  ---
Author: amodra
Date: Tue Mar 15 22:04:42 2016
New Revision: 234235

URL: https://gcc.gnu.org/viewcvs?rev=234235=gcc=rev
Log:
Fix thinko in indirect_jump_optimize

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.


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

[Bug rtl-optimization/47992] ICE: SIGSEGV in ira_reuse_stack_slot (ira-color.c:2887) with -fweb

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47992

--- Comment #8 from Alan Modra  ---
Author: amodra
Date: Tue Mar 15 22:04:42 2016
New Revision: 234235

URL: https://gcc.gnu.org/viewcvs?rev=234235=gcc=rev
Log:
Fix thinko in indirect_jump_optimize

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.


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

[Bug target/70155] Use SSE for TImode load/store

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70155

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-15
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
We can extend STV pass to 64-bit mode to convert load and store of
128-bit ntegers to 128-bit SSE load and store, which is implemented
on hjl/pr70155/master branch.

As a follow-on optimization, we can add TImode bitwise patterns to
use SSE for TImode bitwise operation.

[Bug c++/70209] [5 Regression] ICE in strip_typedefs, at cp/tree.c:1377

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70209

Marek Polacek  changed:

   What|Removed |Added

Summary|[5/6 Regression] ICE in |[5 Regression] ICE in
   |strip_typedefs, at  |strip_typedefs, at
   |cp/tree.c:1377  |cp/tree.c:1377

--- Comment #9 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/70209] [5/6 Regression] ICE in strip_typedefs, at cp/tree.c:1377

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70209

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Tue Mar 15 21:10:11 2016
New Revision: 234234

URL: https://gcc.gnu.org/viewcvs?rev=234234=gcc=rev
Log:
PR c++/70209
* tree.c (strip_typedefs): Call strip_typedefs again on the
DECL_ORIGINAL_TYPE result.

* g++.dg/ext/attribute-may-alias-4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/attribute-may-alias-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70248] New: constexpr initialization with unspecified equality expression accepted

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70248

Bug ID: 70248
   Summary: constexpr initialization with unspecified equality
expression accepted
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Going down the list of valid core constant expressions in [expr.const], the
following example adopted from [expr.eq] should be diagnosed since it
illustrates "a relational (5.9) or equality (5.10) operator where the result is
unspecified" and thus not a valid core constant expression.  However, the
example is accepted without a diagnostic by all versions of GCC (and by my
development version of Clang).

$ cat t.c && /build/gcc-trunk-bootstrap/gcc/xgcc -B
/build/gcc-trunk-bootstrap/gcc -S -Wall -Wextra -Wpedantic -xc++ t.c
struct A {};
struct B : A { int x; };
struct C : A { int x; };
constexpr int A::*bx = (int(A::*))::x;
constexpr int A::*cx = (int(A::*))::x;
constexpr bool b1 = (bx == cx); // unspecified

[Bug fortran/70233] Missing diagnostic in array constructor, different size strings

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70233

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
Created attachment 37982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37982=edit
Patch to generate error message

The above patch generates consistent error messages:

pr70233.f90:9:19:

 ch_array = [bh, "def", ch, ch, bh]! no error given
   1
Error: Different CHARACTER lengths (32/3) in array constructor at (1)
pr70233.f90:10:22:

 ch_array = ["def", bh, ch, ch, ch] ! error given
  1
Error: Different CHARACTER lengths (3/32) in array constructor at (1)


Is that what you want?  Then feel free to use it.

Harald

[Bug c++/70247] New: constexpr error using the address of an initialized reference

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70247

Bug ID: 70247
   Summary: constexpr error using the address of an initialized
reference
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following is another constexpr problem I noticed while testing a fix for
bug 70170.

According to [expr.const]:

A conditional-expression e is a core constant expression unless the evaluation
of e, following the rules of the abstract machine (1.9), would evaluate one of
the following expressions:
...
-- an id-expression that refers to a variable or data member of reference type
unless the reference has a preceding initialization and either
   -- it is initialized with a constant expression or
   -- it is a non-static data member of an object whose lifetime began within
the evaluation of e;

the following program is well-formed but it's rejected by all versions of GCC
that support constexpr.  Clang accepts it with a -Wtautological-pointer-compare
warning.

$ /build/gcc-trunk-bootstrap/gcc/xgcc -B /build/gcc-trunk-bootstrap/gcc -S
-Wall -Wextra -Wpedantic -xc++ t.c
t.c:2:27: warning: the address of ‘i’ will never be NULL [-Waddress]
 constexpr bool b0 =  == 0;
   ^
t.c:5:24: warning: the compiler can assume that the address of ‘r’ will never
be NULL [-Waddress]
 constexpr bool b1 =  == 0;
 ~~~^~~~
t.c:5:27: error: the value of ‘r’ is not usable in a constant expression
 constexpr bool b1 =  == 0;
   ^
t.c:4:12: note: ‘r’ was not declared ‘constexpr’
 const int  = 0;
^

[Bug middle-end/70240] [6 Regression] ICE: in gimplify_modify_expr, at gimplify.c:4854 with -ftree-vectorize

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70240

Richard Henderson  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #7 from Richard Henderson  ---
It appears that if we take some advice from PR68714 #c6,
adjusting the gimplification of VEC_COND_EXPR, that alone
fixes the original PR68215.

If we then revert r231575, this bug is resolved.

Thoughts?

[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141

--- Comment #20 from Alexander Kondratskiy  ---
Awesome! Thank you Jason!

[Bug c++/70246] New: Spurious -Wmaybe-uninitialized warnings with -O1

[michael at jarvis dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70246

Bug ID: 70246
   Summary: Spurious -Wmaybe-uninitialized warnings with -O1
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael at jarvis dot net
  Target Milestone: ---

Created attachment 37980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37980=edit
Source code

The attached code is extracted from a larger code base that can view complex
vectors either normally or conjugated and do the right thing (either conj(rhs)
or not) when assigning values to memory.  Starting with gcc5 (I only have 5.3,
so I don't know about earlier 5.x versions), I am getting warnings related to
the possibly-conjugate assignment, although it took a while to track down,
since the warning shows up in a non-very helpful location.  I've extracted as
much as I could to get a minimal test case that reproduces the warning.

The compile command I'm using, and the warning I get are:

$ g++-5 -c -O1 -Wall -Iinclude gcc5_warning.cpp
gcc5_warning.cpp: In function ‘void TestVector()’:
gcc5_warning.cpp:61:6: warning: ‘rhs’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 void TestVector()
  ^

Compiler information:
$ g++-5 --version
g++-5 (GCC) 5.3.0
Copyright (C) 2015 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.

System information:
$ uname -a
Darwin Fife 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep  1 21:23:09 PDT 2015;
root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64


Things I've discovered that remove the warning:
- Switch to using -O2 or -O3, or no -O flag at all.
- Switch line 13 to use `*_v = _c ? rhs : rhs;`, although interestingly,
changing it to `*_v = _c ? -rhs : rhs;` also gives the warning.
- Use the `*_v = _c ? -rhs : rhs;` variant, and also change CT on line 3 to be
double rather than complex.
- Use literals for 100 and 50 rather than N and N/2
- Change line 63 to use `const int N = 100`, although in the larger code base
that this is extracted from, I did use `const int` and it gave the warning, so
maybe this is a red herring.

[Bug c++/70246] Spurious -Wmaybe-uninitialized warnings with -O1

[michael at jarvis dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70246

--- Comment #1 from Mike Jarvis  ---
Created attachment 37981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37981=edit
Preprocessed file

[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #19 from Jason Merrill  ---
Fixed.

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-15
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
The difference between r227381 and r227382 on the testcase is:
--- r227382-1.s12016-03-15 20:34:52.699640513 +0100
+++ r227382-1.s22016-03-15 20:35:05.278470114 +0100
@@ -116,7 +116,7 @@ _ZL3barP1BPi:
movl24(%esp), %edi
movl%eax, 24(%esp)
movl%edi, 12(%esp)
-   movl(%edx), %ecx
+   movl(%edi), %ecx
movl%eax, (%esp)
addl%edx, %ecx
movl%ebp, 4(%esp)
which is the load of g->d in d's arguments, %edi at this point isn't equal to
g, while %edx is (you can see it a few insns later, g and f are not modified
after assignment and aren't addressable, thus they have the same value, and so
it is actually f + f->d, in the addition it is either correct %edx + (%edx), or
incorrect %edx + (%edi) where %edi happens to point to 0 instead of the right
4.

[Bug c++/70095] [C++14] Link error on partially specialized variable template

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70095

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Tue Mar 15 19:37:37 2016
New Revision: 234231

URL: https://gcc.gnu.org/viewcvs?rev=234231=gcc=rev
Log:
PR c++/70095
* pt.c (instantiate_decl): Fix call to variable_template_p.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ50.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245

--- Comment #2 from Jakub Jelinek  ---
Created attachment 37979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37979=edit
r227382-2.C

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245

--- Comment #1 from Jakub Jelinek  ---
Created attachment 37978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37978=edit
r227382-1.C

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||vmakarov at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug middle-end/70245] New: [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245

Bug ID: 70245
   Summary: [6 Regression] Miscompilation of ICU on i386 with atom
tuning starting with r227382
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37977=edit
r227382.h

The following testcase distilled from ICU's ucnv_bld.cpp is miscompiled on i?86
starting with r227382 with -m32 -march=i386 -mtune=atom -O2 -fPIC:

g++ -m32 -march=i386 -mtune=atom -O2 -fPIC -o r227382{,-1.C,-2.C}

[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141

--- Comment #18 from Jason Merrill  ---
Author: jason
Date: Tue Mar 15 19:21:44 2016
New Revision: 234228

URL: https://gcc.gnu.org/viewcvs?rev=234228=gcc=rev
Log:
PR c++/70141
* pt.c (for_each_template_parm_r): Always walk into TYPENAME_TYPE.

Added:
trunk/gcc/testsuite/g++.dg/template/partial-specialization4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/70244] New: ICE spec_dimen_size() Bad dimension

[cfztol at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70244

Bug ID: 70244
   Summary: ICE spec_dimen_size() Bad dimension
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cfztol at hotmail dot com
  Target Milestone: ---

In the following program 3 out of 4 scenarios work fine. These are commented
away and marked with OK in the program section.

The last variation fails when the over-ridden function is supposed to return a
rank 2 array, and is marked with ICE.

module mymodule
implicit none

type, abstract :: base_t
contains
procedure(fun_i), deferred :: fun
end type
abstract interface
function fun_i( self ) result( val )
import
class(base_t), intent(in) :: self
!real, dimension(:), allocatable :: val   ! OK
real, dimension(:,:), allocatable :: val ! ICE
end function
end interface

type :: base_a
class(base_t), allocatable :: obj
end type

type, extends(base_t) :: deriv_t
contains
procedure :: fun
end type

contains

function fun( self ) result( val )
class(deriv_t), intent(in) :: self
!real, dimension(:), allocatable :: val ! OK
real, dimension(:,:), allocatable :: val ! ICE
end function

end module

program bug
use mymodule
implicit none

! Causes ICE...
type(base_a), dimension(1) :: e
real, dimension(:,:), allocatable :: m
allocate( deriv_t :: e(1)%obj )
m = e(1)%obj%fun( )

! OK
!type(base_a), dimension(1) :: e
!real, dimension(:), allocatable :: m
!allocate( deriv_t :: e(1)%obj )
!m = e(1)%obj%fun( )

! OK
!class(base_t), allocatable :: f
!real, dimension(:,:), allocatable :: m
!allocate( deriv_t :: f )
!m = f%fun()

! OK
!type(base_a) :: g
!real, dimension(:,:), allocatable :: m
!allocate( deriv_t :: g%obj )
!m = g%obj%fun()
end program

Only the case where "fun" returns a rank 2 array in combination with going
through "e(1)%obj%..." causes an error. In this case I get:

gfortran -o bug -Wall -Wextra bug.f90
f951: internal compiler error: spec_dimen_size(): Bad dimension
Please submit a full bug report,

using this setup:

gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--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 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)

[Bug tree-optimization/68809] [6 Regression] ICE: verify_gimple failed (error: type mismatch in binary expression) w/ -O2 (-O3, -Ofast) -floop-nest-optimize

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68809

--- Comment #4 from vries at gcc dot gnu.org ---
*** Bug 69353 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/69353] [6 Regression] [graphite] ICE: verify_gimple failed (error: non-trivial conversion at assignment) w/ -O2 (-O3) -floop-nest-optimize

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69353

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||vries at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from vries at gcc dot gnu.org ---
Duplicate of PR68809.

The ICE for the 3 testcases described in this PR are fixed by the tentative
patch for PR68809.

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

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

--- Comment #7 from Zdenek Sojka  ---
(In reply to Richard Henderson from comment #6)
> Created attachment 37975 [details]
> proposed patch
> 
> This is kind of a hack, but not too bad.
> 
> Zdenek, could you please test on that third testcase that
> you didn't post?  I expect it'll be fixed too, but...

I have most likely deleted it already, but testing r234223 + your patch applied
hasn't triggered that error yet; I will let you know if any problem was found
overnight.

[Bug bootstrap/69513] LTO bootstrap fails with bootstrap-profiled during linking gnat1 in stagefeedback

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69513

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
This should work in the upcoming GCC 6 release.

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659

--- Comment #23 from vries at gcc dot gnu.org ---
*** Bug 69822 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/69822] [6 Regression] internal compiler error: in get_rename, at graphite-isl-ast-to-gimple.c:1202

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69822

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||vries at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from vries at gcc dot gnu.org ---
Marking as duplicate of PR68659.

The test-case no longer ICEs. When undoing the fix for PR68659, the ICE
reappears.

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

[Bug bootstrap/69513] LTO bootstrap fails with bootstrap-profiled during linking gnat1 in stagefeedback

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69513

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Mar 15 17:55:39 2016
New Revision: 234226

URL: https://gcc.gnu.org/viewcvs?rev=234226=gcc=rev
Log:
PR bootstrap/69513
* dwarf2out.c (flush_limbo_die_list): Really flush the limbo list.

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

[Bug target/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70220

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #20 from H.J. Lu  ---
Sorry, it doesn't work out for you.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #4 from Jerry DeLisle  ---
I will get started on this one. Dominique, if you spot the problem let me know.

[Bug fortran/70237] [4.9/5/6 Regression] Incorrect 0.0 output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70237

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #2 from Jerry DeLisle  ---
I will get started on this one.

[Bug testsuite/68232] gcc.dg/ifcvt-4.c fails on some arm configurations

[pthaugen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68232

--- Comment #9 from Pat Haugen  ---
(In reply to James Greenhalgh from comment #8)
> 
> For powerpc64 you'll need to enable conditional move instructions using
> "-misel" (or equivalent) for this test to pass.
> 
Added -misel for powerpc* in r234224.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[agardeux.ge at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #3 from Antoine Gardeux  ---
Thanks for the quick confirmation.

Since this kind of format is widely used in our code base, it would be very
tedious to change all the occurrences. Is there any other way to work around
this issue ?

Thanks again for your help.

[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243

Michael Meissner  changed:

   What|Removed |Added

Summary|PowerPC V4DFmode should not |PowerPC V4SFmode should not
   |use Altivec instructions on |use Altivec instructions on
   |VSX systems |VSX systems

--- Comment #1 from Michael Meissner  ---
Note, I meant V4SFmode (i.e. vector float), not V4DFmode.

[Bug tree-optimization/68715] [6 Regression] ice: in harmful_stmt_in_region, at graphite-scop-detection.c:1043

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68715

--- Comment #8 from vries at gcc dot gnu.org ---
*** Bug 69735 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/69735] [6 Regression] internal compiler error: in harmful_loop_in_region, at graphite-scop-detection.c:1045

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69735

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from vries at gcc dot gnu.org ---
This is a duplicate of PR68715.

There's a different function name reported at the ICE, but the reported line
number is roughly the same.

The reason for the different function name is:
...
2016-01-21  Aditya Kumar  
Sebastian Pop  

(scop_detection::harmful_stmt_in_region): Renamed
harmful_loop_in_region.
...

The tentative fix for PR68715 also fixes the ICE for the test-case in this PR.

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

[Bug bootstrap/70242] GCC bootstrap failed on x86_64 using "--with-build-config=bootstrap-O3"

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70242

--- Comment #2 from Markus Trippelsdorf  ---
So something like this may work:

diff --git a/config/bootstrap-O3.mk b/config/bootstrap-O3.mk
index b269a3f7e12a..b9881e9c1664 100644
--- a/config/bootstrap-O3.mk
+++ b/config/bootstrap-O3.mk
@@ -1 +1,2 @@
-BOOT_CFLAGS := -O3 $(filter-out -O%, $(BOOT_CFLAGS))
+BOOT_CFLAGS := -O3 -Wno-error=maybe-uninitialized \
+   -Wno-error=array-bounds $(filter-out -O%, $(BOOT_CFLAGS))

[Bug target/70243] PowerPC V4DFmode should not use Altivec instructions on VSX systems

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-15
 Ever confirmed|0   |1

[Bug target/70243] New: PowerPC V4DFmode should not use Altivec instructions on VSX systems

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243

Bug ID: 70243
   Summary: PowerPC V4DFmode should not use Altivec instructions
on VSX systems
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The traditional Altivec single precision vector floating point instructions
should not be used if the VSX instructions are available.  This is due to the
fact that the Altivec instruction does not use the current rounding mode, while
the VSX instruction does.

I did a quick glance through vsx.md and altivec.md, and I believe the only
places we use the Altivec instruction by default is for 4 operand fused
multiply-add and 4 operand fused negate multiply-subtract, when the destination
operand does not overlap with the input operands.

[Bug c++/70229] error: constexpr constructor does not have empty body

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70229

--- Comment #3 from Marek Polacek  ---
And the fix should be just to

--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -419,7 +419,8 @@ check_constexpr_ctor_body_1 (tree last, tree list)
   switch (TREE_CODE (list))
 {
 case DECL_EXPR:
-  if (TREE_CODE (DECL_EXPR_DECL (list)) == USING_DECL)
+  if (TREE_CODE (DECL_EXPR_DECL (list)) == USING_DECL
+ || TREE_CODE (DECL_EXPR_DECL (list)) == TYPE_DECL)
return true;
   return false;


but this is not a regression so I suppose we'll have to wait till gcc7?

[Bug tree-optimization/68715] [6 Regression] ice: in harmful_stmt_in_region, at graphite-scop-detection.c:1043

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68715

--- Comment #7 from Joost VandeVondele  
---
(In reply to vries from comment #6)
> Created attachment 37976 [details]
> tentative patch, fixes examples from comment 4 and 5.

also fixes the first testcase, thanks!

For whatever reason I had to apply it manually.

[Bug c++/70229] error: constexpr constructor does not have empty body

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70229

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Reduced:
template 
class S {
  constexpr S (void) {
typedef int i;
  }
};

[Bug rtl-optimization/70222] Test miscompiled with -O1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70222

--- Comment #10 from Jakub Jelinek  ---
Fixed for 6+ so far.

[Bug middle-end/70239] [6 Regression] ICE in ggc_set_mark

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70239

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/70240] [6 Regression] ICE: in gimplify_modify_expr, at gimplify.c:4854 with -ftree-vectorize

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70240

--- Comment #6 from Eric Botcazou  ---
> Well, perhaps even better would be not to build all the trees, but use
> gimple_build () APIs that should also simplify stuff while building it on
> GIMPLE. But that might be too risky for stage4 now.

My previous statement might have been too bold: maybe you can pre-gimplify the
operands of the COND_EXPR without entirely undoing the fix for stage4.

[Bug middle-end/70240] [6 Regression] ICE: in gimplify_modify_expr, at gimplify.c:4854 with -ftree-vectorize

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70240

--- Comment #5 from Jakub Jelinek  ---
(In reply to Eric Botcazou from comment #4)
> > Better gimplify a and b before building the COND_EXPR.
> 
> But then you undo the fix for PR middle-end/68215, so you make
>   c-c++-common/opaque-vector.c
> regress again on a bunch of platforms.
> 
> Besides gimplification is supposed to be fully recursive.

Well, perhaps even better would be not to build all the trees, but use
gimple_build () APIs that should also simplify stuff while building it on
GIMPLE.
But that might be too risky for stage4 now.

[Bug middle-end/70240] [6 Regression] ICE: in gimplify_modify_expr, at gimplify.c:4854 with -ftree-vectorize

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70240

--- Comment #4 from Eric Botcazou  ---
> Better gimplify a and b before building the COND_EXPR.

But then you undo the fix for PR middle-end/68215, so you make
  c-c++-common/opaque-vector.c
regress again on a bunch of platforms.

Besides gimplification is supposed to be fully recursive.

[Bug middle-end/70240] [6 Regression] ICE: in gimplify_modify_expr, at gimplify.c:4854 with -ftree-vectorize

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70240

Richard Henderson  changed:

   What|Removed |Added

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

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

[Bug bootstrap/70242] GCC bootstrap failed on x86_64 using "--with-build-config=bootstrap-O3"

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70242

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
I think there are many more issues when using -O3 without --disable-werror.

[Bug tree-optimization/68715] [6 Regression] ice: in harmful_stmt_in_region, at graphite-scop-detection.c:1043

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68715

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #6 from vries at gcc dot gnu.org ---
Created attachment 37976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37976=edit
tentative patch, fixes examples from comment 4 and 5.

[Bug target/68802] seg fault when non-main thread calls std::current_exception ARMv7-A

[cbaylis at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68802

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from cbaylis at gcc dot gnu.org ---

I managed to look into this in more detail with a colleague. The segfault
happens because the implementation of __tls_get_addr in glibc returns an
invalid pointer. This seems to be a problem with static linking only, and
dynamic linking will avoid the problem.

A slightly simplified test case (without the exception handling) is:

#include 
#include 

__thread int __attribute__ ((tls_model ("global-dynamic"))) x = 10;

class Thread {
  public:
void operator()(){
  fprintf(stderr, "testing (%i) ...\n", x);
}
};

int main(void){
  Thread t;
  std::thread th(std::ref(t));
  th.join();
  return 0;
}


If you install a copy of jessie filesystem somewhere on your build machine, you
should be able to compile and link against the libraries on that version using
--sysroot=/path/to/fs. This should allow you to create dynamically linked
binaries which work on your target

I've created a glibc bug for this
https://sourceware.org/bugzilla/show_bug.cgi?id=19826.

Since I don't think this is a bug in gcc, I'll close this bug.

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

--- Comment #6 from Richard Henderson  ---
Created attachment 37975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37975=edit
proposed patch

This is kind of a hack, but not too bad.

Zdenek, could you please test on that third testcase that
you didn't post?  I expect it'll be fixed too, but...

[Bug rtl-optimization/70222] Test miscompiled with -O1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70222

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 15 16:11:48 2016
New Revision: 234222

URL: https://gcc.gnu.org/viewcvs?rev=234222=gcc=rev
Log:
PR rtl-optimization/70222
* combine.c (simplify_shift_const_1): For A >> B >> C LSHIFTRT
optimization if mode is different from result_mode, queue up masking
of the result in outer_op.  Formatting fix.

* gcc.c-torture/execute/pr70222-1.c: New test.
* gcc.c-torture/execute/pr70222-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr70222-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr70222-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/70239] [6 Regression] ICE in ggc_set_mark

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70239

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 15 16:10:59 2016
New Revision: 234221

URL: https://gcc.gnu.org/viewcvs?rev=234221=gcc=rev
Log:
PR middle-end/70239
* tree-ssa-sccvn.c (VN_INFO_GET): Use safe_grow_cleared instead
of safe_grow.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug bootstrap/70242] New: GCC bootstrap failed on x86_64 using "--with-build-config=bootstrap-O3"

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70242

Bug ID: 70242
   Summary: GCC bootstrap failed on x86_64 using
"--with-build-config=bootstrap-O3"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

With below configuration:
../gcc/configure --prefix=/data/work/gcc-patches/x86_64/trunk-orig//target/
--enable-languages=c,c++,fortran,go,java,lto,objc,obj-c++
--with-build-config=bootstrap-O3

Bootstrap failed with:
In file included from ../../gcc/gcc/target.h:53:0,
 from ../../gcc/gcc/df-scan.c:28:
../../gcc/gcc/df-scan.c: In function ‘void df_ref_record(df_ref_class,
df_collection_rec*, rtx, rtx_def**, basic_block, df_insn_info*, df_ref_type,
int)’:
../../gcc/gcc/hard-reg-set.h:156:44: error: array subscript is above array
bounds [-Werror=array-bounds]
   (!!((SET)[(BIT) / UHOST_BITS_PER_WIDE_INT] \
   ~^
../../gcc/gcc/df-scan.c:2536:18: note: in expansion of macro
‘TEST_HARD_REG_BIT’
   else if (!(TEST_HARD_REG_BIT (elim_reg_set, regno)
  ^
cc1plus: all warnings being treated as errors
make[3]: *** [df-scan.o] Error 1

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Henderson  ---
The problem here is the literal pool isn't a multiple of the
instruction size, so the Letext label is "misaligned", which
affects the encoding of the dwarf2 info.

[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/70209] [5/6 Regression] ICE in strip_typedefs, at cp/tree.c:1377

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70209

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/69032] [5/6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4809 with -fsched-pressure -fsel-sched-pipelining -fselective-scheduling

[abel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69032

--- Comment #3 from Andrey Belevantsev  ---
Author: abel
Date: Tue Mar 15 15:42:07 2016
New Revision: 234219

URL: https://gcc.gnu.org/viewcvs?rev=234219=gcc=rev
Log:
gcc/

PR rtl-optimization/69032
* sel-sched-ir.c (get_seqno_by_preds): Include both insn and head when
looping backwards over basic block insns.

testsuite/

PR rtl-optimization/69032
* gcc.dg/pr69032.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr69032.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-ir.c
trunk/gcc/testsuite/ChangeLog

[Bug target/66660] [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption

[abel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0

--- Comment #9 from Andrey Belevantsev  ---
Author: abel
Date: Tue Mar 15 15:36:44 2016
New Revision: 234218

URL: https://gcc.gnu.org/viewcvs?rev=234218=gcc=rev
Log:
PR target/0
* sel-sched-ir.c (merge_expr): Avoid changing the speculative pattern
to non-speculative when propagating trap bits.


Modified:
trunk/gcc/sel-sched-ir.c

[Bug target/70162] [RX] const_int printing causes wrong code on 32 bit host

[nickc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70162

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-15
 CC||nickc at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |nickc at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Nick Clifton  ---
Created attachment 37974
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37974=edit
Proposed patch

Hi Oleg,

> Nick, do you have any opinion on the patch in c#2?

Yes - I would much prefer to patch the assembler so that it can cope with large
values, even when compiled for a 32-bit host.  That way the assembler will be
able to cope even with source files that are not generated by gcc.

A patch like the one attached here perhaps... :-)

I also happen to like seeing large constants as hex values, as 9 times out of
10, the hex value will make more sense.  (Well at least in my experience
anyway).

Would you like to close this PR and open a binutils one instead, or shall I do
it ?

Cheers
  Nick

[Bug target/64939] ICE in extract_insn, at recog.c:2202

[kbrow1i at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939

--- Comment #3 from Ken Brown  ---
This bug is gone as of gcc 5.3.0.  It can be closed.

[Bug target/64939] ICE in extract_insn, at recog.c:2202

[kbrow1i at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939

--- Comment #2 from Ken Brown  ---
This bug is gone as of gcc 5.3.0.  It can be closed.

[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[abel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

--- Comment #6 from Andrey Belevantsev  ---
Author: abel
Date: Tue Mar 15 15:25:41 2016
New Revision: 234217

URL: https://gcc.gnu.org/viewcvs?rev=234217=gcc=rev
Log:
gcc/

PR rtl-optimization/63384
* sel-sched.c (invoke_aftermath_hooks): Do not decrease issue_more
on DEBUG_INSN_P insns.

testsuite/

PR rtl-optimization/63384
* g++.dg/pr63384.C: New test. 

Added:
trunk/gcc/testsuite/g++.dg/pr63384.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68809] [6 Regression] ICE: verify_gimple failed (error: type mismatch in binary expression) w/ -O2 (-O3, -Ofast) -floop-nest-optimize

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68809

--- Comment #3 from vries at gcc dot gnu.org ---
Hmm, apparently char 0 and int 0 are equal as far as operand_equal_p is
concerned:
...
(gdb) p gimple_phi_arg_def (p1, 0)
$3 = (tree_node *) 0x761463a8
(gdb) p gimple_phi_arg_def (p2, 0)
$4 = (tree_node *) 0x7604f048
(gdb) call debug_tree ($3)
  constant
0>
(gdb) call debug_tree ($4)
  constant 0>
(gdb) p operand_equal_p (gimple_phi_arg_def (p1, 0), gimple_phi_arg_def (p2,
0), 0)
$5 = 1
...

[Bug target/64411] ICE: in verify_target_availability, at sel-sched.c:1577 with -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64411

--- Comment #3 from Andrey Belevantsev  ---
Author: abel
Date: Tue Mar 15 15:13:29 2016
New Revision: 234216

URL: https://gcc.gnu.org/viewcvs?rev=234216=gcc=rev
Log:
gcc/

PR target/64411
* sched-deps.c (get_implicit_reg_pending_clobbers): New function,
factored out from ...
(sched_analyze_insn): ... here.
* sched-int.h (get_implicit_reg_pending_clobbers): Declare it.
* sel-sched-ir.c (setup_id_implicit_regs): New function, use
get_implicit_reg_pending_clobbers in it.
(setup_id_reg_sets): Use setup_id_implicit_regs.
(deps_init_id): Ditto.

testsuite/

PR target/64411
* gcc.target/i386/pr64411.C: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr64411.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c
trunk/gcc/sched-int.h
trunk/gcc/sel-sched-ir.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68809] [6 Regression] ICE: verify_gimple failed (error: type mismatch in binary expression) w/ -O2 (-O3, -Ofast) -floop-nest-optimize

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68809

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 37973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37973=edit
tentative patch, fixed both examples