[Bug middle-end/68339] g++.dg/vect/simd-clone-2.cc ICEs with aggressive GC settings and OpenMP

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed so closing as such.

--- Comment #7 from Andrew Pinski  ---
Fixed so closing as such.

[Bug middle-end/68339] g++.dg/vect/simd-clone-2.cc ICEs with aggressive GC settings and OpenMP

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed so closing as such.

--- Comment #7 from Andrew Pinski  ---
Fixed so closing as such.

[Bug lto/61291] libixion-0.5.0 unable to find boost thread library as lto1 crashes with segfault

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-04
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Does this happen with a newer GCC?
Does this happen when you link like the following:
x86_64-pc-linux-gnu-g++ -o boost_gcc_lto_segfault.o -r -flto=5
-fuse-linker-plugin boost_gcc_lto_segfault.o 

If so please supply the preprocessed source for boost_gcc_lto_segfault.cpp (use
-save-temps and look for the .ii file).

[Bug target/67725] all gcc versions has hardcoded LD path with bootstrap on illumos platform

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
illumos is not solaris2* so it should not use that triplet.

[Bug tree-optimization/68008] Pessimization of simple non-tail-recursive functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug target/68400] ICE in change_address_1, at emit-rtl.c:2125

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Fixed.

[Bug middle-end/68436] [5 Regression] wrong code on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Invalid as mentioned in comment #1 so closing as such.

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
DEF_LIB_BUILTIN_CHKP   (BUILT_IN_MEMMOVE, "memmove",
BT_FN_PTR_PTR_CONST_PTR_SIZE, ATTR_RET1_NOTHROW_NONNULL_LEAF)


memmove is marked as nothrow.  So the question is that correct if so then there
is no bug here; just misusing non-call exceptions :).

[Bug libstdc++/77469] std::regex x("[b\\-a]") throws with message "Invalid range in bracket expression."

[alban...@baker-research.com]

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

--- Comment #3 from alban...@baker-research.com ---
Created attachment 39545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39545=edit
Preprocessed file generated by -save-temps

[Bug tree-optimization/64700] Sink common code through PHI

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2015-01-21 00:00:00 |2016-9-3

--- Comment #3 from Andrew Pinski  ---
here is a much simpler example:
float f(int a, float b, float c, float d)
{
  if (a)
return c + d;
  return b + d;
}

float f1(int a, float b, float c, float d)
{
  float e;
  if (a)
e = c;
  else
e = b;
  return e + d;
}

For aarch64 we get:
f:
cbnzw0, .L5
fadds0, s2, s0
ret
.p2align 3
.L5:
fadds0, s1, s2
ret
...
f1:
cmp w0, 0
fcsel   s0, s1, s0, ne
fadds0, s0, s2
ret

These two functions should produce the same code.

[Bug libstdc++/77469] std::regex x("[b\\-a]") throws with message "Invalid range in bracket expression."

[alban...@baker-research.com]

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

--- Comment #2 from alban...@baker-research.com ---
Created attachment 39544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39544=edit
config.log from building gcc 6.2.0

[Bug libstdc++/77469] std::regex x("[b\\-a]") throws with message "Invalid range in bracket expression."

[alban...@baker-research.com]

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

--- Comment #1 from alban...@baker-research.com ---
Created attachment 39543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39543=edit
Test program with the bug

Build the program:

  g++ testRegex.cc -o testRegex -std=c++11

Run:

  ./testRegex

Output:

  Trying:  [b\-a]
  Exception:  Invalid range in bracket expression.

[Bug libstdc++/77469] New: std::regex x("[b\\-a]") throws with message "Invalid range in bracket expression."

[alban...@baker-research.com]

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

Bug ID: 77469
   Summary: std::regex x("[b\\-a]") throws with message "Invalid
range in bracket expression."
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alban...@baker-research.com
  Target Milestone: ---

Hello,

The std::regex constructor throws when passed "[b\\-a]".  The message is
"Invalid range in bracket expression.".

I understand that this is a valid regular expression that specifies a character
class consisting of a literal "b", a literal "-", and a literal "a".

g++ version:  6.2.0.

System:  Ubuntu 12.04.2 LTS.

Output of 'uname -a':  Linux zeus 3.2.0-68-generic #102-Ubuntu SMP Tue Aug 12
22:02:15 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

gcc configuration options:  ./configure --disable-multilib

Build command line:  g++ testRegex.cc -o testRegex -std=c++11 -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
-fsanitize=undefined

There are no compiler messages.

This behaviour does not occur with gcc Ubuntu 4.9.2-0ubuntu1~14.04.

This behaviour also occurs with MinGW-W64 5.3.0 and 6.1.0.

Thank you,
Alban

[Bug bootstrap/61326] bootstrap failure of gcc-4.8.3 on ia64-hpux

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Does this work with a newer version of GCC?

[Bug target/60301] cross compiler for android: multiple definition of TARGET_POSIX_IO

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-04
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Does this work with a newer version of GCC?

[Bug c/77464] gcc -no-pie breaks -shared

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---

-no-pie
Don't produce a position independent executable.

Maybe the wording is a bit weird but -no-pie says produce an executable which
is not position independent executable.

[Bug c/77464] gcc -no-pie breaks -shared

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
Basically -no-pie says you are now doing an executable overriding the previous
-shared.  This is not a bug, you want -no-pie -shared.
So if you want to disable pie for some building just set CC (and CXX and LD) to
be "gcc -no-pie" and that will work the way you think it will work.  It won't
override if the application understands it wants pie but it also allows shared
libraries to work correctly.

[Bug c/77464] gcc -no-pie breaks -shared

[balint at balintreczey dot hu]

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

--- Comment #7 from Balint Reczey  ---
(In reply to Andrew Pinski from comment #1)
> You need -fPIC to create shared libraries.

I know that the relevant options are -fPIC and -fno-PIC. I have opened the bug
to handle -shared -no-pie and -no-pie -shared consistently and equivalently to
-shared only.

[Bug c/77464] gcc -no-pie breaks -shared

[balint at balintreczey dot hu]

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

--- Comment #6 from Balint Reczey  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Manuel López-Ibáñez from comment #3)
> > Or at least give a clearer error that mentions -fPIC ...
> 
> Actually this is not a driver issue just a binutils issue if that. Why add
> no-pie anyways to the ldflags.

I would like to enable --enable-default-pie in gcc but I would like to default
to not using PIE in the top-level Makefile/configure of some projects.
If "gcc -shared -no-pie foo.c" does not have the same result as "gcc -shared
foo.c" this becomes practically impossible and one need to disable PIE for each
binary one-by-one patching the build system.

Also please note that reversing the parameters works and generates a shared
library as expected:
# gcc -no-pie -shared foo.c
# file a.out 
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, BuildID[sha1]=6512dec4e91253fccda6977a39099c0d4d304629, not stripped

One of those must be a valid bug. For practical reasons please consider the
first reported issue as valid.

From gcc's man page:

-no-pie
Don't produce a position independent executable.

IMO -shared does not produce an executable, thus -no-pie should be silently
handled as a noop without an error.

[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 CC||tulipawn at gmail dot com

--- Comment #2 from PeteVine  ---
Even though I've tested this on a Cortex-A5, the 18% difference does reproduce
on gcc 6.1.1 (2694 vs 3304 ms):

First, the slower profile for A9 codegen:

CPU: ARM Cortex-A5, speed 1.728e+06 MHz (estimated)
Counted CPU_CYCLES events (CPU cycle) with a unit mask of 0x00 (No unit mask)
count 90
samples  %linenr info image name   symbol
name

1446065.7422  c-ray-mt.c:377  c-ray-mt shade
3901 17.7358  c-ray-mt.c:336  c-ray-mt trace
3181 14.4624  c-ray-mt.c:308  c-ray-mt
render_scanline
186   0.8456  e_pow.c:70  libm-2.19.so
__pow_finite
680.3092  e_exp.c:240 libm-2.19.so __exp1
550.2501  (no location information)   no-vmlinux  
/no-vmlinux
400.1819  c-ray-mt.c:454  c-ray-mt
get_primary_ray
380.1728  c-ray-mt.c:497  c-ray-mt
get_sample_pos
170.0773  fraiseexcpt.c:27libm-2.19.so
feraiseexcept
130.0591  e_pow.c:430 libm-2.19.so checkint
6 0.0273  fesetround.c:31 libm-2.19.so
fesetround
5 0.0227  fputc.c:37  libc-2.19.so fputc
5 0.0227  feupdateenv.c:27libm-2.19.so
feupdateenv@@GLIBC_2.4
4 0.0182  feholdexcpt.c:32libm-2.19.so
feholdexcept
4 0.0182  fesetenv.c:31   libm-2.19.so
fesetenv@@GLIBC_2.4
3 0.0136  mpa.c:767   libm-2.19.so __sqr
2 0.0091  strtod_l.c:483  libc-2.19.so
strtod_l_internal
1 0.0045  c-ray-mt.c:170  c-ray-mt main
1 0.0045  dl-tls.c:770ld-2.19.so  
__tls_get_addr
1 0.0045  dl-reloc.c:154  ld-2.19.so  
_dl_relocate_object
1 0.0045  (no location information)   libc-2.19.so
.udivsi3_skip_div0_test
1 0.0045  malloc.c:3302   libc-2.19.so
_int_malloc
1 0.0045  random_r.c:366  libc-2.19.so random_r
1 0.0045  strtod_l.c:201  libc-2.19.so
round_and_return

compared to the default codegen:

samples  %linenr info image name   symbol
name
1165764.6211  c-ray-mt.c:377  c-ray-mt shade
3396 18.8259  c-ray-mt.c:336  c-ray-mt trace
2586 14.3356  c-ray-mt.c:308  c-ray-mt
render_scanline
172   0.9535  e_pow.c:70  libm-2.19.so
__pow_finite
490.2716  (no location information)   no-vmlinux  
/no-vmlinux
470.2605  e_exp.c:240 libm-2.19.so __exp1
410.2273  c-ray-mt.c:454  c-ray-mt
get_primary_ray
390.2162  c-ray-mt.c:497  c-ray-mt
get_sample_pos
160.0887  e_pow.c:430 libm-2.19.so checkint
120.0665  fraiseexcpt.c:27libm-2.19.so
feraiseexcept
7 0.0388  fputc.c:37  libc-2.19.so fputc
2 0.0111  c-ray-mt.c:170  c-ray-mt main
2 0.0111  strtod_l.c:483  libc-2.19.so
strtod_l_internal
2 0.0111  mpa.c:767   libm-2.19.so __sqr
2 0.0111  feholdexcpt.c:32libm-2.19.so
feholdexcept
2 0.0111  fesetround.c:31 libm-2.19.so
fesetround
1 0.0055  cxa_thread_atexit_impl.c:83 libc-2.19.so
__call_tls_dtors
1 0.0055  memchr.S:58 libc-2.19.so memchr
1 0.0055  random_r.c:366  libc-2.19.so random_r
1 0.0055  strtok.c:38 libc-2.19.so strtok
1 0.0055  mpa.c:614   libm-2.19.so __mul
1 0.0055  fesetenv.c:31   libm-2.19.so
fesetenv@@GLIBC_2.4
1 0.0055  feupdateenv.c:27libm-2.19.so
feupdateenv@@GLIBC_2.4

[Bug c/67793] Missing warning for C99 static array dimension mismatch

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Depends on||50584

--- Comment #3 from Martin Sebor  ---
(In reply to Markus Trippelsdorf from comment #1)
> In C99 you can add "static" to the array function argument:
> 
> extern int func(char x[static 32]);
> 
> But unfortunately gcc doesn't warn for this case yet.

Bug 50584 that tracks this feature request.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
[Bug 50584] No warning for passing small array to C99 static array declarator

[Bug c/77468] New: C-ray regression on Aarch64

[tulipawn at gmail dot com]

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

Bug ID: 77468
   Summary: C-ray regression on Aarch64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Compared to gcc 5.3, 7.0 produces slower code:

http://openbenchmarking.org/result/1609039-HA-CRAYREGRE68

I'm going to do some profiling tomorrow.

[Bug tree-optimization/41244] "[i] - data" isn't converted to "i"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2009-09-03 14:12:37 |2016-9-3

--- Comment #3 from Andrew Pinski  ---
On the trunk (on aarch64) we get:
  long int _4;
  long int _5;
  int _7;
  sizetype _10;

  :
  _10 = i_6(D) w* 4;
  _4 = (long int) _10;
  _5 = _4 /[ex] 4;
  _7 = (int) _5;


Which is better.

[Bug tree-optimization/33259] limited range of remainder operation can prove loop runs at most once

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.4

--- Comment #5 from Andrew Pinski  ---
Fixed in GCC 5.4 at least.

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[petschy at gmail dot com]

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

--- Comment #5 from petschy at gmail dot com ---
Sorry. Should I open dedicated bugs for them, or can you work from this single
one? Though the example code would be the same. Probably I would have picked a
more descriptive title mentioning the DSE issue, the bogus error message
formatting and the segfault.

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
You have like three different bugs in listed in here so it was hard to
understand which one was which :)

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
.

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[petschy at gmail dot com]

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

--- Comment #2 from petschy at gmail dot com ---
#22141 does not mention a DSE issue, nor a segfault of the compiler, so hardly
an exact duplicate.

[Bug c/68611] Recommendation for 'cleanup' variable attribute

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Note int** is not implicit casted to int const * const in C.  There is another
bug report about that :)

[Bug libstdc++/77459] [6/7 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.3

[Bug target/77441] Cygwin64: g++ linker: infinite loop when linking a shared library from objects compiled with std=c++14

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Andrew Pinski  ---
Please report this to binutils: http://sourceware.org/bugzilla since that is
where is the linker is from.

[Bug rtl-optimization/60307] define_cond_exec with cc0 comparison generates wrong code, missing insn that sets cc0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
>It's new processor architecture. It doesn't present in GCC sources.


No targets should not be a cc0 target.  cc0 targets cause more issues than what
you really want to deal with.  There are very few cc0 targets left in GCC
already too.

[Bug other/68610] configure failure in libssp

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-03
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
What config options are you using to config gcc?  What target is this located
on?  Does this work with a newer version of GCC?

[Bug target/68690] PowerPC64: TOC save in PHP core loop results in load hit store

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|6.3 |---
   Severity|normal  |enhancement

[Bug bootstrap/68663] Build failure on AIX 7.1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-03
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Does this work with a newer GCC?

[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Confirmed.  I had reported it too:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00552.html

[Bug target/60443] Target specific options that change the ABI should be marked

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Is this still true?

[Bug c++/77467] Segmentation fault with switch statement in constexpr function

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-03
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 /tmp % cat constexpr.ii
constexpr int a() {
  switch (0) {
  case 0:
int b(1);
return b;
  }
}
static_assert(a(), "");

markus@x4 /tmp % /var/tmp/gcc_test/usr/local/bin/g++ -std=c++14 -c constexpr.ii
constexpr.ii:8:16:   in constexpr expansion of ‘a()’
constexpr.ii:8:23: internal compiler error: tree check: expected
statement_list, have bind_expr in tsi_start, at tree-iterator.h:42
 static_assert(a(), "");
   ^
0x100e0bc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9742
0x5b9f63 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3026
0x5b9f63 tsi_start
../../gcc/gcc/tree-iterator.h:42
0x87e110 tsi_start
../../gcc/gcc/cp/constexpr.c:3457
0x87e110 cxx_eval_statement_list
../../gcc/gcc/cp/constexpr.c:3486
0x8791bb cxx_eval_switch_expr
../../gcc/gcc/cp/constexpr.c:3576
0x8791bb cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4298
0x87891d cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4222
0x87891d cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4222
0x876de4 cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1597
0x878c65 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3766
0x87e25b cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4389
0x8811f4 maybe_constant_value_1
../../gcc/gcc/cp/constexpr.c:4584
0x8811f4 maybe_constant_value(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:4608
0x85caf1 cp_fully_fold(tree_node*)
../../gcc/gcc/cp/cp-gimplify.c:1971
0x7a4983 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc/gcc/cp/typeck.c:5196
0x7b1fff ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/gcc/cp/cvt.c:800
0x7eb25b finish_static_assert(tree_node*, tree_node*, unsigned int, bool)
../../gcc/gcc/cp/semantics.c:8767
0x76a560 cp_parser_static_assert
../../gcc/gcc/cp/parser.c:13182
0x77f129 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12359

[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed a while back so closing.

[Bug lto/68791] Segfault during link/compilation after update.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-03
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Still need a testcase.

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||petschy at gmail dot com

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

[Bug c++/77467] New: Segmentation fault with switch statement in constexpr function

[moritz at klammler dot eu]

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

Bug ID: 77467
   Summary: Segmentation fault with switch statement in constexpr
function
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moritz at klammler dot eu
  Target Milestone: ---

Compiling the following file causes GCC to segfault.  (I have version 6.1.1 but
according to Wandbox HEAD is also affected.)

# 1 "raise.cxx"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "raise.cxx"

constexpr int
raise(const int x, const unsigned n) noexcept
{
  switch (n)
{
case 0:
  return 1;
case 1:
  return x;
default:
  const auto m = (n >> 1);
  const auto y = raise(x, m);
  return ((m << 1) == n) ? y * y : x * y * y;
}
}

static_assert(raise(3, 2) == 9, "");
static_assert(raise(2, 3) == 8, "");

As far as I can tell, the program is conforming C++14.  Clang compiles it with
no errors.

Here is the detailed output.

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.1.1 20160802 (GCC) 
COLLECT_GCC_OPTIONS='-std=c++14' '-c' '-v' '-save-temps' '-Wall' '-Wextra'
'-Werror' '-Wpedantic' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
raise.cxx -mtune=generic -march=x86-64 -std=c++14 -Wall -Wextra -Werror
-Wpedantic -fpch-preprocess -o raise.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1

/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/x86_64-pc-linux-gnu

/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++14' '-c' '-v' '-save-temps' '-Wall' '-Wextra'
'-Werror' '-Wpedantic' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/cc1plus -fpreprocessed raise.ii
-quiet -dumpbase raise.cxx -mtune=generic -march=x86-64 -auxbase raise -Wall
-Wextra -Werror -Wpedantic -std=c++14 -version -o raise.s
GNU C++14 (GCC) version 6.1.1 20160802 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.1 20160802, GMP version 6.1.1, MPFR
version 3.1.4-p1, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 6.1.1 20160802 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.1 20160802, GMP version 6.1.1, MPFR
version 3.1.4-p1, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a737bda7bba379565b9dc4d86a8d469f
raise.cxx:18:20:   in constexpr expansion of ‘raise(3, 2u)’
raise.cxx:18:30: internal compiler error: Segmentation fault
 static_assert(raise(3, 2) == 9, "");
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I wasn't able to find this problem already reported but then again, I didn't
really know what to search for.  Thanks for looking into it.

[Bug rtl-optimization/71956] [7 Regression] 176.gcc fails on 32 bits when compiled with -march=core-avx2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed so closing.

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00201.html

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

[Bug middle-end/77457] Print intended value of constants in assembly output

[b7.10110111 at gmail dot com]

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

--- Comment #5 from Ruslan  ---
(In reply to Andrew Pinski from comment #2)
> Note also should be shown in C99 hex floats because that is 100% exactly
> representable of the number in binary :).

Not sure if exactness is worth it. It'll make it harder to see what the decimal
value is (and decimal is the most commonly used radix by humans), while decimal
form, if printed with `max_digits10` digits, is enough to reproduce the
hex/binary form when needed.

[Bug middle-end/77457] Print intended value of constants in assembly output

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #4 from Andrew Pinski  ---
This is an easy hack.
In assemble_real (in varasm.c), after the loop that calls assemble_integer,
print out the value of d (REAL_VALUE_TYPE).
Note GCC is smart and does not use the host floating point (I don't know if
clang/llvm does that or not).

Something like this to do the printing (comes from tree-pretty-print.c):
if (REAL_VALUE_ISINF (d))
  pp_string (pp, REAL_VALUE_NEGATIVE (d) ? " -Inf" : " Inf");
else if (REAL_VALUE_ISNAN (d))
  pp_string (pp, " Nan");
else
  {
char string[100];
real_to_decimal (string, , sizeof (string), 0, 1);
pp_string (pp, string);
  }

[Bug middle-end/77457] Print intended value of constants in assembly output

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
.

[Bug middle-end/77457] Print intended value of constants in assembly output

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #2 from Andrew Pinski  ---
Confirmed, this most likely should only be enabled for -dA:
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Developer-Options.html#Developer-Options

Note also should be shown in C99 hex floats because that is 100% exactly
representable of the number in binary :).

[Bug c/77463] internal compiler error: in output_move_qimode, at config/m68k/m68k.c:3160

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #3 from Andrew Pinski  ---
Fixed so closing.

[Bug c++/77465] [DR909] rejected C-style cast involving casting away constness from result of conversion operator

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c++/77462] Error message prints source from wrong file after #line

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
Hmm, I think this is expected.  Take a good example of why #line are used in
the first place: generated files.

IF you are playing preprocessor tricks like this, you get what you deserve in
the error message.  

In fact I would say clang got it all wrong.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #21 from Jeff Hammond  ---
Thanks.  This is great.  I built GCC master last night and can now compile both
the trivial test program and a more interesting one that encapsulates what I
actually need to work to make progress on OpenMP 5 and other activities.

/* trivial */

#include 

int main(void)
{
return 0;
}

/* nontrivial */

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 201112L) &&
!defined(__STDC_NO_ATOMICS__)

#include 
#include 
#include 

#include 

#ifdef _OPENMP
# include 
#else
# error No OpenMP support!
#endif

#ifdef SEQUENTIAL_CONSISTENCY
int load_model  = memory_order_seq_cst;
int store_model = memory_order_seq_cst;
#else
int load_model  = memory_order_acquire;
int store_model = memory_order_release;
#endif

int main(int argc, char * argv[])
{
int nt = omp_get_max_threads();
#if 1
if (nt != 2) omp_set_num_threads(2);
#else
if (nt < 2)  omp_set_num_threads(2);
if (nt % 2 != 0) omp_set_num_threads(nt-1);
#endif

int iterations = (argc>1) ? atoi(argv[1]) : 100;

printf("thread ping-pong benchmark\n");
printf("num threads  = %d\n", omp_get_max_threads());
printf("iterations   = %d\n", iterations);
#ifdef SEQUENTIAL_CONSISTENCY
printf("memory model = %s\n", "seq_cst");
#else
printf("memory model = %s\n", "acq-rel");
#endif
fflush(stdout);

_Atomic int left_ready  = -1;
_Atomic int right_ready = -1;

int left_payload  = 0;
int right_payload = 0;

#pragma omp parallel
{
int me  = omp_get_thread_num();
/// 0=left 1=right
bool parity = (me % 2 == 0);

int junk = 0;

/// START TIME
#pragma omp barrier
double t0 = omp_get_wtime();

for (int i=0; i

[Bug gcov-profile/77466] New: [7 regression] FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++11 (test for excess errors)

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

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

Bug ID: 77466
   Summary: [7 regression] FAIL: g++.dg/gcov/gcov-dump-1.C
-std=gnu++11 (test for excess errors)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: marxin at gcc dot gnu.org
Blocks: 58306
  Target Milestone: ---

$ gcc/xg++ -Bgcc/ ../gcc/testsuite/g++.dg/gcov/gcov-dump-1.C -m32 -nostdinc++
-Ipowerpc64-suse-linux/32/libstdc++-v3/include/powerpc64-suse-linux
-Ipowerpc64-suse-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++
-I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util
-std=gnu++98 -fprofile-generate -ftest-coverage -lgcov
-Lpowerpc64-suse-linux/32/libstdc++-v3/src/.libs
-Bpowerpc64-suse-linux/32/libstdc++-v3/src/.libs
-Lpowerpc64-suse-linux/32/libstdc++-v3/src/.libs
-Bpowerpc64-suse-linux/32/libitm/ -Lpowerpc64-suse-linux/32/libitm/.libs -lm -o
./gcov-dump-1.exegcc/32/libgcov.a(_gcov_time_profiler.o): In function
`__gcov_time_profiler_atomic':
/daten/gcc/gcc-20160902/Build/powerpc64-suse-linux/32/libgcc/../../../../libgcc/libgcov-profiler.c:352:
undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306
[Bug 58306] Broken profiling for unrar sources: error: corrupted value profile:
value profile counter (X out of Y) inconsistent with basic-block count

[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||ice-checking, patch

--- Comment #10 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00146.html

[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
As I said, I think "<<" on signed integers is generally bogus in a
truth value context.

So I tried an experiment for such a warning:

Index: c-common.c
===
--- c-common.c  (Revision 239953)
+++ c-common.c  (Arbeitskopie)
@@ -4601,6 +4601,13 @@ c_common_truthvalue_conversion (location_t locatio
   /* These don't change whether an object is nonzero or zero.  */
   return c_common_truthvalue_conversion (location, TREE_OPERAND (expr,
0));

+case LSHIFT_EXPR:
+  if (TREE_CODE (TREE_TYPE (expr)) == INTEGER_TYPE
+ && !TYPE_UNSIGNED (TREE_TYPE (expr)))
+   warning_at (EXPR_LOCATION (expr), 0,
+   "<< on signed integer in boolean context");
+  break;
+
 case LROTATE_EXPR:
 case RROTATE_EXPR:
   /* These don't change whether an object is zero or nonzero, but


And guess what: it immediately found something!

In file included from ../../gcc-trunk/gcc/cp/parser.c:24:0:
../../gcc-trunk/gcc/cp/parser.c: In function 'tree_node*
cp_parser_condition(cp_parser*)':
../../gcc-trunk/gcc/cp/cp-tree.h:4964:34: error: << on signed integer in
boolean context [-Werror]
 #define LOOKUP_ONLYCONVERTING (1 << 2)
   ~~~^
../../gcc-trunk/gcc/cp/parser.c:11175:17: note: in expansion of macro
'LOOKUP_ONLYCONVERTING'
bool flags = LOOKUP_ONLYCONVERTING;
 ^
cc1plus: all warnings being treated as errors
make[3]: *** [cp/parser.o] Error 1

[Bug c++/52830] ICE: "canonical types differ for identical types ..." when attempting SFINAE with member type

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #5 from Tom de Vries  ---
PR77427 comment 6 contains untested patch that fixes all these test-cases.

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[peter at lekensteyn dot nl]

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

Peter Wu  changed:

   What|Removed |Added

 CC||peter at lekensteyn dot nl

--- Comment #1 from Peter Wu  ---
External binutils bug:
Linking a MPX instrumented shared object fails with -pie
https://sourceware.org/bugzilla/show_bug.cgi?id=20550

[Bug fortran/77415] ICE: tree check: expected function_type or method_type, have pointer_type in create_function_arglist, at fortran/trans-decl.c:2263

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/77414] ICE in create_function_arglist, at fortran/trans-decl.c:2410

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug fortran/77412] constructor of an extended type with an allocatable component in the base type crashes gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug c/77463] internal compiler error: in output_move_qimode, at config/m68k/m68k.c:3160

[matthias.r...@hu-berlin.de]

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

--- Comment #2 from Matthias Reis  ---
I just compiled the same file using gcc-6.2.0 without any problems, regardless
of the switch -Os.

[Bug c/77464] gcc -no-pie breaks -shared

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Manuel López-Ibáñez from comment #3)
> Or at least give a clearer error that mentions -fPIC ...

Actually this is not a driver issue just a binutils issue if that. Why add
no-pie anyways to the ldflags.

[Bug c/77464] gcc -no-pie breaks -shared

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
No. In most cases the -shared and the compiling part are separated. This was
just a simplified example of not using the right options.

[Bug c/77464] gcc -no-pie breaks -shared

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
Or at least give a clearer error that mentions -fPIC ...

[Bug c/77464] gcc -no-pie breaks -shared

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 CC||manu at gcc dot gnu.org
 Resolution|INVALID |---

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #1)
> You need -fPIC to create shared libraries.

Couldn't the driver do this on its own internally?

[Bug tree-optimization/66946] Spurious uninitialized warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-03
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Manuel López-Ibáñez  ---
Still valid?

[Bug middle-end/66447] -Werror=maybe-uninitialized indicates trashing of variable across longjmp

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-03
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
https://gcc.gnu.org/bugs/#detailed
and https://gcc.gnu.org/bugs/minimize.html

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez  ---
(In reply to Vincent Lefèvre from comment #15)
> Well, detecting uninitialized variables is equivalent to generating better
> code. See the following functions. If you want to be able to remove the i ==
> 0 test in the first one (making generated code better), you'll solve the
> warning problem in the second one.

Not really, the pass that generates better code may happen after the pass that
warns. And heuristics that generate better code often hide warnings: PR18501

Neither generating better code nor warning are exact methods. They rely on
heuristics. The warnings are even more sensitive, because the goal of the
compiler is to generate better code, not to produce accurate warnings, so
information that is useful for warning is not maintained throughout.

And then, there are heuristics such as not warning for f(), by assuming that
it will initialize c, that are implemented because they are more often right
than wrong, but they are sometimes wrong. When it can be established that they
were wrong (after inlining, for example), then warnings are given.

You seem to be assuming that

void g1(int *p);
int f1()
{
 int c;
 g1();
 return c; /* warn maybe-uninit */
}

int g2();
int f2()
{
 int c = g2();
 return c; /* warn maybe-uninit */
}
int h(int p)
{
 int c;
  if (p)
c = 1;
 return c; /* warn maybe-uninit */
}

are equivalent in terms of being maybe uninitialized, and all should either be
warned or not warned about. But in practice, f1() and f2() are most often a
false positive and h() is almost always a real bug.

[Bug fortran/69514] ICE with nested array constructor

[lkrupp at gcc dot gnu.org]

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

--- Comment #4 from lkrupp at gcc dot gnu.org ---
This patch is a kludge.  I don't recommend it.  But it does fix at least one of
the test cases, it passes the test suite, and it might point to a proper
solution:

Index: arith.c
===
--- arith.c (revision 239966)
+++ arith.c (working copy)
@@ -1326,7 +1326,21 @@ reduce_binary_ca (arith (*eval) (gfc_expr *, gfc_e
   for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
 {
   if (c->expr->expr_type == EXPR_CONSTANT)
-   rc = eval (op1, c->expr, );
+   {
+ /* The conversion *should* be done only if necessary. */
+ gfc_expr temp;
+
+ temp.expr_type = EXPR_OP;
+ gfc_clear_ts ();
+
+ temp.value.op.op = INTRINSIC_PLUS; /* Arbitrary */
+ temp.value.op.op1 = op1;
+ temp.value.op.op2 = c->expr;
+
+ gfc_type_convert_binary (,
+   warn_conversion || warn_conversion_extra);
+
+ rc = eval (op1, c->expr, );
+   }
   else
rc = reduce_binary_ca (eval, op1, c->expr, );

[Bug tree-optimization/59970] Bogus Wuninitialized warnings at low optimization levels

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
Summary|Bogus warnings at low   |Bogus Wuninitialized
   |optimization levels |warnings at low
   ||optimization levels

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Thomas Schwinge from comment #0)
> It does seem appropriate to me for GCC not to do such tracking at low
> optimization levels, but then the uninitialized warning should also be
> disabled (which I assume is happening for -O0?) to avoid false positive
> warnings.

It doesn't work like that. The uninit pass sees the code as transformed by
other optimization passes, thus what the uninit pass sees depends not on a
particular level but on the passes enabled, their order and their effect on the
given code. Higher levels do not always mean better uninit warnings, either.
Nonetheless, it would be useful to identify which passes do more good than harm
for uninit (probably VRP) and enable those at lower levels somehow or even in
some limited form in the FEs.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

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

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

--- Comment #20 from Andreas Schwab  ---
aarch64 also fails.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Author: jakub
Date: Sat Sep  3 09:20:03 2016
New Revision: 239970

URL: https://gcc.gnu.org/viewcvs?rev=239970=gcc=rev
Log:
PR c/65467
* gcc.dg/gomp/_Atomic-4.c: Require vect_simd_clones effective target.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/gomp/_Atomic-4.c

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Andreas Schwab from comment #17)
> FAIL -> UNSUPPORTED

That is expected on targets that don't provide compute_vecsize_and_simdlen
target hook.  If it is a target with reasonable vector support (not really
counting here ia64 or alpha, but e.g. powerpc*, s390*, aarch64, arm etc.
should),
then declare simd is not creating any simd clones.
I'll commit the change.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

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

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

--- Comment #17 from Andreas Schwab  ---
FAIL -> UNSUPPORTED

[Bug fortran/69514] ICE with nested array constructor

[lkrupp at gcc dot gnu.org]

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

lkrupp at gcc dot gnu.org changed:

   What|Removed |Added

 CC||lkrupp at gcc dot gnu.org

--- Comment #3 from lkrupp at gcc dot gnu.org ---
This slightly simpler program reproduces the problem at version 7.0:

program p
 implicit none

 real, parameter :: w(1) = 3.0 * [ real :: 2 ]

 write(*,*) w

end program p

The problem seems to be that the constructed array is REAL (in ts.type field)
and its element 2 is an INTEGER, but the 3.0 and 2 are multiplied (in
gfc_arith_times) as if both were REAL.

[Bug target/77405] SIGBUS during gnattools compilation after recent MOVE_MAX_PIECES change

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME
Summary|SIGBUS from gnatmake in |SIGBUS during gnattools
   |stage 3 (gcc 7.0)   |compilation after recent
   ||MOVE_MAX_PIECES change

--- Comment #30 from Eric Botcazou  ---
> I tested a patch that aligns 15 and few bytes at 8 and everything else at
> 16.  With that patch, gcc-7 with Ada front-end builds successfully.  We'll
> push that patch to the master branch and the current release.

Great, thanks for the note.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to Andreas Schwab from comment #15)
> FAIL: gcc.dg/gomp/_Atomic-4.c  (test for warnings, line 7)

Does

--- gcc/testsuite/gcc.dg/gomp/_Atomic-4.c.jj2016-09-02 20:36:22.0
+0200
+++ gcc/testsuite/gcc.dg/gomp/_Atomic-4.c   2016-09-03 10:30:29.708581112
+0200
@@ -1,6 +1,7 @@
 /* PR c/65467 */
 /* { dg-do compile } */
 /* { dg-additional-options "-std=c11" } */
+/* { dg-require-effective-target vect_simd_clones } */

 #pragma omp declare simd
 int

fix it?

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

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

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

--- Comment #15 from Andreas Schwab  ---
FAIL: gcc.dg/gomp/_Atomic-4.c  (test for warnings, line 7)

[Bug bootstrap/70473] genautomata memory footprint for arm

[lly.dev at gmail dot com]

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

--- Comment #12 from Leonid Lisovskiy  ---
(In reply to ktkachov from comment #11)

r239772 seriously decreases genautomata memory consumption for ARM. As for
valgrind massif report, it requires 316MB now.
Thank you!

[Bug c/77463] internal compiler error: in output_move_qimode, at config/m68k/m68k.c:3160

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-03
 Ever confirmed|0   |1

--- Comment #1 from Andreas Schwab  ---
gcc 4.6 isn't maintained any more, please check gcc 5 or later.