[Bug bootstrap/65232] [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug plugins/65227] Plugin headers are unusable when included after inttypes.h

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Doumentation bug then.  gcc-plugin.h should be the _only_ GCC header to
include.

Confirmed as documentation bug.

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #0)
> I'd like to propose that the value of an empty object be printed as "{ }"
> regardless of its type.  I.e., a std::bitset<0> as "std::bitset { }", a
> std::tuple<> as "std::tuple<> { }", and an empty std::vector as
> "std::vector of length 0, capacity N = { }"

Yes, I like this suggestion.

[Bug plugins/65226] gcc-plugin.h is unusable when GCC was build with non-system or in-tree GMP

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
"plugin support" is just a mess.  It really can't work out-of-the-box the way
it
is implemented.

I'd say gcc-plugin.h needs to be autogenerated with both cross-compilation
and in-tree builds of GMP in mind.

[Bug middle-end/65224] fprofile-reorder-functions reorders using expand order

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 27 08:37:51 2015
New Revision: 221043

URL: https://gcc.gnu.org/viewcvs?rev=221043&root=gcc&view=rev
Log:
2015-02-27  Richard Biener  

PR middle-end/63175
* builtins.c (get_object_alignment_2): Make sure to re-apply
the ANDed mask after recursing to its operand gets us a new
misalignment bit position.

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

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Code quality regression fixed for trunk(?).  Testcase is of course still
"bogus"
(wrong scan-dump, doesn't really test the code quality).

[Bug tree-optimization/65193] [4.9 Regression] ICE: Segmentation fault with -g -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/65193] [4.9 Regression] ICE: Segmentation fault with -g -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 27 08:41:26 2015
New Revision: 221044

URL: https://gcc.gnu.org/viewcvs?rev=221044&root=gcc&view=rev
Log:
2015-02-27  Richard Biener  

PR lto/65193
Backport from mainline
2014-07-24  Jan Hubicka  

* lto-streamer-out.c (tree_is_indexable): Consider IMPORTED_DECL
as non-indexable.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/lto-streamer-out.c

[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #4 from Dominik Vogt  ---
This also happens intermittently on my s390x development machine (a zEC12) with
the current 5.0 development trunk.

(In reply to Ian Lance Taylor from comment #1)
> Interestingly, the time for cmpldivide.go on SPARC appears to be primarily
> in the register allocator while compiling.

To be specific:

   LRA hard reg assignment : 217.88 (95%) usr   0.29 (74%) sys 218.24 (95%)
wall   0 kB ( 0%) ggc


> This is true even though no -O option is used.

Actually, on s390x it does not happen

--

Observation
---

Compile time of the test is normally about 4 minutes, but I've seen ~3:50 as
well as ~4:45.  When the machine is slow for some reason (probably does not
matter why), compile time may become more than 5 minutes and therefore the test
times out.

Explanation
---

The test defines a long array of structures with three complex numbers in
cmplxdivide1.go:

  var tests = []Test{ 
Test{complex(0, 0), complex(0, 0), complex(-nan, -nan)}, 
Test{complex(0, 0), complex(0, 1), complex(0, 0)}, 
...
  }

The constants like "nan" map to exported symbols of the math package (unlike C
where this would probably be done with macros): "nan" appears in the code as
"math.NaN@plt".  With dynamic linkage the actual value is unknown at compile
time, and the structure "tests" is initialised in the init function of the main
package.  Compiling with -O0, the executable is about 1.5 MB, and more than 90%
of that is code in the init function.  For each line in the table the assembler
instuctions to initialise is consume about 420 bytes.

As far as I was told, the register allocation code has some trouble with huge
basic blocks of simple code like in this case, when the number of possibilities
explodes.

Note: With -O3, the code compiles in less than two seconds, probably because
the code in the init function is reduced drastically before the expensive
register allocation pass.

[Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

Bug ID: 65233
   Summary: [5 Regression] ICE (segfault) on arm-linux-gnueabihf
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

seen when building ardour on armhf, r220999

$ g++ -c -O3 audio_track.ii
audio_track.ii: In function 'void export_stuff()':
audio_track.ii:71:6: internal compiler error: Segmentation fault
 void export_stuff() {
  ^
Please submit a full bug report,
with preprocessed source if appropriate.

(gdb) bt
#0  0x005ebd8e in integer_zerop(tree_node const*) ()
#1  0x003a1a2e in walk_ssa_copies(tree_node*, hash_set**) ()
#2  0x003a27a0 in
ipa_polymorphic_call_context::ipa_polymorphic_call_context(tree_node*,
tree_node*, gimple_statement_base*, tree_node**) ()
#3  0x0034f028 in fold_stmt_1(gimple_stmt_iterator*, bool, tree_node*
(*)(tree_node*)) ()
#4  0x004c9070 in replace_uses_by(tree_node*, tree_node*) ()
#5  0x004c9554 in gimple_merge_blocks(basic_block_def*, basic_block_def*) ()
#6  0x0028242c in merge_blocks(basic_block_def*, basic_block_def*) ()
#7  0x004ce264 in cleanup_tree_cfg_bb(basic_block_def*) ()
#8  0x004ce6d8 in cleanup_tree_cfg() ()
#9  0x00432232 in execute_function_todo(function*, void*) ()
#10 0x004326b8 in execute_todo(unsigned int) ()
#11 0x00433f88 in execute_one_pass(opt_pass*) ()
#12 0x00434220 in execute_pass_list_1(opt_pass*) [clone .constprop.59] ()
#13 0x0043422a in execute_pass_list_1(opt_pass*) [clone .constprop.59] ()
#14 0x00434258 in execute_pass_list(function*, opt_pass*) ()
#15 0x00298a2a in cgraph_node::expand() ()
#16 0x0029a4b0 in symbol_table::compile() [clone .part.42] ()
#17 0x0029a6ec in symbol_table::finalize_compilation_unit() ()
#18 0x001a3210 in cp_write_global_declarations() ()
#19 0x004a916a in compile_file() ()
#20 0x00156ec2 in toplev::main(int, char**) ()
#21 0x00157914 in main ()

$ cat audio_track.ii
template  class A;
class B;
struct C {
  A &operator*();
};
int a;
class D {
public:
  virtual void m_fn1() {}
  void m_fn2() { m_fn1(); }
};

class shared_count {
  D *pi_;

public:
  shared_count() : pi_() {}
  ~shared_count() {
if (pi_)
  pi_->m_fn2();
  }
  shared_count(shared_count const &p1) : pi_(p1.pi_) {
if (pi_)
  __sync_fetch_and_add(&a, 1);
  }
  void m_fn3(shared_count &p1) {
D *b = p1.pi_;
p1.pi_ = pi_;
pi_ = b;
  }
};

class G;
struct F {
  typedef G *type;
};
template  class A {
  typedef A this_type;

public:
  typedef T element_type;
  A() {}
  template  A(A &p1, element_type *p2) : px(p2), pn(p1.pn) {}
  A &operator=(A p1) {
this_type(p1).m_fn5(*this);
return *this;
  }
  element_type *m_fn4();
  typedef element_type *this_type::*unspecified_bool_type;
  operator unspecified_bool_type() { return px ? 0 : &this_type::px; }
  void m_fn5(A &p1) {
p1.px = px;
pn.m_fn3(p1.pn);
  }
  element_type *px;
  shared_count pn;
};

template  A dynamic_pointer_cast(A &p1) {
  G *p = dynamic_cast(p1.m_fn4());
  return p ? A(p1, p) : A();
}

class B {
public:
  void m_fn7();
  virtual void m_fn6();
};
class G : public B {};
F::type c;
void export_stuff() {
  C i;
  for (;;) {
A d;
if (d = dynamic_pointer_cast(*i))
  c->m_fn7();
  }
}

[Bug plugins/65227] Plugin headers are unusable when included after inttypes.h

[Bert.Wesarg at googlemail dot com]

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

--- Comment #4 from Bert Wesarg  ---
(In reply to Richard Biener from comment #3)
> Doumentation bug then.  gcc-plugin.h should be the _only_ GCC header to
> include.
> 

So inttypes.h is considered a GCC header than? And even if GCC mandates that
gcc-plugin.h should be the first header to include in a compilation unit, how
should this work in a autoconf projects which uses AC_CONFIG_HEADER, because
they also mandate that this header should be the first header to include (from
http://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers):

The package should ‘#include’ the configuration header file before any other
header files, to prevent inconsistencies in declarations (for example, if it
redefines const).

[Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[vogt at linux dot vnet.ibm.com]

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

--- Comment #35 from Dominik Vogt  ---
I'd like to bring back to attention the fact that the code that deducts six
from the pc (s390x) in pprof.go is broken regardless of what patches are made
to the runtime code.  Determining the size of the call instruction is by no
means trivial.  Other platforms certainly have similar problems with the "pc -=
4".  It would be good to solve this at the same time as the "pc--" problem.

[Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-02-27
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Can't reproduce with r221043.
Can you provide the gcc config options?

[Bug fortran/65223] Regresion on elemental type-bound procedure's passed object with INTENT(OUT)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
This is the intended behavior: see the thread starting at
https://gcc.gnu.org/ml/fortran/2014-12/msg00094.html. You must use 'impure
elemental' if there is an INTENT(OUT) polymorphic argument.

[Bug target/57982] GetModuleHandle in __register_frame_info causes abort on unload

[ktietz at gcc dot gnu.org]

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

--- Comment #3 from Kai Tietz  ---
The problem here is the use of weak on pe-coff.  The change you see on gcc is
just addressing the fact that for 64-bit the weak symbol never can get 0 due
relocation-limitations.
We try to address this.
On the other hand we have here to work-a-round a binutils quirk that
default-implementation of a weak is used in its definition TU always, even if a
none-weak symbol is present in a different TU.  This can be worked-a-round by
moving default-implementation into different TU.

Hope this answered some of your questions.

(anyway IMHO, in general we should have used here a variant without any
weak-symbol)

[Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Matthias Klose  ---
Configured with: -v
 --with-pkgversion='Ubuntu 5-20150227-1ubuntu11'
 --with-bugurl='file:///usr/share/doc/gcc-5/README.Bugs'
 --enable-languages=c,c++,java,go,fortran,objc,obj-c++
 --prefix=/usr
 --program-suffix=-5
 --enable-shared
 --enable-linker-build-id
 --libexecdir=/usr/lib
 --without-included-gettext
 --enable-threads=posix
 --with-gxx-include-dir=/usr/include/c++/5
 --libdir=/usr/lib
 --enable-nls
 --with-sysroot=/
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=c++98
 --enable-gnu-unique-object
 --disable-libitm
 --disable-libquadmath
 --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-armhf/jre
 --enable-java-home
 --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf
 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf
 --with-arch-directory=arm
 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
 --enable-objc-gc
 --enable-multiarch
 --enable-multilib
 --disable-sjlj-exceptions
 --with-arch=armv7-a
 --with-fpu=vfpv3-d16
 --with-float=hard
 --with-mode=thumb
 --disable-werror
 --enable-multilib
 --enable-checking=release
 --build=arm-linux-gnueabihf
 --host=arm-linux-gnueabihf
 --target=arm-linux-gnueabihf

[Bug tree-optimization/65193] [4.9 Regression] ICE: Segmentation fault with -g -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 27 10:20:50 2015
New Revision: 221050

URL: https://gcc.gnu.org/viewcvs?rev=221050&root=gcc&view=rev
Log:
2015-02-27  Richard Biener  

PR lto/65193
* g++.dg/lto/pr65193_0.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr65193_0.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/65193] [4.9 Regression] ICE: Segmentation fault with -g -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 27 10:22:04 2015
New Revision: 221051

URL: https://gcc.gnu.org/viewcvs?rev=221051&root=gcc&view=rev
Log:
2015-02-27  Richard Biener  

PR lto/65193
* g++.dg/lto/pr65193_0.C: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/lto/pr65193_0.C
Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Biener  ---
Fixed as far as I am concerned.  Please somebody else fix the testcase itself.

[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 27 10:32:14 2015
New Revision: 221052

URL: https://gcc.gnu.org/viewcvs?rev=221052&root=gcc&view=rev
Log:
2015-02-27  Richard Biener  

PR middle-end/63175
* builtins.c (get_object_alignment_2): Make sure to re-apply
the ANDed mask after recursing to its operand gets us a new
misalignment bit position.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/builtins.c

[Bug fortran/65173] ICE while compiling wrong code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 4.8.4, 4.9.2, and trunk (5.0).

[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak

[ktietz at gcc dot gnu.org]

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

--- Comment #13 from Kai Tietz  ---
Author: ktietz
Date: Fri Feb 27 10:44:43 2015
New Revision: 221053

URL: https://gcc.gnu.org/viewcvs?rev=221053&root=gcc&view=rev
Log:
2015-02-27  Kai Tietz  

PR c/35330
* c-pragma.c (handle_pragma_weak): Do not try to create
weak/alias of declarations not being function, or variable
declarations.

2015-02-27  Kai Tietz  

PR c/35330
* gcc.dg/weak/weak-17.c: New file.


Added:
trunk/gcc/testsuite/gcc.dg/weak/weak-17.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/testsuite/ChangeLog

[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #14 from Kai Tietz  ---
I don't intend to backport this change.  therefore I close as fixed.

[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Biener  ---
Thus fixed.

[Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Can't reproduce either (with cross-compiler from x86_64-linux).
-O3 pr65233.C -quiet -nostdinc  -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard
-mthumb
is what I've tried after -O3 pr65233.C failed to ICE, but no ICE either.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #43 from Dominique d'Humieres  ---
> The testcase passes with it, at the price of leaking memory

Yes: gfortran.dg/alloc_comp_constructor_1.f90 (17 builtin_free instead of 19)
and gfortran.dg/class_array_15.f03 (11 builtin_free instead of 12). I think to
fix this PR without memory leak one has to avoid to free the temporary for
elemental procs

For the reduced test

program main
  implicit none

  integer, parameter :: n = 2

  type :: string_t
 character(LEN=1), dimension(:), allocatable :: chars
  end type string_t

  type :: string_container_t
 type(string_t) :: comp
  end type string_container_t

  type :: string_array_container_t
 type(string_t) :: comp(n)
  end type string_array_container_t

  type(string_t) :: prt_in, tmp, tmpa(n)
  type(string_container_t) :: tmpc, tmpca(n)
  type(string_array_container_t) :: tmpac, tmpaca(n)
  integer :: i, j, k

  do i=1,16

 ! Test without intermediary function
 prt_in = string_t(["A"])
 if (.not. allocated(prt_in%chars)) call abort
 if (any(prt_in%chars .ne. "A")) call abort
 deallocate (prt_in%chars)

 ! scalar elemental function with structure constructor
 prt_in = string_t(["D"])
 if (.not. allocated(prt_in%chars)) call abort
 if (any(prt_in%chars .ne. "D")) call abort
 tmpc = new_prt_spec2 (string_container_t(prt_in))
 if (.not. allocated(prt_in%chars)) call abort
 if (any(prt_in%chars .ne. "D")) call abort
 deallocate (prt_in%chars)
 deallocate(tmpc%comp%chars)

  end do

contains

  elemental function new_prt_spec2 (name) result (prt_spec)
type(string_container_t), intent(in) :: name
type(string_container_t) :: prt_spec
prt_spec = name
  end function new_prt_spec2

end program main

I also see at run time (with/without the patch in comment 42)

a.out(69499,0x7fff748b3300) malloc: *** mach_vm_map(size=18446603339087888384)
failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

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

Backtrace for this error:
#0  0x10a9e4c62
#1  0x10a9e3f80
#2  0x7fff8de21f19
Segmentation fault

[Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose  ---
does adding -fstack-protector-strong make a difference?

[Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

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

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

[Bug libfortran/65234] New: Output descriptor (*(1E15.7)) not accepted

[vehre at gcc dot gnu.org]

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

Bug ID: 65234
   Summary: Output descriptor (*(1E15.7)) not accepted
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vehre at gcc dot gnu.org

An output descriptor of the kind

'(*(1E15.7))' 

is not accepted by the gfortran runtime library, but the error message:

Fortran runtime error: '*' requires at least one associated data descriptor
(*(1E15.7)) 
 ^
is emitted. Now, for a repeat specifier of 1 this makes not much sense, besides
that F2003 and F2008 seem to define this kind of output specifier to be valid.
See F2008, 10.3.1,:

R1003 format-items is format-item [ [ , ] format-item ] ...
R1004 format-item is [ r ] data-edit-desc
  or control-edit-desc
  or char-string-edit-desc
  or [ r ] ( format-items )
R1005 unlimited-format-item is * ( format-items )
R1006 r is int-literal-constant

What for example if one wants to emit/read an even number of floats like with:
'(*(2E15.7))'? 

During research Dominique and Tobias found that '(*(2(E15.7)))' is accepted.

The attached example shows that '(*(2(E15.7)))' is accepted while '(*(2E15.7))'
not.

[Bug libfortran/65234] Output descriptor (*(1E15.7)) not accepted

[vehre at gcc dot gnu.org]

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

--- Comment #1 from vehre at gcc dot gnu.org ---
Created attachment 34887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34887&action=edit
Testcase showing one ok, one fail

[Bug libfortran/65234] Output descriptor (*(1E15.7)) not accepted

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 Ever confirmed|0   |1

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

> What for example if one wants to emit/read an even number of floats like
> with: '(*(2E15.7))'? 

I think this expectation is wrong, i.e., writing an array with an odd number of
elements will print the whole army as demonstrated by the following test

real :: a(11) = [(i,i=1,11)]
print '(*(2(E15.3)))', a
end

which gives at run time

  0.100E+01  0.200E+01  0.300E+01  0.400E+01  0.500E+01
 0.600E+01  0.700E+01  0.800E+01  0.900E+01  0.100E+02 
0.110E+02

[Bug tree-optimization/65193] [4.9 Regression] ICE: Segmentation fault with -g -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 27 11:34:14 2015
New Revision: 221054

URL: https://gcc.gnu.org/viewcvs?rev=221054&root=gcc&view=rev
Log:
2015-02-27  Richard Biener  

PR lto/65193
Backport from mainline
2014-07-24  Jan Hubicka  

* lto-streamer-out.c (tree_is_indexable): Consider IMPORTED_DECL
as non-indexable.

* g++.dg/lto/pr65193_0.C: New testcase.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/lto/pr65193_0.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/lto-streamer-out.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug ipa/65087] [5 Regression] r220742 causes: ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1057

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Markus Trippelsdorf  ---
This issue still happens on ppc64le with -Os -flto -fdevirtualize-at-ltrans

trippels@gcc2-power8 library % cat minimal
/home/trippels/moz-build-dir/toolkit/library/../../gfx/2d/DrawTargetRecording.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/2d/FilterNodeSoftware.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/layers/ImageContainer.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/layers/Layers.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/layers/ImageLayers.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/layers/CompositorParent.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/layers/ImageBridgeChild.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/layers/LayerTransactionParent.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/thebes/gfxPangoFonts.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/thebes/gfxPlatform.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/thebes/gfxFont.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/thebes/gfxFontEntry.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/thebes/gfxPlatformFontList.o
/home/trippels/moz-build-dir/toolkit/library/../../gfx/thebes/gfxTextRun.o
trippels@gcc2-power8 library % ~/gcc_test/usr/local/bin/g++ -flto
-fdevirtualize-at-ltrans -shared @minimal
lto1: internal compiler error: in ipcp_verify_propagated_values, at
ipa-cp.c:1057
0x10d300cf ipcp_verify_propagated_values()
../../gcc/gcc/ipa-cp.c:1057
0x10d3221b ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:2757
0x10d3221b ipcp_driver
../../gcc/gcc/ipa-cp.c:4415
0x10d3221b execute
../../gcc/gcc/ipa-cp.c:4510
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /home/trippels/gcc_test/usr/local/bin/g++ returned 1
exit status

(I don't have the necessary motivation to reduce 14 files individually.)

[Bug web/65231] Dead link in man page to the status of C99 features

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
On Fri, 27 Feb 2015, pinskia at gcc dot gnu.org wrote:

> Someone needs to add the redirect from
> http://gcc.gnu.org/gcc-4.8/c99status.html to http://gcc.gnu.org/c99status.html
> .
> Most likely http://gcc.gnu.org/gcc-4.9/c99status.html might need one too.

No, they are not needed.  The 4.8 branch manual does not contain a 
reference to gcc-4.8/c99status.html, which never existed; the redirects 
are only relevant where the release branch in question has/had such a 
reference before the c99status.html pages were unified.  I don't know 
where the incorrect reference in the manpage referred to came from.

[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

[ktietz at gcc dot gnu.org]

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

--- Comment #3 from Kai Tietz  ---
Author: ktietz
Date: Fri Feb 27 12:05:02 2015
New Revision: 221055

URL: https://gcc.gnu.org/viewcvs?rev=221055&root=gcc&view=rev
Log:
PR target/65038
* config.in: Regenerated.
* configure: Likewise.
* configure.ac (AC_HEADER_STDC): Add explicit.
(AC_CHECK_HEADERS): Check for default headers
plus for ftw.h one.
* libgcov-util.c (gcov_read_profile_dir): Disable use
of ftw-function, if header not found.
(ftw_read_file): Don't translate if ftw header isn't
present.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config.in
trunk/libgcc/configure
trunk/libgcc/configure.ac
trunk/libgcc/libgcov-util.c

[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #4 from Kai Tietz  ---
Bootstrap fixed

[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Fri Feb 27 12:18:57 2015
New Revision: 221056

URL: https://gcc.gnu.org/viewcvs?rev=221056&root=gcc&view=rev
Log:
PR c/65228
* c-decl.c (start_decl): Return NULL_TREE if decl is an error node.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr65228.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Fri Feb 27 12:24:02 2015
New Revision: 221057

URL: https://gcc.gnu.org/viewcvs?rev=221057&root=gcc&view=rev
Log:
PR c/65228
* c-decl.c (start_decl): Return NULL_TREE if decl is an error node.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr65228.c
Modified:
branches/gcc-4_9-branch/gcc/c/ChangeLog
branches/gcc-4_9-branch/gcc/c/c-decl.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug rtl-optimization/65235] New: [4.8, 4.9, 5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[ktkachov at gcc dot gnu.org]

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

Bug ID: 65235
   Summary: [4.8, 4.9, 5 Regression] Simplifying vec_select of
vec_concat miscompiles when first element of
vec_concat is const_int
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
Target: aarch64

This aarch64 intrinsics testcase aborts.

#include "arm_neon.h"

int main (int argc, char** argv)
{
  int64x1_t val1;
  int64x1_t val2;
  int64x1_t val3;
  uint64x1_t val13;
  uint64x2_t val14;
  uint64_t got;
  uint64_t exp;
  val1 = vcreate_s64(UINT64_C(0x80008000));
  val2 = vcreate_s64(UINT64_C(0xf38d));
  val3 = vcreate_s64(UINT64_C(0x7fff809b));
  //  Expect: "val13" = 80001553
  val13 = vcreate_u64 (UINT64_C(0x80001553));
  //  Expect: "val14" = 0010   0002    
  val14 = vcombine_u64(vcgt_s64(vqrshl_s64(val1, val2),
vshr_n_s64(val3, 18)),
   vshr_n_u64(val13, 11));
  /* Should be .  */
  got = vgetq_lane_u64(val14, 0);
  exp = 0;
  if(exp != got)
__builtin_abort ();
}



Investigation shows that the problem is in the simplify-rtx machinery:
Combine tries to combine:
 (insn 72 71 73 2 (set (reg:V2DI 117 [ D.18177 ])
 (vec_concat:V2DI (reg:DI 176 [ D.18179 ])
   (reg:DI 114 [ D.18168 ]))) 
  (expr_list:REG_DEAD (reg:DI 176 [ D.18179 ])
  (expr_list:REG_DEAD (reg:DI 114 [ D.18168 ])

and

 (insn 104 102 105 2 (set (reg:DI 193 [ D.18168 ])
 (vec_select:DI (reg:V2DI 117 [ D.18177 ])
 (parallel [
 (const_int 0 [0])
 ])))
  (expr_list:REG_DEAD (reg:V2DI 117 [ D.18177 ])
 (nil)))

but ends up generating:
(set (reg:DI 193 [ D.18168 ])
(reg:DI 114 [ D.18168 ]))

i.e. it picks element 1 instead of the requested element 0.

This happens during combine where it tries to to simplify a vec_select 0 of the
intermediate rtx:
(vec_concat:V2DI (const_int -1 [0x])
(reg:DI 114 [ D.18166 ]))


The relevant code in simplify-rtx has been there for some time and is broken
for all release branches. I have a patch in testing...

[Bug rtl-optimization/65235] [4.8/4.9/5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
Summary|[4.8, 4.9, 5 Regression]|[4.8/4.9/5 Regression]
   |Simplifying vec_select of   |Simplifying vec_select of
   |vec_concat miscompiles when |vec_concat miscompiles when
   |first element of vec_concat |first element of vec_concat
   |is const_int|is const_int

[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Kai Tietz  ---
I had to revert patch as on boostrap libgcc now tries to test ability to
compile, which is of course not possible.
Other miracle is that configure.ac and actual present configure seem to be
divergent ...

[Bug target/43701] [4.8/4.9/5 Regression] ICE: SIGSEGV (too deep recursion) with -mno-sse and __float128

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
This went away with r195386, and starting with r217279 we even don't error on
this, as we gimple fold the cast away (which is a little bit surprising at -O0,
but perhaps acceptable).

[Bug rtl-optimization/65235] [4.8/4.9/5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|5.0 |4.8.5

[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl

[jan.kratochvil at redhat dot com]

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

--- Comment #8 from Jan Kratochvil  ---
Great, thanks.

[Bug ipa/65236] New: [5 Regression]: IPA ICF causes miscompilation in Chromium built with -Os

[marxin at gcc dot gnu.org]

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

Bug ID: 65236
   Summary: [5 Regression]: IPA ICF causes miscompilation in
Chromium built with -Os
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: marxin at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org

Starting from r221040 ICF introduced new wrapper (thunk) created for a couple
of symbols in chromium (protoc binary).

Semantic equality hit:std::__cxx11::string
google::protobuf::MessageLite::SerializePartialAsString()
const->std::__cxx11::string google::protobuf::MessageLite::SerializeAsString()
const
Assembler symbol
names:_ZNK6google8protobuf11MessageLite24SerializePartialAsStringEv->_ZNK6google8protobuf11MessageLite17SerializeAsStringEv
std::__cxx11::string google::protobuf::MessageLite::SerializePartialAsString()
const (const struct MessageLiteD.25422 * const thisD.27459)
{
  :
  _9 = &MEM[(struct basic_string *)output_3(D)].D.16928._M_local_buf;
  MEM[(struct _Alloc_hider *)output_3(D)]._M_p = _9;
  MEM[(size_type *)output_3(D) + 8B] = 0;
  MEM[(char_type &)output_3(D) + 16] = 0;
  _7 = google::protobuf::MessageLite::AppendPartialToString (this_5(D),
output_3(D));
  if (_7 != 0)
goto ;
  else
goto ;

  :
  MEM[(size_type *)output_3(D) + 8B] = 0;
  _4 = MEM[(const struct basic_string *)output_3(D)];
  MEM[(char_type &)_4] = 0;

  :
  return output_3(D);

}


std::__cxx11::string google::protobuf::MessageLite::SerializeAsString() const
(const struct MessageLiteD.25422 * const thisD.27454)
{
  :
  _8 = &MEM[(struct basic_string *)output_3(D)].D.16928._M_local_buf;
  MEM[(struct _Alloc_hider *)output_3(D)]._M_p = _8;
  MEM[(size_type *)output_3(D) + 8B] = 0;
  MEM[(char_type &)output_3(D) + 16] = 0;
  _4 = google::protobuf::MessageLite::AppendPartialToString (this_5(D),
output_3(D));
  if (_4 != 0)
goto ;
  else
goto ;

  :
  MEM[(size_type *)output_3(D) + 8B] = 0;
  _6 = MEM[(const struct basic_string *)output_3(D)];
  MEM[(char_type &)_6] = 0;

  :
  return output_3(D);

}

Unified; Wrapper has been created.


Optimized dump:
Removing basic block 5
std::__cxx11::string google::protobuf::MessageLite::SerializePartialAsString()
const (const struct MessageLite * const this)
{
  char * const _4;
  bool _7;
  char[16] * _9;

  :
  _9 = &MEM[(struct basic_string *)output_3(D)].D.16928._M_local_buf;
  MEM[(struct _Alloc_hider *)output_3(D)]._M_p = _9;
  MEM[(size_type *)output_3(D) + 8B] = 0;
  MEM[(char_type &)output_3(D) + 16] = 0;
  _7 = google::protobuf::MessageLite::AppendPartialToString (this_5(D),
output_3(D));
  if (_7 != 0)
goto ;
  else
goto ;

  :
  MEM[(size_type *)output_3(D) + 8B] = 0;
  _4 = MEM[(const struct basic_string *)output_3(D)];
  MEM[(char_type &)_4] = 0;

  :
  return output_3(D);

}



;; Function std::__cxx11::string
google::protobuf::MessageLite::SerializeAsString() const
(_ZNK6google8protobuf11MessageLite17SerializeAsStringEv, funcdef_no=1252,
decl_uid=25508, cgraph_uid=355, symbol_order=356)

std::__cxx11::string google::protobuf::MessageLite::SerializeAsString() const
(const struct MessageLite * const this)
{
  :
  *output_2(D) = google::protobuf::MessageLite::SerializePartialAsString
(this_3(D)); [tail call]
  return output_2(D);

}

Unfortunately, emitted assembly is miscompiled with double free (memory
corruption) error.
I'm going to attach RTL dumps.

Martin

[Bug ipa/65236] [5 Regression]: IPA ICF causes miscompilation in Chromium built with -Os

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 34888
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34888&action=edit
RTL dumps without ICF

[Bug ipa/65236] [5 Regression]: IPA ICF causes miscompilation in Chromium built with -Os

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 34889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34889&action=edit
RTL dumps with ICF

[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

[ktietz at gcc dot gnu.org]

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

--- Comment #6 from Kai Tietz  ---
Author: ktietz
Date: Fri Feb 27 13:19:38 2015
New Revision: 221059

URL: https://gcc.gnu.org/viewcvs?rev=221059&root=gcc&view=rev
Log:
PR target/65038
* config.in: Regenerated.
* configure: Likewise.
* configure.ac (AC_HEADER_STDC): Added explicit.
(AC_CHECK_HEADERS): Check for default headers  plus
for ftw.h header.
* libgcov-util.c (gcov_read_profile_dir): Disable use
of ftw-function, if header is not found.
(ftw_read_file): Likewise.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config.in
trunk/libgcc/configure
trunk/libgcc/configure.ac
trunk/libgcc/libgcov-util.c

[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Kai Tietz  ---
Now fixed without regression.
Problem was that header-checks were done before gcc-no-execution.

[Bug ipa/65087] [5 Regression] r220742 causes: ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1057

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
-fno-ipa-icf fixes the issue from comment 6.

[Bug ipa/65237] New: [5 Regression] r221040 caused many regressions

[hjl.tools at gmail dot com]

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

Bug ID: 65237
   Summary: [5 Regression] r221040 caused many regressions
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz

On Linux/x86, r221040 caused:

FAIL: gcc.dg/ipa/ipa-cp-1.c scan-ipa-dump cp "Alignment 2"
FAIL: gcc.dg/ipa/ipa-cp-2.c scan-ipa-dump cp "Alignment 8, misalignment 4"
FAIL: gcc.dg/noreturn-7.c  (test for warnings, line 30)
FAIL: gcc.target/i386/stackalign/longlong-2.c -mno-stackrealign 
scan-assembler-times and[lq]?[^\\n]*-16,[^\\n]*sp 2
FAIL: gcc.target/i386/stackalign/longlong-2.c -mno-stackrealign 
scan-assembler-times and[lq]?[^\\n]*-8,[^\\n]*sp 2
FAIL: gcc.target/i386/stackalign/longlong-2.c -mstackrealign 
scan-assembler-times and[lq]?[^\\n]*-16,[^\\n]*sp 2
FAIL: gcc.target/i386/stackalign/longlong-2.c -mstackrealign 
scan-assembler-times and[lq]?[^\\n]*-8,[^\\n]*sp 2

and may be

FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 32 a[0] == 4
FAIL: gcc.dg/guality/sra-1.c   -O2  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O3 -fomit-frame-pointer  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O3 -g  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -Os  line 21 a.i == 4

[Bug c/65238] New: [5 Regression] __has_attribute is not handled properly with -traditional-cpp.

[iains at gcc dot gnu.org]

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

Bug ID: 65238
   Summary: [5 Regression] __has_attribute is not handled properly
with -traditional-cpp.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org

Created attachment 34890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34890&action=edit
trivial test-case.

between r218893 and 218951 the handling of __has_attribute has regressed for
-traditional-cpp (-E)

(as an example) gcc.dg/cpp/trad/include.c has started to fail with excess
errors - if run manually:

$ ./gcc/xgcc -Bgcc /GCC/gcc-trunk/gcc/testsuite/gcc.dg/cpp/trad/include.c
-traditional-cpp  -E -m32 -o include.i
In file included from /usr/include/Availability.h:145:0,
 from /usr/include/stdlib.h:62,
 from
/GCC/gcc-trunk/gcc/testsuite/gcc.dg/cpp/trad/include.c:13:
/usr/include/AvailabilityInternal.h:1036:0: error: missing '(' after
"__has_attribute"
 #ifdef __has_attribute
 ^
/usr/include/AvailabilityInternal.h:1037:0: error: missing '(' after
"__has_attribute"
 #if __has_attribute(availability)
 ^
=

The trivial test-case compiles fine with:
$ ./gcc/xgcc -Bgcc has-attr.c -E -o t.i

and with :
$ ./gcc/xgcc -Bgcc has-attr.c -E -traditional-cpp -o t.i
has-attr.c:3:0: error: missing '(' after "__has_attribute"
 # if __has_attribute(__totally_non_existant__)
 ^
cc1(52597) malloc: *** error for object 0x1421194c8: incorrect checksum for
freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
cc1(52597) malloc: *** error for object 0x142119438: incorrect checksum for
freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug



Of course, it seems reasonable to exclude __has_attribute from traditional-cpp
- but, in that case:
(a) the testsuite needs amendment in some places, and
(b) use of the tag should not cause the free error.

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[mstahl at redhat dot com]

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

Michael Stahl  changed:

   What|Removed |Added

 CC||dtardon at redhat dot com

--- Comment #9 from Michael Stahl  ---
(In reply to Markus Trippelsdorf from comment #8)
> Also happens with gcc-5 when linking two different LibreOffice libraries.
> (libscfiltlo.so and libooxlo.so)
> 
> The undefined symbol is:
> x4 ~ # c++filt _ZThn40_N3utl28OSeekableOutputStreamWrapper7acquireEv
> non-virtual thunk to utl::OSeekableOutputStreamWrapper::acquire()

interesting ... you are building LO 4.4.1.1 or older?

looking at the git log there is this apparent work-around:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8bb0446974282b32d06cdbd35af83f91e033b4af

not sure if it's the same bug... in case this is triggered by some sort
of de-virtualization new in GCC5 then i guess it is LO's fault
because the acquire() / release() was not dll-exported.

i will push that to the libreoffice-4-3 release branch to get it into 4.3.7.

(i've only tried to build current master, which works fine now with
workaround for the bug from the description)

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 CC||iains at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Iain Sandoe  ---
(In reply to H.J. Lu from comment #0)
> On Linux/x86, r221040 caused:
> 
> FAIL: gcc.dg/ipa/ipa-cp-1.c scan-ipa-dump cp "Alignment 2"
> FAIL: gcc.dg/ipa/ipa-cp-2.c scan-ipa-dump cp "Alignment 8, misalignment 4"

I suspect these ^^^ were unintentional commits - part of a different patch,

> FAIL: gcc.dg/noreturn-7.c  (test for warnings, line 30)
> FAIL: gcc.target/i386/stackalign/longlong-2.c -mno-stackrealign 
> scan-assembler-times and[lq]?[^\\n]*-16,[^\\n]*sp 2
> FAIL: gcc.target/i386/stackalign/longlong-2.c -mno-stackrealign 
> scan-assembler-times and[lq]?[^\\n]*-8,[^\\n]*sp 2
> FAIL: gcc.target/i386/stackalign/longlong-2.c -mstackrealign 
> scan-assembler-times and[lq]?[^\\n]*-16,[^\\n]*sp 2
> FAIL: gcc.target/i386/stackalign/longlong-2.c -mstackrealign 
> scan-assembler-times and[lq]?[^\\n]*-8,[^\\n]*sp 2
> 
> and may be
> 
> FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fno-use-linker-plugin
> -flto-partition=none  line 32 a[0] == 4
> FAIL: gcc.dg/guality/sra-1.c   -O2  line 21 a.i == 4
> FAIL: gcc.dg/guality/sra-1.c   -O3 -fomit-frame-pointer  line 21 a.i == 4
> FAIL: gcc.dg/guality/sra-1.c   -O3 -g  line 21 a.i == 4
> FAIL: gcc.dg/guality/sra-1.c   -Os  line 21 a.i == 4


On Darwin we also see:
gcc.dg/attr-noinline.c (all cases fail)

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
(In reply to Michael Stahl from comment #9)
> interesting ... you are building LO 4.4.1.1 or older? 

4.4.1.2

[Bug libstdc++/65101] cppcheck for vector.tcc: Variable '__new_finish' is reassigned a value before the old one has been used.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
The code is correct, as explained above.

[Bug c/65040] [5 Regression] gcc-5 -Wformat broken

[mpolacek at gcc dot gnu.org]

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

--- Comment #19 from Marek Polacek  ---
Author: mpolacek
Date: Fri Feb 27 14:11:53 2015
New Revision: 221061

URL: https://gcc.gnu.org/viewcvs?rev=221061&root=gcc&view=rev
Log:
PR c/65040
* doc/invoke.texi: Update to reflect that -Wformat=2 doesn't enable
-Wformat-signedness anymore.

* c.opt (Wformat-signedness): Don't enable by -Wformat=2.

* gcc.dg/pr65066.c: Use -Wformat -Wformat-signedness and not
-Wformat=2.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr65066.c

[Bug target/65032] [5 Regression] ICE in reload_combine_note_use, at postreload.c:1556 on i686-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Feb 27 14:15:02 2015
New Revision: 221062

URL: https://gcc.gnu.org/viewcvs?rev=221062&root=gcc&view=rev
Log:
2015-02-27  Vladimir Makarov  

PR target/65032
* lra-remat.c (update_scratch_ops): New.
(do_remat): Call it.
* lra.c (lra_register_new_scratch_op): New. Take code from ...
(remove_scratches): ... here.
* lra-int.h (lra_register_new_scratch_op): New prototype.

2015-02-27  Vladimir Makarov  

PR target/65032
* g++.dg/pr65032.C: New.


Added:
trunk/gcc/testsuite/g++.dg/pr65032.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-int.h
trunk/gcc/lra-remat.c
trunk/gcc/lra.c
trunk/gcc/testsuite/ChangeLog

[Bug c/65040] [5 Regression] gcc-5 -Wformat broken

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from Marek Polacek  ---
Closing.

[Bug fortran/65223] Regresion on elemental type-bound procedure's passed object with INTENT(OUT)

[jwmwalrus at gmail dot com]

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

--- Comment #2 from John  ---
Changing the ELEMENTAL attribute to PURE produces the same error. If that's the
intended behavior, then that's the same as saying type-bound procedures cannot
be pure.

The thread mentioned by Dominique d'Humieres seems to only apply to "unlimited
polymorphic", which is not part of the test case I posted.

[Bug target/65032] [5 Regression] ICE in reload_combine_note_use, at postreload.c:1556 on i686-linux-gnu

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #9 from Markus Trippelsdorf  ---
Fixed. Thanks.

[Bug middle-end/65048] [5 Regression] ICE in add_phi_args_after_copy_edge, at tree-cfg.c

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 27 14:34:18 2015
New Revision: 221063

URL: https://gcc.gnu.org/viewcvs?rev=221063&root=gcc&view=rev
Log:
PR tree-optimization/65048
* gcc.dg/tree-ssa/ssa-dom-thread-9.c: Add -std=gnu89 to dg-options.
(foo): Use K&R style definition.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-9.c

[Bug c/64955] RFE: have -Wformat suggest the correct format string to use

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 CC||manu at gcc dot gnu.org
  Component|c++ |c
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to David Malcolm from comment #0)
> Currently, -Wformat tells me that I got something wrong but doesn't tell we
> what the correct format string is:

I think this should not be hard given the tables already available when
checking formats. This could be an EasyHack.

About generating a patch, we would first need precise locations within format
strings (PR52952), then implement the fix-it hints (PR62314) and editors like
Emacs could parse them to patch the code. Unfortunately, the time I can
dedicate to GCC has been very much reduced lately and I haven't been able to
find anyone to continue this work.

[Bug c/64955] RFE: have -Wformat suggest the correct format string to use

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem here is that usually there are more possibilities of fixing the
code, and so it is a question what to suggest, it might as well just annoy
users when it constantly suggests the opposite hint the user wants to take.  In
some cases, it is desirable to change the format specifier, in others to change
the argument (cast it to something, ...), etc.

[Bug rtl-optimization/65220] [4.8/4.9/5 Regression] integer division in stack alignment for VLA allocation

[aldyh at gcc dot gnu.org]

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

--- Comment #9 from Aldy Hernandez  ---
Author: aldyh
Date: Fri Feb 27 15:01:57 2015
New Revision: 221064

URL: https://gcc.gnu.org/viewcvs?rev=221064&root=gcc&view=rev
Log:
PR rtl-optimization/65220
* config/i386/i386.md (*udivmod4_pow2): New.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr65520.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

[Bug rtl-optimization/65220] [4.8/4.9/5 Regression] integer division in stack alignment for VLA allocation

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #10 from Aldy Hernandez  ---
Fixed in mainline.

[Bug c/60296] Confusing -Wformat warning on invalid format string

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  ---
To be honest, I find the messages by gcc far clearer (except for missing
precise locations). In particular, if we think about suggesting a fix, gcc
could suggest to replace %. with %.d to match '9' and then the second warning
will still be valid (since there are no arguments to match %*d). Currently, gcc
tries to match 9 to %. and skips both on error, that is why it complains about
a missing argument for %d. GCC could not skip the argument '9' and try to match
%*d with 9. I can imagine cases where one strategy is clearer than the other
and viceversa. However, the clang warning does not actually say what is wrong
at all. It does not seem very helpful.

About your questions, yes %d refers to %*d in the format string, and the %d
printed by the warning is not read from the string but hard-coded in the gcc
sources.

What printf does when given invalid arguments is not up to GCC but the C
library that implements printf.

I will close this as invalid then. Improving the location info is what will
make these cases far clearer (PR52952). Then, we can print:

warning: conversion lacks type at end of format [-Wformat=]
   printf("%.%*d\n", 9);
   ~^
note: use '%.d' to match argument of type 'int'
   printf("%.%*d\n", 9);
   ~^^
   %.d

warning: format ‘%d’ expects a matching ‘int’ argument [-Wformat=]
   printf("%.%*d\n", 9);
   ^

[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin

[howarth at bromo dot med.uc.edu]

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

--- Comment #25 from howarth at bromo dot med.uc.edu ---
Bootstrap completed at r221041 on x86_64-apple-darwin14 for
c,c++,fortran,lto,objc,obj-c++,java language set.

[Bug fortran/65223] Regresion on elemental type-bound procedure's passed object with INTENT(OUT)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
   Last reconfirmed||2015-02-27
 CC||janus at gcc dot gnu.org
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
> The thread mentioned by Dominique d'Humieres seems to only apply to
> "unlimited polymorphic", which is not part of the test case I posted.

Sorry, the pointer should be

https://gcc.gnu.org/ml/fortran/2014-12/msg00098.html

The rationale refers to F08:C1278a, however in my F08 draft it is 'A local
variable of a pure subprogram, or of a BLOCK construct within a pure
subprogram, shall not have the SAVE attribute.'. The only related constraint I
can find is

C534 An assumed-size array with the INTENT (OUT) attribute shall not be
polymorphic, finalizable, of a type with an allocatable ultimate component, or
of a type for which default initialization is specied.

but this does not apply to the test in comment 0, CCed Janus.

Nevertheless replacing 'element' with 'impure elemental' allows the code to
compile.

[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 CC||mpolacek at gcc dot gnu.org
  Component|c   |preprocessor
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r217292.

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at bromo dot med.uc.edu

--- Comment #2 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #1)

> 
> On Darwin we also see:
> gcc.dg/attr-noinline.c (all cases fail)

Didin't Martin analyze this failure as the test case just needing "/* {
dg-require-alias "" }  */"?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150#c13

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to howarth from comment #2)
> (In reply to Iain Sandoe from comment #1)
> 
> > 
> > On Darwin we also see:
> > gcc.dg/attr-noinline.c (all cases fail)
> 
> Didin't Martin analyze this failure as the test case just needing "/* {
> dg-require-alias "" }  */"?
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150#c13

Yes, I think the test should be decoared with dg-require-alias.

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
((In reply to howarth from comment #2)
> (In reply to Iain Sandoe from comment #1)
> 
> > 
> > On Darwin we also see:
> > gcc.dg/attr-noinline.c (all cases fail)
> 
> Didin't Martin analyze this failure as the test case just needing "/* {
> dg-require-alias "" }  */"?
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150#c13

That was before Honza did his last round of analysis/changes, just want to be
sure what the correct "fix" is - after all we used to pass that test, right?

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Martin Liška from comment #3)
> (In reply to howarth from comment #2)
> > (In reply to Iain Sandoe from comment #1)
> > 
> > > 
> > > On Darwin we also see:
> > > gcc.dg/attr-noinline.c (all cases fail)
> > 
> > Didin't Martin analyze this failure as the test case just needing "/* {
> > dg-require-alias "" }  */"?
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150#c13
> 
> Yes, I think the test should be decoared with dg-require-alias.

hmm.. so should we understand that we used to pass that test .. "incorrectly?"
.. 
.. it's not clear to me that changing the test to require symbol alias isn't
still a regression … (I'd like to understand that the code-gen is equivalent).

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Yes, I think the test should be decoared with dg-require-alias.

Well, the test used to pass.

[Bug rtl-optimization/65235] [4.8/4.9/5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #1 from Aldy Hernandez  ---
Hi.  The known to work field is empty.  Is this a regression?

I can't reproduce on a cross build to --target=aarch64-linux by running cc1. 
What options causes this to fail?  Could you post a preprocessed file for the
test?

[Bug rtl-optimization/65235] [4.8/4.9/5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Aldy Hernandez from comment #1)
> Hi.  The known to work field is empty.  Is this a regression?
> 
> I can't reproduce on a cross build to --target=aarch64-linux by running cc1.
> What options causes this to fail?  Could you post a preprocessed file for
> the test?

-O2 does it for me. I didn't try anything earlier than 4.8 (since they're not
maintained) but the offending code has been there since 2005:
6516cbaf (bonzini2005-12-16 09:24:19 + 3551)  rtx vec =
trueop0;
6516cbaf (bonzini2005-12-16 09:24:19 + 3552)  int offset =
INTVAL (XVECEXP (trueop1, 0, 0)) * GET_MODE_SIZE (mode);
6516cbaf (bonzini2005-12-16 09:24:19 + 3553) 
6516cbaf (bonzini2005-12-16 09:24:19 + 3554)  /* Try to
find the element in the VEC_CONCAT.  */
6516cbaf (bonzini2005-12-16 09:24:19 + 3555)  while
(GET_MODE (vec) != mode
6516cbaf (bonzini2005-12-16 09:24:19 + 3556) &&
GET_CODE (vec) == VEC_CONCAT)
6516cbaf (bonzini2005-12-16 09:24:19 + 3557){
6516cbaf (bonzini2005-12-16 09:24:19 + 3558) 
HOST_WIDE_INT vec_size = GET_MODE_SIZE (GET_MODE (XEXP (vec, 0)));
6516cbaf (bonzini2005-12-16 09:24:19 + 3559)  if
(offset < vec_size)
6516cbaf (bonzini2005-12-16 09:24:19 + 3560)vec =
XEXP (vec, 0);
6516cbaf (bonzini2005-12-16 09:24:19 + 3561)  else
6516cbaf (bonzini2005-12-16 09:24:19 + 3562){
6516cbaf (bonzini2005-12-16 09:24:19 + 3563) 
offset -= vec_size;
6516cbaf (bonzini2005-12-16 09:24:19 + 3564)  vec =
XEXP (vec, 1);
6516cbaf (bonzini2005-12-16 09:24:19 + 3565)}
6516cbaf (bonzini2005-12-16 09:24:19 + 3566)  vec =
avoid_constant_pool_reference (vec);
6516cbaf (bonzini2005-12-16 09:24:19 + 3567)}
6516cbaf (bonzini2005-12-16 09:24:19 + 3568) 
6516cbaf (bonzini2005-12-16 09:24:19 + 3569)  if (GET_MODE
(vec) == mode)
6516cbaf (bonzini2005-12-16 09:24:19 + 3570)return vec;


and aarch64 wasn't there before 4.8...

[Bug rtl-optimization/65235] [4.8/4.9/5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
gah, sorry, the field is not wide enough to show the output of git blame
properly...

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 Ever confirmed|0   |1

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to D. Hugh Redelmeier from comment #6)
> If an arg is marked as a const char * (i.e. unchanging) and has the strftime
> format attribute, it should be accepted as if it were a literal strftime
> argument.  After all, the necessary checking would have been done at this
> routine's points of call.

The code that warns is this: gcc/c-family/c-format.c

if (res.number_non_literal > 0)
  {
/* Functions taking a va_list normally pass a non-literal format
   string.  These functions typically are declared with
   first_arg_num == 0, so avoid warning in those cases.  */
if (!(format_types[info->format_type].flags & (int)
FMT_FLAG_ARG_CONVERT))
  {
/* For strftime-like formats, warn for not checking the format
   string; but there are no arguments to check.  */
warning_at (loc, OPT_Wformat_nonliteral,
"format not a string literal, format string not
checked");
  }

Thus, there is nothing checking the attributes of the caller. In the same file
there is this code:

tree c;
for (c = TYPE_ATTRIBUTES (TREE_TYPE (current_function_decl));
 c;
 c = TREE_CHAIN (c))
  if (is_attribute_p ("format", TREE_PURPOSE (c))
  && (decode_format_type (IDENTIFIER_POINTER
  (TREE_VALUE (TREE_VALUE (c
  == info.format_type))
break;
if (c == NULL_TREE)
  {
/* Check if the current function has a parameter to which
   the format attribute could be attached; if not, it
   can't be a candidate for a format attribute, despite
   the vprintf-like or vscanf-like call.  */
tree args;
for (args = DECL_ARGUMENTS (current_function_decl);
 args != 0;
 args = DECL_CHAIN (args))
  {
if (TREE_CODE (TREE_TYPE (args)) == POINTER_TYPE
&& (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE
(args)))
== char_type_node))
  break;
  }
if (args != 0)
  warning (OPT_Wsuggest_attribute_format, "function might "
   "be possible candidate for %qs format
attribute",
   format_types[info.format_type].name);
  }

I'm confident that the above code can be adjusted and moved to the point of the
warning in order to check that the caller of strftime has an attribute format
of type 'strftime' that refers to the same declaration as the nonliteral format
argument in the call to strftime, then avoid warning. I'm not planning to work
on this though.

[Bug rtl-optimization/65235] [4.8/4.9/5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez  ---
--target ??

Could you post a preprocessed source code?

Hmmm... fine line, but maybe this isn't a regression?

[Bug ipa/65236] [5 Regression]: IPA ICF causes miscompilation in Chromium built with -Os

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
There's generated assembly:

0045faa0
<_ZNK6google8protobuf11MessageLite24SerializePartialAsStringEv>:
  45faa0:53   push   %rbx
  45faa1:48 89 fb mov%rdi,%rbx
  45faa4:48 89 f7 mov%rsi,%rdi
  45faa7:48 8d 43 10  lea0x10(%rbx),%rax
  45faab:48 c7 43 08 00 00 00 movq   $0x0,0x8(%rbx)
  45fab2:00 
  45fab3:c6 43 10 00  movb   $0x0,0x10(%rbx)
  45fab7:48 89 de mov%rbx,%rsi
  45faba:48 89 03 mov%rax,(%rbx)
  45fabd:e8 0e ff ff ff   callq  45f9d0
<_ZNK6google8protobuf11MessageLite21AppendPartialToStringEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE>
  45fac2:84 c0test   %al,%al
  45fac4:75 0ejne45fad4
<_ZNK6google8protobuf11MessageLite24SerializePartialAsStringEv+0x34>
  45fac6:48 8b 03 mov(%rbx),%rax
  45fac9:48 c7 43 08 00 00 00 movq   $0x0,0x8(%rbx)
  45fad0:00 
  45fad1:c6 00 00 movb   $0x0,(%rax)
  45fad4:48 89 d8 mov%rbx,%rax
  45fad7:5b   pop%rbx
  45fad8:c3   retq   
  45fad9:00 00add%al,(%rax)
  45fadb:00 00add%al,(%rax)
  45fadd:00 00add%al,(%rax)
...

0045fae0 <_ZNK6google8protobuf11MessageLite17SerializeAsStringEv>:
  45fae0:53   push   %rbx
  45fae1:48 89 fb mov%rdi,%rbx
  45fae4:48 83 ec 20  sub$0x20,%rsp
  45fae8:48 89 e7 mov%rsp,%rdi
  45faeb:e8 b0 ff ff ff   callq  45faa0
<_ZNK6google8protobuf11MessageLite24SerializePartialAsStringEv>
  45faf0:48 8b 04 24  mov(%rsp),%rax

(marker)
--

  45faf4:48 89 03 mov%rax,(%rbx)
  45faf7:48 8b 44 24 08   mov0x8(%rsp),%rax
  45fafc:48 89 43 08  mov%rax,0x8(%rbx)
  45fb00:48 8b 44 24 10   mov0x10(%rsp),%rax
  45fb05:48 89 43 10  mov%rax,0x10(%rbx)
  45fb09:48 8b 44 24 18   mov0x18(%rsp),%rax
  45fb0e:48 89 43 18  mov%rax,0x18(%rbx)
  45fb12:48 83 c4 20  add$0x20,%rsp
  45fb16:48 89 d8 mov%rbx,%rax
  45fb19:5b   pop%rbx
  45fb1a:c3   retq   
  45fb1b:00 00add%al,(%rax)
  45fb1d:00 00add%al,(%rax)

Where I suspect a stack load/store instruction after returning from the call
--

[Bug rtl-optimization/65235] [4.8/4.9/5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Created attachment 34891
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34891&action=edit
Self-contained testcase

Here's a testcase with the relevant parts of arm_neon.h extracted.

This aborts for me on aarch64-none-linux-gnu and aarch64-none-elf

[Bug lto/65239] New: typeinfo / VTT for some classes not visibile in shared library when LTO is used

[jana at saout dot de]

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

Bug ID: 65239
   Summary: typeinfo / VTT for some classes not visibile in shared
library when LTO is used
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jana at saout dot de

I am seeing a possible issue with LTO that just seems to have appeared in GCC
5.

When trying to link against the shared library "libgtkmm-2.4.so.1" from gtkmm
2.4 with -flto, I sometimes get complaints that the vtable or VTT for
"Gtk::TreeViewColumn" cannot be found.

In fact:

nm -C .libs/libgtkmm-2.4.so.1.1.0 | egrep '(vtable|VTT) for
Gtk::TreeViewColumn'
002fa8c8 d VTT for Gtk::TreeViewColumn [clone .lto_priv.731]
00323410 d vtable for Gtk::TreeViewColumn [clone .lto_priv.732]

objdump -tC .libs/libgtkmm-2.4.so.1.1.0 | egrep '(vtable|VTT) for
Gtk::TreeViewColumn'
002fa8c8 l O .data.rel.ro.local0038 
.hidden VTT for Gtk::TreeViewColumn [clone .lto_priv.731]
00323410 l O .data.rel.ro00b8  .hidden
vtable for Gtk::TreeViewColumn [clone .lto_priv.732]

(-T comes back empty)


Not using LTO everything is fine (as is LTO with 4.9.2):

objdump -TC /usr/lib64/libgtkmm-2.4.so.1.1.0 | egrep '(vtable|VTT) for
Gtk::TreeViewColumn'
00319a72b7e8  w   DO .data.rel.ro0038  BaseVTT for
Gtk::TreeViewColumn
00319a72b820  w   DO .data.rel.ro00b8  Basevtable
for Gtk::TreeViewColumn



The symbols are from here:

gcc-nm -C .libs/treeviewcolumn.o | egrep '(vtable|VTT) for Gtk::TreeViewColumn'
 W VTT for Gtk::TreeViewColumn
 W vtable for Gtk::TreeViewColumn



Note that if I create a shared library just from that single (slim LTO) object
file, the vtable/VTT are there:

g++ -shared -o x.so -flto -save-temps .libs/treeviewcolumn.o 
objdump -tC x.so | egrep '(vtable|VTT) for Gtk::TreeViewColumn'
97e0 l O .data.rel.ro00b8  vtable
for Gtk::TreeViewColumn
98b8 l O .data.rel.ro.local0038 
VTT for Gtk::TreeViewColumn

If I

g++ -shared -o x.so -flto -save-temps .libs/*.o (whole bunch of object files)

I am getting the shared library where the vtable/VTT are missing (or rather
just have hidden clones). Note that all other vtable/VTT are there, it's just
the Gtk::TreeViewVolumn ones that are missing.



Tested with the latest (20150226) SVN version.


The .res file says:

grep ZT.\*TreeViewColumnE\$ -- -lm.res 
10602 218553227c96204c RESOLVED_IR _ZTTN3Gtk14TreeViewColumnE
4750 218553227c96204c RESOLVED_IR _ZTVN3Gtk14TreeViewColumnE
9268 751c477e728966a5 PREVAILING_DEF_IRONLY_EXP _ZTIN3Gtk14TreeViewColumnE
4192 751c477e728966a5 PREVAILING_DEF_IRONLY_EXP _ZTVN3Gtk14TreeViewColumnE
9270 751c477e728966a5 PREVAILING_DEF_IRONLY_EXP _ZTTN3Gtk14TreeViewColumnE
9287 751c477e728966a5 PREVAILING_DEF_IRONLY_EXP _ZTSN3Gtk14TreeViewColumnE
14067 f3ebcd2e3bf3a025 RESOLVED_IR _ZTIN3Gtk14TreeViewColumnE


(the shared library where the vtable/VTT aren't missing doesn't contain the
RESOLVED_IR lines, just the four PREVAILING_DEF_IRONLY_EXP ones)

This happens with just "-O2 -flto" on an x86_64 system.

I'm not sure how to reduce the testcase or provide further information but can
try to provide further information if you can tell me what you need.

I've uploaded the object files here:
https://www.dropbox.com/s/0rmzoxtpbdq8lc7/objectfiles.tar.gz?dl=0

( g++ -shared -o x.so *.o )

[Bug rtl-optimization/65235] [4.8/4.9/5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---

> Hmmm... fine line, but maybe this isn't a regression?

I guess it isn't a regression in the release branches, but it is wrong-code

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #7 from Jan Hubicka  ---
I sorry, I did not meant to commit ipa-cp-[1,2] patches. Will remove them
shortly.

[Bug target/65240] New: [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 65240
   Summary: [5 Regression] ICE (insn does not satisfy its
constraints) on powerpc64le-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

trunk r221042

$ g++ -c -g -O3 -ffast-math modules_mod.ii 
modules_mod.ii: In member function 'uint32_t D::m_fn3()':
modules_mod.ii:69:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 279 463 432 2 (set (reg:DF 98 21 [360])
(mem/u/c:DF (lo_sum:DI (reg:DI 10 10)
(unspec:DI [
(symbol_ref/u:DI ("*.LC7") [flags 0x82])
(reg:DI 2 2)
] UNSPEC_TOCREL)) [1  S8 A64])) modules_mod.ii:64 499
{*movdf_hardfloat64}
 (expr_list:REG_EQUIV (const_double:DF -5.0e-1 [-0x0.8p+0])
(nil)))
modules_mod.ii:69:1: internal compiler error: in extract_constrain_insn, at
recog.c:2246
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ cat modules_mod.ii
typedef int uint32_t;
extern "C" double atan(double);
template  T lerp(T p1, T p2, U p3) {
  return p1 + (p2 - p1) * p3;
}

template  class audio_module {
public:
  float *ins[];
};

struct A {
  double w1;
  double w2;
  double process___trans_tmp_7;
  double process___trans_tmp_6;
  void m_fn1(double p1) {
double &a = w1;
if (process___trans_tmp_6 < process___trans_tmp_7)
  a = 0.0;
double b = p1 - w1 - w2;
w1 = b;
  }
};
class B {
public:
  float &operator[](int) {}
};
struct C {
  B data;
  int get_interp_1616_ppos;
  int get_interp_1616_pppos;
  float m_fn2(int p1) {
float c(p1);
return lerp(data[get_interp_1616_ppos], data[get_interp_1616_pppos], c);
  }
};
struct rotary_speaker_metadata;
class D : audio_module {
  uint32_t phase_l, phase_h, dphase_h;
  C delay;
  A crossover1r, crossover2l, damper1l, damper1r;
  uint32_t m_fn3();
};
double d, e, f, g, h;
int j;
float k;
uint32_t D::m_fn3() {
  int l;
  for (int i;; i++) {
double m = atan(ins[1][i]);
int n = phase_l, o(phase_h), p = l;
double v = n / 32768.0;
j = 8 + phase_l / 32768.0;
l = 8 + 8 * v - 0.3849;
float q = delay.m_fn2(o) - g * k * delay.m_fn2(o),
  r = g * delay.m_fn2(o) + k * delay.m_fn2(p);
damper1l.m_fn1(q);
f = lerp(0.5, phase_h / 65536.0, h);
float s = f;
damper1r.m_fn1(r);
e = lerp(0.5, j / 65536.0, h);
d = m * e;
float t = d;
crossover2l.m_fn1(s);
crossover1r.m_fn1(t);
phase_l = phase_h = dphase_h;
  }
}

[Bug middle-end/65241] New: [5 Regression] ICE (in remove_local_expressions_from_table, at tree-ssa-dom.c:1081) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 65241
   Summary: [5 Regression] ICE (in
remove_local_expressions_from_table, at
tree-ssa-dom.c:1081) on powerpc64le-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

with r221042

$ gcc -c -g -O3 -Wno-implicit-int wmccc_dialogs.i 
wmccc_dialogs.i: In function 'fn3':
wmccc_dialogs.i:19:3: warning: implicit declaration of function 'fn4'
[-Wimplicit-function-declaration]
   fn4();
   ^
wmccc_dialogs.i:17:1: internal compiler error: in
remove_local_expressions_from_table, at tree-ssa-dom.c:1081
 fn3(wmccc_dialog_t p1) {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ cat wmccc_dialogs.i
typedef enum {
  DLG_SITELIST,
  DLG_NEW_BOARD,
  DLG_NEW_RSS,
  NB_DLG
} wmccc_dialog_t;
fn1(wmccc_dialog_t p1) {
  static w[NB_DLG];
  if (w[p1])
switch (p1)
case DLG_NEW_RSS:
  w[p1] = 0;
}

fn2(p1) { fn1(p1); }

fn3(wmccc_dialog_t p1) {
  fn2(p1);
  fn4();
  fn2(p1);
}

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka  ---
> 
> FAIL: gcc.dg/ipa/ipa-cp-1.c scan-ipa-dump cp "Alignment 2"
> FAIL: gcc.dg/ipa/ipa-cp-2.c scan-ipa-dump cp "Alignment 8, misalignment 4"

Sorry, these was unintentinal commits, I will revert them soon.
> FAIL: gcc.dg/noreturn-7.c  (test for warnings, line 30)

Here we do merging before outputting a warning (testcase expects two warnings).
I suppose there is not much to do than -fno-ipa-cp.
Once user adds one noreturn, he will get warning for anohter, because the
functions will no longer get merged.
> FAIL: gcc.target/i386/stackalign/longlong-2.c -mno-stackrealign 
> scan-assembler-times and[lq]?[^\\n]*-16,[^\\n]*sp 2
> FAIL: gcc.target/i386/stackalign/longlong-2.c -mno-stackrealign 
> scan-assembler-times and[lq]?[^\\n]*-8,[^\\n]*sp 2
> FAIL: gcc.target/i386/stackalign/longlong-2.c -mstackrealign 
> scan-assembler-times and[lq]?[^\\n]*-16,[^\\n]*sp 2
> FAIL: gcc.target/i386/stackalign/longlong-2.c -mstackrealign 
> scan-assembler-times and[lq]?[^\\n]*-8,[^\\n]*sp 2

I suppose here we merge 
void f2 (void)
{
  unsigned long long a __attribute__((aligned (8)));
  fn (&a);
}

and 

void f4 (void)
{
  unsigned long long a __attribute__((aligned (16)));
  fn (&a);
}

I already discussed with Martin yesterday that we need to compare alignments.
I think he has patch on a way

Honza

[Bug target/65242] New: [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 65242
   Summary: [5 Regression] ICE (in gen_add2_insn, at
optabs.c:4761) on powerpc64le-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

with r221042

$ g++ -c -g -O3 loadbi3.ii 
loadbi3.ii: In function 'void J::m_fn8()':
loadbi3.ii:91:1: internal compiler error: in gen_add2_insn, at optabs.c:4761
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ cat loadbi3.ii
class A {
public:
  int m_fn1();
};
class B {
public:
  enum IOMode { reading };
};
class tn_file_buf_stream : B {
public:
  tn_file_buf_stream(IOMode);
  ~tn_file_buf_stream();
};
class C {
public:
  int &operator[](int);
};
class D {
public:
  bool m_fn2();
};
class F {
public:
  int m_fn3(D &);
};
class G {
public:
  D bdt;
};
class ObjectType {
public:
  int id;
  D weather;
  struct H {
F terrainaccess;
  };
  H m_fn4();
  struct {
A images;
  } weatherPicture[];
  ObjectType *m_fn5();
  int m_fn6();
} a;
#pragma pack(1)
class I {};
class J {
  J(I *);
  I translationTableTMISSPart;
  void m_fn8();
  tn_file_buf_stream *MissFile;
  void m_fn9();
  virtual G *m_fn7(int, int);
};
int b, c, d, g;
int e[5];
short f;
void J::m_fn9() {
  int h;
  C k;
  for (; b;) {
int l = c, n = c & 1;
for (int m; d;) {
  int o = 0;
  for (int p = 0; p < 2 && !o; p++)
if (g)
  for (int i; i < a.m_fn6(); i++) {
ObjectType *q = a.m_fn5();
for (int r = 0; r < 6; r++)
  if (q->weather.m_fn2())
for (int j; j < q->weatherPicture[r].images.m_fn1(); j++)
  if (e[m]) {
G *s = m_fn7(l, n);
if (q->m_fn4().terrainaccess.m_fn3(s->bdt))
  g = o = 1;
  }
  }
  k[h++] = f;
}
  }
}

void J::m_fn8() try {
  tn_file_buf_stream t(B::reading);
  MissFile = &t;
  m_fn9();
  J u(0);
  u.m_fn8();
}

catch (int) {
}

[Bug lto/65243] New: [5 Regression] lto1 ICE (segfault) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 65243
   Summary: [5 Regression] lto1 ICE (segfault) on
powerpc64le-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

seen with r221042

build log:
https://launchpadlibrarian.net/198876955/buildlog_ubuntu-vivid-ppc64el.apt-cacher-ng_0.8.0-3_BUILDING.txt.gz

build tarball:
http://people.canonical.com/~doko/tmp/tmp-apt-cacher-ng-ppc64el.tar.xz

Linking CXX executable apt-cacher-ng
/usr/bin/cmake -E cmake_link_script CMakeFiles/apt-cacher-ng.dir/link.txt
--verbose=1
/usr/bin/powerpc64le-linux-gnu-g++   -g -O3 -fPIE -fstack-protector-strong
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2   
-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -flto  
-Wl,--as-needed  CMakeFiles/apt-cacher-ng.dir/source/pkgimport.cc.o
CMakeFiles/apt-cacher-ng.dir/source/maintenance.cc.o
CMakeFiles/apt-cacher-ng.dir/source/apt-cacher.cc.o
CMakeFiles/apt-cacher-ng.dir/source/aclogger.cc.o
CMakeFiles/apt-cacher-ng.dir/source/header.cc.o
CMakeFiles/apt-cacher-ng.dir/source/acfg_defaults.cc.o
CMakeFiles/apt-cacher-ng.dir/source/caddrinfo.cc.o
CMakeFiles/apt-cacher-ng.dir/source/conserver.cc.o
CMakeFiles/apt-cacher-ng.dir/source/dlcon.cc.o
CMakeFiles/apt-cacher-ng.dir/source/filelocks.cc.o
CMakeFiles/apt-cacher-ng.dir/source/lockable.cc.o
CMakeFiles/apt-cacher-ng.dir/source/rfc2553emu.cc.o
CMakeFiles/apt-cacher-ng.dir/source/filereader.cc.o
CMakeFiles/apt-cacher-ng.dir/source/bgtask.cc.o
CMakeFiles/apt-cacher-ng.dir/source/mirror.cc.o
CMakeFiles/apt-cacher-ng.dir/source/fileio.cc.o
CMakeFiles/apt-cacher-ng.dir/source/tcpconnect.cc.o
CMakeFiles/apt-cacher-ng.dir/source/acbuf.cc.o
CMakeFiles/apt-cacher-ng.dir/source/acfg.cc.o
CMakeFiles/apt-cacher-ng.dir/source/cleaner.cc.o
CMakeFiles/apt-cacher-ng.dir/source/meta.cc.o
CMakeFiles/apt-cacher-ng.dir/source/fileitem.cc.o
CMakeFiles/apt-cacher-ng.dir/source/conn.cc.o
CMakeFiles/apt-cacher-ng.dir/source/showinfo.cc.o
CMakeFiles/apt-cacher-ng.dir/source/dirwalk.cc.o
CMakeFiles/apt-cacher-ng.dir/source/job.cc.o
CMakeFiles/apt-cacher-ng.dir/source/expiration.cc.o
CMakeFiles/apt-cacher-ng.dir/source/cacheman.cc.o  -o apt-cacher-ng  -lpthread
-lz -lbz2 -llzma -lssl -lcrypto -lwrap -lsystemd 
make[5]: Leaving directory '/build/buildd/apt-cacher-ng-0.8.0/build'
/usr/bin/cmake -E cmake_progress_report
/build/buildd/apt-cacher-ng-0.8.0/build/CMakeFiles  1 2 3 4 5 6 7 8 9 10 11
[100%] Built target acngfs
In function '__read_alias',
inlined from 'sendfile_generic' at
/build/buildd/apt-cacher-ng-0.8.0/source/job.cc:214:58:
/usr/include/powerpc64le-linux-gnu/bits/unistd.h:39:58: warning: call to
'__read_chk_warn' declared with attribute warning: read called with bigger
length than size of the destination buffer
  return __read_chk (__fd, __buf, __nbytes, __bos0 (__buf));
  ^
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.

[mpolacek at gcc dot gnu.org]

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

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  ---
Let me have a look.

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Author: hubicka
Date: Fri Feb 27 16:56:57 2015
New Revision: 221065

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

PR ipa/65237
* gcc.dg/attr-noinline.c: Add -fno-ipa-icf
* gcc.dg/noreturn-7.c: Add -fno-ipa-icf.
* gcc.dg/ipa/ipa-cp-1.c: Revert accidental commit.
* gcc.dg/ipa/ipa-cp-2.c: Revert accidental commit.

Removed:
trunk/gcc/testsuite/gcc.dg/ipa/ipa-cp-1.c
trunk/gcc/testsuite/gcc.dg/ipa/ipa-cp-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/attr-noinline.c
trunk/gcc/testsuite/gcc.dg/noreturn-7.c

[Bug ipa/65237] [5 Regression] r221040 caused many regressions

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  ---
> > 
> > On Darwin we also see:
> > gcc.dg/attr-noinline.c (all cases fail)
> 
> Didin't Martin analyze this failure as the test case just needing "/* {
> dg-require-alias "" }  */"?
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150#c13

I would just add -fno-ipa-cp.  The testcase matching does not expect functions
to be turned into
wrappers - it counts number of occurences of calls after optimization.  I will
fix that, too.

Honza

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-27
 Ever confirmed|0   |1

--- Comment #1 from Peter Bergner  ---
Confirmed, I'll have a look.

[Bug c/65244] New: Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og

[ulfalizer at gmail dot com]

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

Bug ID: 65244
   Summary: Bogus -Wmaybe-uninitialized warning with
posix_memalign() and -Og
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ulfalizer at gmail dot com

The warning

  posix_memalign_warn.c: In function ‘f’:
  posix_memalign_warn.c:9:5: warning: ‘ptr’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
   return ptr;
   ^

is generated when compiling the following with

  gcc -Og -Wmaybe-uninitialized -c posix_memalign_warn.c

No warning is produced for -O0/1/2/3/fast.


#include 

void *f(void) {
void *ptr;

if (posix_memalign(&ptr, 16, 256) != 0)
exit(EXIT_FAILURE);

return ptr;
}

[Bug c/65244] Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og

[ulfalizer at gmail dot com]

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

--- Comment #1 from Ulf Magnusson  ---
This warning did not occur for GCC 4.8.2 (or whatever the most recent GCC
version is on Ubuntu 14.04) by the way.

[Bug tree-optimization/49234] [4.8/4.9/5 Regression] -Wstrict-overflow gives obviously unwarranted warning

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #26 from Aldy Hernandez  ---
Closed.  Fixed with this:

commit b7f05e98d52b950f3422ea5d161a0e1d0642acf0
Author: rguenth 
Date:   Mon Apr 28 14:07:51 2014 +

2014-04-28  Richard Biener  

* tree-vrp.c (vrp_var_may_overflow): Remove.
(vrp_visit_phi_node): Rather than bumping to +-INF possibly
with overflow immediately bump to one before that value and
let iteration figure out overflow status.

* gcc.dg/tree-ssa/vrp91.c: New testcase.
* gcc.dg/Wstrict-overflow-14.c: XFAIL.
* gcc.dg/Wstrict-overflow-15.c: Likewise.
* gcc.dg/Wstrict-overflow-18.c: Remove XFAIL.