[Bug c++/67960] New: Prefixing a function with [[deprecated]] produces multiple warnings

[chrisb2244 at gmail dot com]

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

Bug ID: 67960
   Summary: Prefixing a function with [[deprecated]] produces
multiple warnings
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrisb2244 at gmail dot com
  Target Milestone: ---

The [[deprecated]] prefix for a function produces multiple warnings.

In v5.2.0, there are 3 warnings for the code

[[deprecated]] void doNothing(){}
int main(){
doNothing();
}

I am informed that in v4.9.2, only 2 warnings are emitted for the same code - 
http://stackoverflow.com/questions/33117030/when-using-deprecated-the-warning-is-given-3-times?noredirect=1#comment54048535_33117030

Replacing the body of main with

auto f = doNothing;
f();

reduces the output to 2 warnings in v5.2.0, and apparently 1 warning in 4.9.2


Bug 17729 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729) seems to be
about a similar issue (the same issue?) but there discusses the attribute
rather than a tag - I assume the tag is implemented in terms of the attribute
but am unsure hence a new bug report.

[Bug testsuite/67959] New: "width of 'code' exceeds its type" error in ssa-thread-13

[thopre01 at gcc dot gnu.org]

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

Bug ID: 67959
   Summary: "width of 'code' exceeds its type" error in
ssa-thread-13
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: law at redhat dot com
  Target Milestone: ---

By declaring the field "code" in struct rtx_def

ssa-thread-13 assumes that enum rtx_code is 16-bit or more in size when
declaring the field "code" in struct rtx_def. This can only be assumed if
passing -fno-short-enums when compiling since targets are free to default to
short enum (ARM does for AAPCS based API, see arm_default_short_enums in
config/arm/arm.c).

Because of that the test is currently failing on ARM.

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

  Attachment #36472|0   |1
is obsolete||

--- Comment #40 from Alexandre Oliva  ---
Created attachment 36505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36505&action=edit
backported patch for the 4.9 branch

Yeah, sorry, I messed up somehow.  Here's the backported patch I meant to post.

[Bug c++/67927] array new expression with excessive number of elements not diagnosed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-14
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
While creating a test for a fix for this, I came across the following
diagnostic issued by grokdeclarator in cp/decl.c, showing that some invalid new
expressions are already being diagnosed.  (The ‘type name’ is wrong because the
array doesn't have a name, and is the result of the function setting the NAME
variable to "type name" when it's null.)

$ cat a.cpp && g++ -c a.cpp
void foo (void)
{
new int [4][__SIZE_MAX__];
}
a.cpp: In function ‘void foo()’:
a.cpp:3:29: error: size of array ‘type name’ is too large
 new int [4][__SIZE_MAX__];
 ^

[Bug c/67925] docs lie about being unable to inline function call before definition

[arkadiusz at drabczyk dot org]

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

--- Comment #10 from Arkadiusz Drabczyk  ---
Patch sent for review here:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01303.html

[Bug bootstrap/67931] [6 Regression] Gcc [trunk revision 228704] failed to profiledbootstrap on x86_64

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed by r228736.

[Bug tree-optimization/66117] GCC can not compile when graphite is enabled, due to missing isl headers.

[pbeeler80 at gmail dot com]

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

--- Comment #5 from Paul Beeler  ---
It is from isl master (0.15).  This was 5 months ago, and I've been using my
own patch authored by me fine since then.  I will continue to use it and not
the recently merged one thanks.

[Bug testsuite/67958] New: The tests changed by r223498 now FAILs on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 67958
   Summary: The tests changed by r223498 now FAILs on darwin
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: andreast at gcc dot gnu.org, iains at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin*
Target: x86_64-apple-darwin*
 Build: x86_64-apple-darwin*

The tests changed by r223498 now FAILs on darwin

FAIL: gcc.target/i386/pr32219-1.c scan-assembler movl[
\\t]xxx@GOTOFF(%[^,]*), %eax
FAIL: gcc.target/i386/pr32219-2.c scan-assembler movl[
\\t]xxx@GOT(%[^,]*), %eax
FAIL: gcc.target/i386/pr32219-3.c scan-assembler movl[
\\t]xxx@GOTOFF(%[^,]*), %eax
FAIL: gcc.target/i386/pr32219-4.c scan-assembler movl[
\\t]xxx@GOT(%[^,]*), %eax
FAIL: gcc.target/i386/pr32219-5.c scan-assembler movl[
\\t]xxx@GOTOFF(%[^,]*), %eax
FAIL: gcc.target/i386/pr32219-6.c scan-assembler movl[
\\t]xxx@GOT(%[^,]*), %eax
FAIL: gcc.target/i386/pr32219-7.c scan-assembler movl[
\\t]xxx@GOTOFF(%[^,]*), %eax
FAIL: gcc.target/i386/pr32219-8.c scan-assembler movl[
\\t]xxx@GOT(%[^,]*), %eax

with -m32 and

FAIL: gcc.target/i386/pr32219-1.c scan-assembler movl[ \\t]xxx(%rip),
%eax
FAIL: gcc.target/i386/pr32219-3.c scan-assembler movl[ \\t]xxx(%rip),
%eax
FAIL: gcc.target/i386/pr32219-3.c scan-assembler-not xxx@GOTPCREL
FAIL: gcc.target/i386/pr32219-5.c scan-assembler movl[ \\t]xxx(%rip),
%eax
FAIL: gcc.target/i386/pr32219-6.c scan-assembler xxx@GOTPCREL
FAIL: gcc.target/i386/pr32219-7.c scan-assembler movl[ \\t]xxx(%rip),
%eax
FAIL: gcc.target/i386/pr32219-7.c scan-assembler-not xxx@GOTPCREL

with -m64 and

FAIL: gcc.target/i386/pr39013-1.c scan-assembler bar@PLT
FAIL: gcc.target/i386/pr39013-1.c scan-assembler foo@PLT
FAIL: gcc.target/i386/pr39013-2.c scan-assembler bar@PLT
FAIL: gcc.target/i386/pr39013-2.c scan-assembler foo@PLT

with -m32 or -m64.

With the following patch

--- ../_clean/gcc/testsuite/gcc.target/i386/pr32219-1.c 2015-05-21
23:58:24.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr32219-1.c   2015-10-13 19:20:57.0
+0200
@@ -12,7 +12,7 @@ foo ()
   return xxx;
 }

-/* { dg-final { scan-assembler "movl\[ \t\]xxx\\(%rip\\), %eax" { target { !
ia32 } } } } */
+/* { dg-final { scan-assembler "movl\[ \t\]_?xxx\\(%rip\\), %eax" { target { !
ia32 } } } } */
 /* { dg-final { scan-assembler-not "xxx@GOTPCREL" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "movl\[ \t\]xxx@GOTOFF\\(%\[^,\]*\\), %eax" {
target ia32 } } } */
+/* { dg-final { scan-assembler "movl\[
\t\]_?xxx(@GOTOFF|-L1\\\$pb)\\(%\[^,\]*\\), %eax" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "movl\[ \t\]xxx@GOT\\(%\[^,\]*\\), %eax" {
target ia32 } } } */
--- ../_clean/gcc/testsuite/gcc.target/i386/pr32219-2.c 2015-05-21
23:58:24.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr32219-2.c   2015-10-13 22:40:20.0
+0200
@@ -14,4 +14,4 @@ foo ()
 /* { dg-final { scan-assembler-not "movl\[ \t\]xxx\\(%rip\\), %eax" { target {
! ia32 } } } } */
 /* { dg-final { scan-assembler "xxx@GOTPCREL" { target { ! ia32 } } } } */
 /* { dg-final { scan-assembler-not "movl\[ \t\]xxx@GOTOFF\\(%\[^,\]*\\), %eax"
{ target ia32 } } } */
-/* { dg-final { scan-assembler "movl\[ \t\]xxx@GOT\\(%\[^,\]*\\), %eax" {
target ia32 } } } */
+/* { dg-final { scan-assembler "movl\[
\t\](L_)?xxx(@GOT|\\\$non_lazy_ptr-L1\\\$pb)\\(%\[^,\]*\\), %eax" { target ia32
} } } */
--- ../_clean/gcc/testsuite/gcc.target/i386/pr32219-4.c 2015-05-21
23:58:24.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr32219-4.c   2015-10-13 22:11:56.0
+0200
@@ -15,4 +15,4 @@ foo ()
 /* { dg-final { scan-assembler-not "movl\[ \t\]xxx\\(%rip\\), %eax" { target {
! ia32 } } } } */
 /* { dg-final { scan-assembler "xxx@GOTPCREL" { target { ! ia32 } } } } */
 /* { dg-final { scan-assembler-not "movl\[ \t\]xxx@GOTOFF\\(%\[^,\]*\\), %eax"
{ target ia32 } } } */
-/* { dg-final { scan-assembler "movl\[ \t\]xxx@GOT\\(%\[^,\]*\\), %eax" {
target ia32 } } } */
+/* { dg-final { scan-assembler "movl\[
\t\](L_)?xxx(@GOT|\\\$non_lazy_ptr-L1\\\$pb)\\(%\[^,\]*\\)(\\(%\[^,\]*\\))?,
%eax" { target ia32 } } } */
--- ../_clean/gcc/testsuite/gcc.target/i386/pr32219-5.c 2015-05-21
23:58:24.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr32219-5.c   2015-10-13 22:14:11.0
+0200
@@ -11,7 +11,7 @@ foo ()
   return xxx;
 }

-/* { dg-final { scan-assembler "movl\[ \t\]xxx\\(%rip\\), %eax" { target { !
ia32 } } } } */
+/* { dg-final { scan-assembler "movl\[ \t\]_?xxx\\(%rip\\), %eax" { target { !
ia32 } } } } */
 /* { dg-final { scan-assembler-not "xxx@GOTPCREL" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "movl\[ \t\]xxx@GOTO

[Bug sanitizer/59748] ptrace isn't instrumented on at least arm-linux-gnueabihf and powerpc-linux.gnu

[adhemerval.zanella at linaro dot org]

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

Adhemerval Zanella  changed:

   What|Removed |Added

 CC||adhemerval.zanella at linaro 
dot o
   ||rg

--- Comment #1 from Adhemerval Zanella  
---
Yes, there are not instrument even in LLVM. I am working on arm-linux-gnueabihf
ptrace instrumentation.

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Actually, the problem seems to be that we're oscillating
between forms.

The old fold-const.c folders converted sequences of sqrts
and cbrts into a pow call while tree-ssa-math-opts.c goes
the other way.  In that situation things were well-controlled:
we did both transformations only once, in that order.
Moving the fold-const.c folders to match.pd means that we
try them many times and that ultimately they win.

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-13
 CC||rsandifo at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Sorry, looks like it was a mistake to think that this transition
could be done one function at a time.

[Bug fortran/52475] option -imacros for fortran code is not supported

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> can -cpp and -imacros be supported in gfortran in the future relases?

More than three years since this PR has been filed. I am afraid nothing will be
done for the next decade. IMO should be closed as WONTFIX.

[Bug fortran/50360] [cleanup] use an ENUM for the return values of gfc_dep_compare_expr

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Any opinion about keeping this four-year old PR opened?

[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled

[pthaugen at gcc dot gnu.org]

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

--- Comment #6 from Pat Haugen  ---
416.gamess now passes on powerpc64 as well.

[Bug fortran/54322] [OOP] Wrong TARGET-attribute handling with CLASS IS/TYPE IS

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Still present at r228753.

[Bug c/67925] docs lie about being unable to inline function call before definition

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #9 from Segher Boessenkool  ---
Please send the patch to gcc-patc...@gcc.gnu.org as described at
.  Thanks!

[Bug fortran/53542] Diagnostic of USE-associated variables shows original instead of renamed symbol name

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Still present at r228753.

[Bug fortran/52365] Procedure interface wrongly imported into interface without IMPORT

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Still present at r228753.

[Bug c/67956] gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

--- Comment #6 from Christos Zoulas  ---
great, thank you. since this is tracked already you can close it if you want.

[Bug c/67956] gcc's printf attribute accepts %m as a format character

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
There has been some discussion recently of adding -Wformat-pedantic (see 
bug 67479), which would seem reasonable to me.  A syslog format also seems 
reasonable (but we already have bug 15338 tracking that idea).  A 
special-case option for only this single case of non-portable formats 
seems more dubious to me.

[Bug c++/67942] diagnose placement new buffer overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Patch posted for review here:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01284.html

[Bug c/67956] gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

--- Comment #4 from Christos Zoulas  ---
I believe that -pedantic enables other "pedantic" warnings which I don't belive
I want. I can add a specific printf format that does not accept %m, but I would
still need to add a syslog format that does (and annotate the syslog functions
with that instead of printf).

Perhaps it is possible to have a separate -W switch that will enable this
behavior (warn for %m in printf formats), and add a syslog format that allows
%m.

I think that we want to encourage people to write portable code, and using %m
in printf isn't.

My goal is to differentiate between syslog-like functions that support %m and
printf-like functions that don't.

Is adding a separate -W flag to enable warnings for %m in printf and a syslog
format acceptable? I think that non-glibc systems will benefit from that.

[Bug fortran/52083] Misleading warning for internal procedures with names of intrinsic procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.8.5, 4.9.3, 5.2.0, 6.0
 Resolution|--- |FIXED

--- Comment #1 from Dominique d'Humieres  ---
> Expected: Do the same as for module procedures, namely print:
>
>   Warning: 'fraction' declared at (1) may shadow the intrinsic of the same
> name.  In order to call the intrinsic, explicit INTRINSIC declarations
> may be required.

This is exactly the warning I get with 4.8 up to trunk (6.0). With 5.2.0 and
6.0 the message ends with ' [-Wintrinsic-shadow]'.

[Bug tree-optimization/67920] [6 Regression] wrong code with -O3

[jamrial at gmail dot com]

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

--- Comment #9 from James Almer  ---
(In reply to Yuri Rumyantsev from comment #8)
> Please check that revision 228760 will cure your issue.

Looks like it did. Thanks.

[Bug fortran/47805] [OOP] Overridding hidden (private) TPB is rejected

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
For what it worth, updated link in comment 1:

http://mailman.j3-fortran.org/pipermail/j3/2011-February/004197.html

The problems are still there at r228753.

[Bug tree-optimization/67953] [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
So mine.

[Bug fortran/54082] Program name shadows other entities with the same name

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
As said by Tobias, the code is invalid and, although the error message could be
improved, nobody tried to do it during the past three years. IMO it is more
realistic to close this PR as WONTFIX rather to let it rot for the next decade.

[Bug middle-end/67912] [6 Regression] ICE in gen_lowpart_common, at emit-rtl.c:1399

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||aoliva at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #6 from Alexandre Oliva  ---
Mine.  Fixed.

[Bug middle-end/67912] [6 Regression] ICE in gen_lowpart_common, at emit-rtl.c:1399

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Tue Oct 13 16:34:29 2015
New Revision: 228774

URL: https://gcc.gnu.org/viewcvs?rev=228774&root=gcc&view=rev
Log:
support BLKmode inputs for store_bit_field

Revision 228586 changed useless_type_conversion_p and added mode
changes for MEM:BLKmode inputs in store_expr_with_bounds, but it
missed store_bit_field.  This caused ada/rts/s-regpat.ads to fail
compilation on x86_64-linux-gnu.

for  gcc/ChangeLog

PR middle-end/67912
* expmed.c (store_bit_field_1): Adjust mode of BLKmode inputs.

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

[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
> Note that, in a way, this 'double mangling' is not a bug but a feature.
> ...

No feedback for more than three years. Closing as WONTFIX.

[Bug c/67956] gcc's printf attribute accepts %m as a format character

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
The gnu_printf format attribute is specifically supposed to accept %m; you 
can use -pedantic to disallow it.  Targets can override what the printf 
attribute maps to; see config/i386/msformat-c.c for example; other OSes 
should do likewise so the correct set of formats for each target is 
accepted.  The desire for a syslog format is bug 15338.

[Bug fortran/53940] Optionally warn about multiple explicit USE-association of the same symbol

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
No warning at r228753.

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[pthaugen at gcc dot gnu.org]

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

--- Comment #6 from Pat Haugen  ---
(In reply to Richard Biener from comment #3)
> Was this maybe fixed by
> 
> 2015-10-13  Richard Sandiford  
> 
> * real.h (real_isinteger): Declare.
> * real.c (real_isinteger): New function.
> * match.pd: Simplify pow(|x|,y) and pow(-x,y) to pow(x,y)
> if y is an even integer.
> 
> ?

That did not fix the powerpc64 failures, they still fail with r228762.

[Bug fortran/65141] ISO_10646 constant parameters convert kind when used with substring references

[alexandros.syrakos at outlook dot com]

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

--- Comment #4 from Alexandros Syrakos  
---
Dominique, thanks for the quick reply. Your answer is just, but I'm afraid that
due to lack of appropriate skills I can't be much more help than reporting
bugs.

Concerning the present bug, let me add some more information: Your suggestion
of removing the "parameter" keyword is nice as a workaround but it doesn't work
for arrays of strings. Consider for example the following modification of the
original code:



program ISO_CONST_SUBST_PR
implicit none
integer, parameter :: UNICODE=selected_char_kind('ISO_10646')
integer, parameter :: DEFAULT=selected_char_kind('DEFAULT')
!character(kind=UNICODE,len=*),parameter :: string='my string'
character(kind=UNICODE,len=9) :: string='my string'
character(kind=UNICODE,len=9), dimension(2) :: page

page = string

write(*,'(A, I0, A, I0)') 'Unicode and default character kinds are:
',UNICODE,', ',DEFAULT
write(*,'(A, I0)') 'kind(string) should be UNICODE and is UNICODE for me:
',kind(string)
write(*,'(A, I0)') 'kind(string(2:4)) should be UNICODE and is UNICODE for
me: ',kind(string(2:4))
write(*,'(A, I0)') 'kind(page) should be UNICODE and is UNICODE for me:
',kind(page)
write(*,'(A, I0)') 'kind(page(1)) should be UNICODE and is UNICODE for me:
',kind(page(1))
write(*,'(A, I0)') 'kind(page(1)(2:4)) should be UNICODE and is DEFAULT for
me: ',kind(page(1)(2:4))
end program ISO_CONST_SUBST_PR



With gfortran 5.2.0 I get kind(page(1)(2:4)) == DEFAULT instead of UNICODE,
although no parameters are involved. Let me include another sample code:



program test
use iso_fortran_env
implicit none
integer, parameter ::ucs4 = selected_char_kind( 'ISO_10646' )
character(kind=ucs4) :: a
character(kind=ucs4, len=8), dimension(2) :: page

a = char( int(z'f17c'), ucs4 )

open (output_unit, encoding='UTF-8')
page(1) = repeat(a,8)
print "(a,i0,2a)", "kind(page(1)) is ", kind(page(1)), "; page(1) contains: ",
page(1)

page(1)(2:4) = a
print "(a,i0,2a)", "kind(page(1)) is ", kind(page(1)), "; page(1) contains: ",
page(1)
end program test



You can see that, once substring page(1)(2:4) has been modified, although the
kind of page(1) is unaltered, printing page(1) to the screen gives rubbish.
This practically makes it impossible to use arrays of unicode strings.

[Bug c/67956] gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

--- Comment #2 from Christos Zoulas  ---
something is wrong with the bug tracking system, when posting a bug with an
attachment as the first post; this is how the dup got created.

[Bug c/67956] gcc's printf attribute accepts %m as a format character

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

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

--- Comment #1 from Andreas Schwab  ---
*** Bug 67957 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> The same points-to set results from
> 
> int *p = (int *)((char *)&a + 2);
> 
> or even
> 
> int *p = &a + 1;
> 

I see, I didn't realize that. But AFAICT, in both these cases, storing to *p is
illegal (if 'a' is a scalar int).

> so you can't use points-to info that way (to derive a must-alias).

I see your point related to an array object, there pointers to different array
elements would have identical points-to sets.

I wonder though: if we have a store '*p = 0', and the size of the store is the
same as the size of the pointed-to object of pointer p, can't we conclude that 
pointer p points to the start of the object?

[Bug c/67957] gcc's printf attribute accepts %m as a format character

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #2 from Andreas Schwab  ---
.

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

[Bug c/67957] gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

--- Comment #1 from Christos Zoulas  ---
Created attachment 36504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36504&action=edit
patch

[Bug c/67957] New: gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

Bug ID: 67957
   Summary: gcc's printf attribute accepts %m as a format
character
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christos at zoulas dot com
  Target Milestone: ---

According to TOG
(http://pubs.opengroup.org/onlinepubs/009695399/functions/fprintf.html), %m is
not a legal formatting character for printf(3) like functions. Some
implementations (glibc) accept this formatting character as an extension and
expand it to the error string via strerror(3) that errno currently points to.
Most other c library implementations do not expand %m. 

Attached is a patch that makes printf warn when %m is present and adds a
"syslog" attribute that accepts %m. I recognize that this is an incompatible
change, and I welcome suggestions how to do this in a less intrusive way.

I tried to mininize the size of the patch; there are better ways to do this,
but require more refactoring.

[Bug c/67956] New: gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

Bug ID: 67956
   Summary: gcc's printf attribute accepts %m as a format
character
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christos at zoulas dot com
  Target Milestone: ---

Created attachment 36503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36503&action=edit
patch

According to TOG
(http://pubs.opengroup.org/onlinepubs/009695399/functions/fprintf.html), %m is
not a legal formatting character for printf(3) like functions. Some
implementations (glibc) accept this formatting character as an extension and
expand it to the error string via strerror(3) that errno currently points to.
Most other c library implementations do not expand %m. 

Attached is a patch that makes printf warn when %m is present and adds a
"syslog" attribute that accepts %m. I recognize that this is an incompatible
change, and I welcome suggestions how to do this in a less intrusive way.

I tried to mininize the size of the patch; there are better ways to do this,
but require more refactoring.

[Bug c/67925] docs lie about being unable to inline function call before definition

[arkadiusz at drabczyk dot org]

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

--- Comment #8 from Arkadiusz Drabczyk  ---
I attach a new patch with an extra whitespace after dot to keep up with an
existing convention.

[Bug c/67925] docs lie about being unable to inline function call before definition

[arkadiusz at drabczyk dot org]

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

Arkadiusz Drabczyk  changed:

   What|Removed |Added

  Attachment #36488|0   |1
is obsolete||

--- Comment #7 from Arkadiusz Drabczyk  ---
Created attachment 36502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36502&action=edit
better suggested patch

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||http://sourceforge.net/p/mi
   ||ngw-w64/bugs/459/
 Resolution|--- |MOVED

--- Comment #10 from Jonathan Wakely  ---
Thanks for the link.

[Bug c/67930] segmentation fault

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Try adding -W -Wall and also -WWrite-string

[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved

[Pidgeot18 at gmail dot com]

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

--- Comment #4 from Joshua Cranmer  ---
(In reply to Richard Biener from comment #3)
> Most interesting would be a C testcase that produces the CFG with the bogus
> counters ;)

Yeah, I know, but doing the minimization on a 5MLOC program takes time.

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #9 from R Copley  ---
For information, this has already been entered on the mingw-w64 issue tracker
(months ago) (see http://sourceforge.net/p/mingw-w64/bugs/459/).

[Bug c/67930] segmentation fault

[ka_bena at yahoo dot fr]

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

--- Comment #2 from BENAÏSSA  ---

 Thank you for your reply.

 Comments::

 I am not convinced by your point of view.

 1- the compilation step does not deliver any message.

 2- I modify the string by address and this is permitted by C for any entity
not 
    private in its context.

 3- if the compiler gcc allows segmentation fault for basic operations on
pointers,
    I think that this is a severe bug and in consequence the compiler must be
    modified to remedie for such situations.

 This is my point of view.    
    A.Benaïssa 


 Le Lundi 12 octobre 2015 13h16, mpolacek at gcc dot gnu.org
 a écrit :


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

Marek Polacek  changed:

          What    |Removed                    |Added

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

--- Comment #1 from Marek Polacek  ---
You're trying to modify a string literal.  That's no-no.

[Bug rtl-optimization/67954] [5 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

[Bug tree-optimization/67955] tree-dse does not use pointer info

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
We use "must point to" nowhere because we don't compute it ;)

The same points-to set results from

int *p = (int *)((char *)&a + 2);

or even

int *p = &a + 1;

so you can't use points-to info that way (to derive a must-alias).

[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Taking.

[Bug tree-optimization/67955] New: tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

Bug ID: 67955
   Summary: tree-dse does not use pointer info
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider this testcase, with dead store '*p = 1':
...
int
f ()
{
  int a;
  int *p = &a;
  *p = 1;
  a = 2;
  return a;
}
...

We compile with -O2 -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre.

At dse1 we have
...
f ()
{
  int * p;
  int a;
  int _5;

  :
  p_1 = &a;
  *p_1 = 1;
  a = 2;
  _5 = a;
  a ={v} {CLOBBER};
  return _5;

}
...

So, the dead store '*p_1 = 1' has not been eliminated.

However, at ealias we already know:
...
Alias information for f

Aliased symbols

a, UID D.1757, int, is addressable

Call clobber information

ESCAPED, points-to non-local, points-to vars: { }

Flow-insensitive points-to information

p_1, points-to vars: { D.1757 }
...

So, we could use points-to info in dce.

[Bug fortran/67696] libbacktrace prints C++ demangled name for Fortran symbol

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu
 Status|WAITING |UNCONFIRMED
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
 Ever confirmed|1   |0

--- Comment #2 from Joost VandeVondele  
---
so seemingly target specific ?

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[redflames1003 at gmail dot com]

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

--- Comment #39 from Christopher Torres  ---
(In reply to Alexandre Oliva from comment #36)
> Created attachment 36472 [details]
> backported patch for the 4.9 branch
> 
> Chris,
> 
> retbnd is of no concern, nothing equivalent existed back then.
> 
> call_stmt was called gimple_call.
> 
> Here's a backported patch, barely tested.  Please let me know how it goes
> for you.

Thank you. Looking at the diff it doesn't look like this will actually compile
since redbnd and call_stmt is still in there. Did you maybe upload the wrong
patch file? 

Thanks

[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
On trunk (6.0 r228753) this has been changed to

  /* Functions returning pointers or allocatables need temporaries.  */
  c = expr2->value.function.esym
  ? (expr2->value.function.esym->attr.pointer
 || expr2->value.function.esym->attr.allocatable)
  : (expr2->symtree->n.sym->attr.pointer
 || expr2->symtree->n.sym->attr.allocatable);
  if (c)
return true;

Any point to keep this PR opened?

[Bug fortran/51820] [doc] underscoring documentation incorrect

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Any interest for this?

[Bug fortran/47495] .mod files: File modification time - Makefile build issue

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #13 from Dominique d'Humieres  ---
Is this still of interest?

[Bug fortran/49590] ENTRY: Reject combining USE associated variable with RESULT variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Still present at r228753 (trunk 6.0).

[Bug fortran/48997] Don't use allocatable arrays for function elimination

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> Thomas, what is the status of this?

PING!

[Bug fortran/51380] ASSIGNMENT(=): Reject ALLOCATABLE/POINTER dummy argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Still no error/warning at r228753 (trunk 6.0).

[Bug fortran/52265] [OOP] TREE dump confusing with nested SELECT TYPE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Still present at r228753.

[Bug rtl-optimization/67954] New: [5 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1281

[dbaryshkov at gmail dot com]

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

Bug ID: 67954
   Summary: [5 Regression] internal compiler error: in
patch_jump_insn, at cfgrtl.c:1281
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dbaryshkov at gmail dot com
  Target Milestone: ---

Created attachment 36501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36501&action=edit
Preprocessed source file

Since https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210824 GCC fails
with ICE when generating ARM Thumb1 code:

/tmp/test.i: In function 'ubidi_writeReordered_55':
/tmp/test.i:4748:1: internal compiler error: in patch_jump_insn, at
cfgrtl.c:1303
 }
 ^
0x63700e patch_jump_insn
../../gcc/gcc/cfgrtl.c:1303
0x63715b redirect_branch_edge
../../gcc/gcc/cfgrtl.c:1329
0x6376e2 rtl_redirect_edge_and_branch
../../gcc/gcc/cfgrtl.c:1462
0x629889 redirect_edge_and_branch(edge_def*, basic_block_def*)
../../gcc/gcc/cfghooks.c:376
0xd0be1d try_forward_edges
../../gcc/gcc/cfgcleanup.c:621
0xd0be1d try_optimize_cfg
../../gcc/gcc/cfgcleanup.c:2835
0xd0be1d cleanup_cfg(int)
../../gcc/gcc/cfgcleanup.c:3049
0xd0d318 execute
../../gcc/gcc/cfgcleanup.c:3178


The following commands fail:

* gcc -march=armv4t -mthumb /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping
* gcc -march=armv5te -mthumb /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping
* gcc -march=armv6 -mthumb /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping

The following work:
* gcc -march=armv6t2 -mthumb /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping
* gcc -march=armv5te -marm /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping
* gcc -march=armv5te -mthumb /tmp/test.i -S -o /tmp/test.o  -O1

The log was produced using clear gcc from gcc-5_1_0-release tag.

The following configure options were passed to gcc:

../gcc/configure --build=x86_64-linux  --host=x86_64-linux 
   --target=arm-linux-gnueabi
--enable-languages=c --enable-checking=all --disable-nls

[Bug fortran/58002] [IR tracking] Pointer function results in non pointer context: Shall use a temporary

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

[Bug fortran/67696] libbacktrace prints C++ demangled name for Fortran symbol

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
On x86_64-apple-darwin14 with lldb I get

frame #5: 0x00010e95 a.out`__foo_MOD_cp__b + 14 at pr67696.f90:4
frame #6: 0x00010e9e a.out`test + 9 at pr67696.f90:10
frame #7: 0x00010ed7 a.out`main(argc=1,
argv="/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out") + 54 at
pr67696.f90:9

and with gdb

#5  0x00010e95 in cp__b () at pr67696.f90:4
#6  0x00010e9e in test () at pr67696.f90:10
#7  0x00010ed7 in main (argc=1, argv=0x7fff5fbff5b0) at pr67696.f90:9

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

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
revision 228760 must fix this bug.

[Bug fortran/67744] polymorphic associating entity is refused TBP invocation

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Dominique d'Humieres  ---
> The first sentence, I think, implies that my code example is valid.

IMO everything is in the "if", but I don't know the answer. Note that this may
be related to pr67743.

[Bug tree-optimization/67920] [6 Regression] wrong code with -O3

[ysrumyan at gmail dot com]

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

--- Comment #8 from Yuri Rumyantsev  ---
Please check that revision 228760 will cure your issue.

[Bug inline-asm/67944] GCC emits unnecessary push/pop for callee-save reads.

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Your expectation is not in line with what the compiler actually promises
you: the only guarantee is that the local register variable will be in
(in your case) ebx _where used in an asm statement_.

Other than that, it is just a local variable.

You get a save/restore sequence in the prologue and epilogue because ebx
is a non-volatile register and this function uses that register.  Scheduling
later moves the push later in the code.

If you want to simply grab what is in ebx, you can use asm, like

long reg; asm("mov %%ebx,%0" : "=r"(reg));

[Bug fortran/67743] Associating entity is not auto-typed

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 4.8 up to trunk (6.0). Probably related to pr67744.

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[afomin.mailbox at gmail dot com]

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

--- Comment #5 from Alexander Fomin  ---
Created attachment 36500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36500&action=edit
Folding regression reproducer

Unfortunately, it does not for x86-64.
Please take a look at the attached reproducer.
When compiling with -m64 -O2 -ffast-math -S it does not perform expected 
folding.

r228614
:
y.1_2 = y;
_3 = __builtin_sqrt (y.1_2);
*x_4(D) = _3;
powroot_18 = __builtin_sqrt (_3);
powroot_19 = _3 * powroot_18;
powroot_20 = y.1_2 * powroot_19;
y = powroot_20;

r228616
:
y.1_2 = y;
_3 = __builtin_sqrt (y.1_2);
*x_4(D) = _3;
powroot_18 = __builtin_pow (y.1_2, 2.5e-1);
powroot_19 = _3 * powroot_18;
powroot_20 = y.1_2 * powroot_19;
y = powroot_20;

[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Tue Oct 13 13:08:31 2015
New Revision: 228760

URL: https://gcc.gnu.org/viewcvs?rev=228760&root=gcc&view=rev
Log:
gcc/

2014-10-13  Yuri Rumyantsev  

PR tree-optimization/67909, 67947
* tree-ssa-loop-unswitch.c (find_loop_guard): Add check that GUARD_EDGE
really skip the inner loop.

gcc/testsuite/

2014-10-13  Yuri Rumyantsev  

PR tree-optimization/67909, 67947
* gcc.dg/torture/pr67947.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr67947.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-unswitch.c

[Bug fortran/67936] Off-by-one column for some caret locations

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for 5.2 and 6.0 (trunk).

[Bug tree-optimization/67949] Regression in GCC-6.0.0's optimizer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Seems to be fixed if it was ever broken.

[Bug fortran/58002] [IR tracking] Pointer function results in non pointer context: Shall use a temporary

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
The test

   Module m200c2
 Integer,Target :: x = 42
   Contains
 Function fx()
   Integer,Pointer :: fx
   fx => x
 End Function
   End Module

   Program q1
 Use m200c2
 Call test(x,fx())  ! The call.
   Contains
 Subroutine test(a,b)
   Integer :: a,b
   a = a*10 ! The assignment.
   Print *,a,b
 End Subroutine
   End Program

outputs 

 420 420

Am I correct to understand that this answer is OK for Fortran 2008, but should
be

 420 42

for Fortran 2003 and older?

Note that if I replace the line

 Call test(x,fx())  ! The call.

with

 Call test(x,(fx()))  ! The call.

I get the later answer.

[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'

[matthijs at stdin dot nl]

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

--- Comment #9 from Matthijs Kooijman  ---
Created attachment 36499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36499&action=edit
Second testcase, needs -Os to break

[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'

[matthijs at stdin dot nl]

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

Matthijs Kooijman  changed:

   What|Removed |Added

 CC||matthijs at stdin dot nl

--- Comment #8 from Matthijs Kooijman  ---
Seems not - just tried with avr-gcc 5.1 and it is still broken:

$ avr-gcc -fpreprocessed -w -mmcu=atmega128 -O2 -s test.i -o /dev/null
test.i: In function 'rtems_fdisk_recycle_segment':
test.i:107:1: error: unable to find a register to spill in class
'POINTER_REGS'
 }
 ^
test.i:107:1: error: this is the insn:
(insn 30 29 31 2 (set (reg:HI 26 r26)
(reg/v/f:HI 51 [ dpd ])) /home/matthijs/test.i:95 83 {*movhi}
 (nil))
test.i:107: confused by earlier errors, bailing out

$ avr-gcc --version
avr-gcc (GCC) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

On the Arduino bugtracker [1], another testcase with the same symptoms was
reported. I'm attaching that here. This testcase works with -O2, but
breaks when -Os is used.

$ avr-gcc -c -Os  -mmcu=atmega328p  test2.c -o /dev/null

test2.c: In function 'getSlope':
test2.c:22:1: error: unable to find a register to spill in class
'POINTER_REGS'
 }
 ^
test2.c:22:1: error: this is the insn:
(insn 40 38 42 3 (set (reg:SF 63 [ D.1613 ])
(mem:SF (post_inc:HI (reg:HI 16 r16 [orig:73 ivtmp.13 ] [73]))
[1 MEM[base: _27, offset: 0B]+0 S4 A8])) /home/matthijs/test.c:15 100 {*movsf}
 (expr_list:REG_INC (reg:HI 16 r16 [orig:73 ivtmp.13 ] [73])
(nil)))
test2.c:22: confused by earlier errors, bailing out

[1]: https://github.com/arduino/Arduino/issues/3972

[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c   (revision 228753)
+++ gcc/tree-cfgcleanup.c   (working copy)
@@ -103,17 +103,22 @@ cleanup_control_expr_graph (basic_block
   edge e;
   edge_iterator ei;
   bool warned;
-  location_t loc;

   fold_defer_overflow_warnings ();
-  loc = gimple_location (stmt);
   switch (gimple_code (stmt))
{
case GIMPLE_COND:
- val = fold_binary_loc (loc, gimple_cond_code (stmt),
-boolean_type_node,
-gimple_cond_lhs (stmt),
-gimple_cond_rhs (stmt));
+ val = const_binop (gimple_cond_code (stmt),
+boolean_type_node,
+gimple_cond_lhs (stmt), gimple_cond_rhs (stmt));
+ if (!val)
+   {
+ tree tem = fold_binary (gimple_cond_code (stmt),
+ boolean_type_node,
+ gimple_cond_lhs (stmt),
+ gimple_cond_rhs (stmt));
+ gcc_assert (!tem || TREE_CODE (tem) != INTEGER_CST);
+   }
  break;

case GIMPLE_SWITCH:

fails in configuring stage2 gcc/ on

if (_12 < 0)

but probably because of your earlier patch now ... and with that disabled on

if (base.96 != base.96)

which is during CFG build in stage2 libcpp lex.c.  It's the GIMPLIFIERs
"CSE" producing

  :
  base.96 = base;
  base.96 = base;
  if (base.96 != base.96)

(see gimplify.c:lookup_tmp_var) and us not folding that stmt during
gimplification (the thing to fix).  Let's see how far I get with that ;)

[Bug tree-optimization/67953] [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r225195 :(.

[Bug tree-optimization/67953] New: [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign

[glisse at gcc dot gnu.org]

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

Bug ID: 67953
   Summary: [6 Regression] match.pd: X - (X / Y) * Y wrong on
change of sign
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

$ cat z.c
#include 
unsigned f(signed a){
  return (unsigned)a-((a/3)*3);
}
unsigned g(signed a){
  return a-((a/3)*3);
}
int main(){
  printf("%d %d\n", f(-5), g(-5));
}
$ gcc-5 z.c && ./a.out
-2 -2
$ clang z.c && ./a.out   
-2 -2
$ gcc-snapshot z.c && ./a.out 
2 -2

[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev  ---
Created attachment 36498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36498&action=edit
proposed patch

This patch cures run-time error for 416.gamess.

[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled

[ysrumyan at gmail dot com]

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

--- Comment #3 from Yuri Rumyantsev  ---
Check that guard edge is around the inner loop was missed. After adding it
416.gamess run successfully.
I sent the fix for review.

[Bug c++/67950] AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

--- Comment #5 from Hans Streibel  ---
Just noticed:
Adding an optimization flag -O1 or -O2 to g++ removes this bug (-O0 does not
help):

[root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/g++ -o tcpserver.4.9.3++ -O1 -Wall
tcpserver.c
[root@dev71 tmp]# ./tcpserver.4.9.3++ 1234
--> before accept() <--
--> accept() returned: 4 <--
fd after accept(): 4
abc
read 0 bytes from the socket. Socket is closed
--> before accept() <--

[Bug c++/67950] AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

--- Comment #4 from Hans Streibel  ---
Created attachment 36497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36497&action=edit
g++ preprocessed result

[Bug c++/67950] AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

--- Comment #3 from Hans Streibel  ---
Created attachment 36496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36496&action=edit
gcc preprocessed result

[Bug c++/67950] AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

--- Comment #2 from Hans Streibel  ---
Ok, here is the missing Information:

[root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.9.3-hans/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.9.3-hans/libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/lto-wrapper
Target: powerpc-ibm-aix7.1.0.0
Configured with: ./configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--prefix=/opt/gcc-4.9.3-hans --enable-languages=c,c++
--enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd
--host=powerpc-ibm-aix7.1.0.0
Thread model: aix
gcc version 4.9.3 (GCC)

Compiler warnings:
Beside the warnings that where already in the original post, there are no
warnings, even None with -W and -Wall

Preprocessed files:
- tcpserver.i (produced by gcc)
- tcpserver.ii (produced by g++)

[Bug other/62279] Demangler crash

[stanislav.angelovic at kistler dot com]

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

--- Comment #5 from Stanislav Angelovic  ---
(In reply to Mikhail Maltsev from comment #4)
> (In reply to Stanislav Angelovic from comment #3)
> > GDB 7.7.1 demangler crashes upon this symbol in our binary:
> > 
> > _ZSt7forwardIKSaINSt6thread5_ImplISt12_Bind_simpleIFZN6WIM_DL5Utils9AsyncTask
> > C4IMNS3_8Hardware12FpgaWatchdogEKFvvEIPS8_EEEibOT_DpOT0_EUlvE_vEESD_RNSt1
> > 6remove_referenceISC_E4typeE
> 
> Whis works fine with binutils 2.25 and gives:
> 
> std::allocator :AsyncTask WIM_DL::Hardware::FpgaWatchdog*>(int, bool, void
> (WIM_DL::Hardware::FpgaWatchdog::*&&)() const,
> WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const&&
> std::forward Utils::AsyncTask::AsyncTask const, WIM_DL::Hardware::FpgaWatchdog*>(int, bool,
> std::allocator :AsyncTask WIM_DL::Hardware::FpgaWatchdog*>(int, bool, void
> (WIM_DL::Hardware::FpgaWatchdog::*&&)() const,
> WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const&&,
> WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > >
> const>(std::remove_reference _Bind_simple (WIM_DL::Hardware::FpgaWatchdog::*)() const,
> WIM_DL::Hardware::FpgaWatchdog*>(int, bool, void
> (WIM_DL::Hardware::FpgaWatchdog::*&&)() const,
> WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const>::type&)
> 
> Could you try a newer version of GDB?

Thanks for the fast response, Mikhail. We use tools shipped with Yocto, so our
hands are tied to some extent. But I tried binutils 2.25 and there it works.
Thank you!

[Bug c++/61636] generic lambda "cannot call member function without object"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jens.auer at cgi dot com

--- Comment #14 from Jonathan Wakely  ---
*** Bug 67952 has been marked as a duplicate of this bug. ***

[Bug c++/67952] [C++14] Compilation error with boost::signals2 and generic lambda: cannot call member function without object

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Does look like another dup.

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

[Bug c++/67952] [C++14] Compilation error with boost::signals2 and generic lambda: cannot call member function without object

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
Summary|Compilation error with  |[C++14] Compilation error
   |boost::signals2 and generic |with boost::signals2 and
   |lambda: cannot call member  |generic lambda: cannot call
   |function without object |member function without
   ||object
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.2.0, 6.0

--- Comment #1 from Jonathan Wakely  ---
Nothing to do with Boost, so it doesn't need thousands of lines of Boost
headers to reproduce it:


template struct signal;

template
struct signal
{
  template
void connect(F f) { f( Args{}... ); }
};

class A
{
public:
A()
{
// these two work
sig2.connect( [this]() {f();} );
sig.connect( [this](auto x) {this->g(x);} );

// this does not work
sig.connect( [this](auto x) {g(x);} );
}


private:
void f();
void g(int);

signal sig;
signal sig2;
};

[Bug c++/67952] New: Compilation error with boost::signals2 and generic lambda: cannot call member function without object

[jens.auer at cgi dot com]

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

Bug ID: 67952
   Summary: Compilation error with boost::signals2 and generic
lambda: cannot call member function without object
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.auer at cgi dot com
  Target Milestone: ---

Created attachment 36495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36495&action=edit
Preprocessed source code

The following code doesn't compile with boost 1.59 and gcc 5.1, but with clang
3.6:

#include 

class A
{
public:
A()
{
// these two work
sig2.connect( [this]() {f();} );
sig.connect( [this](auto x) {this->g(x);} );

// this does not work
sig.connect( [this](auto x) {g(x);} );
}


private:
void f();
void g(int);

boost::signals2::signal sig;
boost::signals2::signal sig2;
};

The error message is
shadow.cpp: In instantiation of ‘A::A():: [with auto:2 = int]’:
/lhome1/auerj/opt/include/boost/function/function_template.hpp:153:11:  
required from ‘static void
boost::detail::function::void_function_obj_invoker1::invoke(boost::detail::function::function_buffer&, T0) [with FunctionObj =
A::A()::; R = void; T0 = int]’
/lhome1/auerj/opt/include/boost/function/function_template.hpp:934:38:  
required from ‘void boost::function1::assign_to(Functor) [with Functor =
A::A()::; R = void; T0 = int]’
/lhome1/auerj/opt/include/boost/function/function_template.hpp:722:7:  
required from ‘boost::function1::function1(Functor, typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
int>::type) [with Functor = A::A()::; R = void; T0 = int;
typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
int>::type = int]’
/lhome1/auerj/opt/include/boost/function/function_template.hpp:1071:16:  
required from ‘boost::function::function(Functor, typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
int>::type) [with Functor = A::A()::; R = void; T0 = int;
typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
int>::type = int]’
/lhome1/auerj/opt/include/boost/function/function_template.hpp:1126:5:  
required from ‘typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
boost::function&>::type boost::function::operator=(Functor) [with
Functor = A::A()::; R = void; T0 = int; typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
boost::function&>::type = boost::function&]’
/lhome1/auerj/opt/include/boost/signals2/detail/slot_template.hpp:160:24:  
required from ‘void boost::signals2::slot::init_slot_function(const F&) [with F = A::A()::;
SlotFunction = boost::function; R = void; Args = {int}]’
/lhome1/auerj/opt/include/boost/signals2/detail/slot_template.hpp:85:27:  
required from ‘boost::signals2::slot::slot(const F&)
[with F = A::A()::; SlotFunction = boost::function;
R = void; Args = {int}]’
shadow.cpp:13:45:   required from here
shadow.cpp:13:38: error: cannot call member function ‘void A::g(int)’ without
object
 sig.connect( [this](auto x) {g(x);} );

I think it is a compiler bug because adding the implicit this-> solves the
problem (see second connect).

My gcc version:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/lhome1/auerj/opt/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/lhome1/auerj/opt
--enable-languages=c,c++
Thread model: posix
gcc version 5.1.0 (GCC) 

I have attached the preprocessed output so it should be easy to reproduce the
issue.

It is probably a duplicate of 61636, but I such that it can be tracked as such.
I guess boost::signals2 is a popular library, so it may be worth to have it in
the database explicitly.

[Bug tree-optimization/67921] [6 Regression] "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r224020.

[Bug c++/67950] AIX: Illegal instruction in accept()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The output of building GCC is not very helpful, please see
https://gcc.gnu.org/bugs/

[Bug tree-optimization/67949] Regression in GCC-6.0.0's optimizer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I can't reproduce, with the current trunk I see

.p2align 4,,15
.globl  main
.type   main, @function
main:
.LFB11:
.cfi_startproc
movl$1, -4(%rsp)
movl-4(%rsp), %eax
xorl%eax, %eax
ret
.cfi_endproc
.LFE11:
.size   main, .-main
.globl  x110
.bss
.align 4
.type   x110, @object
.size   x110, 4
x110:
.zero   4

[Bug tree-optimization/67920] [6 Regression] wrong code with -O3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
This should be the same as PR67947 which has a testcase.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r228599 as well.

[Bug c++/67951] New: Wshadow for type inferenced (auto) lambda parameters

[jens.auer at cgi dot com]

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

Bug ID: 67951
   Summary: Wshadow for type inferenced (auto) lambda parameters
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.auer at cgi dot com
  Target Milestone: ---

int f()
{
auto l = [](int i) {};

int i=0;
l(i);

return i;
}

void h()
{
auto l = [](auto i) {};

int i=0;
l(i);
}

If compiled with "g++ -std=c++1y -Wshadow", I get a warning in h:
shadow.cpp:15:23: warning: declaration of ‘i’ shadows a previous local
[-Wshadow]
 auto l = [](auto i) {};
   ^
shadow.cpp:17:9: note: shadowed declaration is here
 int i=0;

I think this is wrong. If it is not wrong, it is inconsistent because there is
no warning in f().

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r228599, I think there's a dup somewhere...  likely PR67920.

[Bug c++/67950] New: AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

Bug ID: 67950
   Summary: AIX: Illegal instruction in accept()
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: streibel.2003 at gmx dot net
  Target Milestone: ---

Created attachment 36494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36494&action=edit
Output of the GCC build process (make)

I compiled GCC, Version 4.9.3 on an AIX 7.1 machine.
The output of the build process (make) is in the appendix.

A C test program which calls accept() works fine when compiled with gcc.
However it crashes within the accept() function when compiled with g++.
The crash happens as soon as a client connects to the server:

[root@dev71 tmp]# uname -a
AIX dev71 1 7 00F6C0A94C00
[root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/gcc -o tcpserver tcpserver.c
[root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/g++ -o tcpserver tcpserver.c
ld: 0711-768 WARNING: Object /tmp//ccy8CL9X.o, section 1, function .accept:
The branch at address 0x8a8 is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x7C691B78.
ld: 0711-768 WARNING: Object /tmp//ccy8CL9X.o, section 1, function .accept:
The branch at address 0x8a8 is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x7C691B78.
[root@dev71 tmp]# ./tcpserver 1234
--> before accept() <--
Illegal instruction (core dumped)
[root@dev71 tmp]#

A self compiled GCC, Version 4.9.1 Shows the same behaviour.
A GCC, Version 4.8.3 which we installed via an RPM package works fine.

[Bug tree-optimization/67476] Add --param parloops-schedule=

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue Oct 13 10:08:40 2015
New Revision: 228754

URL: https://gcc.gnu.org/viewcvs?rev=228754&root=gcc&view=rev
Log:
Handle original loop tree in expand_omp_for_generic

2015-10-13  Tom de Vries  

PR tree-optimization/67476
* omp-low.c (expand_omp_for_generic): Handle original loop tree.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug tree-optimization/67476] Add --param parloops-schedule=

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue Oct 13 10:08:59 2015
New Revision: 228756

URL: https://gcc.gnu.org/viewcvs?rev=228756&root=gcc&view=rev
Log:
Add param parloops-schedule

2015-10-13  Tom de Vries  

PR tree-optimization/67476
* doc/invoke.texi (@item parloops-schedule): New item.
* params.def (PARAM_PARLOOPS_SCHEDULE): New DEFPARAMENUM5.
* tree-parloops.c: Include params-enum.h.
(create_parallel_loop): Handle PARAM_PARLOOPS_SCHEDULE.

* testsuite/libgomp.c/autopar-3.c: New test.
* testsuite/libgomp.c/autopar-4.c: New test.
* testsuite/libgomp.c/autopar-5.c: New test.
* testsuite/libgomp.c/autopar-6.c: New test.
* testsuite/libgomp.c/autopar-7.c: New test.
* testsuite/libgomp.c/autopar-8.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/autopar-3.c
trunk/libgomp/testsuite/libgomp.c/autopar-4.c
trunk/libgomp/testsuite/libgomp.c/autopar-5.c
trunk/libgomp/testsuite/libgomp.c/autopar-6.c
trunk/libgomp/testsuite/libgomp.c/autopar-7.c
trunk/libgomp/testsuite/libgomp.c/autopar-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/params.def
trunk/gcc/tree-parloops.c
trunk/libgomp/ChangeLog