[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

[rguenther at suse dot de]

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

--- Comment #27 from rguenther at suse dot de  ---
On April 15, 2016 11:58:39 PM GMT+02:00, "jamborm at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
>
>--- Comment #26 from Martin Jambor  ---
>(In reply to Josh Poimboeuf from comment #24)
>> 
>> Yes, I'm looking for a general way to either prevent or try to detect
>> potential other cases of the bug throughout the entire kernel.
>> 
>> Can it only occur with the use of __builtin_constant_p(exp) by an
>inline
>> function (where exp is a constant)?
>
>Yes and no.  Yes, the problematic inlining analysis predicate
>condition type IS_NOT_CONSTANT is only created for conditions
>containing a call to __builtin_constant_p.  But no, a function does
>not have to be explicitly marked inline to be an inline candidate.
>
>This bug can occur when an inlineable function containing a call to
>__builtin_constant_p, which checks a parameter or a value it
>references and a (possibly indirect) caller of the function actually
>passes a constant, but stores it using a type of a different size.
>
>In your testcase, the array initialization is a series of byte stores
>but the "load" in __swab64p is 64-bit.  Note that gcc cannot detect
>that the parameter in your testcase was actually a compile-time
>constant.  IPA level does by mistake and removes the slow path which
>is later selected for real (this can be improved if deemed worthwhile
>but IPA analysis still needs to check the size to be correct).

I was arguing that if IPA proves a condition to true/false then it should
adjust it that way in modification phase.
This would have prevented the bug as well (eventually using the 'wrong' path).
At least it would have avoided hitting a unreachable path at runtime which can
be very tricky to debug.

[Bug libfortran/70684] [Regression 5.3, 6] incorrect reading of values from file on Windows

[ajmay81 at googlemail dot com]

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

--- Comment #4 from Andy May  ---
Yes, I agree that demonstrates the bug - and I see it gives the desired output
with 4.8.3 but not with 5.3.0.

However, I would actually not mind if that modified testcase continued not to
'work' on Linux since this is equivalent to writing the file on Windows and
reading on Linux, which although it's nice that it once did work, it's arguable
it should not have (although if it doesn't breach the Fortran standard I guess
there is no problem to have it).

I think the only case that definitely should work, which currently does not on
Windows, is writing and reading on the same system. In other cases one should
be expected to run dos2unix/unix2dos on the file so that it's in the correct
state before being read.

[Bug c++/70689] New: ICE on valid code at -O1 in 32-bit mode on x86_64-linux-gnu in curr_insn_transform, at lra-constraints.c:3564

[su at cs dot ucdavis.edu]

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

Bug ID: 70689
   Summary: ICE on valid code at -O1 in 32-bit mode on
x86_64-linux-gnu in curr_insn_transform, at
lra-constraints.c:3564
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O1 on x86_64-linux-gnu in the 32-bit mode (but not in 64-bit mode). 

It is a regression from 5.3.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160415 (experimental) [trunk revision 235013] (GCC) 
$ 
$ gcc-trunk -m32 -O0 small.c 
$ gcc-5.3 -m32 -O1 small.c
$ 
$ gcc-trunk -m32 -O1 small.c
small.c: In function ‘main’:
small.c:23:1: error: unable to generate reloads for:
 }
 ^
(insn 22 50 23 4 (set (reg:DF 93 [ a_lsm.7 ])
(float:DF (plus:SI (reg/f:SI 20 frame)
(const_int -20 [0xffec] small.c:14 205
{*floatsidf2_i387}
 (nil))
small.c:23:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3564
0xb05bf8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-source-trunk/gcc/rtl-error.c:108
0xa05822 curr_insn_transform
../../gcc-source-trunk/gcc/lra-constraints.c:3564
0xa07726 lra_constraints(bool)
../../gcc-source-trunk/gcc/lra-constraints.c:4506
0x9f3544 lra(_IO_FILE*)
../../gcc-source-trunk/gcc/lra.c:2290
0x9aa599 do_reload
../../gcc-source-trunk/gcc/ira.c:5425
0x9aa599 execute
../../gcc-source-trunk/gcc/ira.c:5609
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


struct S
{
  int f; 
};

double a;
int c; 

static
void fn1 (struct S *p1)
{
  for (; c; )
if (p1->f++)
  a = (int) p1;
}

int 
main ()
{
  struct S b = { 0 };
  fn1 ();
  return 0; 
}

[Bug c/38295] Support pointer difference as constant in static initializer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #9 from Martin Sebor  ---
I'm going to out on a limb and close this as WONTFIX.  First, I don't believe
this will or can be implemented for the reasons Andrew mentioned.  The linker
also can and some linkers do reorder functions and so the notion of a
difference between them doesn't really make sense, either at runtime, but
certainly not at  compile time.  Second, there has been no activity on this
request in the last 8 years.

[Bug c++/70616] [4.9/5/6/7 Regression] ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
The following test case where test is not a function template does not ICE but
it aborts at runtime because a == 2 at the end of execution:


static int a;

struct A
{
  virtual ~A () { a++; }
};

struct B : public A
{
  virtual ~B () { a++; }
};

void test ()
{
  B *b = new B;
  b->~A ();
} 

int main ()
{
  test  ();
  if (a != 1)
__builtin_abort ();
}


Changing b->~A () to b->A::~A () makes the program not abort.

[Bug go/67180] Gccgo does not support MIPS

[luo_12yan at 163 dot com]

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

czlz  changed:

   What|Removed |Added

 CC||luo_12yan at 163 dot com

--- Comment #5 from czlz  ---
(In reply to tsuibin from comment #1)
> I added MIPS support to gccgo.
> But I don't know how to submit a patch to gccgo
> 
> My code is here :
> https://github.com/tsuibin/libgo_mips_elf_support/blob/master/
> libgo_mips_elf_support.patch
> 
> and here:
> https://github.com/tsuibin/libffi_mips_go_closure/blob/master/
> libffi_mips_go_closure.patch

You rule!


I've compiled MIPS processor GCCGO not passed.

But, do you have a new version of the patch it?

[Bug c/29280] misleading warning for assignment used as truth construct

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2010-02-21 00:38:52 |2016-4-15
 CC||msebor at gcc dot gnu.org
  Known to fail||4.0.0, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.0

--- Comment #5 from Martin Sebor  ---
It seems like it should be trivial to enhance the warning by adding a note with
the suggestion(s) mentioned in the request.

For reference, the following is what Clang prints:

$ cat t.c && clang -S -Wparentheses t.c
int f (int a, int b)
{
if (a = b)
return 1;
return 2;
}
t.c:3:11: warning: using the result of an assignment as a condition without
  parentheses [-Wparentheses]
if (a = b)
~~^~~
t.c:3:11: note: place parentheses around the assignment to silence this warning
if (a = b)
  ^
()
t.c:3:11: note: use '==' to turn this assignment into an equality comparison
if (a = b)
  ^
  ==
1 warning generated.

[Bug c++/70616] [4.9/5/6/7 Regression] ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Is this a valid test case?

[Bug libfortran/70684] [Regression 5.3, 6] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
This slightly modified version of the testcase shows the bug with Linux:

program test
implicit none
integer,parameter :: isize=12
integer,parameter :: funit=12
integer :: i
character(1), parameter :: cr=char(13)

double precision, dimension(isize) :: a

do i=1,isize
 a(i)=dble(i)
enddo

write(6,*)'Value to write'
do i=1,isize
 write(6,*)a(i)
enddo

open(funit,file='test.txt')
write(funit,'(1x,6(f25.20,'',''),a)') (a(i),i=1,6), cr
write(funit,'(1x,6(f25.20,'',''),a)') (a(i),i=7,12), cr
close(funit)

do i=1,isize
 a(i)=0d0
enddo

open(funit,file='test.txt')
read(funit,*) (a(i),i=1,isize)
close(funit)

write(6,*)'Values after read'
do i=1,isize
 write(6,*)a(i)
enddo

end

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #26 from Martin Jambor  ---
(In reply to Josh Poimboeuf from comment #24)
> 
> Yes, I'm looking for a general way to either prevent or try to detect
> potential other cases of the bug throughout the entire kernel.
> 
> Can it only occur with the use of __builtin_constant_p(exp) by an inline
> function (where exp is a constant)?

Yes and no.  Yes, the problematic inlining analysis predicate
condition type IS_NOT_CONSTANT is only created for conditions
containing a call to __builtin_constant_p.  But no, a function does
not have to be explicitly marked inline to be an inline candidate.

This bug can occur when an inlineable function containing a call to
__builtin_constant_p, which checks a parameter or a value it
references and a (possibly indirect) caller of the function actually
passes a constant, but stores it using a type of a different size.

In your testcase, the array initialization is a series of byte stores
but the "load" in __swab64p is 64-bit.  Note that gcc cannot detect
that the parameter in your testcase was actually a compile-time
constant.  IPA level does by mistake and removes the slow path which
is later selected for real (this can be improved if deemed worthwhile
but IPA analysis still needs to check the size to be correct).

[Bug sanitizer/70624] [6/7 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
This is fixed on x86_64-apple-darwin10 without regression on
x86_64-apple-darwin15 by the following patch

--- ../_clean/libsanitizer/asan/asan_mac.cc 2015-11-23 10:17:05.0
+0100
+++ libsanitizer/asan/asan_mac.cc   2016-04-15 13:22:01.0 +0200
@@ -97,10 +97,14 @@ void DisableReexec() {
   reexec_disabled = true;
 }

-extern "C" double dyldVersionNumber;
+extern "C" SANITIZER_WEAK_ATTRIBUTE double dyldVersionNumber;
 static const double kMinDyldVersionWithAutoInterposition = 360.0;

 bool DyldNeedsEnvVariable() {
+  // Although sanitizer support was added to LLVM on Darwin 10.7+, GCC users
+  // still may want use them on older systems. On older Darwin platforms, dyld
+  // doesn't export dyldVersionNumber symbol and we simply can return true.
+  if (!) return true;
   // If running on OS X 10.11+ or iOS 9.0+, dyld will interpose even if
   // DYLD_INSERT_LIBRARIES is not set. However, checking OS version via
   // GetMacosVersion() doesn't work for the simulator. Let's instead check

[Bug c++/70552] __builtin_constant_p fails to reflect the constness of constexpr calls

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
I'm going to confirm this report on the basis of others similar to it, such as
bug 19449 which has some interesting background.  The patch referenced from it
sets a precedent for the intrinsic treating constant expressions as constant
despite its late evaluation under "normal" circumstances (the
force_folding_builtin_constant_p global variable was put in place to circumvent
this delayed evaluation).  cxx_eval_builtin_function_call() in cp/constexpr.c
does set force_folding_builtin_constant_p to true, making it clear that the
intent is for the intrinsic to be evaluated during constexpr evaluation in C++.
 Something seems to be interfering with it (I just haven't yet figured out
what).

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #25 from Martin Jambor  ---
(In reply to Martin Jambor from comment #22)
> I suppose the easiest fix is to overload the value field to store the
> size of the access for these two codes and then add the missing check.

OK, so the IS_NOT_CONSTANT case is relatively easy, the following
(untested) patch fixes this PR:

diff --git a/gcc/ipa-inline-analysis.c b/gcc/ipa-inline-analysis.c
index f8ca825..6901cfb 100644
--- a/gcc/ipa-inline-analysis.c
+++ b/gcc/ipa-inline-analysis.c
@@ -867,8 +867,14 @@ evaluate_conditions_for_known_args (struct cgraph_node
*node,
  clause |= 1 << (i + predicate_first_dynamic_condition);
  continue;
}
-  if (c->code == IS_NOT_CONSTANT || c->code == CHANGED)
+  if (c->code == CHANGED)
continue;
+  if (c->code == IS_NOT_CONSTANT)
+   {
+ if (!operand_equal_p (c->val, TYPE_SIZE (TREE_TYPE (val)), 0))
+   clause |= 1 << (i + predicate_first_dynamic_condition);
+ continue;
+   }

   if (operand_equal_p (TYPE_SIZE (TREE_TYPE (c->val)),
   TYPE_SIZE (TREE_TYPE (val)), 0))
@@ -1807,8 +1813,9 @@ set_cond_stmt_execution_predicate (struct
ipa_func_body_info *fbi,
 return;
   FOR_EACH_EDGE (e, ei, bb->succs) if (e->flags & EDGE_FALSE_VALUE)
 {
+  tree opsize = unshare_expr_without_location (TYPE_SIZE (TREE_TYPE
(op2)));
   struct predicate p = add_condition (summary, index, ,
- IS_NOT_CONSTANT, NULL_TREE);
+ IS_NOT_CONSTANT, opsize);
   e->aux = edge_predicate_pool.allocate ();
   *(struct predicate *) e->aux = p;
 }

On the other hand, the CHANGED part is more difficult because an
unchanged value is represented with an error_mark_node which of course
does not encode the size of the unchanged value.  So if we wanted to
handle it, we'd need to encode it differently.  However, I am not
convinced it is necessary because, unless I'm forgetting about
something, it is only used as inlining heuristics and can never lead
to any optimizations and thus neither to miscompilations.  Am I right?

In any event, I'd like to talk to Honza bout this before going any
further.

[Bug libfortran/70684] [Regression 5.3, 6] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
Summary|incorrect reading of values |[Regression 5.3, 6]
   |from file on Windows|incorrect reading of values
   ||from file on Windows
 Ever confirmed|0   |1

--- Comment #2 from Jerry DeLisle  ---
Confirmed, works on 4.9 Fails on 5.3

Marking as a regression.

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

[jpoimboe at redhat dot com]

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

--- Comment #24 from Josh Poimboeuf  ---
(In reply to Martin Jambor from comment #23)
> (In reply to Josh Poimboeuf from comment #20)
> > Thanks very much to everyone who has looked into this so far.  It would be
> > very helpful to get answers to the following questions, so we can understand
> > the impact to the kernel:
> > 
> > 1) Is there a reliable way to avoid the bug, either in code or with a gcc
> > flag?
> 
> If you mean in general, then unfortunately no, except for disabling
> inlining altogether and removing all always_inline's.  In addition to
> the main bug, I found out that I check --param ipa-max-agg-items only
> after incrementing it, so even setting that to zero does not help.
> I'll prepare a patch for that too.

Yes, I'm looking for a general way to either prevent or try to detect potential
other cases of the bug throughout the entire kernel.

Can it only occur with the use of __builtin_constant_p(exp) by an inline
function (where exp is a constant)?

[Bug target/70682] [7 Regression] -fcompare-debug building LLVM with checking=release compiler on ppc64le

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-04-15
 CC||jakub at gcc dot gnu.org
 Resolution|FIXED   |---
   Target Milestone|--- |7.0
Summary|[6/7 Regression]|[7 Regression]
   |-fcompare-debug building|-fcompare-debug building
   |LLVM with checking=release  |LLVM with checking=release
   |compiler on ppc64le |compiler on ppc64le
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
But we want to revert that change in GCC 7.
What happens is that the SRA fancy name (plus concatenated SSA version, which
already would require small tweak to the fancy name pretty printer for
TDF_NOUID) is passed to:
#0  vect_get_new_vect_var (type=0x7fffd931bb28, var_kind=vect_simple_var,
name=0x9decc50 "begin_iterator$D850593$I_667")
at ../../gcc/tree-vect-data-refs.c:3951
and that function instead of keeping that name in that form and making sure to
make the var DECL_NAMELESS too and use weirdo chars to concatenate (like $)
ends up calling clean_symbol_name which throws away (needlessly, these symbols
shouldn't ever make it into debug info) the '$' chars etc.

[Bug c/69960] "initializer element is not constant"

[bernds at gcc dot gnu.org]

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

--- Comment #13 from Bernd Schmidt  ---
I actually tried this a few weeks ago, it's slightly less trivial than it seems
since you don't want to fold away the inside of &("fish"[0]).

[Bug rtl-optimization/70484] [4.9 Regression] Wrong optimization with aliasing and access via char

[ch3root at openwall dot com]

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

--- Comment #7 from Alexander Cherepanov  ---
On 04/04/2016 12:37 PM, rguenth at gcc dot gnu.org wrote:
> Fixed on trunk sofar.

Thanks. I've checked some variations of the original testcase -- 
everything works fine now.

[Bug c/70688] New: bogus OpenACC data clause errors involving reductions

[cesar at gcc dot gnu.org]

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

Bug ID: 70688
   Summary: bogus OpenACC data clause errors involving reductions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: c
  Assignee: cesar at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38285
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38285=edit
test case

Here is the output of the attached test case when it is build with -fopenacc:

tr1.c: In function ‘sum’:
tr1.c:12:9: error: ‘s’ appears both in data and map clauses
 #pragma acc parallel num_gangs (10) copy (s) reduction (+:s)
 ^~~

There are two problems with this. 1) the c FE should not be reporting a data
map clause error on a reduction variable. 2) That error only gets detected some
of the time, depending on the ordering of the clauses (e.g. a data clause
involving variable 'v' appears before a reduction clause involving 'v' in the
clause list). A third problem would be that this error message is not specific
to OpenACC.

The c++ FE also has a similar problem.

[Bug libfortran/70684] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
You are doing list direct reads here.  You will see where /r is treated as a
separator. Regardless, this has all worked before without a problem, so it may
be your build of gcc has a problem.

I will investigate here a bit with your test case and get back to you.

[Bug c/59753] -Woverflow warning inconsistency with signed constant conversion between T_MAX+1 and UT_MAX vs larger than UT_MAX

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Martin Sebor  ---
Confirming for the inconsistency.  See also bug 41138 for what might be a
related or even the same problem.

[Bug c/41138] Inconsistent (incorrect?) "overflow in implicit constant conversion" warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
 Ever confirmed|0   |1
  Known to fail||4.0.0, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.0

--- Comment #4 from Martin Sebor  ---
Since there is at least one other report complaining about this warning (bug
59753) I'll confirm it as a bug.

[Bug c/59562] __builtin_assume_aligned loses constness when used as initializer element

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
I agree that the builtin should evaluate to a constant expression when its
argument does.  The same could be said about many other builtins as well (see
for example bug 68120, and the C++ bug 70507).

Confirmed:

$ cat v.c && gcc -S -Wall -Wextra -Wpedantic -xc v.c
int i = 0;
int *p = 
void *q = __builtin_assume_aligned (p, 4);

v.c:3:11: error: initializer element is not constant
 void *q = __builtin_assume_aligned (p, 4);
   ^~~~

[Bug rtl-optimization/70687] Undefined shift in change_zero_ext in combine.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
This works for me:

diff --git a/gcc/combine.c b/gcc/combine.c
index 1d0e8be..197b9da 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -11101,6 +11101,9 @@ change_zero_ext (rtx *src)
  && subreg_lowpart_p (XEXP (x, 0)))
   {
 size = GET_MODE_PRECISION (GET_MODE (XEXP (x, 0)));
+/* Check for undefined shift.  */
+if (size >= HOST_BITS_PER_WIDE_INT)
+  continue;
 x = SUBREG_REG (XEXP (x, 0));
   }
   else

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #23 from Martin Jambor  ---
(In reply to Josh Poimboeuf from comment #20)
> Thanks very much to everyone who has looked into this so far.  It would be
> very helpful to get answers to the following questions, so we can understand
> the impact to the kernel:
> 
> 1) Is there a reliable way to avoid the bug, either in code or with a gcc
> flag?

If you mean in general, then unfortunately no, except for disabling
inlining altogether and removing all always_inline's.  In addition to
the main bug, I found out that I check --param ipa-max-agg-items only
after incrementing it, so even setting that to zero does not help.
I'll prepare a patch for that too.

If you want to avoid it at a particular place where you know it
already occurs, then it depends on how the code looks like.  Would for
the following work for you?

  void __attribute__((noinline,noclone)) broken(u64* shost)
  {
   u8 node_name[8];
   memset (_name, 0xFF, sizeof (node_name));
   *shost = wwn_to_u64(node_name);
  }

> 
> 2) Is there a reliable way to detect the bug by looking at the object code?

I cannot think of any.

[Bug rtl-optimization/70687] New: Undefined shift in change_zero_ext in combine.c

[hjl.tools at gmail dot com]

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

Bug ID: 70687
   Summary: Undefined shift in change_zero_ext in combine.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

change_zero_ext in combine.c has

 else if (GET_CODE (x) == ZERO_EXTEND
   && GET_CODE (XEXP (x, 0)) == SUBREG
   && GET_MODE (SUBREG_REG (XEXP (x, 0))) == mode
   && subreg_lowpart_p (XEXP (x, 0)))
{
  size = GET_MODE_PRECISION (GET_MODE (XEXP (x, 0))); 
  x = SUBREG_REG (XEXP (x, 0));
}
  else  
continue;

  unsigned HOST_WIDE_INT mask = 1;
  mask <<= size; 
  mask--;

  x = gen_rtx_AND (mode, x, GEN_INT (mask));

For

(gdb) call debug_rtx (*src)
(zero_extend:TI (subreg:DI (reg/v:TI 91 [ ixi ]) 0))

we got

(gdb) call debug_rtx (*src)
(zero_extend:TI (subreg:DI (reg/v:TI 91 [ ixi ]) 0))
(gdb) p size
$9 = 64
(gdb) p sizeof (mask)
$10 = 8

mask <<= size;

is wrong here, which leads to

(and:TI (reg/v:TI 91 [ ixi ])
(const_int 0 [0]))

[Bug c++/70685] [6/7 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Apr 15 19:53:03 2016
New Revision: 235046

URL: https://gcc.gnu.org/viewcvs?rev=235046=gcc=rev
Log:
PR c++/70685
* constexpr.c (get_fundef_copy): Handle null *slot.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-hana1.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c

[Bug c++/70685] [6/7 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Apr 15 19:47:19 2016
New Revision: 235045

URL: https://gcc.gnu.org/viewcvs?rev=235045=gcc=rev
Log:
PR c++/70685
* constexpr.c (get_fundef_copy): Handle null *slot.

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

[Bug c++/70685] [6/7 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/70685] [6/7 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jason Merrill  ---
Broken by r235033, the constexpr call GC patch.

[Bug c/59976] Spurious warning on converting const int variable to unsigned long (Also inconsistency between O0 and O1)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  The warning is also inconsistent between C and C++ modes, likely
because G++ treats the constant b as a constant expression regardless of
optimization while GCC treats it as an ordinary variable with an unknown value
(i.e., it doesn't fold its value without optimization).

This would be solved by making GCC more aggressive about constant folding and
treating more expressions as constant expressions, as requested for example in
bug 69960.  It might be worth to collect the kinds of expressions that could be
considered constant so that they can all be considered at the same time if/when
someone decides to put together a patch for one (or more) of these bugs.

$ cat v.c && gcc -S -Wconversion -xc v.c
unsigned g;
void fn1() {
  int a;
  const unsigned char b = 0;
  a = b & g;
}
v.c: In function ‘fn1’:
v.c:5:7: warning: conversion to ‘int’ from ‘unsigned int’ may change the sign
of the result [-Wsign-conversion]
   a = b & g;
   ^

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #22 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #18)
> Jakub: There is indeed aliasing issue, but with -fno-strict-aliasing the bug
> is the same.
> 
> Apparently this is ipa-prop bug, because ipa-prop does not track size of
> accesses and thus it does not know there is a mismatch. The value produced
> is thus not INT_MAX as intended but 255. This is Martin's area.

ipa-prop does not track accesses or their sizes, inlining predicate
conditions do.

Anyway, I checked the two places where access sizes need to be checked
(i.e. ipcp_modif_dom_walker::before_dom_children in ipa-prop.c and
evaluate_conditions_for_known_args in ipa-inline-analysis.c) and they
actually are checked, with one exception causing this bug.

The exception is evaluating IS_NOT_CONSTANT and CHANGED types of
conditions in evaluate_conditions_for_known_args, which does not check
access size for them because the size is not even tracked for them
(for normal conditions, size is the size of the stored value to
compare with).

I suppose the easiest fix is to overload the value field to store the
size of the access for these two codes and then add the missing check.

[Bug c/69960] "initializer element is not constant"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||devel at fresse dot org

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

[Bug c/54823] string literal characters not a constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2016-4-15
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE
Summary|string literal characters   |string literal characters
   |not constant|not a constant expression
   Severity|normal  |enhancement

--- Comment #6 from Martin Sebor  ---
I think this request is a duplicate of bug 69960 (or rather the other way
around).  Since, based on the feedback of other GCC developers, I've just
confirmed the request in the other bug I'll close this one as a duplicate of
the other.

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

[Bug c/69960] "initializer element is not constant"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #11 from Martin Sebor  ---
Seems like there is agreement that this would be a useful enhancement so I'll
mark this enhancement request as accepted by changing its Status to New (and
its Severity to Enhancement).

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||mueller at kde dot org

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

[Bug c/20562] no unused warning for static const arrays

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||6.0
 Resolution|--- |DUPLICATE
  Known to fail||4.0.0, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0

--- Comment #9 from Martin Sebor  ---
This has been resolved in 6.0 via the -Wunused-const-variable option (see bug
28901).

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

[Bug c++/70685] [6/7 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat sum.ii
namespace std {
template  struct A { static constexpr _Tp value = __v;
};
typedef A false_type;
template  using conditional_t = _Iftrue;
namespace hana {
template  struct is_default : false_type {};
template  struct tag_of;
struct deleted_implementation;
namespace detail {
namespace operators {
template  struct adl {};
}
}
template  struct B;
template  struct G : std::A {};
template  G integral_c;
template  using int_ = G;
template  int_ int_c;
template  struct C;
template  struct D {
  template  auto operator()(X... x) {
return C::apply(x...);
  }
};
template  D make;
template  struct unpack_impl;
struct Foldable {
  using Tag = int;
  static constexpr int value = is_default::value;
};
struct range_tag;
auto make_range = make;
template  struct sum_impl;
template  struct F;
template > F sum;
template 
struct range : detail::operators::adl> {};
template  struct tag_of> {
  using type = range_tag;
};
template <> struct C {
  template  static auto apply(From, To) {
using T = int;
constexpr T from(From::value);
constexpr T to(To::value);
return range{};
  }
};
template <> struct sum_impl {
  template  static constexpr I sum_helper(I m, I n) {
if (m == n)
  return 0;
return sum_helper(0, 0);
  }
  template  static auto apply(range) {
integral_c;
  }
};
template  struct F {
  template  auto operator()(Xs xs) {
using S = typename tag_of::type;
using Sum =
conditional_t;
Sum::apply(xs);
  }
};
}
auto __hana_tmp_22 =
(hana::sum<>(hana::make_range(hana::int_c<-3>, hana::int_c<-2>)),
 hana::sum<>(hana::make_range(hana::int_c<3>, hana::int_c<7>)),
 hana::int_c<6>);
}

[Bug c/70686] New: -fprofile-generate (not fprofile-use) somehow produces much faster binary

[alekshs at hotmail dot com]

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

Bug ID: 70686
   Summary: -fprofile-generate (not fprofile-use) somehow produces
much faster binary
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alekshs at hotmail dot com
  Target Milestone: ---

I have this small benchmark that does 100mn loops of 20 divisions by 2.
Periodically it bumps up the values so that it continues to have something to
divide /2. I time this and see the results. 

---



#include  
#include  
#include 

int main() 
{
printf("\n");

const double a = 333.3456743289;  //initial randomly assigned values to
start halving
const double aa = 555.444334244;
const double aaa = 777.;
const double  = 3276.123458;

unsigned int i;
double score;
double g; //the number to be used for making the divisions, so essentially
halving everything each round

double b; 
double bb;
double bbb;
double ;

g = 2;  

b = a;
bb = aa;
bbb = aaa;
 = ;

double total_time;
clock_t start, end;

start = 0;
end = 0;
score = 0;

start = clock();

 for (i = 1; i <10001; i++) 
 {
   b=b/g;
   b=b/g;
   b=b/g;
   b=b/g;
   b=b/g;
   bb=bb/g;
   bb=bb/g;
   bb=bb/g;
   bb=bb/g;
   bb=bb/g;
   bbb=bbb/g;
   bbb=bbb/g;
   bbb=bbb/g;
   bbb=bbb/g;
   bbb=bbb/g;
   =/g;
   =/g;
   =/g;
   =/g;
   =/g;

   if (b< 1.001)  {b=b+i+12.432432432;}  //just adding more stuff  in
order for the number
   if (bb   < 1.001)  {bb=bb+i+15.4324442;}  //to return back to larger
values after several
   if (bbb  < 1.001)  {bbb=bbb+i+19.42884;}  //rounds of halving
   if ( < 1.001)  {=+i+34.481;} 
}

 end = clock();

 total_time = ((double) (end - start)) / CLOCKS_PER_SEC * 1000;

 score = (1000 / total_time);
 printf("\nFinal number: %0.20f", (b+bb+bbb+));

 printf("\nTime elapsed: %0.0f msecs", total_time);   
 printf("\nScore: %0.0f\n", score);

 return 0;
}
---



This is run on a quad q8200 @ 1.75ghz

Now notice the times:

gcc Maths4asm.c -lm -O0  => 6224ms
gcc Maths4asm.c -lm -O2 and -O3  => 1527ms
gcc Maths4asm.c -lm -Ofast  => 1227ms
gcc Maths4asm.c -lm -Ofast -march=nocona => 1236ms
gcc Maths4asm.c -lm -Ofast -march=core2 => 1197ms  (I have a core quad,
technically it's core2 arch)
gcc Maths4asm.c -lm -Ofast -march=core2 -fprofile-generate => 624ms.
gcc Maths4asm.c -lm -Ofast -march=nocona -fprofile-generate => 530ms. 
gcc Maths4asm.c -lm -Ofast -march=nocona -fprofile-use => 1258ms (slower than
without PGO, slower than -fprofile-generate)
gcc Maths4asm.c -lm -Ofast -march=core2 -fprofile-use => 1222ms (slower than
without PGO, slower than -fprofile-generate).

So PGO optimization made it worse, but the most mindblowing thing is the
running of the profiler, getting execution times down to 530ms. The profiler
run (-generate) should normally take this to 4000-5000ms or above, as it
monitors the process to create a log file. 

I have never run into a -fprofile-generate build that wasn't at least 2-3 times
slower than a normal build - let alone 2-3 times faster. This is totally
absurd. 

And then, to top it all, -fprofile-use (using the logfile to create the best
binary) created worse binaries. 

Oh, and "nocona" (pentium4+) suddenly became ...the better architecture instead
of core2.

This stuff is almost unbelievable. I thought initially that the profiler must
be activating multithreading, but no. I scripted simultaneous use of 4 runs,
they all give the same time - that means, there was no extra cpu use in other
threads.

The implication of all these is that if -fprofile-generate can somehow give
code that is executing at 500ms, and the non -fprofile-generate binaries are
running at 1200ms, then serious performance is left on the table on normal
builds.

[Bug c++/70685] New: [6/7 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Bug ID: 70685
   Summary: [6/7 Regression] ICE: Segmentation fault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38284
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38284=edit
unreduced testcase

A very recent regression. Was fine a yesterday.

markus@x4 /tmp % clang++ -std=c++14 -c sum.ii
markus@x4 /tmp % g++ -c sum.ii
In file included from ../libs/hana/test/range/sum.cpp:9:0:
../boost/hana/range.hpp: In instantiation of ‘static constexpr auto
boost::hana::sum_impl::apply(const
boost::hana::range&) [with  =
boost::hana::integral_constant_tag; T = int; T from = -3; T to = -1]’:
../boost/hana/sum.hpp:45:42:   required from ‘constexpr decltype(auto)
boost::hana::sum_t::operator()(Xs&&) const [with Xs =
boost::hana::range; M = boost::hana::integral_constant_tag]’
../libs/hana/test/range/sum.cpp:23:102:   required from here
../boost/hana/range.hpp:187:61:   in constexpr expansion of
‘boost::hana::sum_impl::sum_helper(-3, (-1 - 1))’
../boost/hana/range.hpp:182:35:   in constexpr expansion of
‘boost::hana::sum_impl::sum_helper((- n), (- m))’
../boost/hana/range.hpp:187:20: internal compiler error: Segmentation fault

[Bug libstdc++/65434] Memory leak in pool constructor

[lopresti at gmail dot com]

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

Patrick J. LoPresti  changed:

   What|Removed |Added

 CC||lopresti at gmail dot com

--- Comment #5 from Patrick J. LoPresti  ---
Seems pretty sloppy not to free what you allocate, and then demand all leak
checking tools forever work around the sloppiness... Even if you are the
runtime.

Couldn't you fix this by using the init_priority attribute on emergency_pool?

Alternatively, do like any application would and use a Meyers singleton instead
of a global variable? Like so:

namespace {
  pool _pool()
{
  static pool emp;
  return emp;
}
}

Since destructors always run in the opposite order of construction, you would
just need to make sure you obtain the first reference early enough.

[Bug c/70668] nds32-elf toolchain fails to compile on OSX

[stefan.reinauer at coreboot dot org]

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

--- Comment #5 from Stefan Reinauer  ---
Created attachment 38283
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38283=edit
Fix for the issue

[Bug c/70668] nds32-elf toolchain fails to compile on OSX

[stefan.reinauer at coreboot dot org]

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

--- Comment #4 from Stefan Reinauer  ---
Thanks to Segher Boessenkool, https://review.coreboot.org/#/c/14380/2 fixes the
issue.

[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Fri Apr 15 17:03:33 2016
New Revision: 235043

URL: https://gcc.gnu.org/viewcvs?rev=235043=gcc=rev
Log:
PR c++/67164

* pt.c (copy_template_args): New.
(tsubst_pack_expansion): Use it.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/variadic-tuple2.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c

[Bug libfortran/70684] New: incorrect reading of values from file on Windows

[ajmay81 at googlemail dot com]

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

Bug ID: 70684
   Summary: incorrect reading of values from file on Windows
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ajmay81 at googlemail dot com
  Target Milestone: ---

When writing and then reading back values from a file on Windows (program built
with gfortran via mxe cross compiler) the wrong values are read. Here is a
trivial example:

program test
implicit none
integer,parameter :: isize=12
integer,parameter :: funit=12
integer :: i
double precision, dimension(isize) :: a
do i=1,isize
 a(i)=dble(i)
enddo

write(6,*)'Value to write'
do i=1,isize
 write(6,*)a(i)
enddo

open(funit,file='test.txt')
write(funit,'(1x,6(f25.20,'',''))') (a(i),i=1,isize)
close(funit)

do i=1,isize
 a(i)=0d0
enddo

open(funit,file='test.txt')
read(funit,*) (a(i),i=1,isize)
close(funit)

write(6,*)'Values after read'
do i=1,isize
 write(6,*)a(i)
enddo

end

And compiled with:

x86_64-w64-mingw32.static-gfortran test.f90

On Linux the values 1-12 are read, but on Windows the values 1-6,0,7-11 are
read. It seems that the file is written with Windows line endings on Windows,
but when read Linux line endings are expected. I think it should be consistent,
at least one should be able to read files back on the same system they are
generated.

I grepped through a recent 5.3.0 tarball, and it's a bit of a guess but in
libgfortran/io/transfer.c the function next_record_r() knows only about '\n'
line endings, yet it's opposite number next_record_w() knows about both '\n'
and '\r' - so perhaps the same logic just needs copying to the read function?

[Bug c++/70505] [4.9/5/6/7 Regression] Constexpr failure when template type specified

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Apr 15 16:32:22 2016
New Revision: 235042

URL: https://gcc.gnu.org/viewcvs?rev=235042=gcc=rev
Log:
PR c++/70505

* pt.c (tsubst_baselink): Give the new TEMPLATE_ID_EXPR
unknown_type_node, too.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug target/70682] [6/7 Regression] -fcompare-debug building LLVM with checking=release compiler on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
The issue was fixed by r235033. Closing.

[Bug c++/64329] Crash when returning reference from lambda with deduced type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Michael Stahl from comment #1)
> i believe i've hit the same problem

I don't think so. The original bug report is for 4.9.3, and seems to be an
actual compiler bug that is fixed already in GCC 5 and later.

Your case is invalid code. While I agree a warning would be nice, it's not the
same as a bug in 4.9.3 that has been fixed.

[Bug c++/64329] Crash when returning reference from lambda with deduced type

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Oops, the original report was for 4.9.1, but the bug is still present in 4.9.3

[Bug c++/64329] Crash when returning reference from lambda with deduced type

[mstahl at redhat dot com]

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

Michael Stahl  changed:

   What|Removed |Added

 CC||mstahl at redhat dot com

--- Comment #1 from Michael Stahl  ---
i believe i've hit the same problem, here's the footgun reproducer i came up
with:



#include 
#include 

int foo = 42;

int const& bar()
{   
return foo;
}

int main()
{   
std::function f{ [] () { return bar(); } };
int const& rfoo = f();
printf("%p %p\n", (void*), (void*));
return  == 
}


this is g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)

> g++ -std=c++11 -Wall -Wextra -pedantic -Weffc++ -W lambdaref.cc  && ./a.out 
0x60204c (nil)


the problem is that the deduced return type of the lambda is a value
type, never a reference type.  this caught me by surprise, but it's
the same rule as for "auto".

if the C++ committee has to make surprising and error-prone type
inference rules, then at least implementations like g++ could
give a warning about returning a reference from a lambda that
is implicitly copied to a value, only to be implicitly converted
again into nothing.

Visual Studio 2013 gives a "warning C4172 returning address of local
variable or temporary" from somewhere inside its std::function code.

[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 15 15:53:01 2016
New Revision: 235040

URL: https://gcc.gnu.org/viewcvs?rev=235040=gcc=rev
Log:
PR target/70662
* config/i386/sse.md (define_insn "_vec_dup"):
Fix mode size check.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/sse.md

[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi

[kyukhin at gcc dot gnu.org]

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

--- Comment #6 from Kirill Yukhin  ---
Author: kyukhin
Date: Fri Apr 15 15:17:31 2016
New Revision: 235038

URL: https://gcc.gnu.org/viewcvs?rev=235038=gcc=rev
Log:
AVX-512. Fix mode size check.

PR target/70662
gcc/   
   * config/i386/sse.md(define_insn "_vec_dup"):
Fix mode size check.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi

[kyukhin at gcc dot gnu.org]

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

--- Comment #5 from Kirill Yukhin  ---
Author: kyukhin
Date: Fri Apr 15 15:13:42 2016
New Revision: 235037

URL: https://gcc.gnu.org/viewcvs?rev=235037=gcc=rev
Log:
AVX-512, Fix mode size check.

PR target/70662
gcc/
* config/i386/sse.md(define_insn "_vec_dup"):
Fix mode size check.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/sse.md

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[jakub at gcc dot gnu.org]

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

--- Comment #51 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 15 14:51:06 2016
New Revision: 235033

URL: https://gcc.gnu.org/viewcvs?rev=235033=gcc=rev
Log:
PR c++/70594
* constexpr.c (constexpr_call_table): Preserve in GC.
(struct fundef_copy, struct fundef_copies_table_t): Delete.
(fundef_copies_table): Preserve in GC. Change to pointer to
tree->tree hash.
(maybe_initialize_fundef_copies_table): Adjust.
(get_fundef_copy): Return a TREE_LIST.  Use non-inserting search.
(save_fundef_copy): Adjust for a TREE_LIST.
(cxx_eval_call_expression): Adjust for a fundef_copy TREE_LIST.
(fini_constexpr): New.
* cp-tree.h (fini_constexpr): Declare.
* decl2.c (c_parse_final_cleanups): Call fini_constexpr.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c

[Bug sanitizer/70683] [6 Regression] -fcompare-debug bug with -fsanitize=address

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
I guess most or all hash tables using iterative_hash_expr as hashing function
and operand_equal_p as comparison function are affected.

[Bug c/70671] Wrong column number shown for "error: cannot take address of bit-field"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c/70671] Wrong column number shown for "error: cannot take address of bit-field"

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Apr 15 14:46:06 2016
New Revision: 235032

URL: https://gcc.gnu.org/viewcvs?rev=235032=gcc=rev
Log:
PR c/70671
* c-typeck.c (build_unary_op): Pass location down to error and
warning call.

* gcc.dg/bitfld-22.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/bitfld-22.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de  ---
On April 15, 2016 3:31:33 PM GMT+02:00, "hubicka at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
>
>--- Comment #16 from Jan Hubicka  ---
>> Honza?  This seems to be somewhat fragile (redirecting things to
>unreachable
>> but _not_ changing the actual predicates in the IL).  Claiming the
>> predicate is constant true is also a bit bogus (as can be seen in
>following
>> optimization).
>
>At WPA stage inliner can not update IL, so it simply redirects to
>builtin_unreachable if predicate is FALSE and expects scalar passes to
>be
>monotonously smarter than IPA analysis. 
>
>BB3 predicate true is conservatively correct: there is no predicate to
>represent that something is not constant because we assume scalar
>optimizers to
>possibly be stronger than us and decide better.
>
>Here we manage to assume that builtin_constant_p is true and thus we
>conclude
>the following BB is unreachable:
>BB 4 predicate:(op0[ref offset: 0] not constant)   
>   
>iftmp.0_26 = __builtin_bswap64 (_3);   
>  
>freq:0.61 size:  1 time:  1
>This is because ipa-prop analyzes the values in node_name:
>
>Jump functions of caller  broken/2:
>  
>callsite  broken/2 -> wwn_to_u64/1 :   
>
>param 0: UNKNOWN   
> 
>Aggregate passed by reference: 
>  offset: 0, cst: 255  
>  offset: 8, cst: 255  
>  offset: 16, cst: 255 
>  offset: 24, cst: 255 
>  offset: 32, cst: 255 
>  offset: 40, cst: 255 
>  offset: 48, cst: 255 
>  offset: 56, cst: 255 
>
>but later we fold:
>
>:
>  
>node_name[0] = 255;
>  
>node_name[1] = 255;
>  
>node_name[2] = 255;
>  
>node_name[3] = 255;
>  
>node_name[4] = 255;
>  
>node_name[5] = 255;
>  
>node_name[6] = 255;
>  
>node_name[7] = 255;
>  
>_14 = MEM[(const u64 *)_name];
>  
>_15 = __builtin_constant_p (_14);  
>  
>
>into false (which is stupid, but conservatively correct modulo the
>assumption
>about IPA passes being consistently weakter than local passes).
>
>Making IPA passes to fold builtin_constant_p call into true is
>technically
>possible, if I add builtin_true and redirect to it, but it would not be
>very
>good if the local passes can not fold above (as the wrong arm is
>taken).
>
>So can we possibly fix the local passes?You can't rely on this happening, 
>consider -fno-foo.

So my original local hack was to not do this built-in constant stuff for
is_refp

Richard.

>Honza

[Bug sanitizer/70683] New: [6 Regression] -fcompare-debug bug with -fsanitize=address

[jakub at gcc dot gnu.org]

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

Bug ID: 70683
   Summary: [6 Regression] -fcompare-debug bug with
-fsanitize=address
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

On a testcase that has been provided privately to me and I can't share (and
that can't be easily reduced), I'm seeing differences in sanopt optimization,
without -gtoggle ASAN_CHECK is optimized away, while with -gtoggle it is.
maybe_optimize_asan_check_ifn works with a hash_map using tree_operand_hash.
What I'm seeing is that in both cases we first process ASAN_CHECK with ptr
_nullId.m_id
which is ADDR_EXPR of COMPONENT_REF of VAR_DECL, and then later on there is
ASAN_CHECK with ptr
_nullId.m_id
which is actually ADDR_EXPR of COMPONENT_REF of MEM_REF of ADDR_EXPR of
VAR_DECL.
The FIELD_DECL and VAR_DECL in both cases are the same.
Now, because of the VAR_DECL vs. MEM_REF[_DECL, 0] difference both hash
differently using iterative_hash_expr.
Unlike the hash, the comparison is done using operand_equal_p (, , 0), which
has:
2833  else if (flags & OEP_ADDRESS_OF)
2834{
2835  /* If we are interested in comparing addresses ignore
2836 MEM_REF wrappings of the base that can appear just for
2837 TBAA reasons.  */
2838  if (TREE_CODE (arg0) == MEM_REF
2839  && DECL_P (arg1)
2840  && TREE_CODE (TREE_OPERAND (arg0, 0)) == ADDR_EXPR
2841  && TREE_OPERAND (TREE_OPERAND (arg0, 0), 0) == arg1
2842  && integer_zerop (TREE_OPERAND (arg0, 1)))
2843return 1;
2844  else if (TREE_CODE (arg1) == MEM_REF
2845   && DECL_P (arg0)
2846   && TREE_CODE (TREE_OPERAND (arg1, 0)) == ADDR_EXPR
2847   && TREE_OPERAND (TREE_OPERAND (arg1, 0), 0) == arg0
2848   && integer_zerop (TREE_OPERAND (arg1, 1)))
2849return 1;
2850  return 0;
2851}
and thus returns that the two are equal.  While both of the decls in here
(VAR_DECL and FIELD_DECL) have the same DECL_UID for no -gtoggle vs. -gtoggle,
I presume the problem is that there are other tree expressions pushed into the
hash_map as keys that have some DECL_UID differences somewhere, in any case
both the hash maps have the same number of elements, but report different
number of collisions (note debug stmts never query anything, so that is not the
issue).

So, I believe the bug is that we have a hash function that can return different
hashes even for objects that compare equal by the comparison function, so it is
then by pure luck if we find a match or not.
IMHO the right solution would be to have next to operand_equal_p a hashing
function that guarantees that if operand_equal_p returns true on two tree
expressions, then they have the same hash.

As short term, perhaps (maybe just for sanopt, as that is where the problem is
reported), we could use a comparison function that compares both the hash
values and operand_equal_p, i.e. tree expressions that hash differently would
never compare equal.  This can be done either by remembering also the hash
value, or just computing iterative_hash_expr each time.

[Bug sanitizer/70683] [6 Regression] -fcompare-debug bug with -fsanitize=address

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug rtl-optimization/21150] Suboptimal byte extraction from 64bits

[vda.linux at googlemail dot com]

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

--- Comment #7 from Denis Vlasenko  ---
Fixed at least in 4.7.2, maybe earlier. With -m32 -fomit-frame-pointer -O2:

a:  movzbl  v+45, %eax
xorbv+36, %al
xorbv, %al
xorbv+54, %al
xorbv+63, %al
xorbv+9, %al
xorbv+18, %al
xorbv+27, %al
ret
b:  movzbl  v+18, %eax
xorbv+9, %al
xorbv, %al
xorbv+27, %al
xorbv+36, %al
xorbv+45, %al
xorbv+54, %al
xorbv+63, %al
ret
c:  movzbl  v+9, %eax
xorbv, %al
xorbv+18, %al
xorbv+27, %al
xorbv+36, %al
xorbv+45, %al
xorbv+54, %al
xorbv+63, %al
ret
d:  movzbl  v+18, %eax
xorbv+9, %al
xorbv, %al
xorbv+27, %al
xorbv+36, %al
xorbv+45, %al
xorbv+54, %al
xorbv+63, %al
ret

With same but -Os, my only complaint is that word-sized XORs are needlessly
adding partial register update stalls:

d:  movbv+18, %al
xorbv+9, %al
xorlv, %eax
xorbv+27, %al
xorlv+36, %eax
xorbv+45, %al
xorbv+54, %al
xorbv+63, %al
ret

but overall it looks much better. Feel free to close this BZ.

[Bug target/70682] New: [6 Regression] -fcompare-debug building LLVM with checking=release compiler on ppc64le

[trippels at gcc dot gnu.org]

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

Bug ID: 70682
   Summary: [6 Regression] -fcompare-debug building LLVM with
checking=release compiler on ppc64le
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
Target: ppc64le

Created attachment 38282
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38282=edit
unreduced testcase

On ppc64le running r235027 I get:

trippels@gcc2-power8 llvm_build % g++ --save-temps -fcompare-debug -O3
-fno-devirtualize -c CGStmtOpenMP.gk.ii
g++: error: CGStmtOpenMP.gk.ii: -fcompare-debug failure

trippels@gcc2-power8 llvm_build % diff -u  CGStmtOpenMP.gk.gkd
CGStmtOpenMP.gk.gk.gkd
--- CGStmtOpenMP.gk.gkd 2016-04-15 13:59:37.734070548 +
+++ CGStmtOpenMP.gk.gk.gkd  2016-04-15 13:59:50.954364032 +
@@ -177184,7 +177184,7 @@
 (mem/f/c:DI (plus:DI (reg/f:DI 1 1)
 (const_int 928 [0x3a0])) [ MEM[(struct
specific_clause_iterator *)]+0 S8 A128]))# {*movdi_internal64}
  (nil))
-(insn # 0 0 (set (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849456_I_665.9647 ] [786])
+(insn # 0 0 (set (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849458_I_665.9647 ] [786])
 (vec_select:V2DI (mem/c:V2DI (plus:DI (reg/f:DI 1 1)
 (reg:DI 10 10 [916])) [ MEM[(struct
specific_clause_iterator *)]+0 S16 A128])
 (parallel [
@@ -177209,12 +177209,12 @@
  (nil))
 (insn:TI # 0 0 (set (mem/c:V2DI (plus:DI (reg/f:DI 1 1)
 (reg:DI 10 10 [917])) [ MEM[(struct specific_clause_iterator
*)&__for_begin]+0 S16 A128])
-(vec_select:V2DI (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849456_I_665.9647 ] [786])
+(vec_select:V2DI (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849458_I_665.9647 ] [786])
 (parallel [
 (const_int 1 [0x1])
 (const_int 0 [0])
 ])))
/home/trippels/llvm/tools/clang/lib/CodeGen/CGStmtOpenMP.cpp:2355#
{*vsx_stxvd2x2_le_v2di}
- (expr_list:REG_DEAD (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849456_I_665.9647 ] [786])
+ (expr_list:REG_DEAD (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849458_I_665.9647 ] [786])
 (expr_list:REG_DEAD (reg:DI 10 10 [917])
 (nil
 (jump_insn # 0 0 (set (pc)

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jpoimboe at redhat dot com]

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

--- Comment #20 from Josh Poimboeuf  ---
Thanks very much to everyone who has looked into this so far.  It would be very
helpful to get answers to the following questions, so we can understand the
impact to the kernel:

1) Is there a reliable way to avoid the bug, either in code or with a gcc flag?

2) Is there a reliable way to detect the bug by looking at the object code?

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
Josh: This is limitation of ipa-prop tracking. It very easily gives up on
determinging constantness of aggregate parameter. Hope Martin will fix it next
stage1. WIP patches was done few releases back but not merged so far.

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mjambor at suse dot cz

--- Comment #18 from Jan Hubicka  ---
Jakub: There is indeed aliasing issue, but with -fno-strict-aliasing the bug is
the same.

Apparently this is ipa-prop bug, because ipa-prop does not track size of
accesses and thus it does not know there is a mismatch. The value produced is
thus not INT_MAX as intended but 255. This is Martin's area.

[Bug c/70671] Wrong column number shown for "error: cannot take address of bit-field"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I've got a fix (extremely trivial).

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jpoimboe at redhat dot com]

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

--- Comment #17 from Josh Poimboeuf  ---
(In reply to Richard Biener from comment #14)
> (In reply to Josh Poimboeuf from comment #13)
> > Interestingly, the function's epilogue (frame pointer restore) and return
> > instruction are also getting discarded.  Can you tell if that will always be
> > the case when this bug triggers?
> 
> I don't think we can rely on that.  The path could simply fall thru to
> a random instruction which is still inside the function.  Say, if it was
> 
>   if (x)
> ...
>   else
> ...
>   foo ();
> 
> then the arm marked unreachable would simply disappear.

I tried doing that by putting the offending wwn_to_u64() call in an if
statement, but then the bug disappeared.

In fact, adding *any* code before the call seems to make the bug disappear.

[Bug fortran/70673] [5/6 Regression] ICE with module containing functions with allocatable character scalars

[davidgkinniburgh at yahoo dot co.uk]

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

--- Comment #4 from David Kinniburgh  ---
It seems the problem usually arises when there is reassignment in one line, eg

character(:), allocatable: s, t
s = s(2:) ! or even s = s

whereas forcing the temporary 
t = s(2:)
s = t

seems to work. But it is not quite that simple as the above doesn't always
fail. It requires other things to be happening too.

[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
The fix is incomplete:

[hjl@gnu-6 gcc]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/  -mx32 -mtune=slm  
-fno-diagnostics-show-caret -fdiagnostics-color=never   -Og -fschedule-insns
-fno-tree-fre -mavx512vbmi --param=max-sched-ready-insns=1 -masm=intel -c -o
pr70662.o
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr70662.c
/tmp/ccatFXMU.s: Assembler messages:
/tmp/ccatFXMU.s:240: Error: operand size mismatch for `vpbroadcastd'
[hjl@gnu-6 gcc]$ 

vpbroadcastdzmm17{k1}, QWORD PTR [esp+184]

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka  ---
> Honza?  This seems to be somewhat fragile (redirecting things to unreachable
> but _not_ changing the actual predicates in the IL).  Claiming the
> predicate is constant true is also a bit bogus (as can be seen in following
> optimization).

At WPA stage inliner can not update IL, so it simply redirects to
builtin_unreachable if predicate is FALSE and expects scalar passes to be
monotonously smarter than IPA analysis. 

BB3 predicate true is conservatively correct: there is no predicate to
represent that something is not constant because we assume scalar optimizers to
possibly be stronger than us and decide better.

Here we manage to assume that builtin_constant_p is true and thus we conclude
the following BB is unreachable:
 BB 4 predicate:(op0[ref offset: 0] not constant)   
  iftmp.0_26 = __builtin_bswap64 (_3);  
freq:0.61 size:  1 time:  1
This is because ipa-prop analyzes the values in node_name:

  Jump functions of caller  broken/2:   
callsite  broken/2 -> wwn_to_u64/1 :
   param 0: UNKNOWN 
 Aggregate passed by reference: 
   offset: 0, cst: 255  
   offset: 8, cst: 255  
   offset: 16, cst: 255 
   offset: 24, cst: 255 
   offset: 32, cst: 255 
   offset: 40, cst: 255 
   offset: 48, cst: 255 
   offset: 56, cst: 255 

but later we fold:

  :   
  node_name[0] = 255;   
  node_name[1] = 255;   
  node_name[2] = 255;   
  node_name[3] = 255;   
  node_name[4] = 255;   
  node_name[5] = 255;   
  node_name[6] = 255;   
  node_name[7] = 255;   
  _14 = MEM[(const u64 *)_name];   
  _15 = __builtin_constant_p (_14); 

into false (which is stupid, but conservatively correct modulo the assumption
about IPA passes being consistently weakter than local passes).

Making IPA passes to fold builtin_constant_p call into true is technically
possible, if I add builtin_true and redirect to it, but it would not be very
good if the local passes can not fold above (as the wrong arm is taken).

So can we possibly fix the local passes?

Honza

[Bug c/70651] [6 Regression] ICE on invalid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug c/70651] [6 Regression] ICE on invalid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Fri Apr 15 13:15:23 2016
New Revision: 235027

URL: https://gcc.gnu.org/viewcvs?rev=235027=gcc=rev
Log:
PR c/70651
* c-common.c (build_va_arg): Change two asserts into errors and return
error_mark_node.

* c-c++-common/pr70651.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr70651.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
Even with the #c10 change it looks to be aliasing violation, does it work fine
if you compile with -fno-strict-aliasing or use may_alias on the type through
which it is read?

[Bug c++/70505] [4.9/5/6 Regression] Constexpr failure when template type specified

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/70675] [6 Regression] compare-debug failure building LLVM

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/70675] [6 Regression] compare-debug failure building LLVM

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 15 13:07:43 2016
New Revision: 235025

URL: https://gcc.gnu.org/viewcvs?rev=235025=gcc=rev
Log:
PR c++/70675
* tree-pretty-print.c (do_niy): Add FLAGS argument, pass it down
to dump_generic_node.
(NIY): Pass also flags to do_niy.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-pretty-print.c

[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|[6 Regression] FAIL:|[6/7 Regression] FAIL:
   |gcc.dg/ira-shrinkwrap-prep- |gcc.dg/ira-shrinkwrap-prep-
   |2.c  gcc.dg/pr10474.c on|2.c  gcc.dg/pr10474.c on
   |arm and powerpc |arm and powerpc

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Tests xfailed on arm and powerpc for GCC 6.
Changing milestone for GCC 7

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[hjl.tools at gmail dot com]

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

--- Comment #23 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #20)
> The empty class passing ABI changes were reverted and are going to be
> resolved only for GCC7+.
> I've tried your testcase (and latest preprocessed hash_policy.ii from i686
> build) with -g -O2 {,-finline-small-functions} {,-fpic} -mx32, and certainly
> don't see any .cfi_escape directives in there.  So, what is the real bug
> then?

i686 != x32.  Please try the testcase in 

https://gcc.gnu.org/bugzilla/attachment.cgi?id=38281

and compile it with -O2 -S:

[hjl@gnu-6 libstdc++-v3]$ ../../gcc/xgcc -B../../gcc/ -O2 -S hash_policy.ii
-mx32
[hjl@gnu-6 libstdc++-v3]$ grep cfi_escape hash_policy.s
.cfi_escape 0x2e,0x10
.cfi_escape 0x2e,0
[hjl@gnu-6 libstdc++-v3]$

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[hjl.tools at gmail dot com]

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

--- Comment #22 from H.J. Lu  ---
Created attachment 38281
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38281=edit
A testcase

Compile it with -O2 -S -mx32.

[Bug rtl-optimization/70681] [6 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc

[ktkachov at gcc dot gnu.org]

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Apr 15 12:45:20 2016
New Revision: 235024

URL: https://gcc.gnu.org/viewcvs?rev=235024=gcc=rev
Log:
[testsuite] PR rtl-optimization/70681: XFAIL ira-shrinkwrap-prep-2.c and
pr10474.c tests on arm, powerpc

PR rtl-optimization/70681
* gcc.dg/ira-shrinkwrap-prep-2.c: XFAIL shrinkwrapping
dump scan on arm and powerpc.
* gcc.dg/pr10474.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
trunk/gcc/testsuite/gcc.dg/pr10474.c

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[hjl.tools at gmail dot com]

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

--- Comment #21 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #20)
> From gcc-testresults, it seems it only fails with -mx32 -fpic, and not with
> plain -mx32, but that is all I can find out.

See:

https://gcc.gnu.org/ml/gcc-regression/2016-04/msg00123.html
https://gcc.gnu.org/ml/gcc-regression/2016-04/msg00129.html

[Bug c++/70588] SIGBUS on a VLA larger than SIZE_MAX / 2

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 15 12:29:32 2016
New Revision: 235021

URL: https://gcc.gnu.org/viewcvs?rev=235021=gcc=rev
Log:
PR c++/69517
PR c++/70019
PR c++/70588
* g++.dg/cpp1y/vla11.C: Revert for real.

Removed:
trunk/gcc/testsuite/g++.dg/cpp1y/vla11.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/69517] [7 regression] SEGV on a VLA with excess initializer elements

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 15 12:29:32 2016
New Revision: 235021

URL: https://gcc.gnu.org/viewcvs?rev=235021=gcc=rev
Log:
PR c++/69517
PR c++/70019
PR c++/70588
* g++.dg/cpp1y/vla11.C: Revert for real.

Removed:
trunk/gcc/testsuite/g++.dg/cpp1y/vla11.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/70019] VLA size overflow not detected

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 15 12:29:32 2016
New Revision: 235021

URL: https://gcc.gnu.org/viewcvs?rev=235021=gcc=rev
Log:
PR c++/69517
PR c++/70019
PR c++/70588
* g++.dg/cpp1y/vla11.C: Revert for real.

Removed:
trunk/gcc/testsuite/g++.dg/cpp1y/vla11.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 15 12:24:18 2016
New Revision: 235020

URL: https://gcc.gnu.org/viewcvs?rev=235020=gcc=rev
Log:
PR c/70436
c/
* c-parser.c (c_parser_pragma): Add IF_P argument, pass it down
where needed.
(c_parser_external_declaration, c_parser_struct_or_union_specifier,
c_parser_parameter_declaration, c_parser_compound_statement_nostart,
c_parser_objc_class_instance_variables, c_parser_objc_methodprotolist):
Adjust c_parser_pragma callers.
(c_parser_statement_after_labels): Likewise.  Adjust c_parser_cilk_for
caller.
(c_parser_omp_structured_block): Add IF_P argument, pass it down to
c_parser_statement.
(c_parser_oacc_data, c_parser_oacc_host_data, c_parser_oacc_loop,
c_parser_oacc_kernels_parallel, c_parser_omp_critical,
c_parser_omp_simd, c_parser_omp_for, c_parser_omp_master,
c_parser_omp_ordered, c_parser_omp_parallel, c_parser_omp_single,
c_parser_omp_task, c_parser_omp_taskgroup, c_parser_omp_distribute,
c_parser_omp_teams, c_parser_omp_target_data, c_parser_omp_target,
c_parser_omp_taskloop, c_parser_omp_construct, c_parser_cilk_grainsize,
c_parser_cilk_simd, c_parser_cilk_for): Add IF_P argument, pass it
down where needed.
(c_parser_omp_for_loop): Likewise.  Clear IF_P if nbraces.
(c_parser_omp_sections_scope): Adjust c_parser_omp_structured_block
calls.
cp/
* parser.c (cp_parser_pragma): Add IF_P argument, pass it down
where needed.
(cp_parser_declaration_seq_opt, cp_parser_member_specification_opt,
cp_parser_objc_interstitial_code, cp_parser_omp_declare_simd,
cp_parser_oacc_routine): Adjust cp_parser_pragma callers.
(cp_parser_statement): Likewise.  Adjust cp_parser_cilk_for caller.
(cp_parser_omp_structured_block): Add IF_P argument, pass it down to
cp_parser_statement.
(cp_parser_oacc_data, cp_parser_oacc_host_data, cp_parser_oacc_loop,
cp_parser_oacc_kernels_parallel, cp_parser_omp_critical,
cp_parser_omp_simd, cp_parser_omp_for, cp_parser_omp_master,
cp_parser_omp_ordered, cp_parser_omp_parallel, cp_parser_omp_single,
cp_parser_omp_task, cp_parser_omp_taskgroup, cp_parser_omp_distribute,
cp_parser_omp_teams, cp_parser_omp_target_data, cp_parser_omp_target,
cp_parser_omp_taskloop, cp_parser_omp_construct,
cp_parser_cilk_grainsize, cp_parser_cilk_simd, cp_parser_cilk_for):
Add IF_P argument, pass it down where needed.
(cp_parser_omp_for_loop): Likewise.  Clear IF_P if nbraces.
(cp_parser_omp_sections_scope): Adjust cp_parser_omp_structured_block
calls.
testsuite/
* c-c++-common/Wparentheses-1.c: New test.
* c-c++-common/gomp/Wparentheses-1.c: New test.
* c-c++-common/gomp/Wparentheses-2.c: New test.
* c-c++-common/gomp/Wparentheses-3.c: New test.
* c-c++-common/gomp/Wparentheses-4.c: New test.
* c-c++-common/cilk-plus/PS/Wparentheses-1.c: New test.
* c-c++-common/cilk-plus/CK/Wparentheses-1.c: New test.
* c-c++-common/goacc/Wparentheses-1.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wparentheses-1.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/Wparentheses-1.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/PS/Wparentheses-1.c
trunk/gcc/testsuite/c-c++-common/goacc/Wparentheses-1.c
trunk/gcc/testsuite/c-c++-common/gomp/Wparentheses-1.c
trunk/gcc/testsuite/c-c++-common/gomp/Wparentheses-2.c
trunk/gcc/testsuite/c-c++-common/gomp/Wparentheses-3.c
trunk/gcc/testsuite/c-c++-common/gomp/Wparentheses-4.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c/70651] [6 Regression] ICE on valid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
I'm testing this:

--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5725,7 +5725,12 @@ build_va_arg (location_t loc, tree expr, tree type)
   /* Verify that  is still recognized as having va_list type.  */
   tree canon_expr_type
= targetm.canonical_va_list_type (TREE_TYPE (expr));
-  gcc_assert (canon_expr_type != NULL_TREE);
+  if (canon_expr_type == NULL_TREE)
+   {
+ error_at (loc,
+   "first argument to % not of type %");
+ return error_mark_node;
+   }

   return build_va_arg_1 (loc, type, expr);
 }
@@ -5793,7 +5798,12 @@ build_va_arg (location_t loc, tree expr, tree type)
   /* Verify that  is still recognized as having va_list type.  */
   tree canon_expr_type
= targetm.canonical_va_list_type (TREE_TYPE (expr));
-  gcc_assert (canon_expr_type != NULL_TREE);
+  if (canon_expr_type == NULL_TREE)
+   {
+ error_at (loc,
+   "first argument to % not of type %");
+ return error_mark_node;
+   }
 }
   else
 {

[Bug c/70678] Static function compilation behaviour changes with __attribute__((optimize("O2"))) even if already compiling with -O2

[lutoma at ohai dot su]

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

--- Comment #2 from Lukas Martini  ---
Hi,

thanks for testing. I have to admit the explanation regarding how the various
switches play together went a little over my head, but if you tell me that's
intended behaviour, I'll trust your word on it :)

Just to be sure: For me, this also happens when "-fno-strict-aliasing -fwrapv"
are not added as parameters, I only added those because I saw them mentioned
somewhere in the bug reporting guidelines. If it's still intended behaviour
without them, feel free to close this bug report and thanks for the help!

Cheers,
Lukas

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #14 from Richard Biener  ---
(In reply to Josh Poimboeuf from comment #13)
> So if I understand correctly, some reachable code is incorrectly getting
> marked unreachable and then getting discarded.
> 
> Interestingly, the function's epilogue (frame pointer restore) and return
> instruction are also getting discarded.  Can you tell if that will always be
> the case when this bug triggers?

I don't think we can rely on that.  The path could simply fall thru to
a random instruction which is still inside the function.  Say, if it was

  if (x)
...
  else
...
  foo ();

then the arm marked unreachable would simply disappear.

> If so, that should make it possible for objtool to reliably detect the bug.

[Bug middle-end/70680] [5/6 Regression] OpenMP SIMD linear variable privatized too eagerly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-15
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Confirmed, gimplification bug where the shared (i) clause isn't added; I'll
have a look next week; it doesn't have to block 6.1 though, can be backported
after it goes out.

[Bug rtl-optimization/70681] [6 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
  Known to work||5.3.1
 Ever confirmed|0   |1
  Known to fail||6.0

[Bug rtl-optimization/70681] New: [6 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc

[ktkachov at gcc dot gnu.org]

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

Bug ID: 70681
   Summary: [6 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c
gcc.dg/pr10474.c on arm and powerpc
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: arm, powerpc

As reported at:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01640.html
and
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00094.html

The tests:
  gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump pro_and_epilogue
"Performing shrink-wrapping"
  gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping"

Have started failing on arm and powerpc after a regalloc change.
On arm at least the resulting codegen doesn't look worse
(https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00223.html)

but arguably shrink-wrapping could be improved
(https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00265.html)

This is a report to track work on shrinkwrapping or adjustment of the
testscases

[Bug middle-end/70680] [5/6 Regression] OpenMP SIMD linear variable privatized too eagerly

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug middle-end/70680] New: [5/6 Regression] OpenMP SIMD linear variable privatized too eagerly

[amonakov at gcc dot gnu.org]

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

Bug ID: 70680
   Summary: [5/6 Regression] OpenMP SIMD linear variable
privatized too eagerly
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

#include 
int main()
{
  int i=0;
#pragma omp task default(shared) if(0)
  {
#pragma omp simd
  for (i=0; i<100; i++)
;
#ifdef USE
  asm("" : : "r"(i));
#endif
  }
  printf("%d\n", i);
}

Per my understanding of the OpenMP spec, this program should always print
'100'; indeed, that is observed with gcc-4.9, but gcc-5 does not share 'i' with
the task region, unless a dummy use is injected after the openmp-simd loop:

$ gcc-4.9 -O2 -fopenmp t.c && ./a.out
100

$ gcc-5.1 -O2 -fopenmp t.c && ./a.out
0

$ gcc-5.1 -DUSE -O2 -fopenmp t.c && ./a.out
100

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #20 from Jakub Jelinek  ---
The empty class passing ABI changes were reverted and are going to be resolved
only for GCC7+.
I've tried your testcase (and latest preprocessed hash_policy.ii from i686
build) with -g -O2 {,-finline-small-functions} {,-fpic} -mx32, and certainly
don't see any .cfi_escape directives in there.  So, what is the real bug then?
>From gcc-testresults, it seems it only fails with -mx32 -fpic, and not with
plain -mx32, but that is all I can find out.

[Bug c++/70675] [6 Regression] compare-debug failure building LLVM

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 38280
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38280=edit
gcc6-pr70675.patch

Untested fix.

[Bug c++/70679] [6 Regression] -fcompare-debug building LLVM with checking=release compiler

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Sorry this is a bogus bug.

CommandLine.cpp contains:

std::cout << "  Built " << __DATE__ << " (" << __TIME__ << ").\n" 

So this is simply the __TIME__ difference...

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Created attachment 38279
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38279=edit
gcc6-pr70436-omp.patch

Untested fix for OpenMP/OpenACC/Cilk+/#pragma GCC ivdep, both C and C++.

[Bug c++/70679] [6 Regression] -fcompare-debug building LLVM with checking=release compiler

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Richard Biener from comment #1)
> Can you see if the fix in PR70675 works?  That is, is this a dup?  

Unfortunately no.

> Does reducing GC params make it reproduce with the .ii file?

--param ggc-min-expand=5 --param ggc-min-heapsize=5  doesn't help.

[Bug c/70678] Static function compilation behaviour changes with __attribute__((optimize("O2"))) even if already compiling with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Declaring test_function inline and using -Winline shows:

t.c:4:52: warning: inlining failed in call to ‘test_function’: optimization
level attribute mismatch [-Winline]
 static inline void __attribute__((optimize("O2"))) test_function() {
^


which is because while -fwrapv is still set -fno-strict-aliasing is not.

This is because parse_optimize_options (-O2) will turn on -fstrict-aliasing.
It does that via calling

301   default_options_optimization (opts, opts_set,
302 decoded_options, decoded_options_count,
303 loc, lang_mask, , dc);

and I think this is intended behavior.  It's a little inconsistent that
-fwrapv is not changed, but that's because it is never on by default.

[Bug c++/70679] [6 Regression] -fcompare-debug building LLVM with checking=release compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
Can you see if the fix in PR70675 works?  That is, is this a dup?  Does
reducing GC params make it reproduce with the .ii file?