[Bug c++/78047] [7 Regression] Chromium apparently gets miscompiled

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 39846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39846=edit
unreduced testcase

[Bug c++/78047] New: [7 Regression] Chromium apparently gets miscompiled

[trippels at gcc dot gnu.org]

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

Bug ID: 78047
   Summary: [7 Regression] Chromium apparently gets miscompiled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Chromium gets miscompiled with gcc trunk.

Bizarrely, it crashes when one tries to view Stroustrup's CppCon2016 keynote
on github:

https://github.com/CppCon/CppCon2016/blob/master/Keynotes/The%20Evolution%20of%20C++%20-%20Past,%20Present,%20and%20Future/The%20Evolution%20of%20C++%20-%20Past,%20Present,%20and%20Future%20-%20Bjarne%20Stroustrup%20-%20CppCon%202016.pdf

../../third_party/tcmalloc/chromium/src/tcmalloc.cc:289] Attempt to free
invalid pointer 0x5f0c76f0

Thread 1 "chrome" received signal SIGSEGV, Segmentation fault.
0x56028d00 in tcmalloc::Abort() ()
(gdb) bt
#0  0x56028d00 in tcmalloc::Abort() ()
#1  0x5602d1d5 in tcmalloc::Log(tcmalloc::LogMode, char const*, int,
tcmalloc::LogItem, tcmalloc::LogItem, tcmalloc::LogItem, tcmalloc::LogItem) ()
#2  0x5d00ee6f in tc_free ()
#3  0x57eb9b4c in GrResourceProvider::GrResourceProvider(GrGpu*,
GrResourceCache*, GrSingleOwner*) ()
#4  0x57e88345 in GrContext::initCommon(GrContextOptions const&) ()
#5  0x57e88734 in GrContext::Create(GrBackend, long) ()
...

I narrowed it down to a single function:

 23 __attribute__((optimize("-O1")))
 24 GrResourceProvider::GrResourceProvider(GrGpu* gpu, GrResourceCache* cache,
GrSingleOwner* owner)   
 25 : INHERITED(gpu, cache, owner) {
 26 GR_DEFINE_STATIC_UNIQUE_KEY(gQuadIndexBufferKey);   
 27 fQuadIndexBufferKey = gQuadIndexBufferKey;  
 28 } 

__attribute__((optimize("-O1"))) "fixes" the issue.

 33929 class SkOnce {   
 33930 public:  
 33931 constexpr SkOnce() = default;
 33932  
 33933 template  
 33934 void operator()(Fn&& fn, Args&&... args) {   
 33935 auto state = fState.load(std::memory_order_acquire); 
 33936  
 33937 if (state == Done) { 
 33938 return;  
 33939 }
 33940  
 33941  
 33942 if (state == NotStarted && fState.compare_exchange_strong(state,
Claimed,
 33943  
std::memory_order_relaxed)) {   
 33944  
 33945 fn(std::forward(args)...); 
 33946 return fState.store(Done, std::memory_order_release);
 33947 }
 33948  
 33949  
 33950  
 33951 while (fState.load(std::memory_order_acquire) != Done) { }   
 33952 }
 33953  
 33954 private: 
 33955 enum State : uint8_t { NotStarted, Claimed, Done};   
 33956 std::atomic fState{NotStarted}; 
 33957 };  

 34201 static inline void
gr_init_static_unique_key_once(SkAlignedSTStorage<1,GrUniqueKey>* keyStorage) { 
 34202 GrUniqueKey* key = new (keyStorage->get()) GrUniqueKey;  
 34203 GrUniqueKey::Builder builder(key, GrUniqueKey::GenerateDomain(), 0); 
 34204 } 

109423 static SkOnce gQuadIndexBufferKey_once;  
109424  
109425 GrResourceProvider::GrResourceProvider(GrGpu* gpu, 

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger  ---
(In reply to Wilco from comment #4)
> However dealing with partial overlaps is complex so maybe the best option
> would be to add alternatives to di3_neon to either allow full overlap
> "r 0 X X X" or no overlap " r X  X X". The shift code works with full
> overlap.

That sounds like a good idea.

Then this condition in di3_neon could go away too:

&& (!reg_overlap_mentioned_p (operands[0], operands[1])
|| REGNO (operands[0]) == REGNO (operands[1])))

[Bug c++/78046] Unnecessary setne/testb instructions with temporary int brace-initialized in if statement

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Not a bug. Gcc -O0 is not something which is optimized for.

[Bug c++/78046] New: Unnecessary setne/testb instructions with temporary int brace-initialized in if statement

[jamespharvey20 at gmail dot com]

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

Bug ID: 78046
   Summary: Unnecessary setne/testb instructions with temporary
int brace-initialized in if statement
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamespharvey20 at gmail dot com
  Target Milestone: ---

A two-variable comparison

   int main() {
  int i{0};
  int j{0};
  if(i != j) {
  }
   }

And a one-variable comparison to a temporary

   int main() {
  int i{0};
  if(i != int{0}) {
  }
   }

Generate fairly similar assembly, as expected, using gcc -Wa,-adhln -g
source.cpp -O0 > source.s

The two-variable version creates assembly for the declaration and if statement
of:

   movl $0, -8(%rbp)
   movl -4(%rbp), %eax
   cmpl -8(), %eax

The temporary version generates assembly for the if statement and temporary of:

   movl $0, %eax
   cmpl -4(%rbp), %eax
   setne %al
   testb %al, %al

So, at least without optimization, they are (and should be) different in terms
of a stack variable vs a register temporary.

But, why I'm writing is the `setne` and `testb` instructions that appear there.

FWIW, clang assembles with the same difference for stack variable vs a register
temporary, but does NOT create add the `setne` and `testb` instructions.

Additionally, changing from using an `int` to a class, there aren't extra
`setne` and `testb` instructions.  The assembly of stack vs register variables
is effectively identical, just the order of two sets of `leaq` instructions is
reversed, as in:

   class foo {
   public:
  foo(int _x) : x{_x} { }
  int x;
  bool operator!=(const foo& other) { return x != other.x; }
   };

   int main() {
  foo i{0};
  if(i != foo{0}) {
  }
   }

[Bug c++/78045] New: Parsing error when creating temporary object with space in type name (unsigned int)

[jamespharvey20 at gmail dot com]

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

Bug ID: 78045
   Summary: Parsing error when creating temporary object with
space in type name (unsigned int)
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamespharvey20 at gmail dot com
  Target Milestone: ---

For test code comparisons where the expected value can be constructed as a
temporary, I've been doing so.  This has really been for classes, but when I
tried it for `unsigned int` I ran into this bug.

In this test case, `i` is of course a substitute for the function being tested,
and `j` is the expected value.  This compiles and works fine:

   int main() {
  const int i{0};
  if(i != int{0}) {
 throw false;
  }
   }

Changing to an `unsigned int` fails:

   ...const unsigned int i{0};
  if(i != unsigned int{0})) {...

Giving:

   mine.cpp: In function ‘int main()’:
   mine.cpp:4:12: error: expected primary-expression before ‘unsigned’
   if(i != unsigned int{0}) {
   ^~~~
   mine.cpp:4:12: error: expected ‘)’ before ‘unsigned’

Unless the c++11 standard dictates only single word types may be made using
temporaries using initialization braces, I think the space is tripping up the
parsing.

[Bug c/61939] warn when __attribute__((aligned(x))) is ignored

[daniel.santos at pobox dot com]

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

--- Comment #2 from Daniel Santos  ---
(In reply to Vedran Miletic from comment #1)
> #include 
> #include 
> float f(std::vector& A, std::vector& B)
> {
>   __builtin_assume_aligned(A.data(), 64);
>   __builtin_assume_aligned(B.data(), 64);
>   return std::inner_product(A.begin(), A.end(), B.begin(), 0.f);
> }

You are doing it wrong. __builtin_assume_aligned() returns void* and you must
use it's return value for it to be effective. So your code should be something
like this:

float f(std::vector& A, std::vector& B)
{
  float *a_data = __builtin_assume_aligned(A.data(), 64);
  float *b_data = __builtin_assume_aligned(B.data(), 64);
  return std::inner_product(a_data, b_data, B.begin(), 0.f);
}

Of course, this assumes that the buffer that your vector<> implementation
supplies is 64 byte aligned.

[Bug tree-optimization/33784] Disabled -fipa-type-escape

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Andrew Pinski  ---
fipa-type-escape has since been removed .

Though I am thinking about bringing it back soon and will do much more of
testing it.

[Bug c++/78040] Missed mangled names of class methods in the translation unit dump

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
-fdump-translation-unit is only useful for debugging GCC and that is it.  It is
not designed for some random person to use for their own purpose.

[Bug c++/78042] g++ does not select the corresponding overloads of abs() for long and long long

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Invalid, you are calling abs and not std::abs.  There is (or was) a defect
report about C abs function being included in the global scope rather than just
in the std scope.

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

[barannikov88 at gmail dot com]

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

Sergey Barannikov  changed:

   What|Removed |Added

 CC||barannikov88 at gmail dot com

--- Comment #4 from Sergey Barannikov  ---
This is the ABI problem. The search phase of the unwinding process cannot
distinguish between a case when a true handler found and a case when the search
process should stop, because it has reached a call site that must not pass the
exception through. In both cases _URC_HANDLER_FOUND is returned by the
personality routine, and the second phase of the unwinding process begins (the
actual unwinding).

There is another problem in LSDA format (in action table format to be precise).
Consider the following example:

void bad_guy() noexcept {
  try {
Foo foo;
throw 0;
  } catch (float) {
// Don't catch int.
  }
}

void level1() {
  bad_guy();
  throw "dead code";
}

int main() {
  try {
level1();
  } catch (const char *) {
  }
}

When you compile and run it you get:

Foo::Foo()
terminate called after throwing an instance of 'int'
Aborted (core dumped)


It works as expected. But (the funny thing) if you change "catch (const char
*)" in main to "catch (int)", you will get this:

Foo::Foo()
Foo::~Foo()
terminate called without an active exception
Aborted (core dumped)

This is because there is currently no way to represent a "Terminate" action in
the action table of LSDA. gcc represents it as a simply cleanup action, that
means that the unwinder does not stop at a noexcept function and continues
searching for a handler up the stack.
In the original example there is no handler for the exception thrown, and the
runtime terminates the program instantly (no stack unwinding done). When one
changes "catch (const char *)" to "catch (int)", the unwinder finds this
handler at the search phase and launches the second, unwinding, phase. The
unwinding process then destroys the local object "foo", checks the exception
type for matching "float", and falls into the code that calls std::terminate
when the matching fails. Since there is no __cxa_begin_catch prior to
std::terminate, we get the error message "terminate called without an active
exception" instead of correct "terminate called after throwing an instance of
'int'".

[Bug c++/11407] [DR 115] Function cannot be resolved

[colu...@gmx-topmail.de]

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

Robert Haberlach  changed:

   What|Removed |Added

 CC||colu...@gmx-topmail.de

--- Comment #18 from Robert Haberlach  ---
This is not fixed:

template void g();

int i = sizeof();

fails with trunk.

[Bug fortran/78043] ICE in force_decl_die, at dwarf2out.c:23533

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
Code from comment 0 only ICEs in combination with option -g*.
Adding an output routine :

$ cat z3.f90
module m
   common /xc/ a
end
module m2
   use m
end
subroutine s(x)
   use m
   print *, a
   print *, x
end
program p
   use m2, only: z => a
   z = 1.0
   call s(z)
end

$ gfortran-7-20161016 z3.f90
$ a.out
   1.
   1.



Deleting one module layer produces no ICE at all :

$ cat z5.f90
module m2
   common /xc/ a
end
subroutine s(x)
   use m2
   print *, a
   print *, x
end
program p
   use m2, only: z => a
   z = 1.0
   call s(z)
end

$ gfortran-7-20161016 z5.f90
$ a.out
   1.
   1.

$ gfortran-7-20161016 -g z5.f90
$ a.out
   1.
   1.

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[tschwinge at gcc dot gnu.org]

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

--- Comment #6 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Oct 19 21:24:37 2016
New Revision: 241355

URL: https://gcc.gnu.org/viewcvs?rev=241355=gcc=rev
Log:
[PR other/70945] Handle function_glibc_finite_math in offloading

gcc/
PR other/70945
* targhooks.c (default_libc_has_function): Update comment.
* target.def (libc_has_function): Likewise.
* doc/tm.texi: Regenerate.
* coretypes.h (enum function_class): Add
function_glibc_finite_math.
* config/darwin.c (darwin_libc_has_function): Handle it.
* lto-streamer.h (enum lto_section_type): Rename
LTO_section_offload_table to LTO_section_offload_data.  Adjust all
users.
* lto-cgraph.c (void output_offload_data): New function, split out
of output_offload_tables.  Adjust all users.  Stream the target's
function_glibc_finite_math property.
(input_offload_data): New function, split out of
input_offload_tables.  Adjust all users.  Handle mismatch between
the target's and the offloading target's
function_glibc_finite_math property.
libgomp/
PR other/70945
* testsuite/libgomp.oacc-c-c++-common/pr70945-1.c: New file.

Added:
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/pr70945-1.c
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/config/darwin.c
branches/gomp-4_0-branch/gcc/coretypes.h
branches/gomp-4_0-branch/gcc/doc/tm.texi
branches/gomp-4_0-branch/gcc/lto-cgraph.c
branches/gomp-4_0-branch/gcc/lto-streamer-out.c
branches/gomp-4_0-branch/gcc/lto-streamer.h
branches/gomp-4_0-branch/gcc/lto/lto.c
branches/gomp-4_0-branch/gcc/target.def
branches/gomp-4_0-branch/gcc/targhooks.c
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp

[Bug fortran/78021] [5/6/7 Regression] Wrong result with optimization on character constant

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
This looks promising, modulo some line breaks:

Index: dependency.c
===
--- dependency.c(Revision 240928)
+++ dependency.c(Arbeitskopie)
@@ -226,10 +226,24 @@ gfc_dep_compare_functions (gfc_expr *e1, gfc_expr
  if ((args1->expr == NULL) ^ (args2->expr == NULL))
return -2;

- if (args1->expr != NULL && args2->expr != NULL
- && gfc_dep_compare_expr (args1->expr, args2->expr) != 0)
-   return -2;
+ if (args1->expr != NULL && args2->expr != NULL)
+   {
+ gfc_expr *e1, *e2;
+ e1 = args1->expr;
+ e2 = args2->expr;

+ if (gfc_dep_compare_expr (e1, e2) != 0)
+   return -2;
+
+ /* Special case: String arguments which compare equal can
+still have different lengths, which makes them different
calls.   */
+ 
+ if (e1->expr_type == EXPR_CONSTANT && e1->ts.type == BT_CHARACTER
+ && e2->expr_type == EXPR_CONSTANT && e2->ts.type ==
BT_CHARACTER
+ && e1->value.character.length != e2->value.character.length)
+   return -2;
+   }
+
  args1 = args1->next;
  args2 = args2->next;
}

[Bug libstdc++/56383] error with multiple enable_shared_from_this base classes

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
On trunk it's now also possible to mix std::enable_shared_from_this and
std::__enable_shared_from_this bases without a hard error:

struct A : std::enable_shared_from_this
{
void* a() { return shared_from_this().get(); }
};

struct B : std::__enable_shared_from_this
{
};

[Bug target/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
Created attachment 39845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39845=edit
Patch that introduces new builtins with UNSPEC_LZCNT and UNSPEC_TZCNT RTX
patterns

This patch introduces new builtins with UNSPEC_LZCNT and UNSPEC_TZCNT RTX
patterns.

The patch fails following tests:

FAIL: gcc.target/i386/bmi-4.c (test for excess errors)
FAIL: gcc.target/i386/bmi-5.c (test for excess errors)
FAIL: gcc.target/i386/bmi-6.c (test for excess errors)

These tests check that:

/* Test that a constant operand 0 to tzcnt gets folded.  */
extern void link_error(void);
int main()
{
  if (__tzcnt_u32(0) != 32)
link_error();
  return 0;
}

But unpatched gcc simply calls generic __builtin_ctz in the above case. This is
undefined behaviour, so it looks that the test works only by luck...

OTOH, we know that __tzcnt_* and __lzcnt_* builtin functions implement CTZ and
CLZ functionality with defined output for all input arguments. Instead of
simply removing mentioned tests, we can introduce certain constant-folding
functionality to ix86_fold_builtin that would handle constant arguments in a
__builtin_ctz/__builtin_clz way.

The patch is thoroughly tested and works OK (modulo testsuite failures
mentioned above), but I have no idea on how to implement tree-folding stuff. 

So, some kind soul that would take the patch from this point is most welcome.

[Bug rtl-optimization/78038] [5/6/7 Regression] internal compiler error: in get_sub_rtx, at ree.c:655

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #7 from Andrew Pinski  ---
I am a bit shocked you are using ILP32 for aarch64 bare metal.  This is the
first time I have seen that.

[Bug middle-end/78044] -Wmaybe-uninitialized and -O2: false positive with boost::optional

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c++ |middle-end

--- Comment #2 from Andrew Pinski  ---
There are already filed bug reports about false positive for this warning. 
This might be a dup of one of those.  

Also this warning is hard not to get false positives really for conditional
unitialized variables which is why the option was split into two.  One for the
hard for GCC to prove that it is not a false positive (-Wmaybe-uninitialized).

[Bug rtl-optimization/78038] [5/6/7 Regression] internal compiler error: in get_sub_rtx, at ree.c:655

[steffen-schmidt at siemens dot com]

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

--- Comment #6 from Steffen Schmidt  ---
(In reply to ktkachov)
> 
> By the way, the optimisation in which the ICE occurs is ree (redundant
> extension elimination). You can turn it off by adding -fno-ree to the flags.

Thanks a lot for the quick replies, I'll try switching off ree for the moment.

[Bug c++/78044] -Wmaybe-uninitialized and -O2: false positive with boost::optional

[romain.geissler at amadeus dot com]

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

--- Comment #1 from Romain Geissler  ---
Created attachment 39844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39844=edit
test.i

[Bug c++/78044] New: -Wmaybe-uninitialized and -O2: false positive with boost::optional

[romain.geissler at amadeus dot com]

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

Bug ID: 78044
   Summary: -Wmaybe-uninitialized and -O2: false positive with
boost::optional
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

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

Hi,

I am having a false positive when using -O2 and -Wmaybe-uninitialized with the
latest gcc 6 (g++ (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2) from Fedora 24) with
boost::optional. Unfortunately my attempt to reduce the test case by trying to
extract the relevant boost parts failed.

Please find attached the reproducer test.cpp, that includes boost/optional.hpp
(tested with boost 1.60 and 1.61, I have a warning in both cases).

g++ -std=gnu++14 -O2 -Wall -c -o test.o test.cpp
test.cpp: In function 'void someFunction(const void*)':
test.cpp:22:16: warning: '*((void*)& aOptional +4)' may be used uninitialized
in this function [-Wmaybe-uninitialized]
 Optional_t aOptional;
^

In "someFunction()" the boost::optional value that is being passed and copied
is definitely not uninitialized.

You can also find attached the preprocessor output in test.i

Cheers,
Romain

[Bug c++/77474] sizeof and function template don't work properly together

[michele.caini at gmail dot com]

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

--- Comment #3 from Michele Caini  ---
The same applies using member function template.

[Bug fortran/78033] Internal Compiler Error in enforce_single_undo_checkpoint

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Wed, Oct 19, 2016 at 04:17:34AM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78033
> 
> --- Comment #2 from kargl at gcc dot gnu.org ---
> (In reply to kargl from comment #1)
> > Reduced testcase.
> > 
> > function f(n, x)
> >integer, intent(in) :: n 
> >complex, intent(in) :: x(1:n)
> >real :: f
> >f = g([real(x(1:n)), aimag(x(1:n))])
> > end function f
> > 
> > If the array sections are removed in favor of the whole array,
> > the code compiles.
> 
> Even further reduction.
> 
> subroutine f(n, x)
>integer, intent(in) :: n 
>complex, intent(in) :: x(1:n)
>real :: y(2*n)
>y = [real(x(1:n), aimag(x(1:n))]
> end subroutine f
> 
> The constructor with array sections is going south.
> 

A even further reduced testcase.

subroutine f(n, x)
   integer, intent(in) :: n 
   complex, intent(in) :: x(1:n)
   real :: y(2*n)
   ! y = [ real(x)]  ! This works.
y = [ real(x(1:n))]  ! This fails.
end subroutine f

The REAL in the array constructor is confusing the mechanism
for looking for a typespeci, e.g., [ REAL :: x(1:n)]

[Bug fortran/78043] ICE in force_decl_die, at dwarf2out.c:23533

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Related to/duplicate of pr50410? With the patch in pr50410 comment 8, I get the
error

Error: NULL() initialization expected in DATA statement for 'a' at (1)

[Bug c++/67685] ICE on invalid requires expression

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Quickly investigating. In tsubst_requires_expr, we add to the local
specialization stack, which means that any local variables or parameters
referenced within the requires-expression will not be visible, which ultimately
causes undefined behavior in tsubst_copy.

[Bug tree-optimization/71915] A missed opportunity for SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
This is an example of a known limitation in SLSR.  The explanation is in
analyze_increments:

  /* FORNOW: If we need to add an initializer, give up if a cast from   
 the candidate's type to its stride's type can lose precision.  
 This could eventually be handled better by expressly retaining the 
 result of a cast to a wider type in the stride.  Example:  

   short int _1;
   _2 = (int) _1;   
   _3 = _2 * 10;
   _4 = x + _3;ADD: x + (10 * _1) : int 
   _5 = _2 * 15;
   _6 = x + _3;ADD: x + (15 * _1) : int 

 Right now replacing _6 would cause insertion of an initializer 
 of the form "short int T = _1 * 5;" followed by a cast to  
 int, which could overflow incorrectly.  Had we recorded _2 or  
 (int)_1 as the stride, this wouldn't happen.  However, doing   
 this breaks other opportunities, so this will require some 
 care.  */

In this case, we have "int" rather than "short int," and "int *" rather than
"int".  Assuming a 64-bit machine, casting from a 64-bit wrapping type to a
32-bit non-wrapping type isn't legal.

I need to look at the stride-selection logic again.  The various cast-sensitive
bits of this are tricky to get right.

[Bug fortran/78043] New: ICE in force_decl_die, at dwarf2out.c:23533

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78043
   Summary: ICE in force_decl_die, at dwarf2out.c:23533
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With valid code and option -g, ICEs down to at least 4.8 :


$ cat z1.f90
module m
   common /xc/ a
end
module m2
   use m
end
program p
   use m2, only: z => a
   z = 1.0
end


$ gfortran-7-20161016 -c z1.f90
$
$ gfortran-7-20161016 -g -c z1.f90
z1.f90:8:0:

use m2, only: z => a

internal compiler error: in force_decl_die, at dwarf2out.c:23533
0x8bb39f force_decl_die
../../gcc/dwarf2out.c:23533
0x8ce6ef dwarf2out_imported_module_or_decl_1
../../gcc/dwarf2out.c:24071
0x8d5cd4 dwarf2out_imported_module_or_decl
../../gcc/dwarf2out.c:24143
0x75483a gfc_trans_use_stmts
../../gcc/fortran/trans-decl.c:4882
0x7554c8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6431
0x6df570 translate_all_program_units
../../gcc/fortran/parse.c:5940
0x6df570 gfc_parse_file()
../../gcc/fortran/parse.c:6146
0x722652 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[wdijkstr at arm dot com]

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

--- Comment #4 from Wilco  ---
(In reply to Bernd Edlinger from comment #3)
> (In reply to Wilco from comment #2)
> > (In reply to Bernd Edlinger from comment #1)
> > > some background about this bug can be found here:
> > > 
> > > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html
> > 
> > The di3_neon pattern does not constrain the input not to overlap with
> > the output for immediate shifts, and the arm_emit_coreregs_64bit_shift code
> > does not handle partial overlaps. However it is feasible to fix that by
> > swapping the order for the various cases.
> 
> from di3_neon:
> 
> if (INTVAL (operands[2]) < 1)
>   {
> emit_insn (gen_movdi (operands[0], operands[1]));
> DONE;
>   }
> 
> Will the movdi pattern work with partial overlaps?
> It does basically this:
> 
>   emit_move_insn (gen_lowpart (SImode, operands[0]),
>   gen_lowpart (SImode, operands[1]));
>   emit_move_insn (gen_highpart (SImode, operands[0]),
>   gen_highpart (SImode, operands[1]));

I think it's OK - that code only triggers if a movdi has a physical register
that is not a valid DI register which is not the case we're dealing with. movdi
has a split that does check for partial overlap around line 5900 in arm.md:

  /* Handle a partial overlap.  */
  if (rtx_equal_p (operands[0], operands[3]))
 ...

However dealing with partial overlaps is complex so maybe the best option would
be to add alternatives to di3_neon to either allow full overlap "r 0 X X
X" or no overlap " r X  X X". The shift code works with full overlap.

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
So this is a very interesting little issue that highlights a deficiency in the 
semantics of __builtin_constant_p.

So prior to threading we have:

;;   basic block 4, loop depth 0, count 0, freq 1, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [50.0%]  (TRUE_VALUE,EXECUTABLE)
;;3 [100.0%]  (FALLTHRU,EXECUTABLE)
  # iftmp.0_2 = PHI 
  b = iftmp.0_2;
  _1 = __builtin_constant_p (iftmp.0_2);
  if (_1 != 0)
goto ;
  else
goto ;
;;succ:   5 [54.0%]  (TRUE_VALUE,EXECUTABLE)
;;7 [46.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 5, loop depth 0, count 0, freq 5400, maybe hot
;;prev block 4, next block 6, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 [54.0%]  (TRUE_VALUE,EXECUTABLE)
  if (iftmp.0_2 != 0)
goto ;
  else
goto ;
;;succ:   6 [36.6%]  (TRUE_VALUE,EXECUTABLE)
;;7 [63.4%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 6, loop depth 0, count 0, freq 1979, maybe hot
;;prev block 5, next block 7, flags: (NEW, REACHABLE, VISITED)
;;pred:   5 [36.6%]  (TRUE_VALUE,EXECUTABLE)
  ilog2_NaN ();

That's all fine and good.  Threading wants to lookup the value of iftmp.0_2 in
an attempt to eliminate the conditional in BB5.  And it finds that the path
3->4->5 will result in iftmp.0_2 having the value 1.  So it isolates that path.

After isolation things look  like this:

;;   basic block 3, loop depth 0
;;pred:   2
  # iftmp.0_8 = PHI <1(2)>
  b = iftmp.0_8;
  _10 = __builtin_constant_p (iftmp.0_8);
  if (_10 != 0)
goto ;
  else
goto ;
;;succ:   6
;;7

;;   basic block 4, loop depth 0
;;pred:   2
  # iftmp.0_2 = PHI 
  b = iftmp.0_2;
  _1 = __builtin_constant_p (iftmp.0_2);
  if (_1 != 0)
goto ;
  else
goto ;
;;succ:   5
;;7

;;   basic block 5, loop depth 0
;;pred:   4
  if (iftmp.0_2 != 0)
goto ;
  else
goto ;
;;succ:   6
;;7

;;   basic block 6, loop depth 0
;;pred:   5
;;3
  ilog2_NaN ();
;;succ:   7


Note how the path leading out of block 3 will never pass through the
conditional in block 5.  That's the primary effect of jump threading.


The most "obvious" interpretation is that "b" is not constant in this case at
the source level and thus __b_c_p must return zero.  But how does one deal with
cases where analysis such as VRP, CPROP, etc prove certain edges are not
executable and thus certain paths to a b_c_p call are eliminated and the
"obvious" non-constant b_c_p argument turns into a constant argument.  This
could happen virtually with any optimization that eliminates an edge in the
CFG.  Proving edge removal does not change the runtime result of a b_c_p call
is almost certainly akin to the halting problem.

Similarly such an interpretation would essentially mean that a block with a
b_c_p call can only be duplicated if we can prove that the original and
duplicate have the same runtime result as the original -- which we might be
able to prove in some cases, but the context necessary to do so is likely not
available in the places where we have to make that determination -- essentially
we'll likely have to disallow duplication of blocks with b_c_p.

I want folks to realize that the "obvious" interpretation may have very
significant secondary effects and may ultimately result in cases where we must
either totally cripple optimizers or declare that the "obvious" semantics
simply can't be supported.

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
(In reply to Wilco from comment #2)
> (In reply to Bernd Edlinger from comment #1)
> > some background about this bug can be found here:
> > 
> > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html
> 
> The di3_neon pattern does not constrain the input not to overlap with
> the output for immediate shifts, and the arm_emit_coreregs_64bit_shift code
> does not handle partial overlaps. However it is feasible to fix that by
> swapping the order for the various cases.

from di3_neon:

if (INTVAL (operands[2]) < 1)
  {
emit_insn (gen_movdi (operands[0], operands[1]));
DONE;
  }

Will the movdi pattern work with partial overlaps?
It does basically this:

  emit_move_insn (gen_lowpart (SImode, operands[0]),
  gen_lowpart (SImode, operands[1]));
  emit_move_insn (gen_highpart (SImode, operands[0]),
  gen_highpart (SImode, operands[1]));

[Bug tree-optimization/71915] A missed opportunity for SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Something is causing us to hate the second case now, assigning "infinite" cost
to it:

Processing dependency tree rooted at 5.
Using existing initializer: _3 = -_2;

Increment vector:

  0  increment:   -8
 count:   1
 cost:-24
 initializer: _3

  1  increment:   -16
 count:   1
 cost:1000
 initializer:

[Bug c/61939] warn when __attribute__((aligned(x))) is ignored

[rivanvx at gmail dot com]

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

Vedran Miletic  changed:

   What|Removed |Added

 CC||rivanvx at gmail dot com

--- Comment #1 from Vedran Miletic  ---
Confirmed still occurs in 6.2.1 on the following C++ code:

#include 
#include 
float f(std::vector& A, std::vector& B)
{
  __builtin_assume_aligned(A.data(), 64);
  __builtin_assume_aligned(B.data(), 64);
  return std::inner_product(A.begin(), A.end(), B.begin(), 0.f);
}

Compiled using -O3 -ffast-math -mavx2.

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #2 from Wilco  ---
(In reply to Bernd Edlinger from comment #1)
> some background about this bug can be found here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html

The di3_neon pattern does not constrain the input not to overlap with
the output for immediate shifts, and the arm_emit_coreregs_64bit_shift code
does not handle partial overlaps. However it is feasible to fix that by
swapping the order for the various cases.

[Bug tree-optimization/71915] A missed opportunity for SLSR

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-19
 Ever confirmed|0   |1

--- Comment #3 from Bill Schmidt  ---
Confirmed.

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
some background about this bug can be found here:

https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html

[Bug c++/78042] New: g++ does not select the corresponding overloads of abs() for long and long long

[dominik.muth at gmx dot de]

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

Bug ID: 78042
   Summary: g++ does not select the corresponding overloads of
abs() for long and long long
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominik.muth at gmx dot de
  Target Milestone: ---

// begin example file abs.cxx

#include 
#include 
#include 

int main() {
int myint = INT_MAX;
long mylong = LONG_MAX;
long long myllong = LLONG_MAX;
printf("%lu\n", sizeof(myint));
printf("%lu\n", sizeof(mylong));
printf("%lu\n", sizeof(myllong));
printf("%d\n", myint);
printf("%ld\n", mylong);
printf("%lld\n", myllong);
printf("%d\n", -abs(myint));
printf("%ld\n", -abs(mylong));
printf("%lld\n", -abs(myllong));
printf("%d\n", -abs(myint));
printf("%ld\n", -labs(mylong));
printf("%lld\n", -llabs(myllong));
}

// end example file abs.cxx

$ g++6 -Wall -Wextra -Wconversion -std=c++11 -o abs abs.cxx
abs.cxx: In function 'int main()':
abs.cxx:16:29: warning: conversion to 'int' from 'long int' may alter its value
[-Wconversion]
  printf("%ld\n", -abs(mylong));
 ^
abs.cxx:16:30: warning: format '%ld' expects argument of type 'long int', but
argument 2 has type 'int' [-Wformat=]
  printf("%ld\n", -abs(mylong));
  ^
abs.cxx:17:31: warning: conversion to 'int' from 'long long int' may alter its
value [-Wconversion]
  printf("%lld\n", -abs(myllong));
   ^
abs.cxx:17:32: warning: format '%lld' expects argument of type 'long long int',
but argument 2 has type 'int' [-Wformat=]
  printf("%lld\n", -abs(myllong));
^
$ ./abs
4
8
8
2147483647
9223372036854775807
9223372036854775807
-2147483647
4294967295
4294967295
-2147483647
-9223372036854775807
-9223372036854775807

Obviously int abs(int) is called here all the time. However I expect the
corresponding overloads to be selected according to
http://en.cppreference.com/w/cpp/numeric/math/abs.

$ g++6 -v
Using built-in specs.
COLLECT_GCC=g++6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc6/gcc/x86_64-portbld-freebsd11.0/6.2.0/lto-wrapper
Target: x86_64-portbld-freebsd11.0
Configured with: /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.2.0/configure
--with-build-config=bootstrap-debug --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc6
--libexecdir=/usr/local/libexec/gcc6 --program-suffix=6
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc6/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar
--enable-languages=c,c++,objc,fortran,java --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc6
--build=x86_64-portbld-freebsd11.0
Thread model: posix
gcc version 6.2.0 (FreeBSD Ports Collection) 

Note 1: The FreeBSD 11.0 system compiler behaves as expected:

$ clang++ -Wall -Wextra -Wconversion -std=c++11 -o abs abs.cxx
$ ./abs
4
8
8
2147483647
9223372036854775807
9223372036854775807
-2147483647
-9223372036854775807
-9223372036854775807
-2147483647
-9223372036854775807
-9223372036854775807

Note 2: arm-linux-gnueabihf-g++ version 4.8.4 (Ubuntu/Linaro
4.8.4-2ubuntu1~14.04.3) also FAILS to select the long long abs(long long)
overload.

Note 3: armv7l-unknown-linux-gnueabihf-g++ version 6.2.1 20160830 (GCC) also
FAILS to select the long long abs(long long) overload.

Note 4: aarch64--linux-android clang++ version 3.9.0 (tags/RELEASE_390/final)
also FAILS to select the long abs(long) and long long abs(long long) overloads.

[Bug rtl-optimization/78041] New: Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[bernd.edlinger at hotmail dot de]

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

Bug ID: 78041
   Summary: Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

This is a slightly modified test case:
gcc.c-torture/execute/pr34971.c

struct foo
{
  unsigned long long b:40;
} x;

extern void abort (void);

void test1(unsigned long long res)
{
  /* Build a rotate expression on a 40 bit argument.  */
  if ((x.b<<9) + (x.b>>31) != res)
abort ();
}

int main()
{
  x.b = 0x010001;
  test1(0x000202);
  x.b = 0x01;
  test1(0x02);
  return 0;
}


when compiled with these options it fails:

gcc -mcpu=cortex-a9 -mthumb -mfpu=neon-fp16 -O0

[Bug rtl-optimization/78029] ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Kyrill: Anything inconsistent in the CFI will trigger the assert there,
it is most probably not the same bug.

[Bug target/56676] unnecesary splitted load when using avx2

[rivanvx at gmail dot com]

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

Vedran Miletic  changed:

   What|Removed |Added

 CC||rivanvx at gmail dot com

--- Comment #5 from Vedran Miletic  ---
Confirmed still affecting GCC 6.2.1. Similar C++ example:

#include 
#include 
float f(std::vector& A, std::vector& B)
{
  return std::inner_product(A.begin(), A.end(), B.begin(), 0.f);
}

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461597.html

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Jeffrey A. Law from comment #3)
> If someone has a .i file for this issue, it'd be awful handy.

Well, see comment0:

markus@x4 linux % cat timekeeping.i
int a, b;
extern int ilog2_NaN(void);
void by(void) {
  int c = 1;
  b = a ?: c;
  __builtin_constant_p(b) ? b ? ilog2_NaN() : 0 : 0;
}

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
If someone has a .i file for this issue, it'd be awful handy.

[Bug c++/61491] An explicit specialization of a member enumeration of a class template is rejected

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
Resolving this requires some additional work beyond what I did back in 2015.
See:

  https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00781.html

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> Also, what configure comment, and you seem to have CFLAGS set during
> build?

Configure with: /work/botcazou/gcc-head/src/configure --build=powerpc-linux-gnu
--prefix=/work/botcazou/gcc-head/install_ppc
--with-gmp=/work/botcazou/support/ppc --with-mpfr=/work/botcazou/support/ppc
--with-mpc=/work/botcazou/support/ppc
--enable-languages=c,c++,objc,obj-c++,fortran,ada --enable-__cxa_atexit
--disable-nls --disable-libsanitizer

and just type 'make'.

[Bug c++/70909] Libiberty Demangler segfaults (4)

[palves at redhat dot com]

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

Pedro Alves  changed:

   What|Removed |Added

 CC||palves at redhat dot com

--- Comment #3 from Pedro Alves  ---
These crashes are still plaguing GDB users, unfortunately.

Any chance the patches make it to trunk?

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Build, with what flags?

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Also, what configure comment, and you seem to have CFLAGS set during
build?

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> What bootstrap stage is failing here?

It's a simple build failure, just try to compile the preprocessed testcase.

[Bug target/77991] [5/6/7 Regression] ICE on x32 in plus_constant, at explow.c:87

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.0 |5.5

--- Comment #8 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/77991] [5/6/7 Regression] ICE on x32 in plus_constant, at explow.c:87

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Oct 19 15:00:06 2016
New Revision: 241346

URL: https://gcc.gnu.org/viewcvs?rev=241346=gcc=rev
Log:
PR target/77991
* config/i386/i386.c (legitimize_tls_address)
: For TARGET_64BIT || TARGET_ANY_GNU_TLS
convert dest to Pmode if different than Pmode.

testsuite/ChangeLog:

PR target/77991
* gcc.target/i386/pr77991.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr77991.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/77991] [5/6/7 Regression] ICE on x32 in plus_constant, at explow.c:87

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Oct 19 14:57:35 2016
New Revision: 241345

URL: https://gcc.gnu.org/viewcvs?rev=241345=gcc=rev
Log:
PR target/77991
* config/i386/i386.c (legitimize_tls_address)
: For TARGET_64BIT || TARGET_ANY_GNU_TLS
convert dest to Pmode if different than Pmode.

testsuite/ChangeLog:

PR target/77991
* gcc.target/i386/pr77991.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr77991.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #50 from Jeffrey A. Law  ---
Richi,
I haven't followed this BZ at all, but I absolutely trust you on issues WRT
alias analysis.  If we can't propagate these conditional equivalences for
pointers, I'll happily tweak DOM to avoid that.

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Hi Eric,

What bootstrap stage is failing here?

[Bug target/77897] Compile error with KNL & -O3 for GTC code

[longb at cray dot com]

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

--- Comment #4 from Bill Long  ---
Confirmation from the customer system:

GNU assembler (GNU Binutils; SUSE Linux Enterprise 12) 2.25.0
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.

[Bug c++/78039] [6/7 Regression] fails to compile glibc tests

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #5)
> Sorry, that was the wrong link.  The correct link to the email thread where
> the approval was requested is here:
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01094.html
> I don't see Jason's approval in the archive but I still have it in my Inbox.

That doesn't mean it was a good idea to backport the whole patch.
Sure, there is a regression, so you should backport the part of the patch that
resolves that regression (ICE, or rejects-valid, ...), but not other parts of
the patch that reject what has been previously accepted.
People are really not willing to adjust their code in between snapshots from
release branches because it got more and more strict in what it accepts.  Such
changes belong to trunk only.

[Bug sanitizer/78028] ASAN doesn't find memory leak

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
That wouldn't be WONTFIX, but FIXED, the support of GCC release branches mean
that the bug is just fixed on the release branch and later on will make it into
some newer minor release, we can't fix released versions.  But we really don't
know, nobody has managed to reproduce it besides you.  It might be a Ubuntu
specific bug or whatever.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||61502, 49330

--- Comment #49 from Richard Biener  ---
Related testcase from PR61502:

#include 

int main()
{
   int x, y = 1;
   int *volatile v;
   int *p;

   v = 
   p = v;
   if (p ==  + 1) {
 *p = 2;
 printf("y = %d\n", y);
   }
}

which shows how propagating conditional equivalences (+1 into *p = 2) breaks
alias analysis.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
[Bug 49330] Integer arithmetic on addresses optimised with pointer arithmetic
rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
[Bug 61502] == comparison on "one-past" pointer gives wrong result

[Bug c++/78039] [6/7 Regression] fails to compile glibc tests

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Sorry, that was the wrong link.  The correct link to the email thread where the
approval was requested is here:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01094.html
I don't see Jason's approval in the archive but I still have it in my Inbox.

[Bug sanitizer/78028] ASAN doesn't find memory leak

[barto at cambridgesemantics dot com]

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

--- Comment #3 from David Barto  ---
If it is restricted to 5.2, then we can close this as "won't fix"

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias
   Last reconfirmed|2011-06-09 09:36:46 |2016-10-19

--- Comment #12 from Richard Biener  ---
Re-confirmed on trunk.

[Bug c++/78040] New: Missed mangled names of class methods in the translation unit dump

[andrei.moscow at mail dot ru]

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

Bug ID: 78040
   Summary: Missed mangled names of class methods in the
translation unit dump
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrei.moscow at mail dot ru
  Target Milestone: ---

The mangled names of class methods are missed in the translation unit (TU) dump
for a C++ header when using latest GCC 6.2.

All is OK (mangled names are present in the TU dump) when using GCC 4.9.4 or
GCC 5.4.

This feature is very important for maintaining backward binary compatibility of
Linux libraries. Please help.

How to reproduce:

1. Take a header file:

class TestClass
{
public:
int testMethod(int testParam);
};

int testFunc();

2. Compile it by GCC 5.4 with -fdump-translation-unit additional option:

./GCC-5.4/bin/g++ -fdump-translation-unit test.h

3. Check mangled names (GCC 5.4):

cat test.h.001t.tu |grep "testMethod\|testFunc\|TestClass"
@5  identifier_node  strg: testFunc lngt: 8   
@11 identifier_node  strg: TestClass   lngt: 9   
@33 identifier_node  strg: testMethod  lngt: 10  
@34 identifier_node  strg: _ZN9TestClass10testMethodEi

4. Compile it by GCC 6.2 with -fdump-translation-unit additional option:

./GCC-6.2/bin/g++ -fdump-translation-unit test.h

5. Check mangled names (GCC 6.2):

cat test.h.001t.tu |grep "testMethod\|testFunc\|TestClass"
@5  identifier_node  strg: testFunc lngt: 8   
@11 identifier_node  strg: TestClass   lngt: 9   
@33 identifier_node  strg: testMethod  lngt: 10

The mangled name "ZN9TestClass10testMethodEi" is missed when using GCC 6.2.

Thank you.

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|SUSPENDED
   Last reconfirmed||2016-10-19
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #23 from Richard Biener  ---
.

[Bug c++/78039] [6/7 Regression] fails to compile glibc tests

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|rejects-valid   |
 CC||jason at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
The code is invalid and the error is correct (some background is in bug 77650).
 The patch was approved for 6.0 here:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00169.html

The error can be avoided by using the zero-length array extension.   I would
suggest resolving this bug as invalid but I'll leave it to Jason and others to
make the decision.

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

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

--- Comment #17 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Oct 19 13:35:14 2016
New Revision: 241342

URL: https://gcc.gnu.org/viewcvs?rev=241342=gcc=rev
Log:
2016-10-19  Bill Schmidt  

PR tree-optimization/77916
PR tree-optimization/77937
* gimple-ssa-strength-reduction.c (analyze_increments): Remove
stopgap fix.
(insert_initializers): Requirement of initializer for -1 should be
based on pointer-typedness of the candidate basis.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug tree-optimization/77916] [6/7 Regression] ICE in verify_gimple_in_cfg: invalid (pointer) operands to plus/minus

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Oct 19 13:35:14 2016
New Revision: 241342

URL: https://gcc.gnu.org/viewcvs?rev=241342=gcc=rev
Log:
2016-10-19  Bill Schmidt  

PR tree-optimization/77916
PR tree-optimization/77937
* gimple-ssa-strength-reduction.c (analyze_increments): Remove
stopgap fix.
(insert_initializers): Requirement of initializer for -1 should be
based on pointer-typedness of the candidate basis.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug rtl-optimization/78038] [5/6/7 Regression] internal compiler error: in get_sub_rtx, at ree.c:655

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Steffen Schmidt from comment #0)
> Created attachment 39840 [details]
> Test source file
> 
> Dear GCC maintainers,
> 
> we found that gcc / g++ crashes with internal compiler error in get_sub_rtx,
> at ree.c:655 at optimization level -O2
> Target plattform is aarch64-elf, in detail -march=armv8-a -mabi=ilp32
> 
> It seems the the order of the statements, especially the call to a function
> pointer and use of global register variable is important. Unfortunately I
> could not determine a dedicated optimization option causing the problem.
> 

By the way, the optimisation in which the ICE occurs is ree (redundant
extension elimination). You can turn it off by adding -fno-ree to the flags.

[Bug rtl-optimization/78038] [5/6/7 Regression] internal compiler error: in get_sub_rtx, at ree.c:655

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|target  |rtl-optimization
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
I'll take a stab at this

[Bug c++/78039] [6/7 Regression] fails to compile glibc tests

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |6.3

[Bug c++/78039] [6/7 Regression] fails to compile glibc tests

[rguenth at gcc dot gnu.org]

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

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

[Bug target/78038] [5/6/7 Regression] internal compiler error: in get_sub_rtx, at ree.c:655

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #2)
> Hmm, so the zero_extend candidate is:
> (insn 9 10 11 2 (set (reg/f:DI 1 x1 [orig:74 g.1_2 ] [74])
> (zero_extend:DI (reg/v:SI 28 x28 [ g ]))) "ree.c":16 84
> {*zero_extendsidi2_aarch64}
>  (nil))
> 
> and the def_insn that causes the ICE in get_sub_rtx is:
> (call_insn 8 7 10 2 (parallel [
> (call (mem:DI (reg/f:DI 0 x0 [orig:77 test_fptr ] [77]) [0
> *test_fptr.0_1 S8 A8])
> (const_int 0 [0]))
> (use (const_int 0 [0]))
> (clobber (reg:DI 30 x30))
> ]) "ree.c":14 41 {*call_reg}
>  (expr_list:REG_CALL_DECL (nil)
> (nil))
> (expr_list (clobber (reg:DI 17 x17))
> (expr_list (clobber (reg:DI 16 x16))
> (nil
> 
> This doesn't have a SET anywhere in it so it causes the ICE.
> The question is, by what logic did dataflow decide that call_insn 8 defines
> register x28?

I suppose it's because of:
register struct test2_s *g __asm__("x28");
Are calls assumed to clobber/write such things?

[Bug libfortran/74755] libgfortran: build breaks if localtime_r prototype is present, but definition is not

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED
 CC||nathan at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #3 from Thomas Schwinge  ---
Nathan applied a workaround in trunk r239836,
.

(For the record, at least with a "combined" source tree, you don't explicitly
have to configure --with-newlib to make this work, as --with-newlib will be
passed by the build system.)

I still think this should really be fixed in newlib, and that the configure
auto-detection should be re-enabled then.

Nathan's trunk r239836 caused the following changes in
[build]/nvptx-none/libgfortran/config.h:

 /* Define to 1 if you have the `gmtime_r' function. */
-/* #undef HAVE_GMTIME_R */
+#define HAVE_GMTIME_R 1

 /* Define to 1 if you have the `localtime_r' function. */
-/* #undef HAVE_LOCALTIME_R */
+#define HAVE_LOCALTIME_R 1

 /* Define to 1 if you have the `mkstemp' function. */
-/* #undef HAVE_MKSTEMP */
+#define HAVE_MKSTEMP 1

 /* Define to 1 if you have the `strtold' function. */
-#define HAVE_STRTOLD 1
+/* #undef HAVE_STRTOLD */

..., accompanied by a few test case regressions, because some of these
hardwired routines are not actually available in the nvptx newlib port.

[Bug tree-optimization/78035] Inconsistency between address comparison and alias analysis

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Wed, 19 Oct 2016, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035
> 
> Alexander Monakov  changed:
> 
>What|Removed |Added
> 
>  CC||amonakov at gcc dot gnu.org
> 
> --- Comment #5 from Alexander Monakov  ---
> Note that for external function symbols from the standard library there's an
> old DR that clarifies that their addresses may compare equal, since the 
> library
> may be implemented in a language other than C. See point c) in
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_078.html

"Not implemented in C" would apply to any extern function pair as the
compiler does not know wheter it's part of a "standard library"
(I think restricting the answer to standard library function is
misguided).

> But that is only for function declarations, I don't know if for object
> declarations it's the same or different. Credit goes to Szabolcs Nagy for
> pointing me to this DR.

Usually it's out of the scope of the C standard but we generally try
to honor ELF possibilities.

[Bug target/78038] [5/6/7 Regression] internal compiler error: in get_sub_rtx, at ree.c:655

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Hmm, so the zero_extend candidate is:
(insn 9 10 11 2 (set (reg/f:DI 1 x1 [orig:74 g.1_2 ] [74])
(zero_extend:DI (reg/v:SI 28 x28 [ g ]))) "ree.c":16 84
{*zero_extendsidi2_aarch64}
 (nil))

and the def_insn that causes the ICE in get_sub_rtx is:
(call_insn 8 7 10 2 (parallel [
(call (mem:DI (reg/f:DI 0 x0 [orig:77 test_fptr ] [77]) [0
*test_fptr.0_1 S8 A8])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:DI 30 x30))
]) "ree.c":14 41 {*call_reg}
 (expr_list:REG_CALL_DECL (nil)
(nil))
(expr_list (clobber (reg:DI 17 x17))
(expr_list (clobber (reg:DI 16 x16))
(nil

This doesn't have a SET anywhere in it so it causes the ICE.
The question is, by what logic did dataflow decide that call_insn 8 defines
register x28?

[Bug target/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[nlescoua at gmail dot com]

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

--- Comment #8 from Nicolas Le Scouarnec  ---
The same problem may be present in lzcnt which is also expanded as
__builtin_clz which is also undefined if 0.
http://www.felixcloutier.com/x86/LZCNT.html

[Bug sanitizer/77982] deadlock in asan thread initialization/interception.

[pawel_sikora at zoho dot com]

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

--- Comment #1 from Pawel Sikora  ---
Created attachment 39842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39842=edit
reduced testcase.

% gdb ./m
GNU gdb (GDB) Fedora 7.11.1-86.fc24


(gdb) r
Starting program: /home/pawels/src/bug/m 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
initializing library...
[New Thread 0x734ff700 (LWP 26786)]
^C
Thread 1 "m" received signal SIGINT, Interrupt.
__sanitizer::internal_sched_yield () at
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:304
304 }


(gdb) thread apply all bt

Thread 2 (Thread 0x734ff700 (LWP 26786)):
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x75baea76 in __GI___pthread_mutex_lock (mutex=0x77ffd908
<_rtld_local+2312>) at ../nptl/pthread_mutex_lock.c:115
#2  0x77deb6da in tls_get_addr_tail (ti=0x77163b30,
dtv=0x6120bed0, the_map=0x77ff7658) at dl-tls.c:765
#3  0x76e68f4b in __interceptor___tls_get_addr (arg=0x77163b30) at
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4207
#4  0x76f21ec4 in __lsan::DisabledInThisThread () at
../../../../libsanitizer/lsan/lsan_common.cc:33
#5  0x76e62815 in __asan::Allocator::Allocate (this=0x77166d20
<__asan::instance>, size=, alignment=,
stack=0x734fe430, alloc_type=, 
can_fill=) at
../../../../libsanitizer/asan/asan_allocator.cc:449
#6  0x76efe1d1 in __interceptor_realloc (ptr=0x0, size=32) at
../../../../libsanitizer/asan/asan_malloc_linux.cc:83
#7  0x75bae035 in pthread_getattr_np (thread_id=,
attr=attr@entry=0x734fed90) at pthread_getattr_np.c:161
#8  0x76f179fd in __sanitizer::GetThreadStackTopAndBottom
(at_initialization=at_initialization@entry=false,
stack_top=stack_top@entry=0x734fee18,
stack_bottom=stack_bottom@entry=0x734fee20)
at ../../../../libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:112
#9  0x76f17f5e in __sanitizer::GetThreadStackAndTls (main=, stk_addr=stk_addr@entry=0x77f88020,
stk_size=stk_size@entry=0x77f88028, tls_addr=tls_addr@entry=0x77f88030, 
tls_size=tls_size@entry=0x734fee70) at
../../../../libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:388
#10 0x76f0b675 in __asan::AsanThread::SetThreadStackAndTls
(this=this@entry=0x77f88000) at
../../../../libsanitizer/asan/asan_thread.cc:197
#11 0x76f0b8a2 in __asan::AsanThread::Init
(this=this@entry=0x77f88000) at
../../../../libsanitizer/asan/asan_thread.cc:153
#12 0x76f0ba68 in __asan::AsanThread::ThreadStart (this=0x77f88000,
os_id=26786, signal_thread_is_registered=0x7fffc428) at
../../../../libsanitizer/asan/asan_thread.cc:166
#13 0x75bac5ca in start_thread (arg=0x734ff700) at
pthread_create.c:333
#14 0x762cff6d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x77fcf780 (LWP 26778)):
#0  __sanitizer::internal_sched_yield () at
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:304
#1  0x76e685c5 in __interceptor_pthread_create (thread=0x7fffccb0,
attr=, start_routine=0x77fdbb60 , arg=0x0)
at ../../../../libsanitizer/asan/asan_interceptors.cc:256
#2  0x77fdbc02 in startPolling () at s.cpp:19
#3  0x77de8d8a in call_init (l=, argc=argc@entry=1,
argv=argv@entry=0x7fffdb88, env=env@entry=0x7fffdb98) at dl-init.c:72
#4  0x77de8e9b in call_init (env=0x7fffdb98, argv=0x7fffdb88,
argc=1, l=) at dl-init.c:30
#5  _dl_init (main_map=main_map@entry=0x61a1f280, argc=1,
argv=0x7fffdb88, env=0x7fffdb98) at dl-init.c:120
#6  0x77deda91 in dl_open_worker (a=a@entry=0x7fffcfb0) at
dl-open.c:564
#7  0x77de8c34 in _dl_catch_error
(objname=objname@entry=0x7fffcfa0,
errstring=errstring@entry=0x7fffcfa8,
mallocedp=mallocedp@entry=0x7fffcf9f, 
operate=operate@entry=0x77ded640 ,
args=args@entry=0x7fffcfb0) at dl-error.c:187
#8  0x77decfe9 in _dl_open (file=0x400900 "./s.so", mode=-2147483647,
caller_dlopen=0x76e7e454 <__interceptor_dlopen(char const*, int)+116>,
nsid=-2, argc=, argv=, 
env=0x7fffdb98) at dl-open.c:649
#9  0x75fc9f09 in dlopen_doit (a=a@entry=0x7fffd1e0) at dlopen.c:66
#10 0x77de8c34 in _dl_catch_error (objname=0x773848b0
, errstring=0x773848b8
, mallocedp=0x773848a8
, 
operate=0x75fc9eb0 , args=0x7fffd1e0) at
dl-error.c:187
#11 0x75fca591 in _dlerror_run (operate=operate@entry=0x75fc9eb0
, args=args@entry=0x7fffd1e0) at dlerror.c:163
#12 0x75fc9fa2 in __dlopen (file=, mode=)
at dlopen.c:87
#13 0x76e7e454 in __interceptor_dlopen (filename=0x400900 "./s.so",
flag=1) at

[Bug target/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-19
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

--- Comment #7 from Uroš Bizjak  ---
I have a patch.

[Bug c++/78039] [6/7 Regression] fails to compile glibc tests

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
IMHO such rejects-invalid changes (if it is indeed considered invalid)
shouldn't be backported to release branches, unless GCC ICEd all the time and
we just turn ice-on-invalid to rejects-invalid.

[Bug middle-end/78016] REG_NOTE order is not kept during insn copy

[jiwang at gcc dot gnu.org]

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

--- Comment #4 from Jiong Wang  ---
(In reply to Eric Botcazou from comment #3)
> > I am wondering whether it's OK to use copy_insn_1 here? that is to replace
> > the whole for loop into something simply as "REG_NOTES (new_insn) =
> > copy_insn_1 (REG_NOTES (old_insn);"  as I think copy_insn_1 will do
> > recursive copy.  This is what's used in old reload1.c.
> 
> Yet another way of copying notes...  I didn't know about it but, yes, it
> looks well-behaved, albeit a bit heavier than the others.
> 
> Ideally we would have a single routine along the other routines in rtlanal.c
> to deal with note copying, with a few boolean parameters to drop some of
> them.
> 
> > So copy_insn_1 is safe?
> 
> I'd write something more specialized in rtlanal.c instead.

Thanks, Eric.

I am thinking to make those list insertion function in lists.c bi-directional,
then make existed allocate_EXPR_LIST/INST_LIST/INT_LIST call new bi-directional
functions.   Will post the patch once regression OK.

[Bug c++/78039] [6/7 Regression] fails to compile glibc tests

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
gcc-6-branch 20161010 (r240906) built the glibc tests ok.

[Bug c++/78039] New: [6/7 Regression] fails to compile glibc tests

[doko at gcc dot gnu.org]

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

Bug ID: 78039
   Summary: [6/7 Regression]  fails to compile glibc tests
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39841=edit
preprocessed source

gcc-6-branch 20161018 fails to build the glibc-2.24 tests:

$ g++ -std=gnu++11 -c -O2 math/test-math-isinff.ii
In file included from ../include/gconv.h:1:0,
 from ../sysdeps/unix/sysv/linux/_G_config.h:32,
 from ../libio/libio.h:31,
 from ../include/libio.h:4,
 from ../libio/stdio.h:74,
 from ../include/stdio.h:5,
 from test-math-isinff.cc:22:
../iconv/gconv.h:142:50: error: flexible array member '__gconv_info::__data'
not at end of 'struct _IO_codecvt'
In file included from ../include/libio.h:4:0,
 from ../libio/stdio.h:74,
 from ../include/stdio.h:5,
 from test-math-isinff.cc:22:
../libio/libio.h:211:14: note: next member '_G_iconv_t _IO_codecvt::__cd_out'
declared here
../libio/libio.h:187:8: note: in the definition of 'struct _IO_codecvt'
In file included from ../include/gconv.h:1:0,
 from ../sysdeps/unix/sysv/linux/_G_config.h:32,
 from ../libio/libio.h:31,
 from ../include/libio.h:4,
 from ../libio/stdio.h:74,
 from ../include/stdio.h:5,
 from test-math-isinff.cc:22:
../iconv/gconv.h:142:50: error: flexible array member '__gconv_info::__data'
not at end of 'struct _IO_wide_data'
In file included from ../include/libio.h:4:0,
 from ../libio/stdio.h:74,
 from ../include/stdio.h:5,
 from test-math-isinff.cc:22:
../libio/libio.h:211:14: note: next member '_G_iconv_t _IO_codecvt::__cd_out'
declared here
../libio/libio.h:215:8: note: in the definition of 'struct _IO_wide_data'

[Bug target/78038] [5/6/7 Regression] internal compiler error: in get_sub_rtx, at ree.c:655

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-10-19
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|internal compiler error: in |[5/6/7 Regression] internal
   |get_sub_rtx, at ree.c:655   |compiler error: in
   ||get_sub_rtx, at ree.c:655
   Target Milestone|--- |5.5
  Known to fail||4.9.4, 5.4.1, 7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on all versions that support -mabi=ilp32. It doesn't ICE for me
without -mabi=ilp32

[Bug tree-optimization/78035] Inconsistency between address comparison and alias analysis

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
Note that for external function symbols from the standard library there's an
old DR that clarifies that their addresses may compare equal, since the library
may be implemented in a language other than C. See point c) in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_078.html

But that is only for function declarations, I don't know if for object
declarations it's the same or different. Credit goes to Szabolcs Nagy for
pointing me to this DR.

[Bug target/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> That is because _tzcnt_u64 is expanded as __builtin_ctzll, which is
> explicitly UB with zero argument.  So, either we need to expand it like
> x ? __builtin_ctzll (x) : 64 and make sure at RTL level we optimize this into
> just tzcnt instruction if available (though, that is questionable, because
> if you run tzcntq instruction on non-BMI CPUs, it will just be BSF with
> undefined result for 0), or add a new builtin, or unconditionally expand to
> the conditional.

A new UNSPEC insn pattern should be added and expanded from __tzcnt_u{16,32,64}
builtin.

[Bug target/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
That is because _tzcnt_u64 is expanded as __builtin_ctzll, which is explicitly
UB with zero argument.  So, either we need to expand it like
x ? __builtin_ctzll (x) : 64 and make sure at RTL level we optimize this into
just tzcnt instruction if available (though, that is questionable, because if
you run tzcntq instruction on non-BMI CPUs, it will just be BSF with undefined
result for 0), or add a new builtin, or unconditionally expand to the
conditional.

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[harald at gigawatt dot nl]

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

--- Comment #22 from Harald van Dijk  ---
(In reply to Andrew Pinski from comment #21)
> Invalid as mentioned a few times already but never actually closed until now.

I posted a strictly conforming program that with GCC does not behave as
required by the standard. The issue is valid, even if the original test case is
not.

[Bug target/78038] New: internal compiler error: in get_sub_rtx, at ree.c:655

[steffen-schmidt at siemens dot com]

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

Bug ID: 78038
   Summary: internal compiler error: in get_sub_rtx, at ree.c:655
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steffen-schmidt at siemens dot com
  Target Milestone: ---

Created attachment 39840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39840=edit
Test source file

Dear GCC maintainers,

we found that gcc / g++ crashes with internal compiler error in get_sub_rtx, at
ree.c:655 at optimization level -O2
Target plattform is aarch64-elf, in detail -march=armv8-a -mabi=ilp32

It seems the the order of the statements, especially the call to a function
pointer and use of global register variable is important. Unfortunately I could
not determine a dedicated optimization option causing the problem.

Thanks for in advance for any help.

---

aarch64-elf-g++ -v

Using built-in specs.
COLLECT_GCC=aarch64_gcc_elf_6.1.0\bin\aarch64-elf-g++
COLLECT_LTO_WRAPPER=aarch64_gcc_elf_6.1.0/bin/../libexec/gcc/aarch64-elf/6.1.0/lto-wrapper.exe
Target: aarch64-elf
Configured with: ../../gcc-6.1.0//configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32
--prefix=/build/aarch64-elf_6.1.0_x64/cross-gcc/aarch64-elf
--target=aarch64-elf --disable-nls --enable-multilib
--with-multilib-list=lp64,ilp32 --enable-languages=c,c++
--disable-decimal-float
--with-sysroot=/build/aarch64-elf_6.1.0_x64/cross-gcc/aarch64-elf
--without-headers --disable-shared --disable-threads --disable-lto
--disable-libmudflap --disable-libssp --disable-libgomp --disable-libffi
--disable-libstdcxx-pch --disable-win32-registry
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-newlib --with-gcc --with-gnu-as --with-gnu-ld
--with-gmp=/build/aarch64-elf_6.1.0_x64/host
--with-mpfr=/build/aarch64-elf_6.1.0_x64/host
--with-mpc=/build/aarch64-elf_6.1.0_x64/host
--with-isl=/build/aarch64-elf_6.1.0_x64/host : (reconfigured)
../../gcc-6.1.0//configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-multilib --with-multilib-list=lp64,ilp32
--disable-lto --disable-libmudflap --disable-libssp --disable-libgomp
--disable-libffi --with-newlib --with-gcc --with-gnu-ld --with-gnu-as
--with-stabs --disable-shared --disable-threads --disable-win32-registry
--disable-nls --disable-libstdcxx-pch --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --target=aarch64-elf
--prefix=/build/aarch64-elf_6.1.0_x64/cross-gcc/aarch64-elf
--with-gmp=/build/aarch64-elf_6.1.0_x64/host
--with-mpfr=/build/aarch64-elf_6.1.0_x64/host
--with-mpc=/build/aarch64-elf_6.1.0_x64/host
--with-isl=/build/aarch64-elf_6.1.0_x64/host
--with-sysroot=/build/aarch64-elf_6.1.0_x64/cross-gcc/aarch64-elf

Thread model: single
gcc version 6.1.0 (GCC)

---
// Test file test.cpp:
typedef void (*test_fptr_t)(void);
void test_f (void) { }
test_fptr_t test_fptr = test_f;

struct test2_s
{
  int f;
};

register struct test2_s *g __asm__("x28");

void do_something()
{
  test_fptr();
  struct test2_s *p1 = 0;
  *p1 = *g;
}

---
aarch64-elf-g++ -mabi=ilp32 -O2 -march=armv8-a -c -o test.o test.cpp

[Bug c/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[nlescoua at gmail dot com]

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

--- Comment #4 from Nicolas Le Scouarnec  ---
Created attachment 39839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39839=edit
Incorrect assembly at optimization level O2

[Bug c/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[nlescoua at gmail dot com]

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

--- Comment #3 from Nicolas Le Scouarnec  ---
Created attachment 39838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39838=edit
Correct Assembly at optimization level O1

[Bug c/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[nlescoua at gmail dot com]

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

--- Comment #2 from Nicolas Le Scouarnec  ---
Created attachment 39837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39837=edit
i file

[Bug c/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[nlescoua at gmail dot com]

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

--- Comment #1 from Nicolas Le Scouarnec  ---
Created attachment 39836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39836=edit
C file

[Bug c/78037] New: Incorrect code generated at optimization level -O2 for tzcnt and binary and

[nlescoua at gmail dot com]

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

Bug ID: 78037
   Summary: Incorrect code generated at optimization level -O2 for
tzcnt and binary and
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nlescoua at gmail dot com
  Target Milestone: ---

System: Haswell (Linux 64bit)

The following program compiles incorrectly on gcc 6.2.0 (and also gcc 5.3.1).
---
#include 
#include 
#include 

int main(int argc, char ** argv){
  unsigned long l = atol(argv[1]);
  uint32_t t = _tzcnt_u64(l) & 63llu;
  printf("%u\n",t);
}

The tzcnt_u64 intrisic returns the number of trailing zero in the argument and
64 (the register width) if the argument is 0. Complete specification is
available here: http://www.felixcloutier.com/x86/TZCNT.html

Expected output:
~/g/d/gcc_bug ❯❯ gcc -mbmi -O0 toto.c && ./a.out 0
0

Erroneous output when using -O2 or -O3 (the binary and gets eliminated by the
optimizer).
~/g/d/gcc_bug ❯❯ gcc -mbmi -O2 toto.c && ./a.out 0
64

The result must be 0 because 64&63 = 0

When looking at the assembly generated, the "and" instruction is missing at
optimization level 2 or 3, as if the optimizer assumed that the values returned
by tzcnt are in the range [0:63] whereas the effective range is [0:64].

[Bug lto/78034] undefined reference during LTO linking.

[pawel_sikora at zoho dot com]

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

--- Comment #5 from Pawel Sikora  ---
(In reply to Andrew Pinski from comment #3)
> Also why are you using inline-asm here?  Why can't you use the SSE
> intrinsics?

it's a 3rd-party crypto library which works for me with gcc-4.9.
now with gcc-6.2 i've disabled this asm magic with -DCRYPTOPP_DISABLE_X86ASM.
case closed :)

[Bug c/64279] Warning missing for "(cond) ? A : A" / if(cond) expr1; else expr1; // same expression in if and else branch

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
I just posted , but
given the macro issue, I'm not really sanguine.

[Bug tree-optimization/78005] [7 Regression] 172.mgrid and 450.soplex miscompare

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Oct 19 11:02:23 2016
New Revision: 241339

URL: https://gcc.gnu.org/viewcvs?rev=241339=gcc=rev
Log:
PR tree-optimization/78005
* tree-vect-loop-manip.c (vect_gen_prolog_loop_niters): Compute
upper (included) bound for niters of prolog loop.
(vect_gen_scalar_loop_niters): Change parameter VF to VFM1.
Compute niters of scalar loop above which vectorized loop is
preferred, as well as the upper (included) bound for the niters.
(vect_do_peeling): Record niter bound for loops accordingly.

gcc/testsuite
PR tree-optimization/78005
* gcc.dg/vect/pr78005.c: New.
* gcc.target/i386/l_fma_float_1.c: Revise test.
* gcc.target/i386/l_fma_float_2.c: Ditto.
* gcc.target/i386/l_fma_float_3.c: Ditto.
* gcc.target/i386/l_fma_float_4.c: Ditto.
* gcc.target/i386/l_fma_float_5.c: Ditto.
* gcc.target/i386/l_fma_float_6.c: Ditto.
* gcc.target/i386/l_fma_double_1.c: Ditto.
* gcc.target/i386/l_fma_double_2.c: Ditto.
* gcc.target/i386/l_fma_double_3.c: Ditto.
* gcc.target/i386/l_fma_double_4.c: Ditto.
* gcc.target/i386/l_fma_double_5.c: Ditto.
* gcc.target/i386/l_fma_double_6.c: Ditto.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr78005.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_1.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_2.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_3.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_4.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_5.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_double_6.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_1.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_2.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_3.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_4.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_5.c
trunk/gcc/testsuite/gcc.target/i386/l_fma_float_6.c
trunk/gcc/tree-vect-loop-manip.c

[Bug lto/77458] nvptx offloading ICEs after "Implement C _FloatN, _FloatNx types"

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
Fixed in r241338.

[Bug lto/77458] nvptx offloading ICEs after "Implement C _FloatN, _FloatNx types"

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Oct 19 10:48:46 2016
New Revision: 241338

URL: https://gcc.gnu.org/viewcvs?rev=241338=gcc=rev
Log:
[PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types

gcc/
PR lto/77458
* tree-core.h (enum tree_index): Put the complex types after their
component types.
* tree-streamer.c (verify_common_node_recorded): New function.
(preload_common_nodes) : Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree-streamer.c

[Bug libstdc++/77990] unique_ptr<T, D>::unique_ptr(T*) imposes CopyConstructible on the deleter

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for 5.5, 6.3 and trunk. Thanks for reporting it.

[Bug libstdc++/77990] unique_ptr<T, D>::unique_ptr(T*) imposes CopyConstructible on the deleter

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 19 10:36:24 2016
New Revision: 241337

URL: https://gcc.gnu.org/viewcvs?rev=241337=gcc=rev
Log:
PR77990 fix unique_ptr for non-copyable deleters

PR libstdc++/77990
* include/bits/unique_ptr.h (unique_ptr::unique_ptr(pointer)): Set
pointer member after value-initialization of tuple.
* testsuite/20_util/unique_ptr/assign/48635_neg.cc: Adjust dg-errors.
* testsuite/20_util/unique_ptr/cons/77990.cc: New test.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/20_util/unique_ptr/cons/77990.cc
  - copied, changed from r241324,
branches/gcc-5-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/unique_ptr.h
   
branches/gcc-5-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc

[Bug tree-optimization/78024] [7 regression] test cases gfortran.dg/goacc/routine-4.f90 and also routine-5.f90 fail starting with r241296

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Schwinge  ---
(In reply to rguent...@suse.de from comment #6)
> On Wed, 19 Oct 2016, tschwinge at gcc dot gnu.org wrote:
> > (In reply to Richard Biener from comment #4)
> > > Well, must be another missing BB_VISITED clearing then.
> > 
> > I wonder why you didn't see that regression in your testing?
> 
> I did but didn't thought it was my patch (oacc should be unrelated).

Well, compiler optimizations also work for (and, occasionally break) OpenACC
code.  ;-)

> I also assumed the posted patch was already committed (as I approved it)

Committed in r241334.