[Bug target/25967] Add attribute naked for x86

[daniel.santos at pobox dot com]

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

--- Comment #12 from Daniel Santos  ---
For those interested in a work-around, you can define an __attribute__((used))
function and then within that function use inline assembly to declare your real
function.  This can get messy depending upon how portable you need you your
code to be, here is an example:

static void __attribute__((used)) dummy ()
{
  __asm__ ("\n"
"   .globl myfunc\n"
#ifdef __ELF__
"   .type myfunc,@function\n"
#endif
"myfunc:\n"
"   \n"
"   ret\n   # you must do your own ret.\n"
  )
}

I used this in the ms to system v function call tests:
https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c#L172

[Bug c++/81609] incompatible extern C declarations of the same extern function at local scope accepted

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
related to PR 32042,

[Bug c++/81610] bogus fix-it hint for a call to an undeclared function: for

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80567
   Severity|normal  |minor

--- Comment #1 from Martin Sebor  ---
See also bug 80567 for a similar problem.

[Bug c++/81610] New: bogus fix-it hint for a call to an undeclared function: for

[msebor at gcc dot gnu.org]

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

Bug ID: 81610
   Summary: bogus fix-it hint for a call to an undeclared
function: for
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When G++ detects a call to an undeclared function it prints an error message
which may include a fix-it hint with a suggestion for an alternative.  That's
helpful when the alternative is a function with a similar name.  It's not
helpful when the alternative is not a function that can be called as in the
case below where the suggestion is obviously bogus.  G++ should avoid
suggesting symbols that cannot be used in the context in which the original
name is used.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
void f (void *p)
{
  forget (p);
}
t.C: In function ‘void f(void*)’:
t.C:3:3: error: ‘forget’ was not declared in this scope
   forget (p);
   ^~
t.C:3:3: note: suggested alternative: ‘for’
   forget (p);
   ^~
   for

[Bug c++/81609] New: incompatible extern C declarations of the same extern function at local scope accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 81609
   Summary: incompatible extern C declarations of the same extern
function at local scope accepted
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Somewhat similar to bug 81608, G++ correctly rejects a function redeclaration
at local scope that's incompatible with a prior declaration of the same
function at namespace scope but only so long as the function has C++ language
linkage.

G++ fails to reject the same incompatible redeclaration of functions with C
language linkage.

Clang rejects both as expected.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
extern "C" {

int foo (void) { return 123; }

char* f (void)
{
  extern char* foo (void);

  return foo ();
}

}

int bar (void) { return 123; }

char* g (void)
{
  extern char* bar (void);

  return bar ();
}

t.C: In function ‘char* g()’:
t.C:18:16: error: local external declaration ‘char* bar()’ [-fpermissive]
   extern char* bar (void);
^~~
t.C:14:5: note: does not match previous declaration ‘int bar()’
 int bar (void) { return 123; }
 ^~~

[Bug c++/81608] incompatible declarations of the same extern function at different scopes accepted

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think there might be a duplicate of this bug already. It was noticed when
Zack (or was it joseph) implemented the correct behavior for the c front-end.
This was during the 3.4 time frame.

[Bug c++/81608] New: incompatible declarations of the same extern function at different scopes accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 81608
   Summary: incompatible declarations of the same extern function
at different scopes accepted
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ silently accepts the following ill-formed program that declares the same
function with three different return types.

Clang and GCC (in C mode) correctly detect the mismatch and reject the program
expected.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
int f (void)
{
  extern int g (void);

  return g ();
}

void* h (void)
{
  extern void* g (void);

  return g ();
}

void g (void) { }

[Bug c/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.

[hp at bitrange dot com]

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

--- Comment #6 from Hans-Peter Nilsson  ---
On Fri, 28 Jul 2017, egallager at gcc dot gnu.org wrote:
> Testcase compiles, runs, and exits with 0 for me on i386-apple-darwin9.8.0.

I'm not sure how that target is relevant?

(I forgot to set a target and can't edit the bug at present
other than replying by email, but see the original description
for a list of targets where the test was known to fail or
expected to fail.  Note also that the test is brittle and may be
undesirably optimized to always pass.)

> Can you try again?

Not for a couple of weeks, sorry.

brgds, H-P

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||yyc1992 at gmail dot com

--- Comment #2 from Eric Gallager  ---
*** Bug 68336 has been marked as a duplicate of this bug. ***

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #0)
> While testing Marek's patch for PR 64249 I noticed that both gcc and g++
> incorrectly issue a -Wreturn-type warning for the following snippet:
> 
> $ cat u.c && xgcc -Wreturn-type -c u.c
> int foo (_Bool a) {
> if (a) return 0;
> else if (!a) return 1;
> }
> u.c: In function ‘foo’:
> u.c:4:1: warning: control reaches end of non-void function [-Wreturn-type]
>  }
>  ^

Confirmed.

[Bug middle-end/68336] False positive Wreturn-type warning

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
Comment in bug 67629 said this one might be a duplicate of that one, so closing
it as such.

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

[Bug c/68121] __builtin_constant_p should not warn about integer overflow

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, full warning is:

$ /usr/local/bin/gcc -c -S 68121.c
68121.c:4:33: warning: integer overflow in expression of type ‘int’ results in
‘-294967296’ [-Woverflow]
 a = __builtin_constant_p (x + y) ? x : -1,
 ^
$

(Martin Sebor recently added the part where it calculates the result; cc-ing
him)

[Bug c++/81606] A small program works as expected with -O0 but fails with -O1 on all tested gcc versions

[jerome.pioux at atos dot net]

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

--- Comment #2 from jerome.pioux at atos dot net ---
Agreed, sorry, we should have been using single quotes. Thank you.

-Original Message-
From: glisse at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Friday, July 28, 2017 1:39 PM
To: Pioux, Jerome
Subject: [Bug c++/81606] A small program works as expected with -O0 but fails
with -O1 on all tested gcc versions

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  --- What do you
expect "A" >= "B" to mean? You are comparing addresses, the result is
arbitrary.

--
You are receiving this mail because:
You reported the bug.

[Bug tree-optimization/81607] New: Conditional operator: "type mismatch in shift expression" error

[babokin at gmail dot com]

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

Bug ID: 81607
   Summary: Conditional operator: "type mismatch in shift
expression" error
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250630, x86_64.

I see a lot of crashes involving conditional operator and struct field access.
I see at least 7 different kind of crashes. They may be related, so I'm filing
only this one for now to avoid spamming the bug tracker. After fixing this one,
I'll proceed with others if they are not fixed.

> cat f.cpp
int a;
struct b {
  long c : 32;
} d;
char f = (903092 ? int(d.c) : 0) << a;

> g++ -c f.cpp
f.cpp: In function ‘void __static_initialization_and_destruction_0(int, int)’:
f.cpp:5:38: error: type mismatch in shift expression
 char f = (903092 ? int(d.c) : 0) << a;
  ^
int
long int
int
_4 = _2 << a.0_3;
f.cpp:5:38: internal compiler error: verify_gimple failed
0xf5e57d verify_gimple_in_seq(gimple*)
../../gcc_svn_intel/gcc/tree-cfg.c:4975
0xd1d2ad gimplify_body(tree_node*, bool)
../../gcc_svn_intel/gcc/gimplify.c:12589
0xd1d47c gimplify_function_tree(tree_node*)
../../gcc_svn_intel/gcc/gimplify.c:12679
0xbb64b7 cgraph_node::analyze()
../../gcc_svn_intel/gcc/cgraphunit.c:668
0xbb8b73 analyze_functions
../../gcc_svn_intel/gcc/cgraphunit.c:1129
0xbb9a12 symbol_table::finalize_compilation_unit()
../../gcc_svn_intel/gcc/cgraphunit.c:2607
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/81606] A small program works as expected with -O0 but fails with -O1 on all tested gcc versions

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  ---
What do you expect "A" >= "B" to mean? You are comparing addresses, the result
is arbitrary.

[Bug c++/81606] New: A small program works as expected with -O0 but fails with -O1 on all tested gcc versions

[jerome.pioux at atos dot net]

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

Bug ID: 81606
   Summary: A small program works as expected with -O0 but fails
with -O1 on all tested gcc versions
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jerome.pioux at atos dot net
  Target Milestone: ---

Created attachment 41859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41859=edit
Two .ii files (compiled with -O0 and -O1)

Intel(R) Xeon(R) CPU E7- 487
Centos 7.3 x86_64
gcc (GCC) 7.1.0

The program originally failed using gcc 4.8.5 20150623 (CentOS 7 default).

I built gcc 7.1.0 from source to verify that the problem still existed using a
later gcc version.

There is a difference though. On 4.8.5, the program only worked using -O0 and
failed with -O1 ,-O2 or -O3.

On 7.1.0, the program only failed with -O1.

Program compilation (no warnings):
g++ gccproblem.cpp -o gccproblem -O[0-3] -save-temps

Note that gcc seems to be trying to use the character "B" in the string
"NC0404B" below when it makes the comparison if ("A" >= "B")

Note also that the problem only occurs when the "B" in NC0404B and the "B" in
the IF statement are the same, AND the "B" has to be the LAST character in the
string "NC0404B".

There is no problem when the "B" is elsewhere in the string, that is, not the
last character.

#include 
#include 
#include 
#include 
int main (int argc, char *argv[]) {
std::string dummy="NC0404B";

if ("A" >= "B") {
  std::cout << "FAILS." << std::endl;
}
else {
  std::cout << "PASSES." << std::endl;
}
return (0);
};

[Bug c/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Eric Gallager  ---
Testcase compiles, runs, and exits with 0 for me on i386-apple-darwin9.8.0.
Can you try again?

$ /usr/local/bin/gcc -o 54006.exe 54006.c
$ ./54006.exe
$ echo $?
0
$

[Bug c/59616] OpenMP standard conflict in parallel default clause

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed that the error still occurs with trunk.

[Bug c/64609] No -Wbool-compare warning on "(a = 0 && 0) <= 4"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
Summary|No -Wbool-compare warning   |No -Wbool-compare warning
   |on "(a = 0 && 0) <= 4" and  |on "(a = 0 && 0) <= 4"
   |"0 > a < 0" |

--- Comment #3 from Eric Gallager  ---
(In reply to Chengnian Sun from comment #2)
> Another test case. 
> 
> 
> $: cat s.c 
> int a;
> void f() { 
>   (0 > a < 0);
> }
> $: 
> $: gcc-trunk -Wbool-compare -Wtype-limits -c s.c
> $:

This one warns for me:
$ /usr/local/bin/gcc -c -Wparentheses -Wbool-compare -Wbool-operation
-Wtautological-compare -Wint-in-bool-context -Wtype-limits 64609.c
64609.c: In function ‘f’:
64609.c:4:9: warning: comparison of constant ‘0’ with boolean expression is
always false [-Wbool-compare]
  (0 > a < 0);
 ^
64609.c:4:5: warning: comparisons like ‘X<=Y<=Z’ do not have their mathematical
meaning [-Wparentheses]
  (0 > a < 0);
   ~~^~~
$

The first one still doesn't warn though. Retitling to just be about the first
one.

[Bug c++/81605] -Wignored-attributes emitted when decltype(function) used in template for function with __nonnull__

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic, documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81565
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  GCC considers some attributes on a function declaration as part of
the function's type while others only as part of the declaration.  As this is
neither intuitive nor undocumented it's quite confusing and a source of bug
reports.  I just recently opened bug 81565 for this general problem but there
have been others prior to it.  At a minimum, the manual should mention for each
function attribute whether or not it's part of the type system.  Such function
attributes should then also be referenced in the Type Attributes section. 
(Though my own preference would be to remove this feature and to treat all
function attributes the same, i.e., as part of the function declaration only.)

[Bug target/81590] AVX512 run-time test failures

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to H.J. Lu from comment #0)
> On Skylake server running Fedora 25/x86-64, r250630 gave:
> 

This is on a 80-core machine with "make check -j80".

> FAIL: libgomp.c/for-3.c execution test
> FAIL: libgomp.c/for-5.c execution test

The above 2 failed with

WARNING: program timed out.

They passed when running them by hand.

> FAIL: libgomp.fortran/target7.f90   -O0  execution test
> FAIL: libgomp.fortran/target7.f90   -O1  execution test
> FAIL: libgomp.fortran/target7.f90   -O2  execution test
> FAIL: libgomp.fortran/target7.f90   -O3 -fomit-frame-pointer -funroll-loops
> -fpeel-loops -ftracer -finline-functions  execution test
> FAIL: libgomp.fortran/target7.f90   -O3 -g  execution test
> FAIL: libgomp.fortran/target7.f90   -Os  execution test
> FAIL: libgomp.fortran/target8.f90   -O0  execution test
> FAIL: libgomp.fortran/target8.f90   -O1  execution test
> FAIL: libgomp.fortran/target8.f90   -O2  execution test
> FAIL: libgomp.fortran/target8.f90   -O3 -fomit-frame-pointer -funroll-loops
> -fpeel-loops -ftracer -finline-functions  execution test
> FAIL: libgomp.fortran/target8.f90   -O3 -g  execution test
> FAIL: libgomp.fortran/target8.f90   -Os  execution test
> 

Both were compiled with -m32 and failed with

libgomp: Thread creation failed: Resource temporarily unavailableThread
creation failed: Resource temporarily unavailableThread creation failed:
Resource temporarily unavailable
Thread creation failed: Resource temporarily unavailable

when running by hand.

[Bug c++/81605] New: -Wignored-attributes emitted when decltype(function) used in template for function with __nonnull__

[bloerwald at googlemail dot com]

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

Bug ID: 81605
   Summary: -Wignored-attributes emitted when decltype(function)
used in template for function with __nonnull__
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bloerwald at googlemail dot com
  Target Milestone: ---

When using the type of a function with attribute __nonnull__ as a template
parameter, -Wignored-attributes is emitted. With other attributes, like
__noreturn__, no warning is given. Emitting the warning seems wrong since
attributes are not part of a typename and thus can't be handled by e.g. c++17's
std::is_invocable.

Tested with 6.1.0 (afaik -Wignored-attributes was introduced in 6) and 7.1.0.
Not tested with trunk/8.

$ cat gcc_ignored_attributes.cpp 
int fun() __attribute__((ATTRIBUTE));

template auto templ = 0;
auto x = templ;

$ gcc/6.1.0/bin/g++ --std=c++14 -c gcc_ignored_attributes.cpp -o/dev/null
-DATTRIBUTE=__nonnull__
gcc_ignored_attributes.cpp:4:10: warning: ignoring attributes on template
argument ‘int()’ [-Wignored-attributes]
 auto x = templ;
  ^~~~
$ gcc/6.1.0/bin/g++ --std=c++14 -c gcc_ignored_attributes.cpp -o/dev/null
-DATTRIBUTE=__noreturn__
$ clang/4.0.1/bin/clang++ --std=c++14 -c gcc_ignored_attributes.cpp
-o/dev/null -DATTRIBUTE=__nonnull__
$ clang/4.0.1/bin/clang++ --std=c++14 -c gcc_ignored_attributes.cpp
-o/dev/null -DATTRIBUTE=__noreturn__
$

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 41858
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41858=edit
gcc8-pr81604.patch

Untested fix.

[Bug c/64825] -Wcast-qual does not warn about struct members which are arrays

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that gcc doesn't warn, although my version of clang is older so it
doesn't warn either. Still, would be nice to have.

[Bug target/81590] AVX512 run-time test failures

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 41857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41857=edit
A patch to properly check AVX512 features

[Bug sanitizer/81604] New: Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

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

Bug ID: 81604
   Summary: Ubsan type reporting can be bogus in some cases
   Product: gcc
   Version: 8.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, marxin at 
gcc dot gnu.org
  Target Milestone: ---

long a[10];

__attribute__((noinline, noclone)) long *
foo (int i)
{
  return [i];
}

__attribute__((noinline, noclone)) long
bar (long x, long y)
{
  return x * y;
}

int
main ()
{
  volatile int i = -1;
  volatile long l = __LONG_MAX__;
  long *volatile p;
  p = foo (i);
  l = bar (l, l);
  return 0;
}

with -fsanitize=undefined prints:
test.c:6:12: runtime error: index -1 out of bounds for type 'long int [10]'
test.c:12:12: runtime error: signed integer overflow: 9223372036854775807 *
9223372036854775807 cannot be represented in type 'long int [10]'

Note the incorrect 'long int [10]' on the second line, the computation is
obviously done in long int type instead.

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-28
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug inline-asm/65640] multiple alternative constraints and earlyclobbers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Mike Herrick from comment #0)
> There seems to be an issue with earlyclobbers and multiple alternative
> constraints.  Take this example:
> 
>   int f(int out, int in) {
> asm("foo %1,%0;" : "=" (out) : "b" (in));// Okay
> asm("foo %1,%0;" : "=" (out) : "b" (in));// Expected error
> asm("foo %1,%0;" : "=" (out) : "a" (in));// Expected error
> asm("foo %1,%0;" : "=," (out) : "b,b" (in));   // Okay
> asm("foo %1,%0;" : "=," (out) : "a,a" (in));   // Unexpected error
> asm("foo %1,%0;" : "=," (out) : "b,b" (in));   // Okay
> asm("foo %1,%0;" : "=," (out) : "a,a" (in));   // Okay
> return out;
>   }
> 
> With 4.9.2, I see three errors:
> 
> $ g++492 -S ex.c
> ex.c: In function 'int f(int, int)':
> ex.c:3:47: error: 'asm' operand has impossible constraints
>  asm("foo %1,%0;" : "=" (out) : "b" (in));// Expected error
>^
> ex.c:4:47: error: 'asm' operand has impossible constraints
>  asm("foo %1,%0;" : "=" (out) : "a" (in));// Expected error
>^
> ex.c:6:52: error: 'asm' operand has impossible constraints
>  asm("foo %1,%0;" : "=," (out) : "a,a" (in));   // Unexpected error
> ^
> 
> The first two are expected, but I'm at a loss to explain the third error. 
> In all four of the multi alternative constrain cases, there is exactly one
> "good" constraint and one "bad" constraint in the pair, yet only one of the
> four cases is diagnosed.
> 
> What is the expected behavior for this case?

Confirmed that I get errors in the same places as you; I'm not sure exactly
what the expected behavior is though. Maybe someone else can answer.

[Bug inline-asm/55681] Qualifiers on asm statements are order-dependent

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug c++/81597] returns link to temporary value

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Since this code is undefined at runtime (not at compile time) so closing this
bug as invalid.

[Bug tree-optimization/81603] New: Various compiler UB on very large constant offsets

[jakub at gcc dot gnu.org]

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

Bug ID: 81603
   Summary: Various compiler UB on very large constant offsets
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

When compiling libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc
there are various UBs in cc1plus:
../../gcc/ipa-polymorphic-call.c:926:59: runtime error: signed integer
overflow: -9223372036854775808 * 8 cannot be represented in type 'long int'
../../gcc/tree-ssa-alias.c:704:30: runtime error: signed integer overflow:
-9223372036854775808 * 8 cannot be represented in type 'long int'
../../gcc/dwarf2out.c:13534:15: runtime error: signed integer overflow:
9223372036854775408 + 400 cannot be represented in type 'long int [4]'
../../gcc/dwarf2out.c:13559:11: runtime error: signed integer overflow:
-9223372036854775808 + -400 cannot be represented in type 'long int [4]'

  csz01 = str01.max_size();
  // NB: As strlen(str_lit01) != csz01, this test is undefined. It
  // should not crash, but what gets constructed is a bit arbitrary.
  try {
std::string str03(str_lit01, csz01 + 1);
VERIFY( true );
  }  
  catch(std::length_error& fail) {
VERIFY( true );
  }
  catch(...) {
VERIFY( false );
  }

csz01 + 1 is 0x8000UL on x86_64, and both ipa-polymorphic-call.c
and tree-ssa-alias.c try to multiply that by BITS_PER_UNIT.

Another similar UB is on:
void
foo (char *p)
{
  p[- __LONG_MAX__ - 1] = 1;
}
at -g -O2 I'm getting
../../gcc/builtins.c:351:54: runtime error: signed integer overflow:
-9223372036854775808 * 8 cannot be represented in type 'long int [3]'

For ipa-polymorphic-call.c I wrote untested:
2017-07-28  Jakub Jelinek  

* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::ipa_polymorphic_call_context): Perform
offset arithmetic in offset_int, bail out if the resulting bit offset
doesn't fit into shwi.

--- gcc/ipa-polymorphic-call.c.jj   2017-06-12 12:41:55.0 +0200
+++ gcc/ipa-polymorphic-call.c  2017-07-28 15:02:43.747354910 +0200
@@ -921,9 +921,13 @@ ipa_polymorphic_call_context::ipa_polymo
 and MEM_REF is meaningless, but we can look futher.  */
  if (TREE_CODE (base) == MEM_REF)
{
+ offset_int o = mem_ref_offset (base) * BITS_PER_UNIT;
+ o += offset;
+ o += offset2;
+ if (!wi::fits_shwi_p (o))
+   break;
  base_pointer = TREE_OPERAND (base, 0);
- offset
-   += offset2 + mem_ref_offset (base).to_short_addr () *
BITS_PER_UNIT;
+ offset = o.to_shwi ();
  outer_type = NULL;
}
  /* We found base object.  In this case the outer_type
@@ -961,10 +965,15 @@ ipa_polymorphic_call_context::ipa_polymo
break;
}
   else if (TREE_CODE (base_pointer) == POINTER_PLUS_EXPR
-  && tree_fits_uhwi_p (TREE_OPERAND (base_pointer, 1)))
+  && TREE_CODE (TREE_OPERAND (base_pointer, 1)) == INTEGER_CST)
{
- offset += tree_to_shwi (TREE_OPERAND (base_pointer, 1))
-   * BITS_PER_UNIT;
+ offset_int o = offset_int::from (TREE_OPERAND (base_pointer, 1),
+  SIGNED);
+ o *= BITS_PER_UNIT;
+ o += offset;
+ if (!wi::fits_shwi_p (o))
+   break;
+ offset = o.to_shwi ();
  base_pointer = TREE_OPERAND (base_pointer, 0);
}
   else

but given that there are tons of other spots, I wonder if using offset_int for
such stuff is the right way to go.

[Bug target/50077] large model (-mcmodel=large) is broken on *86*-apple-darwin*

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
Summary|FAIL:   |large model
   |gcc.target/i386/pr49866.c   |(-mcmodel=large) is broken
   |(test for excess errors) on |on *86*-apple-darwin*
   |x86_64-apple-darwin1*   |

--- Comment #5 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #3)
> > clang seems to support -mcmodel=large - at least at 3.1 - so any necessary
> > ld64/dyld support is available.
> 
> The test compiles (using -c) with
> 
> Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)
> 
> > This is not likely to get fixed in the short term (certainly not in stage 
> > 4) -
> > so we'll have to decide between XFAIL/tolerate the noise in the error logs.
> 
> When XFAILed, this kind of bug disappears from the radar scopes and tends to
> rot forever (see pr10901) until it resurfaces in a nasty way. I'ld prefer to
> change the summary to something such as "large model is broken on
> *86*-apple-darwin*" to point to the real problem.

OK, retitling.

[Bug target/63893] gcc.dg/pr61599-1.c fails on darwin, due to -mcmodel=medium

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin14   |x86_64-apple-darwin
 CC||egallager at gcc dot gnu.org
   Host|x86_64-apple-darwin14   |x86_64-apple-darwin
  Build|x86_64-apple-darwin14   |x86_64-apple-darwin

--- Comment #4 from Eric Gallager  ---
Removing the "14" from host/target/build since I also have this problem on
darwin9, so I'm assuming it affects all darwin versions in general

[Bug inline-asm/55744] Use of ebx as output register in inline asm on x86_64 PIC mcmodel=medium

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Results from testing on i386-apple-darwin9.8.0 with gcc8:

$ /usr/local/bin/gcc -c -fPIC -mcmodel=medium 55744.c
cc1: error: code model ‘medium’ not supported in the 32 bit mode
$ /usr/local/bin/gcc -c -fPIC -mcmodel=medium -m64 55744.c
$ /usr/local/bin/gcc -o 55744.exe -fPIC -mcmodel=medium -m64 -Wall -Wextra
55744.c
Undefined symbols:
  "_GLOBAL_OFFSET_TABLE_", referenced from:
  _main in ccbh4pRB.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
$ /usr/local/bin/gcc -o 55744.exe -fPIC -mcmodel=large -m64 -Wall -Wextra
55744.c
:14:junk `@GOTOFF' after expression
:18:junk `@PLTOFF' after expression
$ /usr/local/bin/gcc -o 55744.exe -fPIC -mcmodel=small -m64 -Wall -Wextra
55744.c
$ ./55744.exe
Result: 42
$ 

Which is probably bug 63893 and bug 50077 in my case. Can you try again with
your own target and see if it still fails in your case?

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[arnd at linaro dot org]

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

--- Comment #4 from Arnd Bergmann  ---
Thanks for the analysis. I have now submitted a local workaround for the
kernel, adding a temporary variable to avoid accessing the bitfield twice, see
https://patchwork.kernel.org/patch/9869037/

[Bug c++/81597] returns link to temporary value

[lisp2d at rambler dot ru]

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

--- Comment #4 from Lisp2D  ---
-Werror=return-local-addr

it is all i want
 thnx

[Bug c/41045] Extended asm with C operands doesn’t work at top level

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jnz at mail dot com

--- Comment #10 from Eric Gallager  ---
*** Bug 54450 has been marked as a duplicate of this bug. ***

[Bug inline-asm/54450] Extended asm in global scope

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=25967
 Resolution|--- |DUPLICATE

--- Comment #6 from Eric Gallager  ---
(In reply to jnz from comment #1)
> I'd be happy to use __attribute__((naked)) but it's not supported on x86 for
> some reason.

That's bug 25967

(In reply to Marek Polacek from comment #2)
> Probably dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045

Agreed, closing as a duplicate of it

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

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2017-07-28
 CC||wilco at gcc dot gnu.org
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #13 from Wilco  ---
(In reply to Icenowy Zheng from comment #12)
> (In reply to Wilco from comment #11)
> > (In reply to Icenowy Zheng from comment #10)
> > > In my environment (glibc 2.25, and both the building scripts of glibc and
> > > gcc have -fomit-frame-pointer automatically enabled), this bug is not 
> > > fully
> > > resolved yet.
> > > 
> > > With GCC upgraded to 6.4.0, GDB debugger started to work correctly. (With
> > > GCC 6.3.0 GDB cannot even work and segfault at unwind code in libgcc).
> > > 
> > > However, if I still build GCC with -fomit-frame-pointer in CFLAGS, the
> > > backtrace() function of glibc cannot work, and segfault at line 240 of
> > > libgcc/unwind-dw2.c .
> > > 
> > > By reading the source code, I think the unwind code is still trying to get
> > > CFA from the register x29, and when debugging I found that the x29 
> > > register
> > > in the unwind context is 0 (because of -fomit-frame-pointer), so line 240 
> > > is
> > > dereferencing a NULL pointer, so it segfaulted.
> > > 
> > > Maybe the behavior that accessing x29 register to get CFA is not correct?
> > 
> > Well if everything built with -fomit-frame-pointer then it is definitely
> > wrong to read x29. Can you give more info similar to comment #3?
> 
> I didn't remember a lot as this issue is already fixed in our build system
> by removing -fomit-frame-pointer.
> 
> But I remember part of the stacktrace:
> 
> _Unwind_GetGR(index=29) at libgcc/unwind-dw2.c:240 <= segfault here
> _Unwind_GetPtr(index=29) at libgcc/unwind-dw2.c:251
> uw_update_context_1() at libgcc/unwind-dw2.c:1410
> _Unwind_Backtrace() at libgcc/unwind.inc (line number forgot)
> backtrace() in libc.so.6

Right, so it's trivial to reproduce since every call to backtrace will crash
immediately if libgcc is built with -fomit-frame-pointer in any GCC version.

The issue is due to the weird way the generic unwind code works - there is no
code to setup the frame pointer. So in order to unwind any function with a
frame pointer, the very first function that is unwound (_Unwind_Backtrace in
this case) must use the frame pointer. That way the frame pointer is restored
and its value can now be read by _Unwind_GetGR without crashing.

A quick workaround is:

#define LIBGCC2_UNWIND_ATTRIBUTE __attribute__((optimize
("no-omit-frame-pointer")))

Oddly enough I don't see any other targets do this, so this problem may be
widespread... Note this workaround wouldn't work if there could be multiple
frame pointers or several registers which may contain a frame pointer.

[Bug inline-asm/52813] %rsp in clobber list is silently ignored

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Eric Gallager  ---
(In reply to Ralph Corderoy from comment #5)
> The examples clearly show the problem and it bites me here.  Please change
> the status to confirmed.

OK.

[Bug inline-asm/37195] different variables get the same overlapping memory address in inline assembly

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||

--- Comment #9 from Eric Gallager  ---
(In reply to Jeroen Demeyer from comment #5)
> Created attachment 16428 [details]
> Unified testcase
> 
> This testcase exhibits the problem on i386, x86_64, powerpc and powerpc64
> using preprocessor macros.

When compiling this testcase on i386-apple-darwin9.8.0 with gcc8, I get:

$ /usr/local/bin/gcc -O1 -c 16428.c
16428.c:28:Unknown pseudo-op: .ifeqs
16428.c:28:Rest of line ignored. 1st junk character valued 34 (").
16428.c:29:Unknown pseudo-op: .error
16428.c:29:Rest of line ignored. 1st junk character valued 34 (").
16428.c:30:FATAL:Encountered a .endif that doesn't follow a .if or .else
$

So I can't confirm, but I'm assuming that's just an issue with my assembler.

...although:
(In reply to Jeroen Demeyer from comment #8)
> On first sight, it looks fixed in gcc 4.6.0 SVN.

If that's true, then I can close this as FIXED.

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The reason this doesn't trigger without -fsanitize= is that without the extra
UBSAN_* internal function calls we manage to find out earlier that this is a
dead code and optimize it away completely (during cddce1).

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The -Warray-bounds warning has false positives, so you can run into them and in
that case using -Werror isn't really a good idea.
The problem is that the same bitfield, tp->chrono_start, is accessed 2
different ways in the IL before vrp1:
  _5 = tp_2(D)->chrono_type;
  if (_5 == 0)
in one spot, and
  _12 = BIT_FIELD_REF <*tp_2(D), 8, 128>;
  _13 = _12 & 3;
  if (_13 != 0)
in another.  The optimizers don't treat those two as the same thing, and we
have
thus _5 used in the first condition, _13 in second one and then again _5.
>From the first condition it determines that _5 must be zero in that branch
(that is the if (type > tp->chrono_type) condition, where you do nothing if
tp->chrono_type is not 0), it doesn't know that also implies that _13 is 0 to
optimize that as dead code, and finally sees array index of [_5 - 1], and when
_5 is known to be 0, that means [-1], which is invalid.  It is invalid, but in
dead code.

[Bug inline-asm/38925] gcc ignores use of %rbp via assembly, generates bad code

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
When I compile the testcase on i386-apple-darwin9.8.0, I get: 

$ /usr/local/bin/gcc -m64 -c 38925.c
38925.c:76:1: warning: always_inline function might not be inlinable
[-Wattributes]
 VMRUN(uint64 vmcb)
 ^
38925.c: In function ‘test_function’:
38925.c:116:1: error: bp cannot be used in asm here
 }
 ^
$

After adding an additional 'inline' to the testcase to silence the -Wattributes
warning, with any optimization level (-O1, -O2, -O3, -Os, -Og, -Ofast) I then
get:

$ /usr/local/bin/gcc -m64 -O2 -c 38925.c
38925.c:93:no such instruction: `vmrun'
$ 

So I can't confirm, but I'm assuming that's because I'm not using the right
kind of computer...

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

[h2+bugs at fsfe dot org]

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

--- Comment #19 from Hannes Hauswedell  ---
One last question: will the fix be backported to GCC7('s libstdc++)?

Thanks!

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
Summary|incorrect Warray-bounds |[7/8 Regression] incorrect
   |warning with -fsanitize |Warray-bounds warning with
   ||-fsanitize
 Ever confirmed|0   |1
  Known to fail||6.3.0, 7.1.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r239421, which is the commit also mentioned in PR80202.

[Bug c++/81597] returns link to temporary value

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
-Werror=return-local-addr
(we cannot reject those programs by default, if the caller ignores what the
function returns, the program may be valid)

[Bug tree-optimization/80202] Spurious warning "array subscript is below array bounds" with if-statement and char to unsigned int conversion

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Fixed on trunk by r239421 and appeared in time of GCC 6 in r230365.

[Bug c++/81597] returns link to temporary value

[lisp2d at rambler dot ru]

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

--- Comment #2 from Lisp2D  ---
Make an error (don't compile) when returns rvalue from these functions.

To forbid or banning.

[Bug c++/81602] New: Unnecessary zero-extension after 16 bit popcnt

[christoph.diegelmann at gmx dot de]

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

Bug ID: 81602
   Summary: Unnecessary zero-extension after 16 bit popcnt
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christoph.diegelmann at gmx dot de
  Target Milestone: ---

GCC misses an optimization on this:

 #include 
 #include "immintrin.h"

 void test(std::uint16_t* mask, std::uint16_t* data) {
 for (int i = 0; i < 1024; ++i) {
 *data = 0;
 unsigned tmp = *mask++;
 unsigned step = _mm_popcnt_u32(tmp);
 data += step;
 }
 }

g++ -O3 -Wall -std=c++14 -march=skylake generates:

 test(unsigned short*, unsigned short*):
 leaq 2048(%rdi), %rdx
 .L2:
 xorl %eax, %eax
 addq $2, %rdi
 movw %ax, (%rsi)
 popcntw -2(%rdi), %ax
 movzwl %ax, %eax
 leaq (%rsi,%rax,2), %rsi
 cmpq %rdx, %rdi
 jne .L2
 ret

The rax register is known to be zero at the time of `popcntw -2(%rdi), %ax`.
Anyway gcc still clears the upper bits using `movzwl %ax, %eax` afterwards.

While clang uses 32 bit popcnt and `movzwl (%rdi,%rax,2), %ecx` it correctly
recognises that there's no need to clear the upper bits.

clang -O3 -Wall -std=c++14 -march=skylake -fno-unroll-loops generates:

 test(unsigned short*, unsigned short*): 
 xorl %eax, %eax
 .LBB0_1: 
 movw $0, (%rsi)
 movzwl (%rdi,%rax,2), %ecx
 popcntl %ecx, %ecx
 leaq (%rsi,%rcx,2), %rsi
 addq $1, %rax
 cmpl $1024, %eax # imm = 0x400
 jne .LBB0_1
 retq

See https://godbolt.org/g/kgQ7VS

[Bug fortran/67679] -Wunitialized reports on compiler generated variables

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Here is another test case with similar behavior:



subroutine s(h, Gmin, r)

   implicit none
   real, intent(in) ::  Gmin(3), h(3)
   integer, intent(inout) :: r

   integer :: x_min(3), x_max(3), k, iStat
   logical, dimension(:), allocatable :: check

   do k = 1,1
  x_min(k) = int(Gmin(k)*h(k))
  x_max(k) = int(Gmin(k)*h(k))
   end do

   allocate(check(x_min(1):x_max(1)),stat=iStat)

   check(:) = .false.

   do k = x_min(1),x_max(1)
r = r + 1
   end do

end


shows things like ...

Warning: ‘check.dim[0].lbound’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
Warning: ‘check.dim[0].ubound’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
Warning: ‘check.offset’ may be used uninitialized in this function
[-Wmaybe-uninitialized]

... with -O1 and higher.

I see it with all versions starting from 4.7, while 4.4 and 4.6 do not seem to
be affected, so I guess this is a regression?

[Bug sanitizer/81601] New: incorrect Warray-bounds warning with -fsanitize

[arnd at linaro dot org]

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

Bug ID: 81601
   Summary: incorrect Warray-bounds warning with -fsanitize
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot 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, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 41856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41856=edit
reduced version of linux/net/ipv4/tcp_output.c

Compiling the Linux kernel with gcc-7.1.1 and ubsan, I get this warning:

net/ipv4/tcp_output.c: In function 'tcp_connect':
net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds
[-Werror=array-bounds]
   tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
^~
net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds
[-Werror=array-bounds]
   tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
   ~^

I have manually reduced the file to the attached version (this can be reduced
further, I decided to leave a little more context for clarity).

The warning is an array dereference after a range check:

if (tp->chrono_type > TCP_CHRONO_UNSPEC)
tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;

so it clearly cannot be below the bounds.

In the original version, this happens specifically when at least one of
-fsanitize=object-size, -fsanitize=alignment, or -fsanitize=null is set in
addition to "-O2 -Wall", but not when all three are disabled. In the reduced
version, I can also reproduce it with "-Os -Wall" (without ubsan).

I also see the problem with gcc-7.0.1 on all architectures I tried (arm, arm64
and x86), but not with gcc-6.3.1.

[Bug hsa/81477] HSA offloading regressions: "function cannot be cloned"

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
I have posted the fix to the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01909.html

[Bug tree-optimization/81600] tree-vect-loop.c:6075:22: runtime error: index -1 out of bounds for type 'tree_node *[3]'

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
I think the following is the correct fix.

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 250659)
+++ gcc/tree-vect-loop.c(working copy)
@@ -6071,8 +6071,10 @@ vectorizable_reduction (gimple *stmt, gi
 {
   /* Only call during the analysis stage, otherwise we'll lose
 STMT_VINFO_TYPE.  */
-  if (!vec_stmt && !vectorizable_condition (stmt, gsi, NULL,
-   ops[reduc_index], 0, NULL))
+  if (!vec_stmt
+ && (reduc_index == -1
+ || !vectorizable_condition (stmt, gsi, NULL,
+ ops[reduc_index], 0, NULL)))
 {
   if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,

[Bug tree-optimization/81600] New: tree-vect-loop.c:6075:22: runtime error: index -1 out of bounds for type 'tree_node *[3]'

[jakub at gcc dot gnu.org]

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

Bug ID: 81600
   Summary: tree-vect-loop.c:6075:22: runtime error: index -1 out
of bounds for type 'tree_node *[3]'
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

There seems to be undefined behavior in tree-vect-loop.c
(vectorizable_reduction) on e.g. gcc.c-torture/execute/pr68250.c testcase at
-O3.
To reproduce, put a breakpoint on vectorizable_condition, run and see reduc_def
is garbage, like:
reduc_def=
The problem is that reduc_index is -1, and ops is array of 3 elements:
6072  /* Only call during the analysis stage, otherwise we'll lose
6073 STMT_VINFO_TYPE.  */
6074  if (!vec_stmt && !vectorizable_condition (stmt, gsi, NULL,
6075ops[reduc_index], 0,
NULL))
6076{
In this exact case vectorizable_condition seems to ignore the reduc_def
argument, but it isn't clear when exactly does it use that.
So not sure if the right fix is
  tree reduc_def = reduc_index == -1 ? NULL_TREE : ops[reduc_index];
and s/ops.reduc_index./reduc_def/ in the call or something else.

[Bug middle-end/50790] ICE in copy_constant on divide by expression that evaluates to zero

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-28
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
The ICE has been fixed between revisions r250529 and r250610.

[Bug sanitizer/81340] ICE in compute_bb_dataflow, at var-tracking.c:6877

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug sanitizer/81340] ICE in compute_bb_dataflow, at var-tracking.c:6877

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Fri Jul 28 11:56:47 2017
New Revision: 250660

URL: https://gcc.gnu.org/viewcvs?rev=250660=gcc=rev
Log:
Set DECL_VALUE_EXPR after a debug stmt is generated (PR sanitizer/81340).

2017-07-28  Martin Liska  

PR sanitizer/81340
* sanopt.c (sanitize_rewrite_addressable_params): Set VALUE_EXPR after
gimple_build_debug_bind.
2017-07-28  Martin Liska  

PR sanitizer/81340
* g++.dg/asan/pr81340.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/asan/pr81340.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sanopt.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/81388] [7/8 Regression] Incorrect code generation with -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Known to fail||7.1.0

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

[Bug middle-end/81502] In some cases the data is moved to memory unnecessarily [partial regression]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.  Thanks for reporting!

[Bug middle-end/81502] In some cases the data is moved to memory unnecessarily [partial regression]

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Fri Jul 28 11:27:45 2017
New Revision: 250659

URL: https://gcc.gnu.org/viewcvs?rev=250659=gcc=rev
Log:
2017-07-28  Richard Biener  

PR tree-optimization/81502
* match.pd: Add pattern combining BIT_INSERT_EXPR with
BIT_FIELD_REF.
* tree-cfg.c (verify_expr): Verify types of BIT_FIELD_REF
size/pos operands.
(verify_gimple_assign_ternary): Likewise for BIT_INSERT_EXPR pos.
* gimple-fold.c (maybe_canonicalize_mem_ref_addr): Use bitsizetype
for BIT_FIELD_REF args.
* fold-const.c (make_bit_field_ref): Likewise.
* tree-vect-stmts.c (vectorizable_simd_clone_call): Likewise.

* gcc.target/i386/pr81502.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81502.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/gimple-fold.c
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-vect-stmts.c

[Bug target/81414] [6/7 Regression] ICE in fma steering on AArch64/cortex-a57

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Jul 28 11:25:08 2017
New Revision: 250658

URL: https://gcc.gnu.org/viewcvs?rev=250658=gcc=rev
Log:
Backport from mainline r250496
2017-07-25  Bin Cheng  

PR target/81414
* config/aarch64/cortex-a57-fma-steering.c (analyze): Skip fmul/fmac
instructions if no du chain is found.

2017-07-25  Kyrylo Tkachov  

PR target/81414
* gcc.target/aarch64/pr81414.C: New.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/aarch64/pr81414.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/aarch64/cortex-a57-fma-steering.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/81599] New: Error in documentation of std::stack

[chtz at informatik dot uni-bremen.de]

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

Bug ID: 81599
   Summary: Error in documentation of std::stack
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chtz at informatik dot uni-bremen.de
  Target Milestone: ---

I just noticed an error in the documentation of std::stack.

It is claimed here: 
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/libstdc++/api/a01646_source.html#l00087

that the underlying container must support 
   "@c back, @c push_back, and @c pop_front,"
however, it must of course provide pop_back (instead of pop_front).
The error seems to have existed for quite a while, e.g., in version 4.6 is
exactly the same paragraph:
https://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/api/a01078_source.html#l00083

[Bug target/81414] [6/7 Regression] ICE in fma steering on AArch64/cortex-a57

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Jul 28 11:13:45 2017
New Revision: 250657

URL: https://gcc.gnu.org/viewcvs?rev=250657=gcc=rev
Log:
Backport from mainline r250496
2017-07-25  Bin Cheng  

PR target/81414
* config/aarch64/cortex-a57-fma-steering.c (analyze): Skip fmul/fmac
instructions if no du chain is found.

* gcc.target/aarch64/pr81414.C: New.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr81414.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/aarch64/cortex-a57-fma-steering.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/81598] -fsanitize=enum does not detect range violation

[tim.ruehsen at gmx dot de]

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

--- Comment #2 from Tim Ruehsen  ---
(In reply to Jakub Jelinek from comment #1)
> This isn't a load, it is a cast, we sanitize just loads from memory.

Hmmm, seems ok if the compiler doesn't warn.
But the sanitizer IMO should trigger.

What if this cast has been done in a function returning flag_t ?
This could even be buggy code in an external library.
Then the sanitizer should definitely trigger.
And it doesn't with this code:

#include 

typedef enum {
FLAG1 = (1 << 0),
FLAG2 = (1 << 1),
} flag_t;

static flag_t setter(int x)
{
return (flag_t) x;
}

int main(void)
{
int x = 5;
flag_t flags = setter(x);

printf("flags = %X\n", flags);

return 0;
}

$ g++-7 -O0 -fsanitize=undefined -fsanitize=enum -fno-sanitize-recover
enum_undef.cc
$ ./a.out
flags = 5

Hopefully, -O0 doesn't optimize into a single cast.

[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jul 28 10:37:51 2017
New Revision: 250656

URL: https://gcc.gnu.org/viewcvs?rev=250656=gcc=rev
Log:
PR sanitizer/80998
* sanopt.c (pass_sanopt::execute): Handle IFN_UBSAN_PTR.
* tree-ssa-alias.c (call_may_clobber_ref_p_1): Likewise.
* flag-types.h (enum sanitize_code): Add SANITIZER_POINTER_OVERFLOW.
Or it into SANITIZER_UNDEFINED.
* ubsan.c: Include gimple-fold.h and varasm.h.
(ubsan_expand_ptr_ifn): New function.
(instrument_pointer_overflow): New function.
(maybe_instrument_pointer_overflow): New function.
(instrument_object_size): Formatting fix.
(pass_ubsan::execute): Call instrument_pointer_overflow
and maybe_instrument_pointer_overflow.
* internal-fn.c (expand_UBSAN_PTR): New function.
* ubsan.h (ubsan_expand_ptr_ifn): Declare.
* sanitizer.def (__ubsan_handle_pointer_overflow,
__ubsan_handle_pointer_overflow_abort): New builtins.
* tree-ssa-tail-merge.c (merge_stmts_p): Handle IFN_UBSAN_PTR.
* internal-fn.def (UBSAN_PTR): New internal function.
* opts.c (sanitizer_opts): Add pointer-overflow.
* lto-streamer-in.c (input_function): Handle IFN_UBSAN_PTR.
* fold-const.c (build_range_check): Compute pointer range check in
integral type if pointer arithmetics would be needed.  Formatting
fixes.
gcc/testsuite/
* c-c++-common/ubsan/ptr-overflow-1.c: New test.
* c-c++-common/ubsan/ptr-overflow-2.c: New test.
libsanitizer/
* ubsan/ubsan_handlers.cc: Cherry-pick upstream r304461.
* ubsan/ubsan_checks.inc: Likewise.
* ubsan/ubsan_handlers.h: Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/ptr-overflow-1.c
trunk/gcc/testsuite/c-c++-common/ubsan/ptr-overflow-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/flag-types.h
trunk/gcc/fold-const.c
trunk/gcc/internal-fn.c
trunk/gcc/internal-fn.def
trunk/gcc/lto-streamer-in.c
trunk/gcc/opts.c
trunk/gcc/sanitizer.def
trunk/gcc/sanopt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-tail-merge.c
trunk/gcc/ubsan.c
trunk/gcc/ubsan.h
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/ubsan/ubsan_checks.inc
trunk/libsanitizer/ubsan/ubsan_handlers.cc
trunk/libsanitizer/ubsan/ubsan_handlers.h

[Bug sanitizer/81460] [8 Regression] ICE in force_constant_size, at gimplify.c:684

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed.

[Bug sanitizer/81460] [8 Regression] ICE in force_constant_size, at gimplify.c:684

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Fri Jul 28 10:36:36 2017
New Revision: 250655

URL: https://gcc.gnu.org/viewcvs?rev=250655=gcc=rev
Log:
Do not handle VLA in sanitization (PR sanitizer/81460).

2017-07-28  Martin Liska  

PR sanitizer/81460
* sanopt.c (sanitize_rewrite_addressable_params): Do not rewrite
parameters that are of a variable-length.
2017-07-28  Martin Liska  

PR sanitizer/81460
* gcc.dg/asan/pr81460.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/asan/pr81460.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sanopt.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/81598] -fsanitize=enum does not detect range violation

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
This isn't a load, it is a cast, we sanitize just loads from memory.

>From the almost non-existent testsuite coverage in LLVM it is hard to find out
what exactly they decided to implement (-fsanitize=enum has a single testcase
with a single memory load there, -fsanitize=bool 2 testcases with a single
memory load each).

[Bug libgomp/81591] segmentation fault when using priorities of nested tasks

[sistek at seznam dot cz]

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

--- Comment #2 from Jakub Sistek  ---
With the _LIBGOMP_CHECKING_ enabled, I am getting

libgomp: priority_tree_next_task: t1 != t2

Best wishes,

Jakub Sistek


(In reply to Richard Biener from comment #1)
> There's
> 
> static void inline
> priority_queue_downgrade_task (enum priority_queue_type type,
>struct priority_queue *head,
>struct gomp_task *task)
> {
> #if _LIBGOMP_CHECKING_
>   if (!priority_queue_task_in_queue_p (type, head, task))
> gomp_fatal ("Attempt to downgrade missing task %p", task);
> #endif
>   if (priority_queue_multi_p (head))
> {
>   struct priority_list *list
> = priority_queue_lookup_priority (head, task->priority);
>   priority_list_downgrade_task (type, list, task);
> 
> so maybe you can build libgomp with _LIBGOMP_CHECKING_ to help track this
> down?
> (just change libgomp/libgomp.h)

[Bug sanitizer/81598] New: -fsanitize=enum does not detect range violation

[tim.ruehsen at gmx dot de]

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

Bug ID: 81598
   Summary: -fsanitize=enum does not detect range violation
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
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, marxin at 
gcc dot gnu.org
  Target Milestone: ---

g++'s (nor gcc's) -fsanitize=enum doesn't detect enum range violation.
The documentation says that it does.


Having this little C/C++ code (enum_undef.cc):
#include 

typedef enum {
FLAG1 = (1 << 0),
FLAG2 = (1 << 1),
} flag_t;

int main(void)
{
int x = 5;
flag_t flags = (flag_t) x;

printf("flags = %X\n", flags);

return 0;
}


$ g++-7 -fsanitize=undefined -fsanitize=enum enum_undef.cc
$ $ ./a.out 
flags = 5


In comparison, clang detects this kind of violation:
$ clang++-5.0 -fsanitize=undefined -fsanitize=enum enum_undef.cc
$ ./a.out 
enum_undef.cc:13:25: runtime error: load of value 5, which is not a valid value
for type 'flag_t'
flags = 5


Adding -fno-sanitize-recover doesn't make a difference for gcc/g++.

[Bug c++/81597] returns link to temporary value

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Sorry, what change are you asking for?

Compiling with current gcc, we get plenty of warnings, and at runtime:

int &&
zsh: segmentation fault  ./a.out

[Bug rtl-optimization/81595] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug libgomp/81591] segmentation fault when using priorities of nested tasks

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
There's

static void inline
priority_queue_downgrade_task (enum priority_queue_type type,
   struct priority_queue *head,
   struct gomp_task *task)
{
#if _LIBGOMP_CHECKING_
  if (!priority_queue_task_in_queue_p (type, head, task))
gomp_fatal ("Attempt to downgrade missing task %p", task);
#endif
  if (priority_queue_multi_p (head))
{
  struct priority_list *list
= priority_queue_lookup_priority (head, task->priority);
  priority_list_downgrade_task (type, list, task);

so maybe you can build libgomp with _LIBGOMP_CHECKING_ to help track this down?
(just change libgomp/libgomp.h)

[Bug target/81590] AVX512 run-time test failures

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So partly a testsuite issue but the libgomp cases may be wrong-code?

[Bug tree-optimization/81588] [7/8 Regression] Wrong code at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/81597] New: returns link to temporary value

[lisp2d at rambler dot ru]

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

Bug ID: 81597
   Summary: returns link to temporary value
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lisp2d at rambler dot ru
  Target Milestone: ---

Functions returning C && , C const && , C const & from temporary object will
ALWAYS with wrong result.
Warning is good but ...
To do : prevent return rvalue from those functions.

example :

//> g++ -std=c++11 returntemp.cpp -o returntemp
#include  

int && f  ( ) {
  return  1 ; }

int && g  ( ) {
  return  2 ; }

int const &&  ft  ( ) {
  return  7 ; }

int const &&  gt  ( ) {
  return  8 ; }  

int const & fc  ( ) {
  return  5 ; }

int const & gc  ( ) {
  return  6 ; }

int fok ( ) {
  return  3 ; }

int gok ( ) {
  return  4 ; }  

int main  ( int , char  * * ) {
  std ::  cout  <<  "int &&"  <<  std ::  endl  ;
  { int &&  x ( f ( ) ) ;
std ::  cout  <<  "x="  <<  x <<  std ::  endl  ;
int &&  y ( g ( ) ) ;
std ::  cout  <<  "y="  <<  y <<  std ::  endl  ;
std ::  cout  <<  "x="  <<  x <<  std ::  endl  ; }
  std ::  cout  <<  "---"  <<  std ::  endl  ;
  std ::  cout  <<  "int const &&"  <<  std ::  endl  ;
  { int const &&  x ( ft  ( ) ) ;
std ::  cout  <<  "x="  <<  x <<  std ::  endl  ;
int const &&  y ( gt  ( ) ) ;
std ::  cout  <<  "y="  <<  y <<  std ::  endl  ;
std ::  cout  <<  "x="  <<  x <<  std ::  endl  ; }
  std ::  cout  <<  "---"  <<  std ::  endl  ;
  std ::  cout  <<  "int const &"  <<  std ::  endl  ;
  { int const & x ( fc  ( ) ) ;
std ::  cout  <<  "x="  <<  x <<  std ::  endl  ;
int const & y ( gc  ( ) ) ;
std ::  cout  <<  "y="  <<  y <<  std ::  endl  ;
std ::  cout  <<  "x="  <<  x <<  std ::  endl  ; }
  std ::  cout  <<  "---"  <<  std ::  endl  ;
  std ::  cout  <<  "int"  <<  std ::  endl  ;
  { int &&  x ( fok ( ) ) ;
std ::  cout  <<  "x="  <<  x <<  std ::  endl  ;
int &&  y ( gok ( ) ) ;
std ::  cout  <<  "y="  <<  y <<  std ::  endl  ;
std ::  cout  <<  "x="  <<  x <<  std ::  endl  ; } }

result :

int &&
x=1
y=2
x=32621
---
int const &&
x=7
y=8
x=32621
---
int const &
x=5
y=6
x=32621
---
int
x=3
y=4
x=3

[Bug middle-end/81596] backwards threader misses simple copy within the same BB

[aldyh at gcc dot gnu.org]

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

--- Comment #1 from Aldy Hernandez  ---
Well, it looks like we're purposely not handling the aforementioned case in the
rest of the threader.  So perhaps this is more of a feature request.

Jeff, is this worth looking into, or should we close this?

  /* We can get a length of 0 here when the statement that
 makes a conditional generate a compile-time constant
 result is in the same block as the conditional.

 That's not really a jump threading opportunity, but instead is
 simple cprop & simplification.  We could handle it here if we
 wanted by wiring up all the incoming edges.  If we run this
 early in IPA, that might be worth doing.   For now we just
 reject that case.  */
  if (path_length == 0)
  return NULL;

[Bug middle-end/81596] New: backwards threader misses simple copy within the same BB

[aldyh at gcc dot gnu.org]

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

Bug ID: 81596
   Summary: backwards threader misses simple copy within the same
BB
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldyh at gcc dot gnu.org
  Target Milestone: ---

For the following simple testcase, the SSA backwards threader misses that xcopy
is a copy of a constant, because the definitions for both xcopy and x all occur
in the same BB, and the threader incorrectly thinks it will infinitely recurse.

void com (void);

void
foo()
{
  int x = 25;
  int xcopy = x;
  if (xcopy == 25)
com();
}

./cc1 test.c -fdump-tree-all-details-alias -quiet -I/tmp -O2 -fno-tree-vrp
-fno-tree-ccp -fno-early-inlining -fno-forward-propagate -fno-tree-forwprop

As can be seen in the early threader dump (*.ethread), the compare is still
there, even though we can easily see it's a constant.  This happens because
fsm_find_control_statement_thread_paths() will mark the BB containing xcopy as
seen, and then recurse into
handle_assignment/fsm_find_control_statement_thread_paths again to find the
definition for xcopy.  Since the definition of xcopy also occurs in the same
basic block, and we've marked the BB as seen, we bail with no further
processing:

  /* Avoid infinite recursion.  */
  if (visited_bbs->add (var_bb))
return;

This is obviously a highly contrived test whose options disable a lot of the
optimizations that would've caused the problem to go away.  As such, feel free
to mark as WONTFIX if this is something that will never happen in real life.

[Bug middle-end/50168] __builtin_ctz() and intrinsics __bsr(), __bsf() generate suboptimal code on x86_64

[lh_mouse at 126 dot com]

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

Liu Hao  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #11 from Liu Hao  ---
I think it is okay to zero-extend the result (which is a no-op, because on x64,
writing to the lower 32 bits of a GPR zeroes its upper 32 bits implicitly,
except the `NOP` instruction which is actually encoded as `XCHG EAX, EAX`),
because sign-extending an _undefined_ result doesn't produce a defined result
after all.

Clang generates the optimal code, as follows:

source:
```c
unsigned long long my_ctz(unsigned n){
return (unsigned)__builtin_ctz(n);
}
```

clang 4.0.0 with `-O3`:
```
my_ctz(unsigned int):
bsfl%edi, %eax
retq
```

gcc 7.1 with `-O3`:
```
my_ctz(unsigned int):
xorl%eax, %eax
rep bsfl%edi, %eax
cltq   # This conversion from `int` to `unsigned long long` is
redundent.
ret
```

[Bug rtl-optimization/81595] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-28
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r250390.

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work|7.1.0   |7.0

--- Comment #33 from Martin Liška  ---
(In reply to Matt Godbolt from comment #32)
> Thanks! One thing, I probably misunderstand this, but you've put 7.1 in
> "known to work" above: is this on purpose? 7.1 is the version the issue
> comes up in, I assume it'll be fixed in an upcoming 7.2 release?

Yep, it's a typo. I'm going to change it.

[Bug tree-optimization/81555] [5/6/7/8 Regression] Wrong code at -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug tree-optimization/81556] [7/8 Regression] Wrong code at -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/81578] [8 Regression] ICE in omp_reduction_init_op

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/81578] [8 Regression] ICE in omp_reduction_init_op

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jul 28 07:11:51 2017
New Revision: 250651

URL: https://gcc.gnu.org/viewcvs?rev=250651=gcc=rev
Log:
PR tree-optimization/81578
* tree-parloops.c (build_new_reduction): Bail out if
reduction_code isn't one of the standard OpenMP reductions.
Move the details printing after that decision.

* gcc.dg/pr81578.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr81578.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug tree-optimization/81573] [8 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Fri Jul 28 07:08:38 2017
New Revision: 250650

URL: https://gcc.gnu.org/viewcvs?rev=250650=gcc=rev
Log:
2017-07-28  Richard Biener  

PR tree-optimization/81573
* gcc.dg/torture/pr81573.c: Explicitely use signed char.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr81573.c