[Bug rtl-optimization/68205] [5 regression] ICE compiling gcc.c-torture/execute/20040709-2.c with -fno-common on arm-none-eabi

2015-11-05 Thread ramana at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68205

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.3
   Keywords||ice-on-valid-code
   Last reconfirmed||2015-11-05
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE compiling   |[5 regression] ICE
   |gcc.c-torture/execute/20040 |compiling
   |709-2.c with -fno-common on |gcc.c-torture/execute/20040
   |arm-none-eabi   |709-2.c with -fno-common on
   ||arm-none-eabi
  Known to fail||5.1.0

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed. Occurs only with -march=armv4t.  The -fno-common is key to trigger
this. 5.1 triggers it, 4.9 doesn't, so for now mark it probably as a 5
regression to flag up.

[Bug rtl-optimization/68217] Wrong constant folding

2015-11-05 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68217

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Ok, so combine should have used sign_extract here because of the comparison
code I think.

There is also a missed optimization in VRP as signed & sign-bit-CST should
result in a [-INF, 0] range, not a [-INF, INF] range as now.

[Bug fortran/53320] -fcheck=pointer should diagnose pointer-assignment of a noncontiguous tgt to a CONTIGUOUS ptr

2015-11-05 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53320

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Duplicate or pr49232?

[Bug fortran/68218] ALLOCATE with size given by a module function

2015-11-05 Thread anlauf at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68218

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
This jewel is really funny.

Extending the testcase in comment #0:

MODULE mo_test
  implicit none
  integer :: n = 0
CONTAINS
  FUNCTION nquery()
INTEGER :: nquery
n = n + 1
WRITE (0,*) "hello #", n
nquery = n
  END FUNCTION nquery
END MODULE mo_test
! --
! MAIN PROGRAM
! --
PROGRAM example
  USE mo_test
  implicit none
  INTEGER, ALLOCATABLE :: query_buf(:)
  ALLOCATE(query_buf(nquery()))
  print *, "n, size (query_buf) =", n, size (query_buf)
  if (n /= 1 .or. size (query_buf) /= n) print *, "ERROR!"
END PROGRAM example


one finds:

4.3, 4.6:

 hello #   1
 hello #   2
 hello #   3
 hello #   4
 n, size (query_buf) =   4   1
 ERROR!

4.7 and newer:

 hello #   1
 hello #   2
 hello #   3
 hello #   4
 n, size (query_buf) =   4   4
 ERROR!


Looking at the dump tree, there is no temporary generated for the function
result.

If one was interested only in the size of query_buf, this would be technically
a regression...

[Bug rtl-optimization/68217] Wrong constant folding

2015-11-05 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68217

Richard Biener  changed:

   What|Removed |Added

  Known to fail||4.1.2, 4.3.5

--- Comment #2 from Richard Biener  ---
Fails with just -O1 as well, --param max-combine-insns=2 "fixes" it, =3
"fails".
Thus it's triggered by a 3-insn combine:

Trying 9 -> 10:
Successfully matched this instruction:
(set (reg:CCNO 17 flags)
(compare:CCNO (and:DI (reg:DI 91 [ D.1848 ])
(reg:DI 93))
(const_int 0 [0])))
allowing combination of insns 9 and 10
original costs 4 + 4 = 8

Trying 7, 8 -> 10:
Successfully matched this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:DI (subreg:DI (reg:SI 87 [ D.1847 ]) 0)
(const_int 1 [0x1])
(const_int 31 [0x1f]))
(const_int 0 [0])))
Successfully matched this instruction:
(set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 15)
(pc)))
allowing combination of insns 7, 8 and 10
original costs 4 + 3 + 8 = 0
replacement cost 4

Before:

(insn 7 6 8 2 (set (reg:DI 91 [ D.1848 ])
(sign_extend:DI (reg:SI 87 [ D.1847 ]))) t.c:5 142 {*extendsidi2_rex64}
 (expr_list:REG_DEAD (reg:SI 87 [ D.1847 ])
(nil)))
(insn 8 7 9 2 (set (reg:DI 93)
(const_int -9223372036854775808 [0x8000])) t.c:5 89
{*movdi_internal}
 (nil))
(insn 9 8 10 2 (parallel [
(set (reg:DI 92 [ x ])
(and:DI (reg:DI 91 [ D.1848 ])
(reg:DI 93)))
(clobber (reg:CC 17 flags))
]) t.c:5 381 {*anddi_1}
 (expr_list:REG_DEAD (reg:DI 93)
(expr_list:REG_DEAD (reg:DI 91 [ D.1848 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (and:DI (reg:DI 91 [ D.1848 ])
(const_int -9223372036854775808 [0x8000]))
(nil))
(insn 10 9 11 2 (set (reg:CCNO 17 flags)
(compare:CCNO (reg:DI 92 [ x ])
(const_int 0 [0]))) t.c:5 4 {*cmpdi_ccno_1}
 (expr_list:REG_DEAD (reg:DI 92 [ x ])
(nil)))

After:

(note 7 6 8 2 NOTE_INSN_DELETED)
(note 8 7 9 2 NOTE_INSN_DELETED)
(note 9 8 10 2 NOTE_INSN_DELETED)
(insn 10 9 11 2 (set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:DI (subreg:DI (reg:SI 87 [ D.1847 ]) 0)
(const_int 1 [0x1])
(const_int 31 [0x1f]))
(const_int 0 [0]))) t.c:5 368 {*testqi_ext_3}
 (expr_list:REG_DEAD (reg:SI 87 [ D.1847 ])
(nil)))


The zero-extract is weird and the subreg should be the high-part?

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

2015-11-05 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216

--- Comment #2 from Dominique d'Humieres  ---
If this help, I have found the following PRs related to deferred-length:
pr49630, pr49954, pr50221, pr54070, pr55735, pr57735, pr57910, pr63932,
pr65677, pr66408, and pr67674. Will it worth opening a "meta-bug" for them? or
adding '[DL]' at the beginning of the summaries?

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

2015-11-05 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216

--- Comment #3 from Dominique d'Humieres  ---
Oops! read pr55735 instead of pr57735.

[Bug middle-end/57845] ICE with -freg-struct-return on SPARC

2015-11-05 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845

Eric Botcazou  changed:

   What|Removed |Added

Summary|ICE with|ICE with
   |-freg-struct-return on  |-freg-struct-return on
   |Sparc target|SPARC

--- Comment #3 from Eric Botcazou  ---
Because nobody is interested in fixing it but patches are welcome of course.

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

2015-11-05 Thread yba at tkos dot co.il 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099

--- Comment #10 from Jonathan Ben-Avraham  ---
(In reply to Marek Polacek from comment #9)
> I've built a cross-compiler for arm-linux-gnueabihf target and can't
> reproduce the issue with GCC trunk:
> 
> $ ./cc1plus  -I. /tmp/test.i -quiet -O3 -fsanitize=undefined -Wall -Wextra
> dog.cpp: In function ‘int main(int, char**)’:
> dog.cpp:31:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
> dog.cpp:31:31: warning: unused parameter ‘argv’ [-Wunused-parameter]
> 
> so I think this was really fixed in PR66977.
> 
> Hence closing, please reopen if you can reproduce with GCC trunk, or if you
> think I goofed something up, thanks.

Please post your configure command line for gcc and the svn revision number
that you used so that I can try to duplicate your success. I was not able to
build trunk rev 229474 using the same crosstool-ng .config that I used when
building the the GCC 5.1 for which I reported this bug. The error that I
received was

[INFO ]  Installing C library
[ERROR]strchrnul.c:72:40: error: result of '2130640638l << 16' requires 48
bits to represent, but 'long int' only has 32 bits [-Werror=shift-overflow=]
[ERROR]strchrnul.c:72:47: error: result of '-16908288l << 16' requires 42
bits to represent, but 'long int' only has 32 bits [-Werror=shift-overflow=]
[ERROR]make[3]: ***
[/opt/home/yba/gcc/crosstool-ng-gcc-rev-229474/.build/arm-mxs-linux-gnueabihf/build/build-libc-final/string/strchrnul.o]
Error 1
[ERROR]make[2]: *** [string/subdir_lib] Error 2
[ERROR]make[1]: *** [all] Error 2
[ERROR]   
[ERROR]  >>
[ERROR]  >>  Build failed in step 'Installing C library'
[ERROR]  >>called in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@257]
[ERROR]  >>called from:
do_libc_backend_once[scripts/build/libc/glibc.sh@456]
[ERROR]  >>called from:
do_libc_backend[scripts/build/libc/glibc.sh@153]
[ERROR]  >>called from: do_libc[scripts/build/libc/glibc.sh@75]
[ERROR]  >>called from: main[scripts/crosstool-NG.sh@638]
[ERROR]  >>
[ERROR]  >>  For more info on this error, look at the file: 'build.log'
[ERROR]  >>  There is a list of known issues, some with workarounds, in:
[ERROR]  >>  'usr/local/share/doc/crosstool-ng//B - Known issues.txt'
[ERROR]   
[ERROR]  (elapsed: 8:54.60)
[08:54] / make: *** [build] Error 2

Many thanks,

 - yba

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

2015-11-05 Thread yba at tkos dot co.il 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099

--- Comment #11 from Jonathan Ben-Avraham  ---
Created attachment 36652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36652=edit
tail -500 of build log for trunk rev 229474 showing build failure

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

2015-11-05 Thread yba at tkos dot co.il 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099

--- Comment #12 from Jonathan Ben-Avraham  ---
(In reply to Jonathan Ben-Avraham from comment #10)
> (In reply to Marek Polacek from comment #9)
> > I've built a cross-compiler for arm-linux-gnueabihf target and can't
> > reproduce the issue with GCC trunk:
> > 
> > $ ./cc1plus  -I. /tmp/test.i -quiet -O3 -fsanitize=undefined -Wall -Wextra
> > dog.cpp: In function ‘int main(int, char**)’:
> > dog.cpp:31:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
> > dog.cpp:31:31: warning: unused parameter ‘argv’ [-Wunused-parameter]
> > 
> > so I think this was really fixed in PR66977.
> > 
> > Hence closing, please reopen if you can reproduce with GCC trunk, or if you
> > think I goofed something up, thanks.
> 
> Please post your configure command line for gcc and the svn revision number
> that you used so that I can try to duplicate your success. I was not able to
> build trunk rev 229474 using the same crosstool-ng .config that I used when
> building the the GCC 5.1 for which I reported this bug. The error that I
> received was
> 
> [INFO ]  Installing C library
> [ERROR]strchrnul.c:72:40: error: result of '2130640638l << 16' requires
> 48 bits to represent, but 'long int' only has 32 bits
> [-Werror=shift-overflow=]
> [ERROR]strchrnul.c:72:47: error: result of '-16908288l << 16' requires
> 42 bits to represent, but 'long int' only has 32 bits
> [-Werror=shift-overflow=]
> [ERROR]make[3]: ***
> [/opt/home/yba/gcc/crosstool-ng-gcc-rev-229474/.build/arm-mxs-linux-
> gnueabihf/build/build-libc-final/string/strchrnul.o] Error 1
> [ERROR]make[2]: *** [string/subdir_lib] Error 2
> [ERROR]make[1]: *** [all] Error 2
> [ERROR]   
> [ERROR]  >>
> [ERROR]  >>  Build failed in step 'Installing C library'
> [ERROR]  >>called in step '(top-level)'
> [ERROR]  >>
> [ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@257]
> [ERROR]  >>called from:
> do_libc_backend_once[scripts/build/libc/glibc.sh@456]
> [ERROR]  >>called from:
> do_libc_backend[scripts/build/libc/glibc.sh@153]
> [ERROR]  >>called from: do_libc[scripts/build/libc/glibc.sh@75]
> [ERROR]  >>called from: main[scripts/crosstool-NG.sh@638]
> [ERROR]  >>
> [ERROR]  >>  For more info on this error, look at the file: 'build.log'
> [ERROR]  >>  There is a list of known issues, some with workarounds, in:
> [ERROR]  >>  'usr/local/share/doc/crosstool-ng//B - Known issues.txt'
> [ERROR]   
> [ERROR]  (elapsed: 8:54.60)
> [08:54] / make: *** [build] Error 2
> 
> Many thanks,
> 
>  - yba

See attached build.tail.xz for build log with failure notice

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

2015-11-05 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #9 from Marek Polacek  ---
I've built a cross-compiler for arm-linux-gnueabihf target and can't reproduce
the issue with GCC trunk:

$ ./cc1plus  -I. /tmp/test.i -quiet -O3 -fsanitize=undefined -Wall -Wextra
dog.cpp: In function ‘int main(int, char**)’:
dog.cpp:31:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
dog.cpp:31:31: warning: unused parameter ‘argv’ [-Wunused-parameter]

so I think this was really fixed in PR66977.

Hence closing, please reopen if you can reproduce with GCC trunk, or if you
think I goofed something up, thanks.

[Bug sanitizer/67941] calls on function pointer from a captureless lambda cause ubsan warning

2015-11-05 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67941

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.3
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed, I think.

[Bug other/19165] (Natural) language independent error / warning classification

2015-11-05 Thread dmalcolm at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

--- Comment #19 from David Malcolm  ---
Parsing textual gcc diagnostics is non-trivial.

FWIW, as noted on the gcc list, I had a go at creating an interchange format
for static analysis results (which includes compiler diagnostics).  The aim was
to run lots of static analyzers on lots of code, and capture the results in a
consistent format in a browseable database, hence the need for an interchange
format. [1] I created a format I call "Firehose":
  https://github.com/fedora-static-analysis/firehose
as a set of Python classes that can be roundtripped through XML and JSON.  It
currently provides parsers for the output of gcc, clang-analyzer, cppcheck, and
findbugs, and my gcc-python-plugin has a branch that can emit firehose reports
directly.

It can store more than just location+message: clang-analyzer can emit a series
of messages describing a trace of events leading to a bug, and firehose can
capture that (by reading the plist file).  We don't provide that yet from gcc,
but it might be worth thinking about.

The gcc diagnostic parser is here:
https://github.com/fedora-static-analysis/firehose/blob/master/firehose/parsers/gcc.py

with test cases:
https://github.com/fedora-static-analysis/firehose/blob/master/tests/parsers/test_gcc_parser.py

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

2015-11-05 Thread zeccav at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497

--- Comment #2 from Vittorio Zecca  ---
Traveling now, I cannot check it.

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

2015-11-05 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Started with r218985.

[Bug sanitizer/68100] runtime segfault ARM boost::regex_replace -fsanitize=undefined member access within misaligned address

2015-11-05 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68100

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-05
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Could you please provide the preprocessed source file, as usually?

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

2015-11-05 Thread joseph at codesourcery dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162

--- Comment #6 from joseph at codesourcery dot com  ---
On Thu, 5 Nov 2015, mpolacek at gcc dot gnu.org wrote:

> Started with r218985.

That's what I expected, but my analysis says that that change was OK and 
the underlying cause is incorrectly constructed array type tree nodes from 
Richard's older patch (r171245) (and fixing the array type construction, 
as in the patches I attached, fixes this bug but makes 
gcc.dg/debug/dwarf2/pr47939-4.c regress, for reasons I suspect are 
somewhere inside the DWARF output code).

[Bug sanitizer/65148] ICE: in get_biv_step, at loop-iv.c:823

2015-11-05 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65148

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
I guess fixed then.

[Bug middle-end/68215] [6 regression] FAIL: c-c++-common/opaque-vector.c -std=c++11 (internal compiler error)

2015-11-05 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68215

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/54262] LOC shouldn't use copy-in/copy-out

2015-11-05 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54262

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-05
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
The code in comment 0 compiles with 4.8.5, but gives an error

pr54262.f90:5:20:

   p = transfer (loc(x), p)
1
Error: Assumed-type argument at (1) is not permitted as actual argument to the
intrinsic loc

when compiled with 4.9.3 up to trunk (6.0).

The change occurred between revisions r199034 (2013-05-17, no error) and
r199221 (2013-05-22, error). The message has been introduced by revision
r199158 (pr57035).

[Bug fortran/68218] ALLOCATE with size given by a module function

2015-11-05 Thread vehre at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68218

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug other/19165] (Natural) language independent error / warning classification

2015-11-05 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

--- Comment #22 from Manuel López-Ibáñez  ---
(In reply to David Malcolm from comment #21)
> Our "column numbers" are also simply a byte-count, I believe, so a tab
> character is treated by us as simply an increment of 1 right now.
> 
> I guess this is a separate issue though.

There was a discussion in the mailing list not so long ago about this precise
issue and I think there were quite good ideas on how to fix this. I cannot find
the link, but if you do, would you mind adding it to
https://gcc.gnu.org/wiki/Better_Diagnostics under B) ?

I added PR49973, which is related to this.

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

2015-11-05 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Can you please check that it has not been fixed by r229153 for pr67939 (trunk
6.0) and r229555 (5.2.1)?

[Bug fortran/67123] ICE with source allocation

2015-11-05 Thread vehre at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67123
Bug 67123 depends on bug 66927, which changed state.

Bug 66927 Summary: [6 Regression] ICE in gfc_conf_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927

   What|Removed |Added

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

[Bug other/19165] (Natural) language independent error / warning classification

2015-11-05 Thread dmalcolm at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

--- Comment #20 from David Malcolm  ---
(In reply to Teodor Petrov from comment #15)
> I'm speaking as one of Code::Blocks' developers:
> If you implement this we'll for sure use it, because we have many complaints
> similar to the one Eclipse's developers have. 
> 
> (After one such complaint I've found this bug, by the way).
> 
> Some suggestions: 
> Don't pack the line/column info with the file name, if possible.
> So the proposed diagnostic from this:
>  location="/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c:10:8">
> inicializacin de un miembro de matriz flexible en un contexto anidado
> 
> 
> will turn in to this, which will be easier to parse:
>  location="/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c" line="10"
> column="8">
> inicializacin de un miembro de matriz flexible en un contexto anidado
> 

Indeed.

> Also, if it is possible group the notes/instances info with the
> error/warning messages. This way it will allows us to show the information
> in a better way.

FWIW, in the "firehose" gcc parser, I captured the warning's switch so e.g.
"num_get_float.cpp:535:29: warning: dereferencing type-punned pointer will
break strict-aliasing rules [-Wstrict-aliasing]"

has id="string-aliasing" as one of the captured attributes in the XML.

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

2015-11-05 Thread vehre at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #20 from vehre at gcc dot gnu.org ---
Given that 68108 is marked as fixed and there are no other complaints, I am
closing.

[Bug other/19165] (Natural) language independent error / warning classification

2015-11-05 Thread dmalcolm at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

--- Comment #21 from David Malcolm  ---
One other issue is that column numbering is rather a mess right now.  From my
rich-location patch:

/* Both gcc and emacs number source *lines* starting at 1, but
   they have differing conventions for *columns*.

   GCC uses a 1-based convention for source columns,
   whereas Emacs's M-x column-number-mode uses a 0-based convention.

   For example, an error in the initial, left-hand
   column of source line 3 is reported by GCC as:

  some-file.c:3:1: error: ...etc...

   On navigating to the location of that error in Emacs
   (e.g. via "next-error"),
   the locus is reported in the Mode Line
   (assuming M-x column-number-mode) as:

 some-file.c   10%   (3, 0)

   i.e. "3:1:" in GCC corresponds to "(3, 0)" in Emacs.  */

Our "column numbers" are also simply a byte-count, I believe, so a tab
character is treated by us as simply an increment of 1 right now.

I guess this is a separate issue though.

[Bug c++/67846] ICE on code with lambda expression on x86_64-linux-gnu in check_return_expr, at cp/typeck.c:8609

2015-11-05 Thread paolo.carlini at oracle dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67846

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Fixed.

[Bug middle-end/57845] ICE with -freg-struct-return on SPARC

2015-11-05 Thread sorganov at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845

--- Comment #4 from Sergey Organov  ---
"WONTFIX: The problem described is a bug which will never be fixed." sounds
very different from "nobody is interested in fixing it but  but patches are
welcome". No?

Anyway, setting RESOLVED WONTFIX on an ICE sounds like bad idea in general. Is
there some agreement between gcc developers about it?

[Bug middle-end/68215] [6 regression] FAIL: c-c++-common/opaque-vector.c -std=c++11 (internal compiler error)

2015-11-05 Thread ienkovich at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68215

--- Comment #1 from Ilya Enkovich  ---
It is reproducible without vector comparison on older compilers.  Here is a
smaller reproducer:

long double v __attribute__((vector_size(16)));
__typeof((v

[Bug ipa/68220] [5/6 Regression] Devirtualization ICE in record_target_from_binfo, at ipa-devirt.c:2389

2015-11-05 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220

--- Comment #2 from Markus Trippelsdorf  ---
Created attachment 36654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36654=edit
somewhat reduced testcase

[Bug ipa/68035] [5/6 Regression] ipa performance issue when no procedures are present

2015-11-05 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68035

--- Comment #2 from Martin Liška  ---
Created attachment 36655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36655=edit
Suggested patch

Hello.

Following patch should correctly force calculation of hash values that are
different for all variables and no O(n^2) comparison is processed.

Could you Neil test the patch on the whole source file before I'm going to send
the patch to mailing list?

Thanks,
Martin

[Bug libstdc++/68222] New: _Safe_iterator provides operators the wrapped iterator can't actually support

2015-11-05 Thread TonyELewis at hotmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68222

Bug ID: 68222
   Summary: _Safe_iterator provides operators the wrapped iterator
can't actually support
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: TonyELewis at hotmail dot com
  Target Milestone: ---

It would be very helpful if the _Safe_iterator wrapper disabled operators, such
as non-member operator-(), that aren't actually supported by the wrapped
iterator type. Since the non-member operator-() is well formed, modern iterator
 code might reasonably choose to enable code that uses it but this will result
in a compile error. One example of this cropping up:

https://github.com/ericniebler/range-v3/issues/231

This issue is illustrated in the following code:

// Turn debug mode on
#define _GLIBCXX_DEBUG

#include 
#include 

template  void ignore_unused(const Ts &...);

int main() {
// A list of int
const std::list nums = { 1, 2, 3, 4 };

// Grab the iterator type (which is
_Safe_iterator<_List_const_iterator, list >)
using list_itr_type = decltype( std::cbegin( nums ) );
// TD bob;

// Confirm cend returns the same type
static_assert( std::is_same< decltype( std::cend( nums ) ),
list_itr_type >::value, "" );

// The list's iterator type provides a well-formed non-member
operator-() with valid return type (long int)
using subtraction_return_type = decltype( std::declval()
- std::declval() );
static_assert( std::is_same< subtraction_return_type, long int
>::value, "" );

// Yet an attempt to actually fails to compile because the wrapped list
iterator
// doesn't support operator-()
const auto fail_here = std::cend( nums ) - std::begin( nums );
ignore_unused( fail_here );

return 0;
}


// Command : g++ -std=c++14 -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations safe_itr_prob.cpp
// STL : GNU libstdc++ version 20151010 (
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 )
// Compiler: GNU C++ version 5.2.1 20151010
// OS  : Ubuntu 15.10 (Linux 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8
15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux)

[Bug target/68192] AIX libstdc++ TLS symbols not exported

2015-11-05 Thread dje at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192

David Edelsohn  changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
   Assignee|unassigned at gcc dot gnu.org  |dje at gcc dot gnu.org
   Severity|normal  |critical

[Bug c++/67846] ICE on code with lambda expression on x86_64-linux-gnu in check_return_expr, at cp/typeck.c:8609

2015-11-05 Thread paolo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67846

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Nov  5 16:47:40 2015
New Revision: 229819

URL: https://gcc.gnu.org/viewcvs?rev=229819=gcc=rev
Log:
/cp
2015-11-05  Paolo Carlini  

PR c++/67846
* parser.c (cp_parser_lambda_body): Check lambda_return_type
return value.
* typeck2.c (cxx_incomplete_type_diagnostic): Print member or
member function used invalidly.

/testsuite
2015-11-05  Paolo Carlini  

PR c++/67846
* g++.dg/cpp0x/lambda/lambda-ice15.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/68220] [5/6 Regression] Devirtualization ICE in record_target_from_binfo, at ipa-devirt.c:2389

2015-11-05 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka  ---
Mine.

[Bug ipa/68220] [5/6 Regression] Devirtualization ICE in record_target_from_binfo, at ipa-devirt.c:2389

2015-11-05 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220

--- Comment #4 from Jan Hubicka  ---
OK, we have:

(gdb) p context
$4 = {offset = 0, speculative_offset = 96, outer_type = 0x76c77c78,
speculative_outer_type = 0x76cd5348, maybe_in_construction = 1,
maybe_derived_type = 1, 
  speculative_maybe_derived_type = 1, invalid = 0, dynamic = 1}

and the code gets lost in analyzing speculative_outer_type, because there is
simply no binfo on the address:

  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set 3 canonical type 0x76cd5348
fields 
public unsigned DI size  unit size

align 64 symtab 0 alias set 4 canonical type 0x76c34540>
unsigned virtual DI file /aux/hubicka/t.C line 225 col 8 size
 unit size 
align 64 offset_align 128
offset 
bit offset  context 
chain 
used nonlocal decl_4 VOID file /aux/hubicka/t.C line 225 col 17
align 1 context  result

   >> context 
full-name "struct Fragment"
needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=0
use_template=0 interface-only
pointer_to_this  reference_to_this
 chain >

Well, the type is simply too small. The assert is simply too overactive, but
restrict_to_inner_type could probably drop the info when it knows the offset is
off the range.

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

2015-11-05 Thread joseph at codesourcery dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162

--- Comment #8 from joseph at codesourcery dot com  ---
I don't know what DWARF semantics are meant to be, but the language 
semantics are definitely that in C array types are always unqualified, 
whereas in C++, while the qualifiers still apply to the element type, the 
array type is also considered qualified for most/all purposes.

> When I just not do that main variant punning here I get
> 
>  <1><60>: Abbrev Number: 10 (DW_TAG_variable)
> <61>   DW_AT_name: (indirect string, offset: 0x7b): harry
> <65>   DW_AT_decl_file   : 1
> <66>   DW_AT_decl_line   : 5
> <67>   DW_AT_type: <0x75>
> ...
>  <1><75>: Abbrev Number: 6 (DW_TAG_const_type)
> <76>   DW_AT_type: <0x49>
>  <1><49>: Abbrev Number: 7 (DW_TAG_array_type)
> <4a>   DW_AT_type: <0x39>
> <4e>   DW_AT_sibling : <0x59>
>  <1><39>: Abbrev Number: 5 (DW_TAG_typedef)
> <3a>   DW_AT_name: (indirect string, offset: 0x0): Harry_t
> <3e>   DW_AT_decl_file   : 1
> <3f>   DW_AT_decl_line   : 4
> <40>   DW_AT_type: <0x44>
> 
> instead.  Not sure about that "extra" const qualifier on the array type
> though.

Does the extra qualifier come from decl_quals extracting qualifiers from a 
decl to combine with those for the type?  My guess would be that such code 
for extracting qualifiers is a legacy of when, a long time ago (before 
), the types of 
decls in the C and C++ front ends did not include top-level qualifiers, 
and so should be obsolete now.

[Bug target/57845] ICE with -freg-struct-return on SPARC

2015-11-05 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2015-11-05
  Component|middle-end  |target
 Resolution|WONTFIX |---
 Ever confirmed|0   |1

--- Comment #5 from Eric Botcazou  ---
> "WONTFIX: The problem described is a bug which will never be fixed." sounds
> very different from "nobody is interested in fixing it but  but patches are
> welcome". No?

No, the latter implies the former in 99% of the cases.

> Anyway, setting RESOLVED WONTFIX on an ICE sounds like bad idea in general.

We should indeed sorry out given that the option used to be accepted.

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

2015-11-05 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #8 from Jan Hubicka  ---
I will take a look. Noticed it only now.
Honza

[Bug ipa/68220] [5/6 Regression] Devirtualization ICE in record_target_from_binfo, at ipa-devirt.c:2389

2015-11-05 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220

--- Comment #5 from Jan Hubicka  ---
I am testing the following. This bug crept in when adding the dynamic types:
Index: ipa-polymorphic-call.c
===
--- ipa-polymorphic-call.c  (revision 229820)
+++ ipa-polymorphic-call.c  (working copy)
@@ -154,6 +154,8 @@ ipa_polymorphic_call_context::restrict_t
   && tree_to_shwi (TYPE_SIZE (outer_type)) >= 0
   && tree_to_shwi (TYPE_SIZE (outer_type)) <= offset)
{
+ bool der = maybe_derived_type; /* clear_outer_type will reset it.  */
+ bool dyn = dynamic;
  clear_outer_type (otr_type);
  type = otr_type;
  cur_offset = 0;
@@ -162,7 +164,7 @@ ipa_polymorphic_call_context::restrict_t
For dynamic types, we really do not have information about
size of the memory location.  It is possible that completely
different type is stored after outer_type.  */
- if (!maybe_derived_type && !dynamic)
+ if (!der && !dyn)
{
 clear_speculation ();
 invalid = true;
@@ -467,6 +469,7 @@ contains_type_p (tree outer_type, HOST_W
   context.offset = offset;
   context.outer_type = TYPE_MAIN_VARIANT (outer_type);
   context.maybe_derived_type = false;
+  context.dynamic = false;
   return context.restrict_to_inner_class (otr_type, consider_placement_new,
consider_bases);
 }

[Bug c/68090] VLA compound literal -- "confused by earlier errors, bailing out"

2015-11-05 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68090

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 6.

[Bug target/68223] [arm] arm_[su]min_cmp pattern fails

2015-11-05 Thread michael.collison at linaro dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68223

Michael Collison  changed:

   What|Removed |Added

 Target||armeb-none-linux-gnueabihf

--- Comment #1 from Michael Collison  ---
Although the pattern fails under armeb-none-linux-gnueabihf it will also fail
on little endian arm targets. It just so happens that the pattern is not
utilized for the test cases that fail under big endian targets

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

2015-11-05 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

--- Comment #9 from Jan Hubicka  ---
Patch posted to PR68220

[Bug c/68090] VLA compound literal -- "confused by earlier errors, bailing out"

2015-11-05 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68090

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Thu Nov  5 18:21:30 2015
New Revision: 229823

URL: https://gcc.gnu.org/viewcvs?rev=229823=gcc=rev
Log:
PR c/68090
* c-parser.c (c_parser_postfix_expression_after_paren_type): Don't
deal with pre-evaluation on invalid types.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr68090.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/65963] Missed vectorization of loads strided with << when equivalent * succeeds

2015-11-05 Thread alalaw01 at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65963

--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Thu Nov  5 18:39:38 2015
New Revision: 229825

URL: https://gcc.gnu.org/viewcvs?rev=229825=gcc=rev
Log:
[PATCH] tree-scalar-evolution.c: Handle LSHIFT by constant

gcc/:

PR tree-optimization/65963
* tree-scalar-evolution.c (interpret_rhs_expr): Try to handle
LSHIFT_EXPRs as equivalent unsigned MULT_EXPRs.

gcc/testsuite/:

* gcc.dg/pr68112.c: New.
* gcc.dg/vect/vect-strided-shift-1.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr68112.c
trunk/gcc/testsuite/gcc.dg/vect/vect-strided-shift-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-scalar-evolution.c

[Bug target/68223] New: [arm] arm_[su]min_cmp pattern fails

2015-11-05 Thread michael.collison at linaro dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68223

Bug ID: 68223
   Summary: [arm] arm_[su]min_cmp pattern fails
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.collison at linaro dot org
  Target Milestone: ---

The patterns arm_smin_cmp and arm_umin_cmp which were added to optimize code
such as

#define min(x, y) ((x) <= (y)) ? (x) : (y)

unsigned int foo (unsigned int i, unsigned int x ,unsigned int y)
{
  return i < (min (x, y));
}

fail if (i == x) and both are less than y.

Three test cases in testsuite/gcc.dg/vect  

vect-reduc-7.c
vect-reduc-8.c
vect-reduc-9.c

fail execution tests configure with target armeb-none-linux-gnueabihf.

The solution is to remove the patterns from arm.md.

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

2015-11-05 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

--- Comment #10 from Jan Hubicka  ---
Hmm, the patch does not fix this testcase. I will analyze it.

[Bug target/68228] New: __builtin_ia32_pbroadcastd256 generates wrong insn at >= -O1

2015-11-05 Thread mirq-gccboogs at rere dot qmqm.pl 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68228

Bug ID: 68228
   Summary: __builtin_ia32_pbroadcastd256 generates wrong insn at
>= -O1
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mirq-gccboogs at rere dot qmqm.pl
  Target Milestone: ---

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

__builtin_ia32_pbroadcastd256() generates VBROADCASTSS instead of VPBROADCASTD
with optimization turned on. At -O0 there's a lot of useless moving data
to/from stack, but in the end the correct VPBROADCASTD is issued.

command line: gcc -march=core-avx2 -O1 -S test.c

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

[Bug debug/68229] .debug_pubnames length field is too large

2015-11-05 Thread todd.allen at ccur dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68229

--- Comment #1 from Todd Allen  ---
Created attachment 36660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36660=edit
Patch to correct gcc 4.8.2

This patch was against gcc-4.8.2-16.2.el7_0 from RHEL 7.0.  But it should be
pretty clear how it applies to vanilla gcc.  In fact, it might just apply with
slight line number differences.

[Bug target/57845] ICE with -freg-struct-return on SPARC

2015-11-05 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845

--- Comment #7 from Eric Botcazou  ---
> Contrary to the rationale for closing this bug, the option
> -freg-struct-return seems to be supported and does work fine in some cases,
> see below. What do I miss?

That it works in some cases doesn't mean that it is supported.  Did you try to
compile more than toy examples with the 3.4.4 compiler?

[Bug debug/68229] .debug_pubnames length field is too large

2015-11-05 Thread todd.allen at ccur dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68229

--- Comment #2 from Todd Allen  ---
Yeah, the patch code is clumsy.  I wrote it that way to mirror the use of a
continue in output_pubnames().

[Bug fortran/68225] ICE with -Wrealloc-lhs-all on structure constructor with allocatable components

2015-11-05 Thread gerhard.steinmetz.fort...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68225

--- Comment #2 from Gerhard Steinmetz  
---
Here, one or both components are initialized :

$ cat z1.f90
program p
   type t
  integer, allocatable :: a
   end type
   type, extends(t) :: t2
  integer, allocatable :: b
   end type
   type(t2) :: x
   x = t2(1)
   print *, allocated(x%a), x%a
   print *, allocated(x%b), x%b
end

$ gfortran -g -O0 -Wall -Wrealloc-lhs-all z1.f90
...
in gfc_format_decoder, at fortran/error.c:1124

---

$ cat z2.f90
program p
   type t
  integer, allocatable :: a
   end type
   type, extends(t) :: t2
  integer, allocatable :: b
   end type
   type(t2) :: x
   x = t2(1, 2)
   print *, allocated(x%a), x%a
   print *, allocated(x%b), x%b
end


$ gfortran -g -O0 -Wall -Wrealloc-lhs-all z2.f90
z2.f90:9:13:

x = t2(1, 2)
 1
Warning: Code for reallocating the allocatable variable at (1) will be added
[-Wrealloc-lhs-all]

# ... or ...
$ gfortran -g -O0 -Wall -fcheck=all z1.f90
# ... or ...
$ gfortran -g -O0 -Wall -fcheck=all z2.f90
# ...
# generate a binary a.out -- that always signals SIGSEGV.


$ a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x2B6933228507
#1  0x2B6933227700
#2  0x2B6933CB91FF
#3  0x2B69332F4550
#4  0x2B69332F7DED
#5  0x2B69332F982E
#6  0x400AB4 in p at z2.f90:10 (discriminator 6)
Segmentation fault

[Bug debug/68229] New: .debug_pubnames length field is too large

2015-11-05 Thread todd.allen at ccur dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68229

Bug ID: 68229
   Summary: .debug_pubnames length field is too large
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: todd.allen at ccur dot com
  Target Milestone: ---

Created attachment 36659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36659=edit
Example program

For C programs that use system header files (those rarities :) the length field
of .debug_pubnames is too large.  Obviously, this requires -gpubnames.

The problem occurs if there are enum types in the system header files that are
not marked for emission in the object file.  size_of_pubnames() still counts
them, but output_pubnames() does not emit them.  So the size ends up being too
large.

This is a big problem for dwarf readers because, when reading a linked
executable, they will use the length field for the contribution from one object
file to determine the location of the contribution for the next object file. 
If it's wrong, they can skip whole contributions and possibly (likely) end up
at a random byte in the middle of some subsequent contribution.

I'll include an example.  This example is small enough that the result is that
the contribution from the second object file is skipped entirely and it
overruns the end of the section.  It would require a few more object files
before there was enough material for it to end up in the middle of a subsequent
contribution.

[Bug target/68228] __builtin_ia32_pbroadcastd256 generates wrong insn at >= -O1

2015-11-05 Thread mirq-gccboogs at rere dot qmqm.pl 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68228

--- Comment #1 from Micha³ Miros³aw  ---
Created attachment 36657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36657=edit
gcc assembler output for -O1

[Bug target/68228] __builtin_ia32_pbroadcastd256 generates wrong insn at >= -O1

2015-11-05 Thread mirq-gccboogs at rere dot qmqm.pl 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68228

--- Comment #2 from Micha³ Miros³aw  ---
Created attachment 36658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36658=edit
gcc assembler output for -O0

[Bug fortran/68224] ICE on referencing parameter array with dimension null

2015-11-05 Thread gerhard.steinmetz.fort...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68224

--- Comment #1 from Gerhard Steinmetz  
---
Detected when assignment is separated from declaration :

$ cat z6.f90
program p
   integer, parameter :: c(null()) = [1, 2]
   integer :: a, b
   a = c(1)
   b = c(2)
end

$ gfortran -g -O0 -Wall -fcheck=all z6.f90
z6.f90:2:27:

integer, parameter :: c(null()) = [1, 2]
   1
Error: Expression at (1) must be of INTEGER type, found UNKNOWN
z6.f90:2:34:

integer, parameter :: c(null()) = [1, 2]
  1
Error: Parameter array 'c' at (1) cannot be automatic or of deferred shape

[Bug target/57845] ICE with -freg-struct-return on SPARC

2015-11-05 Thread sorganov at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845

--- Comment #6 from Sergey Organov  ---
Contrary to the rationale for closing this bug, the option -freg-struct-return
seems to be supported and does work fine in some cases, see below. What do I
miss?

$ cat struct.c
typedef struct { int i; } T;

T f(int i)
{
  T r;
  r.i = i;
  return r;
}
$ ~/try/sparc-elf-5.2.0/bin/sparc-elf-gcc -O2 -freg-struct-return -save-temps
-c struct.c
$ cat struct.s
.file   "struct.c"
.section".text"
.align 4
.global f
.type   f, #function
.proc   010
f:
jmp %o7+8
 nop
.size   f, .-f
.ident  "GCC: (GNU) 5.2.0"
$ ~/try/sparc-elf-5.2.0/bin/sparc-elf-gcc -O2 -save-temps -c struct.c
$ cat struct.s
.file   "struct.c"
.section".text"
.align 4
.global f
.type   f, #function
.proc   010
f:
ld  [%sp+64], %g1
st  %o0, [%g1]
jmp %o7+12
 mov%g1, %o0
.size   f, .-f
.ident  "GCC: (GNU) 5.2.0"
$

[Bug fortran/68226] ICE on wrong assignment of function pointer to allocatable

2015-11-05 Thread gerhard.steinmetz.fort...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68226

--- Comment #1 from Gerhard Steinmetz  
---
As a note, a correct code compiles and works :


$ cat z1ok.f90
program p
   type t
  integer :: n
   end type
   type(t), pointer :: a(:)
   a => f()
   print *, a
contains
   function f() result(r)
  class(t), pointer :: r(:)
  type(t), target :: b(2) = [t(1), t(2)]
  r => b
   end
end


$ gfortran -g -O0 -Wall -fcheck=all z1ok.f90
$ a.out
   1   2

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

2015-11-05 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67942

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Nov  5 21:42:10 2015
New Revision: 229827

URL: https://gcc.gnu.org/viewcvs?rev=229827=gcc=rev
Log:
PR c++/67942 - diagnose placement new buffer overflow

gcc/
* invoke.texi (-Wplacement-new): Document new option.
* gcc/testsuite/g++.dg/warn/Wplacement-new-size.C: New test.

gcc/c-family/
* c.opt (-Wplacement-new): New option.

gcc/cp/
* cp/init.c (warn_placement_new_too_small): New function.
(build_new_1): Call it.

gcc/testsuite/
* g++.dg/warn/Wplacement-new-size.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wplacement-new-size.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68224] New: ICE on referencing parameter array with dimension null

2015-11-05 Thread gerhard.steinmetz.fort...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68224

Bug ID: 68224
   Summary: ICE on referencing parameter array with dimension null
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Referencing a parameter array with dimension null :

$ cat z1.f90
program p
   integer, parameter :: c(null()) = [1, 2]
   integer, parameter :: a = c(1)
   integer :: b = c(2)
end

$ gfortran -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: in find_array_element, at fortran/expr.c:1222

[Bug fortran/68225] New: ICE with -Wrealloc-lhs-all on structure constructor with allocatable components

2015-11-05 Thread gerhard.steinmetz.fort...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68225

Bug ID: 68225
   Summary: ICE with -Wrealloc-lhs-all on structure constructor
with allocatable components
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This case aborts with option -Wrealloc-lhs-all :

$ cat y0.f90
program p
   type t
  integer, allocatable :: a
   end type
   type(t) :: x
   x = t()
   print *, allocated(x%a), x%a
end


$ gfortran -g -O0 -Wall -Wrealloc-lhs-all y0.f90

y0.f90:6:0:

x = t()
 1
in gfc_format_decoder, at fortran/error.c:1124


---

Without -Wrealloc-lhs-all :

$ gfortran -g -O0 -Wall -fcheck=all -Wrealloc-lhs y0.f90
$ a.out
 T   0


Note, F2008 4.5.10 specifies : If an allocatable component has
no corresponding component-data-source, then that component has
an allocation status of unallocated.

[Bug fortran/68225] ICE with -Wrealloc-lhs-all on structure constructor with allocatable components

2015-11-05 Thread gerhard.steinmetz.fort...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68225

--- Comment #1 from Gerhard Steinmetz  
---
Adding one type extension :

$ cat z0.f90
program p
   type t
  integer, allocatable :: a
   end type
   type, extends(t) :: t2
  integer, allocatable :: b
   end type
   type(t2) :: x
   x = t2()
   print *, allocated(x%a), x%a
   print *, allocated(x%b), x%b
end


$ gfortran -g -O0 -Wall -Wrealloc-lhs-all z0.f90

z0.f90:9:0:

x = t2()
 1
in gfc_format_decoder, at fortran/error.c:1124


---

$ gfortran -g -O0 -Wall -fcheck=all z0.f90
$ a.out
 F   0
 T   0


Note that allocation status is different.

[Bug fortran/68226] New: ICE on wrong assignment of function pointer to allocatable

2015-11-05 Thread gerhard.steinmetz.fort...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68226

Bug ID: 68226
   Summary: ICE on wrong assignment of function pointer to
allocatable
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This wrong code :

$ cat z1.f90
program p
   type t
  integer :: n
   end type
   type(t), allocatable :: a(:)
   a = f()
contains
   function f() result(r)
  class(t), pointer :: r(:)
  type(t), target :: b(2) = [t(1), t(2)]
  r => b
   end
end


$ gfortran -g -O0 -Wall -fcheck=all z1.f90
z1.f90:6:7:

a = f()
   1
Warning: POINTER-valued function appears on right-hand side of assignment at
(1) [-Wsurprising]
z1.f90:6:0:

a = f()
 1
internal compiler error: in gfc_trans_arrayfunc_assign, at
fortran/trans-expr.c:8315

[Bug fortran/68227] New: ICE on using variable limit in forall header (gfc_do_allocate)

2015-11-05 Thread gerhard.steinmetz.fort...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68227

Bug ID: 68227
   Summary: ICE on using variable limit in forall header
(gfc_do_allocate)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code with variable n :

$ cat y2.f90
program p
   type t
   end type
   type t2
  type(t), pointer :: a
   end type

   type(t), target :: x
   type(t2), pointer :: y(:)
   integer :: i
   integer :: n = 2

   allocate (y(n))
   forall (i=1:n) y(i)%a = x
end


$ gfortran -g -O0 -Wall -fcheck=all y2.f90
y2.f90:14:0:

forall (i=1:n) y(i)%a = x
 1
internal compiler error: in gfc_do_allocate, at fortran/trans-stmt.c:3121

[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)

2015-11-05 Thread gerhard.steinmetz.fort...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68227

--- Comment #1 from Gerhard Steinmetz  
---
Of course, above code works with :
   forall (i=1:n) y(i)%a => x


But it works too, if above n is replaced with literal value 2 :

$ cat y3.f90
program p
   type t
   end type
   type t2
  type(t), pointer :: a
   end type

   type(t), target :: x
   type(t2), pointer :: y(:)
   integer :: i

   allocate (y(2))
   forall (i=1:2) y(i)%a = x   !

   print *, y(1)%a
   print *, y(2)%a
end


$ gfortran -g -O0 -Wall -fcheck=all y3.f90
$ a.out

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

2015-11-05 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67942

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Committed in revision 229827.

[Bug tree-optimization/66324] GOACC_parallel is optimization barrier

2015-11-05 Thread vries at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66324

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from vries at gcc dot gnu.org ---
With foffload-alias committed to gomp-4_0-branch, this is no longer an issue.
Marking resolved-worksforme.

[Bug bootstrap/68231] AIX bootstrap failure after GOMP 4.5 merge

2015-11-05 Thread dje at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68231

--- Comment #3 from David Edelsohn  ---
(gdb) where
#0  _Z11fancy_abortPKciS0_ (
file=0x1259d104  "/nasfarm/edelsohn/src/src/gcc/tree.c", 
line=7297, function=0x125a1140  "tree_to_shwi")
at /nasfarm/edelsohn/src/src/gcc/diagnostic.c:1208
#1  0x1014ca34 in _Z12tree_to_shwiPK9tree_node (t=0x0)
at /nasfarm/edelsohn/src/src/gcc/tree.c:7297
#2  0x1091bf1c in _ZL28warn_placement_new_too_smallP9tree_nodeS0_S0_S0_ (
type=0x70941480, nelts=0x0, size=0x7062e540, oper=0x70a4de70)
at /nasfarm/edelsohn/src/src/gcc/cp/init.c:2392
#3  0x1091e254 in _ZL11build_new_1PP3vecIP9tree_node5va_gc8vl_embedES1_S1_S6_bi
(placement=0x2ff218d0, type=0x70941480, nelts=0x0, init=0x2ff218d4, 
globally_qualified_p=false, complain=3)
at /nasfarm/edelsohn/src/src/gcc/cp/init.c:2877
#4  0x1091f63c in _Z9build_newPP3vecIP9tree_node5va_gc8vl_embedES1_S1_S6_ii (
placement=0x2ff218d0, type=0x70941480, nelts=0x0, init=0x2ff218d4, 
use_global_new=0, complain=3)
at /nasfarm/edelsohn/src/src/gcc/cp/init.c:3314
#5  0x10bf3484 in _ZL24cp_parser_new_expressionP9cp_parser (parser=0x7058)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:7847
#6  0x10bf29ec in _ZL26cp_parser_unary_expressionP9cp_parserP10cp_id_kindbbb (
parser=0x7058, pidk=0x0, address_p=false, cast_p=false, 
decltype_p=false) at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:7502
#7  0x10bf42b8 in _ZL25cp_parser_cast_expressionP9cp_parserbbbP10cp_id_kind (
parser=0x7058, address_p=false, cast_p=false, decltype_p=false, 
pidk=0x0) at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:8361
#8  0x10bf43c8 in
_ZL27cp_parser_binary_expressionP9cp_parserbbb14cp_parser_precP10cp_id_kind
(parser=0x7058, cast_p=false, no_toplevel_fold_p=false, 
decltype_p=false, prec=PREC_NOT_OPERATOR, pidk=0x0)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:8463
#9  0x10bf50fc in
_ZL31cp_parser_assignment_expressionP9cp_parserP10cp_id_kindbb
(parser=0x7058, pidk=0x0, cast_p=false, decltype_p=false)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:8726
#10 0x10bf5580 in _ZL20cp_parser_expressionP9cp_parserP10cp_id_kindbb (
parser=0x7058, pidk=0x0, cast_p=false, decltype_p=false)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:8885
#11 0x10bf8bdc in _ZL30cp_parser_expression_statementP9cp_parserP9tree_node (
parser=0x7058, in_statement_expr=0x0)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:10317
#12 0x10bf8698 in
_ZL19cp_parser_statementP9cp_parserP9tree_nodebPbP3vecIS2_7va_heap6vl_ptrE
(parser=0x7058, in_statement_expr=0x0, in_compound=true, 
if_p=0x0, chain=0x0) at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:10168
#13 0x10bf9258 in _ZL27cp_parser_statement_seq_optP9cp_parserP9tree_node (
parser=0x7058, in_statement_expr=0x0)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:10440
#14 0x10bf90b4 in _ZL28cp_parser_compound_statementP9cp_parserP9tree_nodeib (
parser=0x7058, in_statement_expr=0x0, bcs_flags=0, function_body=false)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:10394
#15 0x10bfbf44 in
_ZL37cp_parser_implicitly_scoped_statementP9cp_parserPbRK17token_indent_infoP3vecIP9tree_node7va_heap6vl_ptrE
(parser=0x7058, 
if_p=0x2ff21ec4, guard_tinfo=..., chain=0x0)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:11534
#16 0x10bf9490 in
_ZL29cp_parser_selection_statementP9cp_parserPbP3vecIP9tree_node7va_heap6vl_ptrE
(parser=0x7058, if_p=0x0, chain=0x0)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:10522
#17 0x10bf8364 in
_ZL19cp_parser_statementP9cp_parserP9tree_nodebPbP3vecIS2_7va_heap6vl_ptrE
(parser=0x7058, in_statement_expr=0x0, in_compound=true, 
if_p=0x0, chain=0x0) at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:10024
#18 0x10bf9258 in _ZL27cp_parser_statement_seq_optP9cp_parserP9tree_node (
parser=0x7058, in_statement_expr=0x0)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:10440
#19 0x10bf90b4 in _ZL28cp_parser_compound_statementP9cp_parserP9tree_nodeib (
parser=0x7058, in_statement_expr=0x0, bcs_flags=0, function_body=true)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:10394
#20 0x10c0f504 in _ZL23cp_parser_function_bodyP9cp_parserb (parser=0x7058, 
in_function_try_block=false)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:20203
#21 0x10c0f788 in
_ZL48cp_parser_ctor_initializer_opt_and_function_bodyP9cp_parserb
(parser=0x7058, in_function_try_block=false)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:20239
#22 0x10c1ab8c in
_ZL46cp_parser_function_definition_after_declaratorP9cp_parserb
(parser=0x7058, inline_p=false)
at /nasfarm/edelsohn/src/src/gcc/cp/parser.c:24843
#23 0x10c1a88c in
_ZL60cp_parser_function_definition_from_specifiers_and_declaratorP9cp_parserP21cp_decl_specifier_seqP9tree_nodePK13cp_declarator
(
parser=0x7058, decl_specifiers=0x2ff222d8, attributes=0x0, 
declarator=0x305eafdc) at

[Bug bootstrap/68231] New: AIX bootstrap failure after GOMP 4.5 merge

2015-11-05 Thread dje at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68231

Bug ID: 68231
   Summary: AIX bootstrap failure after GOMP 4.5 merge
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++98/ios_init.cc: In static member
function 'static bool std::ios_base::sync_with_stdio(bool)':
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++98/ios_init.cc:181:59: internal
compiler error: in tree_to_shwi, at tree.c:7297
  new (_cout) stdio_filebuf(stdout, ios_base::out);
   ^

[Bug c++/68230] New: Unused function parameters not reported by -Wunused-parameter when only used recursively.

2015-11-05 Thread j.fisher at digipen dot edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68230

Bug ID: 68230
   Summary: Unused function parameters not reported by
-Wunused-parameter when only used recursively.
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j.fisher at digipen dot edu
  Target Milestone: ---

The code below does not produce a warning when -Wunused-parameter is turned on.
It would be fantastic if it did, as fundamentally, the variable notUsed is
still not actually being used.

#include 
using namespace std;

int Recursive(int num, const char *notUsed);

int main() {
  const char *notUsedLocal = "Not used";

  cout << "Test: " << Recursive(1, notUsedLocal) << endl;
  return 0;
}

int Recursive(int num, const char *notUsed) {
  if (num > 5)
return num;
  else
return Recursive(++num, notUsed);
}

[Bug bootstrap/68231] AIX bootstrap failure after GOMP 4.5 merge

2015-11-05 Thread dje at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68231

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-06
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1
   Severity|normal  |blocker

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/68231] AIX bootstrap failure after GOMP 4.5 merge

2015-11-05 Thread dje at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68231

--- Comment #2 from David Edelsohn  ---
Success: [trunk revision 229809]
Fail: [trunk revision 229830]

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

2015-11-05 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67942

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Fri Nov  6 01:08:53 2015
New Revision: 229831

URL: https://gcc.gnu.org/viewcvs?rev=229831=gcc=rev
Log:
PR c++/67942 - diagnose placement new buffer overflow

gcc/cp/
* cp/init.c (warn_placement_new_too_small): Avoid assuming
the size of the first operand of placement new or its type
is known.

gcc/testsuite/
* g++.dg/warn/Wplacement-new-size.C: Exercise placement new
invocations where the size of the destination buffer object
or its type (or both) is unknown.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wplacement-new-size.C

[Bug middle-end/68221] New: libgomp reduction-11/12 failures

2015-11-05 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68221

Bug ID: 68221
   Summary: libgomp reduction-11/12 failures
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Without the XFAILs I've added I'm getting:
FAIL: libgomp.c/reduction-11.c execution test
FAIL: libgomp.c/reduction-12.c execution test
FAIL: libgomp.c++/reduction-11.C execution test
FAIL: libgomp.c++/reduction-12.C execution test
on i686-linux (32-bit only, 64-bit x86_64-linux works) when the testcases are
compiled with -fopenmp -O2.  At -O0 they work.

These testcases test array reductions with non-zero low-bound, where for stack
space reasons the compiler is creating private variable just for the array
section and not elements before or after it in the original array.
E.g. for reduction (b[2:3]) the user is allowed to touch in the region
b[2], b[3], b[4], but not b[0], b[1] or b[5].  The current implementation
allocates short int b.23[3]; automatic variable in this case, and needs to
replace the original b with  - 2, so that b + 2 then is in range.  If the
low-bound is not constant (or if it is zero), all is fine, but when it is
constant, we after IL simplifications end up with
MEM[(short int *) + 4294967292B][2]
but apparently on i686-linux -m32 -O2 -fopenmp on reduction-11.c at least
PRE seems to think that stores to
MEM[(short int *) + 4294967292B][2]
can't alias reads from it.

On the OpenMP side I guess I could try casting  to uintptr_t and then
back, but I'm afraid it will get folded away anyway.  Another option is to add
some optimization barrier like short *p; p =  asm ("" : "+g" (p));
but then points-to analysis will pessimize code.  If we could get
the above folded into MEM[(short int *)][0], it would be nice, but can we
really rely on that being always done?

[Bug middle-end/68221] libgomp reduction-11/12 failures

2015-11-05 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68221

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||openmp
   Target Milestone|--- |6.0

[Bug c/68090] VLA compound literal -- "confused by earlier errors, bailing out"

2015-11-05 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68090

Marek Polacek  changed:

   What|Removed |Added

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

[Bug ipa/68219] New: ICF could fold functions called via a table of function pointers

2015-11-05 Thread jay.foad at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68219

Bug ID: 68219
   Summary: ICF could fold functions called via a table of
function pointers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.foad at gmail dot com
  Target Milestone: ---

Consider this simplified example:

$ cat x.cpp
namespace {
  template
  int f() { return 0; }
}
int g(int n) {
  static int (*const t[4])() = { f<0>, f<1>, f<2>, f<3> };
  return t[n]();
}

I can see from the output of "gcc -S -o - -O3 x.cpp" that GCC
generates four separate but identical function bodies for f<0>, f<1>,
f<2> and f<3>. It would be nice if it could generate just one copy.

(I realise that there might be concerns about the standard specifying
that different functions should have different addresses; but in a
case like this the compiler should be able to prove that the addresses
of the functions don't escape.)

[Bug c++/68220] New: [5.2.1 Regression] Devirtualization ICE in record_target_from_binfo, at ipa-devirt.c:2389

2015-11-05 Thread sebastien.piat at epita dot fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220

Bug ID: 68220
   Summary: [5.2.1 Regression] Devirtualization ICE in
record_target_from_binfo, at ipa-devirt.c:2389
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastien.piat at epita dot fr
  Target Milestone: ---

Created attachment 36653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36653=edit
The preprocessed file.

The following piece of code causes an internal compiler error when compiled
with this command line : `g++-5 -O3 -std=c++11 ice.cc`.
With this version of g++-5 : Debian 5.2.1-21 and boost version 1.58.
I could not find any simpler way to cause this error, as removing any of the
elements of the given code solves the problem (even using symbol instead of
boost::variant).
Note that it works if compiled with optimization up to -O2 or with the flag
`-fno-devirtualize`.

The code:

#include 

struct symbol
{
  virtual ~symbol();
};

using Identifier = boost::variant;

struct Fragment
{
  virtual void foo() const = 0;
  virtual ~Fragment();
};

struct ProcFrag : Fragment
{
  ~ProcFrag() {}
  virtual void foo() const override;
  Identifier id;
};

struct Fragments
{
  ~Fragments()
  {
delete x;
  }
  Fragment* x;
};

Fragments fragments;

Fragment::~Fragment()
{}

The compilation output with `-v -save-temps` (I have attached the preprocessed
file):

Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-21'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151003 (Debian 5.2.1-21) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-std=c++11' '-Wall' '-Werror'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE ice.cc -mtune=generic -march=x86-64 -std=c++11
-Wall -Werror -O3 -fpch-preprocess -o ice.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-std=c++11' '-Wall' '-Werror'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -fpreprocessed ice.ii -quiet -dumpbase
ice.cc -mtune=generic -march=x86-64 -auxbase ice -O3 -Wall -Werror -std=c++11
-version -o ice.s
GNU C++11 (Debian 5.2.1-21) version 5.2.1 20151003 (x86_64-linux-gnu)
compiled by GNU C version 5.2.1 20151003, GMP version 6.0.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (Debian 5.2.1-21) version 5.2.1 20151003 (x86_64-linux-gnu)
compiled by GNU C version 5.2.1 20151003, GMP version 6.0.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 60de134094777aef87cb5f2c7eb1a063
ice.cc:35:2: internal compiler error: in record_target_from_binfo, at
ipa-devirt.c:2389
 {}
  ^
0x9264f0 record_target_from_binfo
../../src/gcc/ipa-devirt.c:2389
0x92616a record_target_from_binfo
../../src/gcc/ipa-devirt.c:2430
0x926894 possible_polymorphic_call_targets_1

[Bug ipa/68220] [5.2.1 Regression] Devirtualization ICE in record_target_from_binfo, at ipa-devirt.c:2389

2015-11-05 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-05
 CC||trippels at gcc dot gnu.org
  Component|c++ |ipa
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Probably a dup of PR68057. But is nice to have a non LTO testcase.

Reducing...

[Bug ipa/68220] [5/6 Regression] Devirtualization ICE in record_target_from_binfo, at ipa-devirt.c:2389

2015-11-05 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.3
Summary|[5.2.1 Regression]  |[5/6 Regression]
   |Devirtualization ICE in |Devirtualization ICE in
   |record_target_from_binfo,   |record_target_from_binfo,
   |at ipa-devirt.c:2389|at ipa-devirt.c:2389

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

2015-11-05 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162

--- Comment #7 from Richard Biener  ---
With the latest patch we again get the broken

 <1><50>: Abbrev Number: 8 (DW_TAG_variable)
<51>   DW_AT_name: (indirect string, offset: 0x73): harry
<55>   DW_AT_decl_file   : 1
<56>   DW_AT_decl_line   : 5
<57>   DW_AT_type: <0x65>
<5b>   DW_AT_external: 1
<5b>   DW_AT_location: 9 byte block: 3 20 0 0 0 0 0 0 0
(DW_OP_addr: 20)
 <1><65>: Abbrev Number: 9 (DW_TAG_const_type)
<66>   DW_AT_type: <0x39>
...
 <1><39>: Abbrev Number: 5 (DW_TAG_array_type)
<3a>   DW_AT_type: <0x19>
<3e>   DW_AT_sibling : <0x49>

and no DW_TAG_typedef of Harry_t.

Note that we do generate the DIE but nothing ends up referencing it.  We
equate the type-decl DIE with its type .

The issue is that when emitting the type for 'harry' we do (in
gen_type_die_with_usage):

  /* We are going to output a DIE to represent the unqualified version
 of this type (i.e. without any const or volatile qualifiers) so
 get the main variant (i.e. the unqualified version) of this type
 now.  (Vectors are special because the debugging info is in the
 cloned type itself).  */
  if (TREE_CODE (type) != VECTOR_TYPE)
type = type_main_variant (type);

and that get's us the "C" way of the main variant of the array,
_Harray[].  dwarf2out.c expects us to strip the qualifiers on
the array type (but not its element types) here.  That is, the C way
of handling things may not be compatible with the middle-end ways
(or debug info expectations for this case in C is different?)

When I just not do that main variant punning here I get

 <1><60>: Abbrev Number: 10 (DW_TAG_variable)
<61>   DW_AT_name: (indirect string, offset: 0x7b): harry
<65>   DW_AT_decl_file   : 1
<66>   DW_AT_decl_line   : 5
<67>   DW_AT_type: <0x75>
...
 <1><75>: Abbrev Number: 6 (DW_TAG_const_type)
<76>   DW_AT_type: <0x49>
 <1><49>: Abbrev Number: 7 (DW_TAG_array_type)
<4a>   DW_AT_type: <0x39>
<4e>   DW_AT_sibling : <0x59>
 <1><39>: Abbrev Number: 5 (DW_TAG_typedef)
<3a>   DW_AT_name: (indirect string, offset: 0x0): Harry_t
<3e>   DW_AT_decl_file   : 1
<3f>   DW_AT_decl_line   : 4
<40>   DW_AT_type: <0x44>

instead.  Not sure about that "extra" const qualifier on the array type
though.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 229804)
+++ gcc/dwarf2out.c (working copy)
@@ -20768,7 +20768,8 @@ gen_type_die_with_usage (tree type, dw_d
  get the main variant (i.e. the unqualified version) of this type
  now.  (Vectors are special because the debugging info is in the
  cloned type itself).  */
-  if (TREE_CODE (type) != VECTOR_TYPE)
+  if (TREE_CODE (type) != VECTOR_TYPE
+  && TREE_CODE (type) != ARRAY_TYPE)
 type = type_main_variant (type);

   /* If this is an array type with hidden descriptor, handle it first.  */

Not tested apart from on pr47939-*.c ontop of your last patch.

We are missing C++ variants of those testcases, eventually Fortran / Ada
variants if those have typedefs and qualified element types.

That said, I'm unsure about the expectations on debug info here.  Eventually
we need a debug langhook here?

[Bug tree-optimization/68145] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5684

2015-11-05 Thread ienkovich at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68145

Ilya Enkovich  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ienkovich at gcc dot 
gnu.org

--- Comment #2 from Ilya Enkovich  ---
Problem is in vectorizable_operation which tries to determine a vectype using a
scalar type of a boolean constant.  Output vectype may used instead for boolean
values.  I'll try it.

[Bug middle-end/57845] ICE with -freg-struct-return on Sparc target

2015-11-05 Thread sorganov at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845

Sergey Organov  changed:

   What|Removed |Added

 CC||sorganov at gmail dot com

--- Comment #2 from Sergey Organov  ---
Just ran into this ICE with gcc 5.2.0 sparc-elf target. How comes ICE gets
"WONT FIX" "resolution"??? 

BTW, gcc 3.4.4 did support -freg-struct-return on sparc-elf. Here is simple
code on which gcc 5.2.0 ICEs, along with asm output from gcc 3.4.4:

$ cat struct.c
typedef struct { short int i; } T;

T f(short int i)
{
  T r;
  r.i = i;
  return r;
}
$ ~/try/sparc-elf-5.2.0/bin/sparc-elf-gcc -O0 -v -freg-struct-return -c
struct.c
Using built-in specs.
COLLECT_GCC=/home/osv/try/sparc-elf-5.2.0/bin/sparc-elf-gcc
Target: sparc-elf
Configured with: ../../gcc/configure --prefix=/home/osv/try/sparc-elf-5.2.0
--target=sparc-elf --enable-languages=c,c++ --disable-shared --disable-lto
--disable-nls --disable-libstdcxx --disable-libssp --disable-__cxa_atexit
--disable-newlib-hw-fp --with-gnu-as --with-gnu-ld -with-newlib --with-cpu=v8
Thread model: single
gcc version 5.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-O0' '-v' '-freg-struct-return' '-c' '-mcpu=v8'
 /home/osv/try/sparc-elf-5.2.0/libexec/gcc/sparc-elf/5.2.0/cc1 -quiet -v
-imultilib v8 -D__sparc_v8__ struct.c -quiet -dumpbase struct.c -mcpu=v8
-auxbase struct -O0 -version -freg-struct-return -o /tmp/cc8Q7Kz8.s
GNU C11 (GCC) version 5.2.0 (sparc-elf)
compiled by GNU C version 4.4.5 20101112 (Red Hat 4.4.5-2), GMP version
5.0.1, MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/home/osv/try/sparc-elf-5.2.0/lib/gcc/sparc-elf/5.2.0/../../../../sparc-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /home/osv/try/sparc-elf-5.2.0/lib/gcc/sparc-elf/5.2.0/include
 /home/osv/try/sparc-elf-5.2.0/lib/gcc/sparc-elf/5.2.0/include-fixed

/home/osv/try/sparc-elf-5.2.0/lib/gcc/sparc-elf/5.2.0/../../../../sparc-elf/include
End of search list.
GNU C11 (GCC) version 5.2.0 (sparc-elf)
compiled by GNU C version 4.4.5 20101112 (Red Hat 4.4.5-2), GMP version
5.0.1, MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 88c66c4c8e0ff180c6a3d3a418365f25
struct.c: In function 'f':
struct.c:7:10: internal compiler error: in emit_move_insn, at expr.c:3601
   return r;
  ^
0x66a1bc emit_move_insn(rtx_def*, rtx_def*)
../../../gcc/gcc/expr.c:3601
0x59ba27 expand_value_return
../../../gcc/gcc/cfgexpand.c:3177
0x59f30c expand_return
../../../gcc/gcc/cfgexpand.c:3300
0x59f30c expand_gimple_stmt_1
../../../gcc/gcc/cfgexpand.c:3373
0x59f30c expand_gimple_stmt
../../../gcc/gcc/cfgexpand.c:3497
0x5a18ea expand_gimple_basic_block
../../../gcc/gcc/cfgexpand.c:5509
0x5a66a7 execute
../../../gcc/gcc/cfgexpand.c:6127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ /opt/sparc-elf-3.4.4/bin/sparc-elf-gcc -O0 -v -freg-struct-return -save-temps
-c struct.c
Reading specs from /opt/sparc-elf-3.4.4/lib/gcc/sparc-elf/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --target=sparc-elf
--prefix=/opt/sparc-elf-3.4.4 --with-gnu-as --with-gnu-ld --verbose
--enable-languages=c,c++ --disable-shared --disable-nls --with-newlib
--with-cpu=leon
Thread model: single
gcc version 3.4.4
 /opt/sparc-elf-3.4.4/libexec/gcc/sparc-elf/3.4.4/cc1 -E -quiet -v
-D__leonbare__ struct.c -freg-struct-return -O0 -o struct.i
ignoring nonexistent directory
"/opt/sparc-elf-3.4.4/lib/gcc/sparc-elf/3.4.4/../../../../sparc-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/sparc-elf-3.4.4/lib/gcc/sparc-elf/3.4.4/include
 /opt/sparc-elf-3.4.4/lib/gcc/sparc-elf/3.4.4/../../../../sparc-elf/include
End of search list.
 /opt/sparc-elf-3.4.4/libexec/gcc/sparc-elf/3.4.4/cc1 -fpreprocessed struct.i
-quiet -dumpbase struct.c -auxbase struct -O0 -version -freg-struct-return -o
struct.s
GNU C version 3.4.4 (sparc-elf)
compiled by GNU C version 3.4.6.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 /opt/sparc-elf-3.4.4/lib/gcc/sparc-elf/3.4.4/../../../../sparc-elf/bin/as -V
-Qy -s -o struct.o struct.s
GNU assembler version 2.16.1 (sparc-elf) using BFD version 2.16.1
$ cat struct.s
.file   "struct.c"
.section".text"
.align 4
.global f
.type   f, #function
.proc   010
f:
!#PROLOGUE# 0
save%sp, -112, %sp
!#PROLOGUE# 1
mov %i0, %g1
sth %g1, [%fp+68]
lduh[%fp+68], %g1
sth %g1, [%fp-10]
lduh

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

2015-11-05 Thread law at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68198

--- Comment #5 from Jeffrey A. Law  ---
I've reproduced this issue.  We've got a reasonably sized switch statement that
the FSM threader is able to optimize. The problem is we go from something 2k
edges and 1k blocks to 70k edges and 35k blocks.

I'll have to put in some instrumentation, but early indications are most of the
paths are redundant.  ie, many of the incoming blocks thread to the same
outgoing block.  The FSM threader creates a distinct copy for each of those
cases where the old threader knew how to factor them into a single path.

I probably won't get much further than that while I'm on the road.