[Bug c++/67561] New: [C++14] ICE in tsubst_copy (nested auto lambdas may be involved)

[bisqwit at iki dot fi]

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

Bug ID: 67561
   Summary: [C++14] ICE in tsubst_copy (nested auto lambdas may be
involved)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

When compiling this program, 

struct Polygon {};

template
struct View {};

template
void RenderLight(PixType, Params&&... pack)
{
View tmp;
DrawView(pack..., tmp);
}

template
static void DrawPolygon(Plotter plot_pixel)
{
plot_pixel(1,1,1, [&](unsigned n) { return n; });
}

template
static void DrawView(PlotFunc&& GetPlotFunc,
 View& view)
{
DrawPolygon(GetPlotFunc(view, Polygon{}, false));
}

static auto LightmapRenderer = [](unsigned round)
{
return [round](auto& view, const Polygon& polygon, bool)
{
return [=,,](unsigned x,unsigned y, float z, auto&&
prop)
{
if(true) { if(round == 1) {} }
else { if(round > 1) {} }
};
};
};

void CalculateLightmap()
{
RenderLight( 0, LightmapRenderer(1) );
}

The following error is produced:

testv.cc: In instantiation of '::::
[with auto:2 = DrawPolygon(Plotter) [with Plotter = :: [with auto:1 =
View]::]::; auto:1 = View]':
testv.cc:16:15:   required from 'void DrawPolygon(Plotter) [with Plotter =
:: [with auto:1 =
View]::]'
testv.cc:23:16:   required from 'void DrawView(PlotFunc&&, View&) [with
View = View; PlotFunc = ::&]'
testv.cc:10:13:   required from 'void RenderLight(PixType, Params&& ...)
[with PixType = int; Params = {::}]'
testv.cc:40:41:   required from here
testv.cc:29:5: internal compiler error: in tsubst_copy, at cp/pt.c:12997
 {
 ^
0x632bbe tsubst_copy
../../src/gcc/cp/pt.c:12997
0x623a08 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
../../src/gcc/cp/pt.c:15740
0x6246c8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
../../src/gcc/cp/pt.c:14771
0x6242d1 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
../../src/gcc/cp/pt.c:15522
0x62c002 tsubst_expr
../../src/gcc/cp/pt.c:14552
0x63492d tsubst_decl
../../src/gcc/cp/pt.c:11500
0x632a7a tsubst_copy
../../src/gcc/cp/pt.c:13127
0x623a08 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
../../src/gcc/cp/pt.c:15740
0x624ae7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
../../src/gcc/cp/pt.c:14930
0x62c002 tsubst_expr
../../src/gcc/cp/pt.c:14552
0x62b3c5 tsubst_expr
../../src/gcc/cp/pt.c:14113
0x62bf4c tsubst_expr
../../src/gcc/cp/pt.c:14135
0x62b3e5 tsubst_expr
../../src/gcc/cp/pt.c:14115
0x62bf4c tsubst_expr
../../src/gcc/cp/pt.c:14135
0x62b8f4 tsubst_expr
../../src/gcc/cp/pt.c:13949
0x62bf4c tsubst_expr
../../src/gcc/cp/pt.c:14135
0x62acb7 instantiate_decl(tree_node*, int, bool)
../../src/gcc/cp/pt.c:20582
0x659f62 mark_used(tree_node*, int)
../../src/gcc/cp/decl2.c:5035
0x5f9800 build_over_call
../../src/gcc/cp/call.c:7501
0x5fbf31 build_op_call_1
../../src/gcc/cp/call.c:4345
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Compiler version 5.2.1, on Debian x86_64. More information (g++ -v):

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-16'
--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

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> If you had a sanitized version of libgfortran you could check them by 
> yourself.

Could you please post the exact command line you are using for configure and
make and, if needed, the environment?

[Bug target/67447] [6 Regression] ICE in extract_constrain_insn (reload_cse_simplify_operands): insn does not satisfy its constraints

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

   Last reconfirmed||2015-9-12
 CC||miyuki at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #1 from Mikhail Maltsev  ---
I bisected this regression to r227382 (adding Vladimir to CC list). Also, my
guess is that PR67474 could be related (at least, the backtrace looks similar).

[Bug fortran/67560] New: False positive with -fcheck=recursion

[neil.n.carlson at gmail dot com]

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

Bug ID: 67560
   Summary: False positive with -fcheck=recursion
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

The following example produces a runtime recursion error during finalization
with -fcheck=recursion.  There is indeed recursion, but the final subroutine is
declared recursive.

module foo
  type :: list
type(list), pointer :: next => null()
  contains
final :: list_delete
  end type
contains
  recursive subroutine list_delete (this)
type(list), intent(inout) :: this
if (associated(this%next)) deallocate(this%next)
  end subroutine
end module foo

program main
  use foo
  type(list), pointer :: x
  allocate(x)
  allocate(x%next)
  deallocate(x)
end program

[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Jan Hubicka from comment #5)
> > None of them is applicable to a weakdef with "ld -r".
> Yep, GCC simply assumes that incremental linking is not going to happen and
> it makes strong assumptions
> about visibility in static binaries.
> To support incremental linking we need a way to pass this information to
> GCC. Either by extra codes or
> by informing the plugin that linking is incremental.
> See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
> 
> Honza

Linker passes this

/* The type of output file being generated by the linker.  */

enum ld_plugin_output_file_type
{
  LDPO_REL,
  LDPO_EXEC,
  LDPO_DYN,
  LDPO_PIE
};

to GCC plug-in.  But this information is never used by GCC plug-in.

[Bug fortran/67560] False positive with -fcheck=recursion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr67505.

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

[Bug fortran/67505] Runtime error: recursive call to final subroutine

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #2 from Dominique d'Humieres  ---
*** Bug 67560 has been marked as a duplicate of this bug. ***

[Bug c++/67561] [C++14] ICE in tsubst_copy (nested auto lambdas may be involved)

[bisqwit at iki dot fi]

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

Joel Yliluoma  changed:

   What|Removed |Added

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

--- Comment #2 from Joel Yliluoma  ---
Looks like a duplicate of PR67411.

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

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
I believe the test case is erroneous. NULL pointers are dereferenced
in subroutines
source_check and source_check4:

if(str4 == '12a56b78') call abort()

and

if(str4 == 4_'12a56b78') call abort()

are dereferencing the null pointer str4 and this goes down to
string_intrinsics_inc.c

There are more test cases with lvz==0.
If you had a sanitized version of libgfortran you could check them by yourself.

[Bug c++/67559] New: [C++] [regression] Passing non-trivially copyable objects through '...' doesn't generate warning or error

[bisqwit at iki dot fi]

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

Bug ID: 67559
   Summary: [C++] [regression] Passing non-trivially copyable
objects through '...' doesn't generate warning or
error
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

In GCC 4.9, this code generates an error. In GCC 5.2, it generates no warning
or error, even on -Wall -Wextra -pedantic.

struct test { test(){} ~test(){} };
void a(int, ...) {}
int main()
{
test object;
a(5, object);
}

Tried different standards modes: -std=c++98, -std=c++03, -std=c++11, -std=c++14

Tried also lambda functions with variadic args, same result.

The error message in GCC 4.9 (and earier down to 4.6) was:

cannot pass objects of non-trivially-copyable type 'struct test' through
'...'

In GCC 5.2, no error or warning message is given in any of the standard modes.
In the standard version C++03, this behavior is undefined (§5.2.2/7). In C++11,
it is conditionally supported with implementation-defined semantics.

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #11 from Dominique d'Humieres  ---
*** Bug 67562 has been marked as a duplicate of this bug. ***

[Bug fortran/67562] Bad result from sourced allocation with class(*) arrays

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr60322, fixed on trunk (6.0) by revision r222361.

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

[Bug c++/67411] [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473

[bisqwit at iki dot fi]

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

Joel Yliluoma  changed:

   What|Removed |Added

 CC||bisqwit at iki dot fi

--- Comment #2 from Joel Yliluoma  ---
*** Bug 67561 has been marked as a duplicate of this bug. ***

[Bug fortran/67562] New: Bad result from sourced allocation with class(*) arrays

[neil.n.carlson at gmail dot com]

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

Bug ID: 67562
   Summary: Bad result from sourced allocation with class(*)
arrays
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

The following example produces incorrect results from the sourced allocation
involving class(*) arrays.  Perhaps the same as 64692, but that is reported as
fixed.

Expected output:
 source=   1   2
 copy= 1   2 (expect same as source)

But getting this:
 source=   1   2
 copy= 2   0 (expect same as source)

module any_vector_type

  type :: any_vector
class(*), allocatable :: x(:)
  end type

  interface any_vector
procedure any_vector_init
  end interface

contains

  function any_vector_init (x) result (this)
class(*), intent(in) :: x(:)
type(any_vector) :: this
call fubar (this, x)
  end function

  subroutine fubar (this, x)
class(any_vector), intent(out) :: this
class(*), intent(in) :: x(:)
allocate(this%x(lbound(x,1):ubound(x,1)), source=x)
select type (x)
type is (integer)
  print *, 'source=', x
end select
select type (y => this%x)
type is (integer)
  print *, 'copy=  ', y, '(expect same as source)'
end select
  end subroutine

end module

program main
  use any_vector_type
  type(any_vector) :: a
  a = any_vector([1,2])
end program

[Bug ada/66965] gnat.dg/specs/addr1.ads obsolete -- failing on trunk

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  ---
Author: ebotcazou
Date: Sat Sep 12 16:35:20 2015
New Revision: 227709

URL: https://gcc.gnu.org/viewcvs?rev=227709=gcc=rev
Log:
PR ada/66965
* gnat.dg/specs/addr1.ads: Remove.

Removed:
trunk/gcc/testsuite/gnat.dg/specs/addr1.ads
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ada/66965] gnat.dg/specs/addr1.ads obsolete -- failing on trunk

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
.

[Bug c++/67561] [C++14] ICE in tsubst_copy (nested auto lambdas may be involved)

[bisqwit at iki dot fi]

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

--- Comment #1 from Joel Yliluoma  ---
Further reduced example:

template
void DrawView(PlotFunc GetPlotFunc)
{
GetPlotFunc(1)(2);
}

void CalculateLightmap()
{
auto LightmapRenderer = [](unsigned round)
{
return [round](const auto& view)
{
return [=](auto prop)
{
round + 0;
};
};
};

DrawView(LightmapRenderer(0));
}

Replacing the [=] with [] or [&] retains the error. Replacing it with [round]
removes the error.

[Bug libobjc/24775] libobjc should not include GCC's target headers

[tbsaunde at gcc dot gnu.org]

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

--- Comment #4 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Sat Sep 12 22:19:00 2015
New Revision: 227710

URL: https://gcc.gnu.org/viewcvs?rev=227710=gcc=rev
Log:
remove STRUCT_VALUE macro

This macro was converted to the TARGET_STRUCT_VALUE_RTX hook many years
ago, however there are still some lingering definitions, and a use in
libobjc.  All the remaining definitions define the macro to 0, which
libobjc treats the same as undefined, so it won't break anything else to
have libobjc stop checking the macro.  However it may be that this part
of libobjc has been broken for a long time on targets that only define
the hook, but that is a separate issue.

gcc/ChangeLog:

2015-09-12  Trevor Saunders  

* config/arc/arc.h: Remove define of STRUCT_VALUE.
* config/lm32/lm32.h: Likewise.
* config/mep/mep.h: Likewise.
* config/visium/visium.h: Likewise.
* system.h: Poison STRUCT_VALUE macro.

libobjc/ChangeLog:

2015-09-12  Trevor Saunders  

PR libobjc/24775
* sendmsg.c: Remove check of STRUCT_VALUE macro.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arc/arc.h
trunk/gcc/config/lm32/lm32.h
trunk/gcc/config/mep/mep.h
trunk/gcc/config/visium/visium.h
trunk/gcc/system.h
trunk/libobjc/ChangeLog
trunk/libobjc/sendmsg.c

[Bug libobjc/24775] libobjc should not include GCC's target headers

[tbsaunde at gcc dot gnu.org]

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

--- Comment #5 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Sat Sep 12 22:19:06 2015
New Revision: 227711

URL: https://gcc.gnu.org/viewcvs?rev=227711=gcc=rev
Log:
remove unused defines from sendmsg.c

libobjc/ChangeLog:

2015-09-12  Trevor Saunders  

PR libobjc/24775
* sendmsg.c (gen_rtx): Remove macro.
(gen_rtx_MEM): Likewise.
(gen_rtx_REG): Likewise.
(rtx): Likewise.

Modified:
trunk/libobjc/ChangeLog
trunk/libobjc/sendmsg.c

[Bug libobjc/24775] libobjc should not include GCC's target headers

[tbsaunde at gcc dot gnu.org]

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

--- Comment #6 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Sat Sep 12 22:19:11 2015
New Revision: 227712

URL: https://gcc.gnu.org/viewcvs?rev=227712=gcc=rev
Log:
stop including tm.h in sendmsg.c

libobjc/ChangeLog:

2015-09-12  Trevor Saunders  

PR libobjc/24775
* sendmsg.c (tm.h): Remove include.

Modified:
trunk/libobjc/ChangeLog
trunk/libobjc/sendmsg.c

[Bug fortran/65889] [6 Regressions] [OOP] ICE with sizeof a polymorphic variable.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||vehre at gcc dot gnu.org
Summary|ICE on invalid(?) with  |[6 Regressions] [OOP] ICE
   |sizeof polymorphic variable |with sizeof a polymorphic
   |[OOP]   |variable.

--- Comment #2 from Dominique d'Humieres  ---
AFAIU PR57305 it is about the sizeof CLASS(*) and I don't see why the code
should be invalid. 

The ICE occurred between revisions r222352 (2015-04-23, no ICE) and r222398
(2015-04-24, ICE), likely r222361 for pr60322.

[Bug fortran/67562] Bad result from sourced allocation with class(*) arrays

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Please pardon my ignorance (I rarely use gfortran), but is there a 6.0 source
> distribution somewhere?  The latest I can find is 5.2.  Are you talking about
> the current trunk?  

Yes, you can probably get 6.0 from https://www.macports.org or build you own.

> I'm puzzled because the r222361 you reference appears to predate 5.2
> by several months.

Patches are applied to trunk first, and are back ported to older branches only
when fixing a regression.

> I've got a bunch of other gfortran bugs (with 5.2) to chase down,
> and it looks like much would be wasted effort.

Filing duplicates is better than not reporting. For internal compiler errors
pointing to a file and line number, you can search bugzilla for the (part of)
the error. Otherwise don't bother.

[Bug fortran/67562] Bad result from sourced allocation with class(*) arrays

[neil.n.carlson at gmail dot com]

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

--- Comment #2 from neil.n.carlson at gmail dot com ---
Please pardon my ignorance (I rarely use gfortran), but is there a 6.0 source
distribution somewhere?  The latest I can find is 5.2.  Are you talking about
the current trunk?  I'm puzzled because the r222361 you reference appears to
predate 5.2 by several months.  I've got a bunch of other gfortran bugs (with
5.2) to chase down, and it looks like much would be wasted effort.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #102 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #101)
> 
> I've forgotten that some atomic builtins fail with spill_failure
> in class 'R0_REGS' for old RA.  So libstdc++-v3 was configured
> so to undefine _GLIBCXX_ATOMIC_BUILTINS for old RA and we see
> the above difference.

Ah!  I always wondered why those failures disappeared from your nightly tests. 
Did you do this locally in your setup, or has this been committed at some time?

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

[Bug c/67556] Regex \w doesn't support the unicode character <U+200C>

[mm.masaeli at gmail dot com]

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

--- Comment #2 from Mohammad Masood Masaeli  ---
You're right, sorry.
Thanks for your time.

[Bug libfortran/67534] libgfortran.h sanitizer complains on left shift of ~0 runtime error: left shift of negative value -1

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #1 from Francois-Xavier Coudert  ---
(In reply to Vittorio Zecca from comment #0)
> The sanitizer complains on libgfortran.h:408
> 
> ((~((index_type) 0) >> GFC_DTYPE_SIZE_SHIFT) << GFC_DTYPE_SIZE_SHIFT)

That code is gone on trunk. Could you test there?

[Bug c/67547] may be an error in printf(%a..) for nexttowardf(0.f,1.f)

[ka_bena at yahoo dot fr]

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

--- Comment #2 from BENAÏSSA  ---
Thank you very much for your reply.
A.Benaïssa



 Le Vendredi 11 septembre 2015 13h25, pinskia at gcc dot gnu.org
 a écrit :


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

Andrew Pinski  changed:

          What    |Removed                    |Added

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

--- Comment #1 from Andrew Pinski  ---
Report this to mingw since that is where printf comes from (though it might
come directly from Microsoft's libc).

Also by the way nexttowardf is C99 and not C89 so I am getting warnings with
glibc and C89:
t1.c: In function 'main':
t1.c:6:20: warning: implicit declaration of function 'nexttowardf'
[-Wimplicit-function-declaration]
  printf("  %E\n", nexttowardf ( 0.F , 1.F ) ) ;
                    ^
t1.c:6:10: warning: format '%E' expects argument of type 'double', but argument
2 has type 'int' [-Wformat=]
  printf("  %E\n", nexttowardf ( 0.F , 1.F ) ) ;
          ^
t1.c:7:10: warning: format '%A' expects argument of type 'double', but argument
2 has type 'int' [-Wformat=]
  printf("  %A\n", nexttowardf ( 0.F , 1.F ) ) ;
          ^
t1.c:8:20: warning: implicit declaration of function 'nexttoward'
[-Wimplicit-function-declaration]
  printf("  %A\n", nexttoward  ( 0.  , 1.  ) ) ;
                    ^
t1.c:8:10: warning: format '%A' expects argument of type 'double', but argument
2 has type 'int' [-Wformat=]
  printf("  %A\n", nexttoward  ( 0.  , 1.  ) ) ;

[Bug fortran/66640] Symbolic (addr2line) backtrace handler sometimes does not terminate when using OpenMP

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #3 from Francois-Xavier Coudert  ---
We've completely changed the backtrace mechanism in trunk (6.0). The new
mechanism is more robust. Closing as FIXED, please open new PR (and CC me) if
you experience more trouble in this area.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #101 from Kazumoto Kojima  ---
> Perhaps the both codes are ok, though something odd happens
> on atomic things anyway.

I've forgotten that some atomic builtins fail with spill_failure
in class 'R0_REGS' for old RA.  So libstdc++-v3 was configured
so to undefine _GLIBCXX_ATOMIC_BUILTINS for old RA and we see
the above difference.  I've tried to disable it on LRA build
and rebuild libstdc++-v3 libs.  14.exe still fails and it looks
very sensitive with code/option changes.  Weird.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-12
 CC||fxcoudert at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Francois-Xavier Coudert  ---
(In reply to Vittorio Zecca from comment #0)
> During make check-fortran in gcc build the sanitizer complains
> that a null pointer is passed to memcpy in string_intrinsics_inc.c:89

Which test case generates that? It seems weird to be calling string_compare()
with a NULL pointer, so it may actually be a front-end issue.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
The pointer is NULL but the length is zero.
The test case is allocate_deferred_char_scalar_1.exe
on all eight combinations. As in

Executing on host:
/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../gfortran
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/
/home/vitti/gcc-5.2.0/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O0
-pedantic-errors
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libatomic/.libs
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
 -lm -L/home/vitti/local/gcc-5.2.0/lib64 -lasan -lubsan -ldl -lpthread
 -o ./allocate_deferred_char_scalar_1.exe(timeout = 300)
spawn -ignore SIGHUP
/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../gfortran
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/
/home/vitti/gcc-5.2.0/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0
-pedantic-errors
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libatomic/.libs
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-lm -L/home/vitti/local/gcc-5.2.0/lib64 -lasan -lubsan -ldl -lpthread
-o ./allocate_deferred_char_scalar_1.exe^M
PASS: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O0  (test for
excess errors)
Executing on unix: ./allocate_deferred_char_scalar_1.exe(timeout = 300)
spawn -ignore SIGHUP ./allocate_deferred_char_scalar_1.exe^M
lvz=0^M
lvz=0^M
Executed ./allocate_deferred_char_scalar_1.exe, status 0
lvz=0^M
lvz=0^M

PASS: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O0  execution test

lvz=0 is my addition to expose the issue

[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  ---
> None of them is applicable to a weakdef with "ld -r".
Yep, GCC simply assumes that incremental linking is not going to happen and it
makes strong assumptions
about visibility in static binaries.
To support incremental linking we need a way to pass this information to GCC.
Either by extra codes or
by informing the plugin that linking is incremental.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860

Honza

[Bug c++/67519] warn for calls to member functions before all base classes constructed

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
Summary|New warning: calls to   |warn for calls to member
   |member functions before all |functions before all base
   |base classes constructed|classes constructed

--- Comment #3 from Manuel López-Ibáñez  ---
Perhaps related to PR19808 (one has to keep track of what has been initialized
while parsing the member initializer list).

[Bug c++/67558] New: [C++] OpenMP "if" clause does not utilize compile-time constants

[bisqwit at iki dot fi]

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

Bug ID: 67558
   Summary: [C++] OpenMP "if" clause does not utilize compile-time
constants
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

Consider this example code.

unsigned x;

template
void plain_if(unsigned y)
{
if(Threads)
{
#pragma omp task firstprivate(y) shared(x)
x = y >> 1;
}
else
{
x = y >> 1;
}
}

template
void omp_if(unsigned y)
{
#pragma omp task if(Threads) firstprivate(y) shared(x)
x = y >> 1;
}

void plain_if_false(unsigned y) { plain_if(y); }
void plain_if_true(unsigned y) { plain_if(y); }

void omp_if_false(unsigned y) { omp_if(y); }
void omp_if_true(unsigned y) { omp_if(y); }

plain_if and omp_if do essentially the same thing. In both of them, the
template parameter "Threads" controls whether to create an OpenMP task for the
action or not.

However, when the code is compiled, all functions explicitly call GOMP_task,
except plain_if.
It is clear that GCC treats a plain if() differently than an OpenMP if(). It is
a case of lacking optimization.

[Bug c++/67519] New warning: calls to member functions before all base classes constructed

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
Also -fsanitize=undefined doesn't handle this issue yet.

[Bug c++/67557] Calling copy constructor of base class in constructor of derived class produces crashing code

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
See PR67519 for a possible future compiler warning.

[Bug c++/67557] New: Calling copy constructor of base class in constructor of derived class produces crashing code

[Georg.Baum at post dot rwth-aachen.de]

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

Bug ID: 67557
   Summary: Calling copy constructor of base class in constructor
of derived class produces crashing code
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Georg.Baum at post dot rwth-aachen.de
  Target Milestone: ---

Created attachment 36327
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36327=edit
Test case

The bug reported below happens with a self compiled gcc on Linux (Debian
jessie):
$ LANG=C gcc-5.1 -v
Using built-in specs.
COLLECT_GCC=/home/u/bin-gcc5/bin/gcc-5.1
COLLECT_LTO_WRAPPER=/home/u/bin-gcc5/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.1.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5-branch/configure --prefix=/home/u/bin-gcc5
--program-suffix=-5.1 --enable-languages=c,c++,fortran --disable-bootstrap :
(reconfigured) ../gcc-5-branch/configure --prefix=/home/u/bin-gcc5
--program-suffix=-5.1 --enable-languages=c,c++,fortran --disable-bootstrap
Thread model: posix
gcc version 5.1.1 20150507 (GCC) 

Compiling and running the attached example with

g++-5.1 t.cpp -o t && ./t

produces an eror:

*** Error in `./t': free(): invalid pointer: 0x7ffd93f3cae0 ***
Aborted.

Running the test case with valgrind produces this:

==6021== Memcheck, a memory error detector
==6021== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6021== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==6021== Command: ./t
==6021== 
==6021== Invalid free() / delete / delete[] / realloc()
==6021==at 0x4C2A360: operator delete(void*) (vg_replace_malloc.c:507)
==6021==by 0x4009E3: StartTag::~StartTag() (in /home/u/t)
==6021==by 0x400A4B: FontTag::~FontTag() (in /home/u/t)
==6021==by 0x400993: main (in /home/u/t)
==6021==  Address 0xffefffc80 is on thread 1's stack
==6021==  in frame #0, created by operator delete(void*)
(vg_replace_malloc.c:507)
==6021== 
==6021== 
==6021== HEAP SUMMARY:
==6021== in use at exit: 72,704 bytes in 1 blocks
==6021==   total heap usage: 1 allocs, 1 frees, 72,704 bytes allocated
==6021== 
==6021== LEAK SUMMARY:
==6021==definitely lost: 0 bytes in 0 blocks
==6021==indirectly lost: 0 bytes in 0 blocks
==6021==  possibly lost: 0 bytes in 0 blocks
==6021==still reachable: 72,704 bytes in 1 blocks
==6021== suppressed: 0 bytes in 0 blocks
==6021== Rerun with --leak-check=full to see details of leaked memory
==6021== 
==6021== For counts of detected and suppressed errors, rerun with: -v
==6021== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Compiling the same source with gcc 4.x produces a working executable. This bug
was originally reported as a LyX bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1260976. The code may not be
oprtimal (and I am going to change it in LyX to work around the compiler bug),
but it is valid.

[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop

[spop at gcc dot gnu.org]

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

--- Comment #37 from Sebastian Pop  ---
I think gcc should stop blocking initialization loops: it should only block a
loop when it contains more than two arrays, one array accessing non-contiguous
elements in memory, and another array accessing contiguous elements in memory.

[Bug c++/67557] Calling copy constructor of base class in constructor of derived class produces crashing code

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
No, this is invalid and undefined.

See §12.6.2 - 14:

»Member functions (including virtual member functions, 10.3) can be called for
an object under construction. Similarly, an object under construction can be
the operand of the typeid operator (5.2.8) or of a dynamic_cast (5.2.7).
However, if these operations are performed in a ctor-initializer (or in a
function called directly or indirectly from a ctor-initializer) before all the
mem-initializers for base classes have completed, the result of the operation
is undefined.«

[Bug libfortran/67536] unix.c sanitizer detects null pointer passed to memcpy

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #2 from Francois-Xavier Coudert  ---
Fixed.

[Bug libfortran/67527] io.h sanitizer complains on 1 << 31

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |fxcoudert at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #3 from Francois-Xavier Coudert  ---
Fixed. Thanks for the report.

[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop

[dominiq at lps dot ens.fr]

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

--- Comment #36 from Dominique d'Humieres  ---
> i.e., r227264 (or 4.8, 4.9, and 5.2) is ~3 time faster than r227383.

It is due to r227277 (with r227265 reverted in order to bootstrap Ada).

[Bug libfortran/67527] io.h sanitizer complains on 1 << 31

[fxcoudert at gcc dot gnu.org]

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

--- Comment #2 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Sat Sep 12 12:05:44 2015
New Revision: 227705

URL: https://gcc.gnu.org/viewcvs?rev=227705=gcc=rev
Log:
PR libfortran/67527
PR libfortran/67535
PR libfortran/67536
* io/io.h: Use unsigned values for 31-bit left shifts.
* io/unix.c (buf_read): Do not call memcpy() with NULL pointer arg.
* io/write.c (nml_write_obj): Likewise.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/unix.c
trunk/libgfortran/io/write.c

[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy

[fxcoudert at gcc dot gnu.org]

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

--- Comment #7 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Sat Sep 12 12:05:44 2015
New Revision: 227705

URL: https://gcc.gnu.org/viewcvs?rev=227705=gcc=rev
Log:
PR libfortran/67527
PR libfortran/67535
PR libfortran/67536
* io/io.h: Use unsigned values for 31-bit left shifts.
* io/unix.c (buf_read): Do not call memcpy() with NULL pointer arg.
* io/write.c (nml_write_obj): Likewise.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/unix.c
trunk/libgfortran/io/write.c

[Bug libfortran/67536] unix.c sanitizer detects null pointer passed to memcpy

[fxcoudert at gcc dot gnu.org]

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

--- Comment #1 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Sat Sep 12 12:05:44 2015
New Revision: 227705

URL: https://gcc.gnu.org/viewcvs?rev=227705=gcc=rev
Log:
PR libfortran/67527
PR libfortran/67535
PR libfortran/67536
* io/io.h: Use unsigned values for 31-bit left shifts.
* io/unix.c (buf_read): Do not call memcpy() with NULL pointer arg.
* io/write.c (nml_write_obj): Likewise.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/unix.c
trunk/libgfortran/io/write.c

[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |fxcoudert at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #8 from Francois-Xavier Coudert  ---
Fixed. Thanks for the report.