[Bug fortran/65925] New: Memory leak with source allocation nested inside the source of another source allocation

[damian at sourceryinstitute dot org]

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

Bug ID: 65925
   Summary: Memory leak with source allocation nested inside the
source of another source allocation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

Valgrind reports a memory leak with the code below for gfortran 6.0.0 (and 4.10
and 5.0.0):

$ cat reduced-gforLeak.f90 
type IndexSpace
end type
type,extends(IndexSpace) :: OuterProductSpace
end type
type base
  class(IndexSpace),allocatable :: b
end type
type,extends(base) :: subdata
endtype
class(base),allocatable :: d
allocate(d,source = newData())
contains
   type(subdata) function newData() 
  allocate(newData%base%b,source = OuterProductSpace())
   end function
end
$ gfortran reduced-gforLeak.f90 
$ valgrind ./a.out
==3960== Memcheck, a memory error detector
==3960== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==3960== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==3960== Command: ./a.out
==3960== 
==3960== 
==3960== HEAP SUMMARY:
==3960== in use at exit: 17 bytes in 3 blocks
==3960==   total heap usage: 28 allocs, 25 frees, 12,692 bytes allocated
==3960== 
==3960== LEAK SUMMARY:
==3960==definitely lost: 17 bytes in 2 blocks
==3960==indirectly lost: 0 bytes in 1 blocks
==3960==  possibly lost: 0 bytes in 0 blocks
==3960==still reachable: 0 bytes in 0 blocks
==3960== suppressed: 0 bytes in 0 blocks
==3960== Rerun with --leak-check=full to see details of leaked memory
==3960== 
==3960== For counts of detected and suppressed errors, rerun with: -v
==3960== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
$ gfortran --version
GNU Fortran (GCC) 6.0.0 20150422 (experimental)

[Bug target/65924] [6.0 Regression] ICE const_int_operand failed on arm-none-eabi

[yroux at gcc dot gnu.org]

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

Yvan Roux  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-04-29
 Ever confirmed|0   |1

--- Comment #1 from Yvan Roux  ---
Fix is obvious, there is a typo in insn *thumb2_addsi3_compare0_scratch where
match_operand should be done on operand 1 and not 2 (there is only 2 operands
in this insn).  I'll prepare a testcase as this insn doesn't seem to be
generated really often.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
> 
> --- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
> (In reply to clyon from comment #16)
> > (In reply to prathamesh3492 from comment #15)
> > 
> > > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > > run_gcc().
> > Isn't this because you configured GCC --with-fpu=vfpv3-d16?
> 
> COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
> /* Build COLLECT_GCC_OPTIONS to have all of the options specified to
>  the compiler.  */
>   obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
> sizeof ("COLLECT_GCC_OPTIONS=") - 1);
> 
> and at the end of set_collect_gcc_options():
> xputenv (XOBFINISH (&collect_obstack, char *));
> which makes it environment variable.
> 
> set_collect_gcc_options() is called by do_spec, which is called by
> driver::maybe_run_linker(), before executing linker.
> So the driver has no knowledge of options passed at compile-time,
> it sets the default -mfpu=vfpv3-d16.
> 
> When lto-wrapper executes,
> it gets linker command line options from environment variable
> COLLECT_GCC_OPTIONS,
> which contains -mfpu=vfpv3-d16.
> and since that was being appended after compile-time options
> (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.
> 
> This also explains why it works in one shot
> arm-linux-gnueabihf -flto -mfpu=neon test.c
> 
> COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
> line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.
> 
> When compiler and linker are run separately, at link time, the driver has no
> knowledege of flags of compile-time run,
> and hence sets default flags in COLLECT_GCC_OPTIONS.
> 
> I think correct way to fix would be in run_gcc() to get values from
> COLLECT_GCC_OPTIONS in decoded_options as is currently done.
> run_gcc() walks through options in object file and saves it in
> fdecoded_options. So override the value in
> decoded_options for the same option found in fdecoded_options. 
> Would that be a right approach ?

No, link-time options always override compile-time ones.

I suspect the fix will be to somehow avoid setting defaults when linking?

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
(In reply to prathamesh3492 from comment #18)
> Created attachment 35420 [details]
> patch to override default options by options in object file
> 
> Hi,
> 
> The following untested patch gives preference to option value in object file.
> In run_gcc(),
> options from COLLECT_GCC_OPTIONS which are taken from command line are
> stored in decoded_options.
> options from object file are stored in fdecoded_options.
> so override the option in decoded_options if it is present in
> fdecoded_options.
> 
> With the patch this works:
> arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -flto 
> only passes -mfpu=neon to lto1
> 
> However the patch doesn't work when same option is passed different values
> at compile and link-time:
> arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto
> 
> In this case, -mfpu=neon is still passed to lto1, since the patch prefers
> option value from object file.
> Without the patch, the option from the command line was given preference.
> 
> for both the following cases: 
> arm-linux-gnueabihf-gcc test.o -flto
> arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16
> 
> COLLECT_GCC_OPTIONS contains "-mfpu=vfpv3-d16", however in the first case it
> isn't explictly passed by user, so passing -mfpu=neon
> would be correct. In the second case, since -mfpu=vfpv3-d16 is passed
> intentionally by user, should it be considered
> as an error - "conflicting options" ?
> 
> Unfortunately, it looks like there is no way to distinguish between options
> defined by default and explicitly passed options from COLLECT_GCC_OPTIONS
> and that's the only way command line options are passed to lto-wrapper from
> the driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to
> indicate which options were explicitly passed from command line.
> For instance, additionally COLLECT_GCC_OPTIONS would contain 
> "-mfpu=vfpv3-d16-explicit" to indiciate that -mfpu=vfpv3-d16 was
> passed from command line and not set by default. In lto-wrapper the options
> could be parsed to check if they have "explicit" suffix and thus distinguish
> between explicit and defualt defined options.
> Does that sound reasonable ? I would be grateful for suggestions.
> 
> Thank you,
> Prathamesh

As said the patch is wrong.

[Bug target/65924] [6 Regression] ICE const_int_operand failed on arm-none-eabi

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|[6.0 Regression] ICE|[6 Regression] ICE
   |const_int_operand failed on |const_int_operand failed on
   |arm-none-eabi   |arm-none-eabi

[Bug c/65926] New: MinGW-W64, xmmintrin.h, error: can't convert between vector values of different size

[i.nixman at autistici dot org]

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

Bug ID: 65926
   Summary: MinGW-W64, xmmintrin.h, error: can't convert between
vector values of different size
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.nixman at autistici dot org
  Target Milestone: ---

I'm trying to build MinGW-⁠W64(i686-⁠sjlj) based on GCC-⁠5.1.0 and faced with
this errors:
http://pastebin.com/U9Lm8saL

but x86_64-⁠sjlj with the same configuration flags is built successfully.

Configure flags:
--host=i686-w64-mingw32
--build=i686-w64-mingw32
--target=i686-w64-mingw32
--prefix=/mingw32
--with-sysroot=/c/mingw510/i686-510-posix-sjlj-rt_v4-rev0/mingw32
--with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++
--enable-shared
--enable-static
--enable-targets=all
--enable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes
--enable-threads=posix
--enable-libgomp
--enable-libatomic
--enable-lto
--enable-graphite
--enable-checking=release
--enable-fully-dynamic-string
--enable-version-specific-runtime-libs
--enable-sjlj-exceptions
--disable-isl-version-check
--disable-cloog-version-check
--disable-libstdcxx-pch
--disable-libstdcxx-debug
--enable-bootstrap
--disable-rpath
--disable-win32-registry
--disable-nls
--disable-werror
--disable-symvers
--with-gnu-as
--with-gnu-ld
--with-arch-32=i686
--with-arch-64=nocona
--with-tune-32=generic
--with-tune-64=core2
--with-libiconv
--with-system-zlib
--with-gmp=/c/mingw510/prerequisites/i686-w64-mingw32-static
--with-mpfr=/c/mingw510/prerequisites/i686-w64-mingw32-static
--with-mpc=/c/mingw510/prerequisites/i686-w64-mingw32-static
--with-isl=/c/mingw510/prerequisites/i686-w64-mingw32-static
--with-cloog=/c/mingw510/prerequisites/i686-w64-mingw32-static
--enable-cloog-backend=isl

Ideas?

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ramana at gcc dot gnu.org]

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

--- Comment #22 from Ramana Radhakrishnan  ---
(In reply to prathamesh3492 from comment #18)
> Created attachment 35420 [details]
> patch to override default options by options in object file
> 
> Hi,
> 
> The following untested patch gives preference to option value in object file.
> In run_gcc(),
> options from COLLECT_GCC_OPTIONS which are taken from command line are
> stored in decoded_options.
> options from object file are stored in fdecoded_options.
> so override the option in decoded_options if it is present in
> fdecoded_options.
> 
> With the patch this works:
> arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -flto 
> only passes -mfpu=neon to lto1
> 
> However the patch doesn't work when same option is passed different values
> at compile and link-time:
> arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto
> 
> In this case, -mfpu=neon is still passed to lto1, since the patch prefers
> option value from object file.
> Without the patch, the option from the command line was given preference.
> 
> for both the following cases: 
> arm-linux-gnueabihf-gcc test.o -flto
> arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16
> 
> COLLECT_GCC_OPTIONS contains "-mfpu=vfpv3-d16", however in the first case it
> isn't explictly passed by user, so passing -mfpu=neon
> would be correct. In the second case, since -mfpu=vfpv3-d16 is passed
> intentionally by user, should it be considered
> as an error - "conflicting options" ?

No, otherwise users will have to rebuild their compilers for different
defaults, thus defeating the whole purpose of having command line options ! 

> 
> Unfortunately, it looks like there is no way to distinguish between options
> defined by default and explicitly passed options from COLLECT_GCC_OPTIONS
> and that's the only way command line options are passed to lto-wrapper from
> the driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to
> indicate which options were explicitly passed from command line.
> For instance, additionally COLLECT_GCC_OPTIONS would contain 
> "-mfpu=vfpv3-d16-explicit" to indiciate that -mfpu=vfpv3-d16 was
> passed from command line and not set by default. In lto-wrapper the options
> could be parsed to check if they have "explicit" suffix and thus distinguish
> between explicit and defualt defined options.
> Does that sound reasonable ? I would be grateful for suggestions.
> 
> Thank you,
> Prathamesh

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ramana at gcc dot gnu.org]

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

--- Comment #23 from Ramana Radhakrishnan  ---
(In reply to rguent...@suse.de from comment #20)
> On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
> > 
> > --- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
> > (In reply to clyon from comment #16)
> > > (In reply to prathamesh3492 from comment #15)
> > > 
> > > > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > > > run_gcc().
> > > Isn't this because you configured GCC --with-fpu=vfpv3-d16?
> > 
> > COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
> > /* Build COLLECT_GCC_OPTIONS to have all of the options specified to
> >  the compiler.  */
> >   obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
> > sizeof ("COLLECT_GCC_OPTIONS=") - 1);
> > 
> > and at the end of set_collect_gcc_options():
> > xputenv (XOBFINISH (&collect_obstack, char *));
> > which makes it environment variable.
> > 
> > set_collect_gcc_options() is called by do_spec, which is called by
> > driver::maybe_run_linker(), before executing linker.
> > So the driver has no knowledge of options passed at compile-time,
> > it sets the default -mfpu=vfpv3-d16.
> > 
> > When lto-wrapper executes,
> > it gets linker command line options from environment variable
> > COLLECT_GCC_OPTIONS,
> > which contains -mfpu=vfpv3-d16.
> > and since that was being appended after compile-time options
> > (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.
> > 
> > This also explains why it works in one shot
> > arm-linux-gnueabihf -flto -mfpu=neon test.c
> > 
> > COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
> > line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.
> > 
> > When compiler and linker are run separately, at link time, the driver has no
> > knowledege of flags of compile-time run,
> > and hence sets default flags in COLLECT_GCC_OPTIONS.
> > 
> > I think correct way to fix would be in run_gcc() to get values from
> > COLLECT_GCC_OPTIONS in decoded_options as is currently done.
> > run_gcc() walks through options in object file and saves it in
> > fdecoded_options. So override the value in
> > decoded_options for the same option found in fdecoded_options. 
> > Would that be a right approach ?
> 
> No, link-time options always override compile-time ones.
> 
> I suspect the fix will be to somehow avoid setting defaults when linking?

Well I'm not sure how easy that's going to be - You will need some amount of
defaults to get through especially if the user hasn't provided the options in
the first place :( .

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #31 from vehre at gcc dot gnu.org ---
That should not matter. I have prepared the patch on trunk (aka 6.0), but it
should also apply on the 5.x-branch (with automatic offsets).

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

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

--- Comment #32 from Jürgen Reuter  ---
With gcc-6.0 trunk I cannot test our complete code because of 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
For gcc 5 trunk I have massive problems in checking out the svn at the moment,
always getting timeouts.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  ---
On Wed, 29 Apr 2015, ramana at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
> 
> --- Comment #23 from Ramana Radhakrishnan  ---
> (In reply to rguent...@suse.de from comment #20)
> > On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
> > > 
> > > --- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
> > > (In reply to clyon from comment #16)
> > > > (In reply to prathamesh3492 from comment #15)
> > > > 
> > > > > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > > > > run_gcc().
> > > > Isn't this because you configured GCC --with-fpu=vfpv3-d16?
> > > 
> > > COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
> > > /* Build COLLECT_GCC_OPTIONS to have all of the options specified to
> > >  the compiler.  */
> > >   obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
> > > sizeof ("COLLECT_GCC_OPTIONS=") - 1);
> > > 
> > > and at the end of set_collect_gcc_options():
> > > xputenv (XOBFINISH (&collect_obstack, char *));
> > > which makes it environment variable.
> > > 
> > > set_collect_gcc_options() is called by do_spec, which is called by
> > > driver::maybe_run_linker(), before executing linker.
> > > So the driver has no knowledge of options passed at compile-time,
> > > it sets the default -mfpu=vfpv3-d16.
> > > 
> > > When lto-wrapper executes,
> > > it gets linker command line options from environment variable
> > > COLLECT_GCC_OPTIONS,
> > > which contains -mfpu=vfpv3-d16.
> > > and since that was being appended after compile-time options
> > > (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.
> > > 
> > > This also explains why it works in one shot
> > > arm-linux-gnueabihf -flto -mfpu=neon test.c
> > > 
> > > COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
> > > line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.
> > > 
> > > When compiler and linker are run separately, at link time, the driver has 
> > > no
> > > knowledege of flags of compile-time run,
> > > and hence sets default flags in COLLECT_GCC_OPTIONS.
> > > 
> > > I think correct way to fix would be in run_gcc() to get values from
> > > COLLECT_GCC_OPTIONS in decoded_options as is currently done.
> > > run_gcc() walks through options in object file and saves it in
> > > fdecoded_options. So override the value in
> > > decoded_options for the same option found in fdecoded_options. 
> > > Would that be a right approach ?
> > 
> > No, link-time options always override compile-time ones.
> > 
> > I suspect the fix will be to somehow avoid setting defaults when linking?
> 
> Well I'm not sure how easy that's going to be - You will need some amount of
> defaults to get through especially if the user hasn't provided the options in
> the first place :( .

The other option is to special-case only those options that are slipping
in that way (-march, -mtune, -mcpu, -mfpu?) and emit those always first,
hoping that explicit ones will override that.  Of course lto-wrapper
cannot distinguish between implicitely and explicitely such given
arguments at link-time.  Which means the only solution would be to
completely ignore these at link-time.

But I suspect this might break otherwise working cases (due to the fact
that which -march/-mtune/-mcpu/-mfpu options lto-wrapper chooses from
the object files is essentially "random" if they don't agree for all
objects).

It's really unfortunate that these configure-time defaults appear
as regular user command-line arguments :(  I suppose this was done
to make them visible to specs processing.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

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

--- Comment #33 from vehre at gcc dot gnu.org ---
I can only work on the issue, not do magic.

When you have issues with svn checkout try the gitmirror:
https://gcc.gnu.org/wiki/GitMirror

[Bug target/65924] [6 Regression] ICE const_int_operand failed on arm-none-eabi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
As arm-none-eabi (with newlib) is a frequently built target (at least for me),
can you please post the patch to fix it and add the testcase later if it takes
a while to reduce, since this is a bug introduce with the recent patch, rather
than a latent one being exposed?

[Bug tree-optimization/65917] [6 Regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|law at redhat dot com  |rguenth at gcc dot 
gnu.org
Summary|[6.0 regression] FAIL:  |[6 Regression] FAIL:
   |gcc.dg/tree-ssa/20030922-2. |gcc.dg/tree-ssa/20030922-2.
   |c scan-tree-dump-times dom1 |c scan-tree-dump-times dom1
   |"if " 2 |"if " 2

--- Comment #5 from Richard Biener  ---
So on x86_64 ifcombine has "removed" the if but after dom1 we still have

  _14 = *_13;
  if (_8 != _14)
goto ;
  else
goto ;

  :
  target_bb.1_15 = target_bb;
  _16 = _8 != target_bb.1_15;
  _17 = _14 == target_bb.1_15;
  _18 = _16 & _17;
  if (_18 != 0)

which shows that running ifcombine before DOM might not be the best idea.

It also shows that the testcase should disable ifcombine to really test what it
was supposed to test.  And then it also fails on x86_64.

VRP does optimize this case because it has a more powerful way to track
equivalences (and does a quadratic job in trying to simplify compares using
all equivalences of the lhs vs all equivalences of the rhs).

Which is another hint at the fact that DOM maybe shouldn't treat equivalences
derived from conditionals in the SSA_VALUE table where you can't really record
both _14 = target_bb.1_15 and target_bb.1_15 = _14 (which would get you a
nice cycle there).

For the existing way of DOM handlign this I don't see anything in the testcase
that could be used to build a new heuristic (in fact another heuristic
would say that what we do now is good -- _14 dies at the point where we
build the equivalency, target_bb.1_15 does not, so we don't want to propagate
_14 because that will increase its lifetime!)

I suggest to "fix" the testcase and XFAIL it.  I'll take care of that.

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[mwahab at gcc dot gnu.org]

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

--- Comment #44 from mwahab at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #43)
> (In reply to torvald from comment #37)
> 
> > > I'm not worried about __sync_lock_release, I think the documentation is
> > > strong enough and unambiguous.
> > 
> > Are you aware that the GCC's __sync disallow store-store reordering across
> > __sync_lock_release, whereas the psABI docs don't?
> 
> No I was not, and even looking exactly for the text you were referring to,
> it took
> me three attempts to spot it. Yes, I understand now why you are concerned
> about
> the GCC wording. Perhaps this is just an artefact of a mistake transcribing
> the psABI?
> 
> AArch64 is certainly not providing that guarantee just now.

I wasn't able to find the text, could you copy it in a reply. 
In the GCC manual, the only description of __sync_lock_release behaviour is in
the last paragraph. That descriptions seems consistent with the function being
a release barrier and with the current Aarch64 code generated for it.

[Bug tree-optimization/65917] [6 Regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Wed Apr 29 08:51:08 2015
New Revision: 222562

URL: https://gcc.gnu.org/viewcvs?rev=222562&root=gcc&view=rev
Log:
2015-04-29  Richard Biener  

PR tree-optimization/65917
* gcc.dg/tree-ssa/20030922-2.c: Disable ifcombine and XFAIL.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c

[Bug tree-optimization/65917] [6 Regression] XFAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, xfail
 Status|ASSIGNED|NEW
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
Summary|[6 Regression] FAIL:|[6 Regression] XFAIL:
   |gcc.dg/tree-ssa/20030922-2. |gcc.dg/tree-ssa/20030922-2.
   |c scan-tree-dump-times dom1 |c scan-tree-dump-times dom1
   |"if " 2 |"if " 2

--- Comment #7 from Richard Biener  ---
Ok, XFAILed.

[Bug tree-optimization/65893] ifcombine not done anymore on expansion of va_arg

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01835.html

[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Earnshaw  ---
(In reply to Bernd Edlinger from comment #5)
> Well, I thought maybe it would not hurt to be more permissive...
> 
> At least math.h and stdlib.h include 
> which contains something like this:
> 
> #ifndef __cplusplus
> 
> typedef cyg_halbool bool;
> 
> # ifndef false
> #  define false 0
> # endif
> 
> # ifndef true
> #  define true (!false)
> # endif
> 
> #endif

Neither of those headers should be doing that...

I think you'll find more packages than just GCC are going to fail to build if
they do.

[Bug tree-optimization/65893] ifcombine not done anymore on expansion of va_arg

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Apr 29 09:13:49 2015
New Revision: 222567

URL: https://gcc.gnu.org/viewcvs?rev=222567&root=gcc&view=rev
Log:
Move pass_stdarg to after pass_dce in pass_all_optimizations

2015-04-29  Tom de Vries  

PR tree-optimization/65893
* passes.def (pass_all_optimizations): Move pass_stdarg to after
pass_dce.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def

[Bug tree-optimization/65893] ifcombine not done anymore on expansion of va_arg

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from vries at gcc dot gnu.org ---
patch committed, marking resolved-fixed.

[Bug libstdc++/65927] New: cppcheck: bits/locale_facets_nonio.h (_M_am_pm_format): Assignment of function parameter has no effect outside the function

[burnus at gcc dot gnu.org]

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

Bug ID: 65927
   Summary: cppcheck: bits/locale_facets_nonio.h
(_M_am_pm_format): Assignment of function parameter
has no effect outside the function
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

cppcheck claims:

[gcc-trunk/include/c++/5.0.0/bits/locale_facets_nonio.h:241]: (warning)
Assignment of function parameter has no effect outside the function. Did you
forget dereferencing it?


That's the code:

  void
  _M_am_pm_format(const _CharT* __ampm) const
  { __ampm = _M_data->_M_am_pm_format; }

[Bug tree-optimization/65791] Postpone expand_ifn_va_arg till after optimize_va_list_gpr_fpr_size

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Hopefully, after implementing this todo we can revert this change in
tree-ssa/stdarg-2.c:
-
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/testsuite/gcc.dg/tree-ssa/stdarg-2.c;h=5a74280f7281814eff9cf221946744c0f6c8e43f;hp=fe39da3528059173c33f0a8930af9de9c02541f4;hb=82fc0e0a3a4f82770e7e076cab5309bb1bd9fe87;hpb=4036aeb0fb3b3765d257383b1a55af043c23988d

[Bug libstdc++/65928] New: std::find_if compilation errors

[david.claessens at tomra dot com]

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

Bug ID: 65928
   Summary: std::find_if compilation errors
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.claessens at tomra dot com
  Target Milestone: ---

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

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='Ubuntu
5.1.0-0ubuntu11~14.04.1' --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=c++98 --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 --disable-werror --with-arch-32=i686
--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.1.0 (Ubuntu 5.1.0-0ubuntu11~14.04.1)


The code below compiles fine under 4.9.2 but gives errors under 5.1.0

compiler command: g++-5 -std=c++1y bug.cpp

adding -Wall -Wextra does not change the output for v5.1.0 but gives
unused-but-set-variable warnings on v4.9.2


#include 
#include 
#include 

int main(int, char **)
{
const std::string test_string("this is a test");

auto first_space = std::find_if(
std::begin(test_string),
std::end(test_string),
std::isblank);

int (*myblank)(int) = &std::isblank;

auto _space = std::find_if(
std::begin(test_string),
std::end(test_string),
myblank);

return 0;
}

The compiler output:
bug.cpp: In function ‘int main(int, char**)’:
bug.cpp:13:25: error: no matching function for call to
‘find_if(std::basic_string::const_iterator,
std::basic_string::const_iterator, )’
 std::isblank);
 ^
In file included from /usr/include/c++/5/algorithm:62:0,
 from bug.cpp:4:
/usr/include/c++/5/bits/stl_algo.h:3806:5: note: candidate: template _IIter std::find_if(_IIter, _IIter, _Predicate)
 find_if(_InputIterator __first, _InputIterator __last,
 ^
/usr/include/c++/5/bits/stl_algo.h:3806:5: note:   template argument
deduction/substitution failed:
bug.cpp:13:25: note:   couldn't deduce template parameter ‘_Predicate’
 std::isblank);

[Bug ada/65476] Long_Float array does not byte-swap correctly with reverse Scalar_Storage_Order

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-29
Summary|Long_Float array does not   |Long_Float array does not
   |byte swap correctly when|byte-swap correctly with
   |set to Scalar_Storage_Order |reverse
   |with High Order First   |Scalar_Storage_Order
 Ever confirmed|0   |1

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

[Bug ada/65476] Long_Float array does not byte-swap correctly with reverse Scalar_Storage_Order

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug ada/65476] Long_Float array does not byte-swap correctly with reverse Scalar_Storage_Order

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> When an array of Long_Floats is set to a scalar_storage_order of
> High_Order_First, only the two 32 bit words that make up the 64 bit value
> are swapped with each other but the bytes under those words are not swapped
> properly. Attached is a simple program that reproduces the behavior.

I'm actually seeing exactly the reverse effect: in Low_Order_First

power_of_two.4177:
.long   0
.long   1072693248
.long   0
.long   1073741824

and in High_Order_First:

power_of_two.4177:
.long   0
.long   61503
.long   0
.long   64

so correct byte-swapping but missing word-swapping.

[Bug libstdc++/65928] std::find_if compilation errors

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
It seems normal to me. There are now several functions called isblank in
namespace std, and the compiler doesn't know which one to pick when you don't
give it a hint (like you do for myblank). A more explicit diagnostic would be
nice though.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ramana.radhakrishnan at arm dot com]

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

--- Comment #25 from ramana.radhakrishnan at arm dot com  ---
On 29/04/15 09:09, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
>
> --- Comment #24 from rguenther at suse dot de  ---
> On Wed, 29 Apr 2015, ramana at gcc dot gnu.org wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
>>
>> --- Comment #23 from Ramana Radhakrishnan  ---
>> (In reply to rguent...@suse.de from comment #20)
>>> On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
>>>
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

 --- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
 (In reply to clyon from comment #16)
> (In reply to prathamesh3492 from comment #15)
>
>> I am not understanding why vfpv3-d16 appears in collect_gcc_options in
>> run_gcc().
> Isn't this because you configured GCC --with-fpu=vfpv3-d16?

 COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
 /* Build COLLECT_GCC_OPTIONS to have all of the options specified to
   the compiler.  */
obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
  sizeof ("COLLECT_GCC_OPTIONS=") - 1);

 and at the end of set_collect_gcc_options():
 xputenv (XOBFINISH (&collect_obstack, char *));
 which makes it environment variable.

 set_collect_gcc_options() is called by do_spec, which is called by
 driver::maybe_run_linker(), before executing linker.
 So the driver has no knowledge of options passed at compile-time,
 it sets the default -mfpu=vfpv3-d16.

 When lto-wrapper executes,
 it gets linker command line options from environment variable
 COLLECT_GCC_OPTIONS,
 which contains -mfpu=vfpv3-d16.
 and since that was being appended after compile-time options
 (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.

 This also explains why it works in one shot
 arm-linux-gnueabihf -flto -mfpu=neon test.c

 COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
 line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.

 When compiler and linker are run separately, at link time, the driver has 
 no
 knowledege of flags of compile-time run,
 and hence sets default flags in COLLECT_GCC_OPTIONS.

 I think correct way to fix would be in run_gcc() to get values from
 COLLECT_GCC_OPTIONS in decoded_options as is currently done.
 run_gcc() walks through options in object file and saves it in
 fdecoded_options. So override the value in
 decoded_options for the same option found in fdecoded_options.
 Would that be a right approach ?
>>>
>>> No, link-time options always override compile-time ones.
>>>
>>> I suspect the fix will be to somehow avoid setting defaults when linking?
>>
>> Well I'm not sure how easy that's going to be - You will need some amount of
>> defaults to get through especially if the user hasn't provided the options in
>> the first place :( .
>
> The other option is to special-case only those options that are slipping
> in that way (-march, -mtune, -mcpu, -mfpu?) and emit those always first,
> hoping that explicit ones will override that.  Of course lto-wrapper
> cannot distinguish between implicitely and explicitely such given
> arguments at link-time.  Which means the only solution would be to
> completely ignore these at link-time.

IMHO that will cause more problems.

Alternatively, add options_default_specs in the beginning and then 
filter out all those values of options that are the same as the default 
options hoping that the user doesn't put that back in again.
But again it's sticky tape and doesnt' really fix the problem.

I'm not sure we're improving the situation in anyway by putting in the 
hack - it just pushes a compile time breakage into possibly subtle 
runtime failure which can easily be achieved by adding the "relaxed 
option" in this case -mfpu=neon to the command line at link time.

At least then it's evident to the user that they need to do something 
specific to their use-case to get LTO working or fail very quickly if 
their code relies on absence of SIMD code in the default case or in the 
case without auto-detection.

I'm pretty sure this will be the first thing to sort out when trying to 
build kernels with LTO for e.g.. .

So, I guess I'm voting for doing this properly with target attributes 
rather than putting one more bit of sticky tape in a pretty painful area 
of the compiler.

>
> But I suspect this might break otherwise working cases (due to the fact
> that which -march/-mtune/-mcpu/-mfpu options lto-wrapper chooses from
> the object files is essentially "random" if they don't agree for all
> objects).
>
> It's really unfortunate that these configure-time defaults appear
> as regular user command-line arguments :(  I suppose this was done
> to make them visible to specs pr

[Bug target/65924] [6 Regression] ICE const_int_operand failed on arm-none-eabi

[yroux at gcc dot gnu.org]

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

--- Comment #3 from Yvan Roux  ---
Author: yroux
Date: Wed Apr 29 11:31:40 2015
New Revision: 222572

URL: https://gcc.gnu.org/viewcvs?rev=222572&root=gcc&view=rev
Log:
gcc/
2015-04-29  Yvan Roux  

PR target/65924
* config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand
number in type attribute expression.

gcc/testsuite/
2015-04-29  Yvan Roux  

PR target/65924
* gcc.target/arm/pr65924.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr65924.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/thumb2.md
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/65929] New: FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE

[ubizjak at gmail dot com]

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

Bug ID: 65929
   Summary: FAIL: gcc.dg/tree-prof/pr34999.c compilation,
-fprofile-use -D_PROFILE_USE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Revision r222473 causes following warning on alpha-linux-gnu when compiling
pr34999.c:

/tmp/ccPdj6Kv.s: Assembler messages:
/tmp/ccPdj6Kv.s:107: Warning: nested .ent directives
/tmp/ccPdj6Kv.s:121: Warning: .end directive names different symbol than .ent
/tmp/ccPdj6Kv.s:124: Warning: .end directive without matching .ent

The failure can be seen with a crosscompiler to from x86_64-linux-gnu to
alpha-linux-gnu with following command:

gcc-build-alpha/gcc/cc1 -O2 -freorder-blocks-and-partition -fprofile-use
-o pr34999.s -fpreprocessed pr34999.i

The resulting assembly shows nested .ent/.end directives where main.cold.0 was
inserted:

--cut here--
.set noreorder
.set volatile
.set noat
.section.rodata
$LC0:
.string "test"
.section.text.unlikely,"ax",@progbits
.align 2
$LCOLDB1:
.section.text.startup,"ax",@progbits
$LHOTB1:
.align 2
.align 4
.globl main
.ent main
main:
.frame $15,32,$26,0
.mask 0x4008000,-32
$LFB1:
ldgp $29,0($27)
$main..ng:
lda $30,-32($30)
$LCFI0:
lda $1,$LC0
lda $3,buf
bis $31,$31,$31
stq $15,8($30)
$LCFI1:
mov $30,$15
$LCFI2:
stq $26,0($30)
$LCFI3:
.prologue 1
lda $30,-48($30)
stq $30,16($15)
lda $6,4($1)
ldq_u $4,4($1)
ldq_u $5,0($1)
ldq_u $2,3($1)
bis $31,$31,$31
extbl $4,$6,$8
ldl $19,4($30)
extll $5,$1,$0
lda $24,$L2
extlh $2,$1,$7
insbl $8,0,$21
bic $19,255,$20
cpys $f31,$f31,$f31
bis $0,$7,$16
stl $16,0($30)
bis $21,$20,$22
stl $22,4($30)
stq $24,8($3)
lda $23,16($15)
stq $30,16($3)
bis $31,$31,$31
stq $23,0($3)
lda $3,4096($31)
ldl $25,0($30)
sll $25,40,$26
sra $26,56,$27
s4addq $27,30,$28
bic $28,15,$1
cmpult $1,$3,$5
subq $30,$1,$2
bne $5,$L7
lda $6,-4096($30)
bis $31,$31,$31
$L6:
stq $31,0($6)
lda $6,-8192($6)
cmpule $6,$2,$4
beq $4,$L6
stq $31,0($2)
$L7:
mov $2,$30
mov $30,$16
ble $27,$L9
subl $27,1,$0
zapnot $0,15,$7
mov $31,$17
s4addq $7,4,$18
jsr $26,memset
ldgp $29,0($26)
$L9:
jsr $26,sub2
$L2:
lda $15,-16($15)
br $27,$LSJ100
$LSJ100:
ldgp $29,0($27)
ldq $16,16($15)
lda $17,$LC0
jsr $26,strcmp
ldgp $29,0($26)
bne $0,$L17
mov $31,$16
jsr $26,exit
$L17:
br $31,$L4
.section.text.unlikely
.ent main.cold.0
main.cold.0:
.frame $15,32,$26,0
.mask 0x4008000,-32
$L4:
$LCFI4:
jsr $26,abort
$LFE1:
.section.text.startup
bis $31,$31,$31
.end main
.section.text.unlikely
bis $31,$31,$31
.end main.cold.0
$LCOLDE1:
.section.text.startup
$LHOTE1:
.section.text.unlikely
.align 2
$LCOLDB2:
.text
$LHOTB2:
.align 2
.align 4
.globl sub2
.ent sub2
sub2:
.frame $15,16,$26,0
.mask 0x4008000,-16
$LFB0:
ldgp $29,0($27)
$sub2..ng:
lda $30,-16($30)
$LCFI5:
lda $1,buf
stq $15,8($30)
$LCFI6:
mov $30,$15
$LCFI7:
stq $26,0($30)
$LCFI8:
.prologue 1
ldq $27,8($1)
ldq $15,0($1)
ldq $30,16($1)
jmp $31,($27),0
$LFE0:
.end sub2
.section.text.unlikely
$LCOLDE2:
.text
$LHOTE2:
[...]
--cut here--

[Bug gcov-profile/65929] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Created attachment 35422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35422&action=edit
Preprocessed source

[Bug gcov-profile/65929] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Created attachment 35423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35423&action=edit
gcda file

[Bug gcov-profile/65929] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
The difference between new (zzz.s) and previous (yyy.s) asm dumps is:

--- yyy.s   2015-04-29 13:44:03.870706031 +0200
+++ zzz.s   2015-04-29 13:26:41.812887199 +0200
@@ -99,7 +99,10 @@
 $L17:
br $31,$L4
.section.text.unlikely
+   .ent main.cold.0
 main.cold.0:
+   .frame $15,32,$26,0
+   .mask 0x4008000,-32
 $L4:
 $LCFI4:
jsr $26,abort
@@ -108,6 +111,8 @@
bis $31,$31,$31
.end main
.section.text.unlikely
+   bis $31,$31,$31
+   .end main.cold.0
 $LCOLDE1:
.section.text.startup
 $LHOTE1:

[Bug target/51996] ICE in extract_insn gcc.dg/pr48335-5.c

[shenders at gcc dot gnu.org]

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

Stuart Henderson  changed:

   What|Removed |Added

 CC||shenders at gcc dot gnu.org

--- Comment #2 from Stuart Henderson  ---
FYI: Julian Brown from Codesourcery posted a patch here:
https://gcc.gnu.org/ml/gcc-patches/2013-06/msg00947.html
back in 2013, but it appears to have been orphaned along the way.

[Bug tree-optimization/57634] Missed vectorization for a "fixed point multiplication" reduction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-29
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The reduction operation is way too complex (and not handled).  It's

 s = (unsigned int) (((unsigned long long)s * b[i] + 4194304) >> 23)

it's not clear that you can even vectorize this (independently handle
four 's') because of the truncation.  For the case with s being
unsigned long long the point about the not handled reduction operation
is still true.

Thus confirmed in part (redL).

[Bug tree-optimization/61171] vectorization fails for a reduction in presence of subtraction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-29
 Ever confirmed|0   |1

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

[Bug tree-optimization/65930] New: Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

Bug ID: 65930
   Summary: Reduction with sign-change not handled
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Blocks: 53947
  Target Milestone: ---

Neither

int foo (unsigned int *x)
{
  int sum = 0;
  for (int i = 0; i < 4; ++i)
sum += x[i*4+0]+ x[i*4 + 1] + x[i*4 + 2] + x[i*4 + 3];
  return sum;
}

nor

int bar (unsigned int *x)
{
  int sum = 0;
  for (int i = 0; i < 16; ++i)
sum += x[i];
  return sum;
}

are currently vectorized because

t.c:4:3: note: reduction: not commutative/associative: sum_27 = (int) _26;

though the sign of 'sum' vs the sign of 'x' doesn't really matter here.

It works for

unsigned baz (int *x)
{
  unsigned int sum = 0;
  for (int i = 0; i < 16; ++i)
sum += x[i];
  return sum;
}

because C promotes x[i] instead of sum in this case.

For vectorization we might want to change the add(s) to int - of course
not strictly valid because of undefined overflow issues.

This kind of loop appears in a hot area of x264.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-04-29
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

[Bug libstdc++/65927] cppcheck: bits/locale_facets_nonio.h (_M_am_pm_format): Assignment of function parameter has no effect outside the function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-29
 Ever confirmed|0   |1
   Severity|normal  |minor

--- Comment #1 from Jonathan Wakely  ---
Most of the member functions in __timepunct are not used anywhere.

The fix for this would be:

--- a/libstdc++-v3/include/bits/locale_facets_nonio.h
+++ b/libstdc++-v3/include/bits/locale_facets_nonio.h
@@ -237,8 +237,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }

   void
-  _M_am_pm_format(const _CharT* __ampm) const
-  { __ampm = _M_data->_M_am_pm_format; }
+  _M_am_pm_format(const _CharT** __ampm) const
+  { *__ampm = _M_data->_M_am_pm_format; }

   void
   _M_am_pm(const _CharT** __ampm) const

But we could just as well remove the function entirely.

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #45 from James Greenhalgh  ---
(In reply to mwahab from comment #44)
> (In reply to James Greenhalgh from comment #43)
> > (In reply to torvald from comment #37)
> > 
> > > > I'm not worried about __sync_lock_release, I think the documentation is
> > > > strong enough and unambiguous.
> > > 
> > > Are you aware that the GCC's __sync disallow store-store reordering across
> > > __sync_lock_release, whereas the psABI docs don't?
> > 
> > No I was not, and even looking exactly for the text you were referring to,
> > it took
> > me three attempts to spot it. Yes, I understand now why you are concerned
> > about
> > the GCC wording. Perhaps this is just an artefact of a mistake transcribing
> > the psABI?
> > 
> > AArch64 is certainly not providing that guarantee just now.
> 
> I wasn't able to find the text, could you copy it in a reply. 
> In the GCC manual, the only description of __sync_lock_release behaviour is
> in the last paragraph. That descriptions seems consistent with the function
> being a release barrier and with the current Aarch64 code generated for it.

Yes, so this part is fine...

  void __sync_lock_release (type *ptr, ...)

  This built-in function releases the lock acquired by
  __sync_lock_test_and_set. Normally this means writing the
  constant 0 to *ptr.

  This built-in function is not a full barrier, but rather a release barrier.
  This means that all previous memory stores are globally visible, and all
  previous memory loads have been satisfied,

And this final sentence is buggy by omission of a mention of memory writes:

  but following memory reads are not prevented from being speculated to
  before the barrier.

Which can be read as forbidding store-store reordering across the barrier.

As I say though, I think this is an artefact of transcribing the documentation,
rather than an attempt to provide stronger ordering semantics in the GCC
implementation.

[Bug c++/65923] False positive for warning about literal operator suffix and using

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-29
 CC||emsr at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes, the warning is meant to be for declaring invalid UDLs, but should not fire
for a using-declaration.

[Bug libstdc++/65928] std::find_if compilation errors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Definitely not a libstdc++ bug, the code is simply not valid C++ because
std::isblank is an overloaded function.

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[LpSolit at netscape dot net]

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

--- Comment #25 from Frédéric Buclin  ---
Did this problem disappear? Or are there still some bugmails today with a wrong
timestamp?

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
More "correct" would be to replace the reduction in sum with one using an
unsigned int type.  Not sure where this kind of transform would fit best,
but as it's an enablement for vectorization I suppose the vectorizer should
take care of that.

[Bug target/65931] New: [5/6 regression] dsymutil assertion failure building libgnat-5.dylib

[ro at gcc dot gnu.org]

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

Bug ID: 65931
   Summary: [5/6 regression] dsymutil assertion failure building
libgnat-5.dylib
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: howarth.at.gcc at gmail dot com, iains at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin14.3.0
Target: x86_64-apple-darwin14.3.0
 Build: x86_64-apple-darwin14.3.0

For about two weeks (thus affecting both the gcc-5 branch and mainline), Ada
bootstrap on Mac OS X 10.10.3 is broken:

cd rts; dsymutil libgnat-5.dylib
Assertion failed: (linked_addr_pos != line_table_map.end()), function
FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-121/source/DWARFdSYM.cpp, line
3883.
/bin/sh: line 1: 85928 Abort trap: 6   dsymutil libgnat-5.dylib
make[3]: *** [gnatlib-shared-darwin] Error 134

This is dsymutil from dwarfutils-121.  I haven't yet checked if gcc's DWARF
output
changed in a way dsymutil cannot handle or dsymutil was upgraded (from Mac OS
10.10.2 to .3) adding some bogus check.

  Rainer

[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |5.2

[Bug libstdc++/65928] std::find_if compilation errors

[david.claessens at tomra dot com]

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

--- Comment #3 from david.claessens at tomra dot com ---
To be honest, I would have expected that since only  is included and
not  where the other version of isblank is defined, there would be no
confusion.

[Bug libstdc++/65928] std::find_if compilation errors

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
It's unspecified whether any of your headers includes , and in our
implementation  includes it.

[Bug libstdc++/65928] std::find_if compilation errors

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
More precisely,  includes  which declares (but does
not define) the overload of std::isblank.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

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

--- Comment #34 from Jürgen Reuter  ---
Andre, I checked your patch with r222305 of the gcc 6.0 trunk. Our complete
code (without workarounds for the two remaining cases reported) compiles, and
our complete testsuite works. Thanks for the patch.

[Bug libstdc++/65928] std::find_if compilation errors

[david.claessens at tomra dot com]

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

--- Comment #6 from david.claessens at tomra dot com ---
Apparently it is not (only) included from string.
Changing to a char array and removing that include doesn't change anything.

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[mwahab at gcc dot gnu.org]

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

--- Comment #46 from mwahab at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #45)
> (In reply to mwahab from comment #44)
>
> And this final sentence is buggy by omission of a mention of memory writes:
> 
>   but following memory reads are not prevented from being speculated to
>   before the barrier.
> 
> Which can be read as forbidding store-store reordering across the barrier.

It doesn't say anything about store-store reordering so it's trumped by the
stated intention to be compatible with the psABI.

> As I say though, I think this is an artefact of transcribing the
> documentation, rather than an attempt to provide stronger ordering semantics
> in the GCC implementation.

Agreed.

[Bug libstdc++/65928] std::find_if compilation errors

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The code is invalid. No amount of fiddling about with headers will change that.
Even if you manage to find some combination that works today, it might not work
tomorrow or with a different compiler. Fix the code.

[Bug c++/55080] -pedantic produces error: floating-point literal cannot appear in a constant-expression

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
This should be an easy fix once a solution and the text is agreed.

[Bug c++/55080] -pedantic produces error: floating-point literal cannot appear in a constant-expression

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #3 from Manuel López-Ibáñez  ---
This should be an easy fix once a solution and the text is agreed.

[Bug c++/55095] Wshift-overflow

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #9 from Manuel López-Ibáñez  ---
Marek has been doing some nice work with shift warnings lately, perhaps he
knows how to tackle this.

[Bug preprocessor/52899] tabstop has no effect

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||tromey at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
Recent discussion about this: 

https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00888.html

Joseph thinks it should be fixed:

https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01797.html

[Bug c++/64667] -Winit-self ignored for reference fields

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Apr 29 14:06:27 2015
New Revision: 222577

URL: https://gcc.gnu.org/viewcvs?rev=222577&root=gcc&view=rev
Log:
/cp
2015-04-29  Paolo Carlini  

PR c++/64667
* init.c (perform_member_init): Handle references for -Winit-self.

/testsuite
2015-04-29  Paolo Carlini  

PR c++/64667
* g++.dg/warn/Winit-self-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Winit-self-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/64667] -Winit-self ignored for reference fields

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/51513] Only partially optimizes away __builtin_unreachable switch default case

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
(In reply to Steven Bosscher from comment #4)
> This should be solved by allowing labels in trivially_empty_bb_p.

I tried the following, but it doesn't fix the problem.

--- cfgcleanup.c(revision 222550)
+++ cfgcleanup.c(working copy)
@@ -2647,7 +2647,8 @@ trivially_empty_bb_p (basic_block bb)
 {
   if (insn == BB_HEAD (bb))
return true;
-  if (!DEBUG_INSN_P (insn))
+  if (!(DEBUG_INSN_P (insn)
+   || (LABEL_P (insn) && !LABEL_PRESERVE_P (insn
return false;
   insn = PREV_INSN (insn);
 }

[Bug libstdc++/64657] Support iterators with overloaded operator-comma

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed Apr 29 15:22:13 2015
New Revision: 222579

URL: https://gcc.gnu.org/viewcvs?rev=222579&root=gcc&view=rev
Log:
PR libstdc++/64657
* include/bits/basic_string (basic_string::_S_copy_chars): Cast
expression to void.
* include/bits/locale_facets_nonio.tcc (money_get::_M_extract,
time_get::_M_extract_num, time_get::_M_extract_name,
time_get::_M_extract_wday_or_month): Likewise.
* include/bits/stl_algo.h (__includes, __replace_copy_if,
__is_sorted_until, __is_permutation, transform): Likewise.
* include/bits/stl_algobase.h (swap_ranges, __copy_move::__copy_m,
__equal::equal, __lexicographical_compare_impl, equal): Likewise.
* include/bits/stl_numeric.h (inner_product): Likewise.
* include/bits/stl_uninitialized.h (__uninitialized_copy_a): Likewise.
* testsuite/util/testsuite_iterators.h (output_iterator_wrapper,
input_iterator_wrapper): Declare unusable comma operator.
* testsuite/21_strings/basic_string/cons/char/64657.cc: New.
* testsuite/21_strings/basic_string/modifiers/assign/char/64657.cc:
New.

Added:
trunk/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/64657.cc
   
trunk/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/64657.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/basic_string.h
trunk/libstdc++-v3/include/bits/locale_facets_nonio.tcc
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/include/bits/stl_algobase.h
trunk/libstdc++-v3/include/bits/stl_numeric.h
trunk/libstdc++-v3/include/bits/stl_uninitialized.h
trunk/libstdc++-v3/testsuite/util/testsuite_iterators.h

[Bug libstdc++/64657] Support iterators with overloaded operator-comma

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed

[Bug target/65932] New: [5.1 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[christian.eggers at kathrein dot de]

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

Bug ID: 65932
   Summary: [5.1 Regression] Linux-3.10.75 on arm926ej-s does not
boot due to wrong code generation
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christian.eggers at kathrein dot de
  Target Milestone: ---

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

gcc version: 5.1.0 / 5.1.1 (current git snapshot)

host : x86_64_suse_linux (13.1)

target: arm-arm926ejs-linux-gnueabi

Configured with:
/home/eggers/Projekte/cds/repos/software/tools/toolchain/src/gcc-gcc-5-branch-1e71966/configure
--prefix=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi
--with-pkgversion='Kathrein CDS 15278' --target=arm-arm926ejs-linux-gnueabi
--disable-multilib
--mandir=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/share/man
--infodir=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/share/info
--with-gmp=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/install
--with-mpfr=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/install
--with-mpc=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/install
--with-isl=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/install
--with-sysroot=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/sys-root
--disable-nls
--with-slibdir=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/sys-root/lib
--with-gxx-include-dir=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/sys-root/usr/include/c++/gcc-5-branch-1e71966
--enable-shared --enable-__cxa_atexit --enable-c99 --enable-threads=posix
--disable-install-libiberty --with-system-zlib --with-cpu=arm926ej-s
--with-float=soft --with-mode=arm --enable-languages=c,c++ --enable-long-long

command line: arm-arm926ejs-linux-gnueabi-gcc -Wp,-MD,lib/.vsprintf.o.d 
-nostdinc -isystem
/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/lib64/gcc/arm-arm926ejs-linux-gnueabi/5.1.0/include
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/arch/arm/include
-Iarch/arm/include/generated 
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/include
-Iinclude
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/arch/arm/include/uapi
-Iarch/arm/include/generated/uapi
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/include/uapi
-Iinclude/generated/uapi -include
/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/include/linux/kconfig.h

-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/lib
-Ilib -D__KERNEL__ -mlittle-endian  
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/arch/arm/mach-at91/include
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized
-fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables
-marm -D__LINUX_ARM_ARCH__=5 -march=armv5te -mtune=arm9tdmi -msoft-float -Uarm
-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable
-fomit-frame-pointer -fno-var-tracking-assignments -g
-fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO   
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vsprintf)" 
-D"KBUILD_MODNAME=KBUILD_STR(vsprintf)" -c -o lib/vsprintf.o
/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/lib/vsprintf.c

linux-3.10.75 compiled with gcc-4.9.2  --> running
same kernel compiled with gcc-5.1.0 / gcc-5.1.1 (git snapshot) --> NOT running

Observations

Function string() (part of vsnprintf()) in lib/vsprintf.c is not compiled
correctly:

 f5c:   e1dd51f8ldrsh   r5, [sp, #24]

[...] 
# r5 = 0x 
 f70:   e2453001sub r3, r5, #1
# r3 = 0x FFFE
 f74:   e1a03803lsl r3, r3, #16
# r3 = 0xFFFE 
while (len < spec.field_width--) {

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[trippels at gcc dot gnu.org]

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

--- Comment #26 from Markus Trippelsdorf  ---
Path: news.gmane.org!not-for-mail   
From: "christian.eggers at kathrein dot de"   
Newsgroups: gmane.comp.gcc.bugs 
Subject: [Bug target/65932] New: [5.1 Regression] Linux-3.10.75 on arm926ej-s
does not boot due to wrong code generation  
Date: Wed, 29 Apr 2015 10:29:49 +   
Lines: 113  
Approved: n...@gmane.org
Message-ID: 
NNTP-Posting-Host: plane.gmane.org  
Mime-Version: 1.0   
Content-Type: text/plain; charset="UTF-8"   
Content-Transfer-Encoding: 7bit 
X-Trace: ger.gmane.org 1430323200 7510 80.91.229.3 (29 Apr 2015 16:00:00 GMT)   
X-Complaints-To: use...@ger.gmane.org   
NNTP-Posting-Date: Wed, 29 Apr 2015 16:00:00 + (UTC)
To: gcc-bugs@gcc.gnu.org
Original-X-From: gcc-bugs-return-484992-gcgb-bugs-2=m.gmane@gcc.gnu.org Wed
Apr 29 17:59:59 2015
Return-path:
Envelope-to: gcgb-bug...@plane.gmane.org
Original-Received: from server1.sourceware.org ([209.132.180.131]
helo=sourceware.org)
by plane.gmane.org with esmtp (Exim 4.69)   
(envelope-from
)   
id 1YnUOz-0001Mr-Sk 
for gcgb-bug...@plane.gmane.org; Wed, 29 Apr 2015 17:59:58 +0200
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id  
:list-unsubscribe:list-archive:list-post:list-help:sender:from  
:to:subject:date:message-id:content-type
:content-transfer-encoding:mime-version; q=dns; s=default; b=wF4
XpCycQCKvZYEpgslmjeE/iyiMnzvS1lDuekTkvBsh11w0fFLtrheGihbsGd4KOB9
ivtOHv6qMqlEQFpYWzluqxl6rLzXuUCD+WQFy4JkOijERIaAslqvycmQ+a3zAZKZ
1y/iA4Y0U5IceFqB9oakq8ZhmuhC7yETPRNmgnfI=   
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id
:list-unsubscribe:list-archive:list-post:list-help:sender:from  
:to:subject:date:message-id:content-type
:content-transfer-encoding:mime-version; s=default; bh=MPQLMLxNK
n5OEvc8DOdegu6zUbA=; b=lvJgWyPE2h0vlF+zFQdx9kxE+20elsY465TPyxTUv
f6bSgFWl9zYehzSjTv8mhRd0ogv7ZD2Nuiyyf1wb3gWdeVd8aWJ4fCWuTLRejMA6
XTLhIodTKUNUl5S/0Q8Mdvduu6v2+tZyDSoBFX7ZCDjtR8K3JrhqR8okTbijha6u
mg= 
Original-Received: (qmail 114156 invoked by alias); 29 Apr 2015 15:59:55 -  
Mailing-List: contact gcc-bugs-h...@gcc.gnu.org; run by ezmlm   
Precedence: bulk
List-Id:  
List-Unsubscribe:
   
List-Archive:  
List-Post: 
List-Help:    
Original-Sender: gcc-bugs-ow...@gcc.gnu.org 
Delivered-To: mailing list gcc-bugs@gcc.gnu.org 
Original-Received: (qmail 114125 invoked by uid 48); 29 Apr 2015 15:59:51 - 
X-Bugzilla-Reason: CC   
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None   
X-Bugzilla-Product: gcc 
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.1   
X-Bugzilla-Keywords:
X-Bugzilla-Severity: critical   
X-Bugzilla-Who: christian.eggers at kathrein dot de 
X-Bugzilla-Status: UNCONFIRMED   

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[amacleod at redhat dot com]

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

--- Comment #47 from Andrew Macleod  ---
Created attachment 35425
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35425&action=edit
potential patch to add MEMMODEL_SYNC

I don't know where we've finally settled on this, but I did prototype out what
involved in adding a new MEMMODEL_SYNC which can be identified and made
stronger than MEMMODEL_SEQ_CST if so desired. Normally it will behave exactly
like MEMMODEL_SEQ_CST.   This bootstraps on x86-64 with no testsuite
regressions.

Other than using the new memmodel in the expanders for __sync routines, there
were 3 common idioms that needed changing:
- a few places assumed SEQ_CST was the end of the enumeration, changed those to
check for MEMMODEL_LAST instead. 
- if (model == MEMMODEL_SEQ_CST) needed changing to if (model >=
MEMMODEL_SEQ_CST)
- case MEMMODEL_SEQ_CST:  needed a CASE MEMMODEL_SYNC: added.

Its actually not that invasive, and should have no impact on any existing
target.  If a target feels they need to strengthen the __sync cases, then they
can look for MEMMODEL_SYNC in their rtl atomic patterns and do something
different.

I did a quick and dirty test on x86_64 to make the atomic_sub pattern issue an
extra lock if it sees MEMMODEL_SYNC.. and that worked fine.

MEMMODEL_SYNC is not exposed in any way to the user, it is only generated from
the __sync expanders, and the compare_swap loop generator.

If someone wants to fool around with it and see if this resolves their issues,
go for it.  

If we decide we don't need to support a stronger __sync model and leave things
as originally intended, then we simply don't use the patch.

If we do decide to go ahead with it, I will also do a comparison run on the
__sync tests in the testsuite to verify that the code generated is in fact
identical and I didn't miss anything.

[Bug libstdc++/65760] invalid use of incomplete type with std::is_convertible

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed Apr 29 16:07:47 2015
New Revision: 222581

URL: https://gcc.gnu.org/viewcvs?rev=222581&root=gcc&view=rev
Log:
PR libstdc++/65760
* include/std/functional (__check_func_return_type): Use is_same to
avoid using _is_convertible on incomplete types.
* testsuite/20_util/function/65760.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/function/65760.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional

[Bug libstdc++/65760] invalid use of incomplete type with std::is_convertible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk.

[Bug c/64610] No -Wbool-compare warning on "(0 != a) >= 0"

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Apr 29 18:13:44 2015
New Revision: 222587

URL: https://gcc.gnu.org/viewcvs?rev=222587&root=gcc&view=rev
Log:
PR c/64610
* c-common.c (maybe_warn_bool_compare): Warn when comparing a boolean
with 0/1.

* c-c++-common/Wbool-compare-1.c (fn1): Remove a few lines.
* c-c++-common/Wbool-compare-2.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wbool-compare-2.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wbool-compare-1.c

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

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
Created attachment 35426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35426&action=edit
gzipped C++ source code

gcc trunk dated 20150427 ices in the same way on the attached code.

[Bug c/64610] No -Wbool-compare warning on "(0 != a) >= 0"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Should be fixed.

[Bug other/65933] New: final.c:2239:8: error: 'vector_type_mode' was not declared in this scope

[danglin at gcc dot gnu.org]

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

Bug ID: 65933
   Summary: final.c:2239:8: error: 'vector_type_mode' was not
declared in this scope
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

In r222551, the following error occurs in stage1:

g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-
W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I.
-I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gmp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o final.o -MT final.o -MMD
-MP -MF ./.deps/final.TPo ../../gcc/gcc/final.c
../../gcc/gcc/final.c: In function 'rtx_insn* final_scan_insn(rtx_insn*, FILE*,
int, int, int*)':
../../gcc/gcc/final.c:2239:8: error: 'vector_type_mode' was not declared in
this scope
../../gcc/gcc/final.c:2239:8: error: 'vector_type_mode' was not declared in
this scope
make[3]: *** [final.o] Error 1

[Bug debug/65934] New: objdump can't print correct DW_AT_encoding name

[jamesgua at ca dot ibm.com]

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

Bug ID: 65934
   Summary: objdump can't print correct DW_AT_encoding name
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamesgua at ca dot ibm.com
  Target Milestone: ---

In DWARF 4 spec DW_ATE_UTF is value 0x10 or 16, but objdump can't map that
value to UTF, instead, print "unknown type":

e.g.
char16_t utf16 = u'a';
...
<3><148>: Abbrev Number: 7 (DW_TAG_variable)
<149>   DW_AT_name: (indirect string, offset: 0x139): utf16
<14d>   DW_AT_decl_file   : 1
<14e>   DW_AT_decl_line   : 9
<14f>   DW_AT_type: <0x178>
<153>   DW_AT_location: 3 byte block: 91 de 7e  (DW_OP_fbreg: -162)
...
<1><178>: Abbrev Number: 2 (DW_TAG_base_type)
<179>   DW_AT_byte_size   : 2
<17a>   DW_AT_encoding: 16  (unknown type)
<17b>   DW_AT_name: (indirect string, offset: 0x13f): char16_t

It should be displayed UTF like similar to other values 
...
<1c8>   DW_AT_encoding: 7   (unsigned)

[Bug debug/65934] objdump can't print correct DW_AT_encoding name

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You should file this bug to binutils rather than GCC since GCC is outputting
the correct value.  binutils bugzilla can be found at
https://sourceware.org/bugzilla/ .

[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Apr 29 18:53:19 2015
New Revision: 222588

URL: https://gcc.gnu.org/viewcvs?rev=222588&root=gcc&view=rev
Log:
PR target/65871
* config/i386/i386.md (*bmi_bextr__cczonly): New pattern.
(*bmi2_bzhi_3_1_cczonly): Ditto.

testsuite/ChangeLog:

PR target/65871
* gcc.target/i386/pr65871-1.c: New test
* gcc.target/i386/pr65871-2.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr65871-1.c
trunk/gcc/testsuite/gcc.target/i386/pr65871-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[hjl.tools at gmail dot com]

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

--- Comment #21 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #19)
> I know it isn't the same.  But, IMHO this isn't worth adding another knob
> which will be a maintainance nightmare.

Performance difference between -fsymbolic -fPIE and -fPIC on PIE is
about 2%.  X86 and x86-64 Android don't support copy reloc.  All
executables are compiled as PIE. -fPIE no longer works on Android.

Can you explain why -fsymbolic is a maintenance nightmare?

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[hjl.tools at gmail dot com]

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

--- Comment #22 from H.J. Lu  ---
Created attachment 35427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35427&action=edit
A patch to enable -fsymbolic in LTO if -Bsymbolic is used

This patch improves LTO when -Bsymbolic is used.

[Bug other/65933] final.c:2239:8: error: 'vector_type_mode' was not declared in this scope

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Seems like stor-layout.h needs to be included somewhere.

[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[daniel.f.starke at freenet dot de]

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

Daniel Starke  changed:

   What|Removed |Added

 CC||daniel.f.starke at freenet dot 
de

--- Comment #17 from Daniel Starke  ---
I have used a different example to debug this issue. This was easier for me to
reconstruct the problem. The reason for this problem is probably the same.
Using gcc 5.1.0 and binutils 2.25 on mingw32-w64 (Windows host) I observed that
the first object file passed to lto-wrapper.exe fails to be included in the
list of object files. This happens because find_and_merge_options() in
run_gcc() fails when executing simple_object_find_section() for the section
.gnu.lto_.opts which appears to be inside the object file in question (checked
with objdump). Further investigation seems to be needed to track down why it
only fails to read the section only for some object files. Maybe some
incompatibility between the new binutils and gcc?

[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[ktietz at gcc dot gnu.org]

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

--- Comment #18 from Kai Tietz  ---
Does the following patch fixes your problem?

Index: lto-wrapper.c
===
--- lto-wrapper.c   (Revision 69)
+++ lto-wrapper.c   (Arbeitskopie)
@@ -934,7 +934,7 @@ run_gcc (unsigned argc, char *argv[])
  filename[p - argv[i]] = '\0';
  file_offset = (off_t) loffset;
}
-  fd = open (argv[i], O_RDONLY);
+  fd = open (argv[i], O_RDONLY|O_BINARY);
   if (fd == -1)
{
  lto_argv[lto_argc++] = argv[i];

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[jason at gcc dot gnu.org]

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

--- Comment #17 from Jason Merrill  ---
Author: jason
Date: Wed Apr 29 20:51:05 2015
New Revision: 222591

URL: https://gcc.gnu.org/viewcvs?rev=222591&root=gcc&view=rev
Log:
PR c++/50800
* tree.c (apply_identity_attributes): Fix handling of classes.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alignas3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c

[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Apr 29 20:58:25 2015
New Revision: 222592

URL: https://gcc.gnu.org/viewcvs?rev=222592&root=gcc&view=rev
Log:
PR target/65871
* config/i386/i386.md (*bmi_bextr__cczonly): New pattern.
(*bmi2_bzhi_3_1_cczonly): Ditto.
(setcc+movzbl peephole2): Check also clobbered reg.
(setcc+andl peephole2): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

[Bug libstdc++/65839] xmethods need updating once gdb decides how to fix 18285

[devans at gcc dot gnu.org]

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

--- Comment #4 from devans at gcc dot gnu.org ---
Author: devans
Date: Wed Apr 29 22:50:31 2015
New Revision: 222599

URL: https://gcc.gnu.org/viewcvs?rev=222599&root=gcc&view=rev
Log:
PR libstdc++/65839
* python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
Replace all lookups of "bool" with this.
(get_std_size_type): New function.  Replace all lookups of std::size_t
with this.
(*Worker): New method get_result_type.
(DequeWorkerBase.__init__): New arg val_type.  All callers updated.
(ListWorkerBase.__init__): New arg val_type.  All callers updated.
(UniquePtrGetWorker.__init__): New arg elem_type.  All callers updated.
Delete setting of name, enabled.
(UniquePtrDerefWorker.__init__): New arg elem_type.  All callers
updated.  Delete setting of name.
(UniquePtrMethodsMatcher): Rewrite for consistency with all other
libstdc++ xmethod matchers.
* testsuite/libstdc++-xmethods/array.cc: Add whatis tests.
* testsuite/libstdc++-xmethods/associative-containers.cc: Ditto.
* testsuite/libstdc++-xmethods/deque.cc: Ditto.
* testsuite/libstdc++-xmethods/forwardlist.cc: Ditto.
* testsuite/libstdc++-xmethods/list.cc: Ditto.
* testsuite/libstdc++-xmethods/unique_ptr.cc: Ditto.
* testsuite/libstdc++-xmethods/vector.cc: Ditto.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/xmethods.py
trunk/libstdc++-v3/testsuite/libstdc++-xmethods/array.cc
trunk/libstdc++-v3/testsuite/libstdc++-xmethods/associative-containers.cc
trunk/libstdc++-v3/testsuite/libstdc++-xmethods/deque.cc
trunk/libstdc++-v3/testsuite/libstdc++-xmethods/forwardlist.cc
trunk/libstdc++-v3/testsuite/libstdc++-xmethods/list.cc
trunk/libstdc++-v3/testsuite/libstdc++-xmethods/unique_ptr.cc
trunk/libstdc++-v3/testsuite/libstdc++-xmethods/vector.cc

[Bug c++/61683] decltype-specifier not accepted as mem-initializer-id

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |6.0

--- Comment #1 from Paolo Carlini  ---
Mine.

[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #3 from amker at gcc dot gnu.org ---
Hi,
The newly added test case failed on aarch64 as below:

FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^\\n]*inline copy
in test"

GCC is configured with below options:

/home/.../src/gcc/configure \
  --target=aarch64-none-elf \
  --prefix=/home/.../target-aarch64-none-elf.orig \
  --with-gmp=/home/.../build-aarch64-none-elf.orig/host-tools \
  --with-mpfr=/home/.../build-aarch64-none-elf.orig/host-tools \
  --with-mpc=/home/.../build-aarch64-none-elf.orig/host-tools \
  --with-cloog=/home/.../build-aarch64-none-elf.orig/host-tools \
  --with-isl=/home/.../build-aarch64-none-elf.orig/host-tools \
  --with-pkgversion=unknown \
  --disable-shared --disable-nls \
  --disable-threads --disable-tls \
  --enable-checking=yes \
  --enable-languages=c,c++ --with-newlib

[Bug tree-optimization/65935] New: [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

Bug ID: 65935
   Summary: [6 Regression] 433.milc in SPEC CPU 2006 is
miscompiled
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On Linux/i686, r62283 miscompiled 433.milc in SPEC CPU 2006:

gcc -m32 -c -o com_vanilla.o -DSPEC_CPU -DNDEBUG -I. -DFN -DFAST
-DCONGRAD_TMP_VECTORS -DDSLASH_TMP_LINKS  -O3 -funroll-loops -msse2
-mfpmath=sse -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin   
com_vanilla.c
gcc -m32 -c -o io_nonansi.o -DSPEC_CPU -DNDEBUG -I. -DFN -DFAST
-DCONGRAD_TMP_VECTORS -DDSLASH_TMP_LINKS  -O3 -funroll-loops -msse2
-mfpmath=sse -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin   
io_nonansi.c
gcc -m32  -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math -fwhole-program
-flto=jobserver -fuse-linker-plugin  control.o f_meas.o gauge_info.o
setup.o update.o update_h.o update_u.o layout_hyper.o check_unitarity.o
d_plaq4.o gaugefix2.o io_helpers.o io_lat4.o make_lattice.o path_product.o
ploop3.o ranmom.o ranstuff.o reunitarize2.o gauge_stuff.o grsource_imp.o
mat_invert.o quark_stuff.o rephase.o cmplx.o addmat.o addvec.o clear_mat.o
clearvec.o m_amatvec.o m_mat_an.o m_mat_na.o m_mat_nn.o m_matvec.o make_ahmat.o
rand_ahmat.o realtr.o s_m_a_mat.o s_m_a_vec.o s_m_s_mat.o s_m_vec.o s_m_mat.o
su3_adjoint.o su3_dot.o su3_rdot.o su3_proj.o su3mat_copy.o submat.o subvec.o
trace_su3.o uncmp_ahmat.o msq_su3vec.o sub4vecs.o m_amv_4dir.o m_amv_4vec.o
m_mv_s_4dir.o m_su2_mat_vec_n.o l_su2_hit_n.o r_su2_hit_a.o m_su2_mat_vec_a.o
gaussrand.o byterevn.o m_mat_hwvec.o m_amat_hwvec.o dslash_fn2.o
d_congrad5_fn.o com_vanilla.o io_nonansi.o -lm-o milc

  Running 433.milc ref peak lto default

433.milc: copy 0 non-zero return code (exit code=1, signal=0)

WARMUPS COMPLETED
Unitarity problem on node 0, site 0, dir 0 tolerance=1.00e-04
SU3 matrix:
0.991448 0.021247 -0.099836 -0.054012 0.051686 0.032000 
0.100302 -0.049616 0.989806 -0.028206 0.027581 -0.078778 
-0.059070 0.023841 -0.022247 -0.078163 0.994634 0.006470 
repeat in hex:
82a7e05f 9c8421c0 b159fbbd cc2c8301 eca1e2e4 4a88bfbf 
7c12f3d5 f7ba11aa 1939e0e5 a49c5e6c 0095ea4b a16c5754 
cfce59e0 209d3be4 702a8d28 2fdd37ea d75f9836 f0058a61 
...
Unitarity error count exceeded.
termination: Wed Apr 29 11:44:07 2015

Termination: status = 1

[Bug testsuite/62234] warnings/errors from LTO cannot be tested

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01538.html has a testcase that
should be added once this is fixed.

[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-30
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
gcc -m32  -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math also miscompiled.

[Bug tree-optimization/65337] [5/6 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Last reconfirmed|2015-03-13 00:00:00 |2015-4-30

--- Comment #5 from Jan Hubicka  ---
Still ICE during LTObootstrap on PPC64 (gcc110). I will try to at least figure
out what goes wrong with the PHI (if it is wrong control dependency due to
critical edge or something else)

I suppose we can relax the check to:

  degenerate_phi_p (phi) || SSA_NAME_OCCURS_IN_ABNORMAL_PHI (gimple_phi_result
(phi)

but we may need to trigger SSA rewrite on resulting code as cddce will break
dominance conditions on the PHI.

[Bug c++/65936] New: [6 Regression] ICE building libboost_log.so.1.58.0

[jamrial at gmail dot com]

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

Bug ID: 65936
   Summary: [6 Regression] ICE building libboost_log.so.1.58.0
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

Created attachment 35428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35428&action=edit
Preprocessed source as generated by -freport-bug

In file included from ./boost/move/utility_core.hpp:29:0,
 from ./boost/intrusive/list.hpp:39,
 from libs/log/src/attribute_set.cpp:19:
./boost/log/attributes/attribute_set.hpp: In member function
‘boost::log::v2_mt_posix::attribute_set::operator
boost::rv&()’:
./boost/move/core.hpp:246:56: internal compiler error: canonical types differ
for identical types boost::rv* and
boost::rv*
   {  return *static_cast< ::boost::rv* >(this);  }\
^
./boost/log/attributes/attribute_set.hpp:82:5: note: in expansion of macro
‘BOOST_COPYABLE_AND_MOVABLE_ALT’
 BOOST_COPYABLE_AND_MOVABLE_ALT(attribute_set)
 ^
0x746a4e comptypes(tree_node*, tree_node*, int)
/home/jamrial/gcc-6-20150426/gcc/cp/typeck.c:1428
0x7619de ocp_convert(tree_node*, tree_node*, int, int, int)
/home/jamrial/gcc-6-20150426/gcc/cp/cvt.c:704
0x607310 convert_like_real
/home/jamrial/gcc-6-20150426/gcc/cp/call.c:6557
0x612e0b initialize_reference(tree_node*, tree_node*, int, int)
/home/jamrial/gcc-6-20150426/gcc/cp/call.c:9746
0x750bf2 check_return_expr(tree_node*, bool*)
/home/jamrial/gcc-6-20150426/gcc/cp/typeck.c:8718
0x78e59e finish_return_stmt(tree_node*)
/home/jamrial/gcc-6-20150426/gcc/cp/semantics.c:887
0x731cbe cp_parser_jump_statement
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:11057
0x731cbe cp_parser_statement
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:9707
0x732252 cp_parser_statement_seq_opt
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:10095
0x7323ab cp_parser_compound_statement
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:10049
0x7325db cp_parser_function_body
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:19185
0x7325db cp_parser_ctor_initializer_opt_and_function_body
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:19221
0x73341a cp_parser_function_definition_after_declarator
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:23467
0x736a6c cp_parser_late_parsing_for_member
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:24150
0x711c71 cp_parser_class_specifier_1
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:20041
0x711c71 cp_parser_class_specifier
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:20067
0x711c71 cp_parser_type_specifier
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:14707
0x724eff cp_parser_decl_specifier_seq
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:11938
0x7361b1 cp_parser_simple_declaration
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:11515
0x72fe23 cp_parser_block_declaration
/home/jamrial/gcc-6-20150426/gcc/cp/parser.c:11462
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

-

This is one of many ICEs i get while compiling libboost_log.so from Boost 1.58
with GCC 6.0.0 (20150426 snapshot) on ArchLinux x86_64. Most if not all seem to
have a similar backtrace, so I'm posting only the first.

[Bug c++/65936] [6 Regression] ICE building libboost_log.so.1.58.0

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-30
 CC||trippels at gcc dot gnu.org
  Known to work||5.0
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat test.ii
class A;
template  struct B
{
  typedef A type;
};
template  class C : public B::type
{
}

__attribute__ ((__may_alias__));
class A
{
  operator const C &() { return *static_cast *> (this); }
};

markus@x4 tmp % g++ -c test.ii
test.ii: In member function ‘A::operator const C&()’:
test.ii:13:72: internal compiler error: canonical types differ for identical
types const C* and const C*

[Bug testsuite/65785] libgo TestIPv4MulticastListener test fails on machine with no network connection

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
ran into this again with new build and test