[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 #4 from Markus Trippelsdorf  ---
Well, the automatically generated copy constructor is a (special) member
function.

[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

 CC||redi at gcc dot gnu.org

--- Comment #5 from Markus Trippelsdorf  ---
Anyway, the issue started with the new std::string implementation r218964.

Jonathan?

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

[olegendo at gcc dot gnu.org]

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

--- Comment #105 from Oleg Endo  ---
Created attachment 36328
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36328&action=edit
20040709-2.s without LRA (PASS)

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

[olegendo at gcc dot gnu.org]

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

--- Comment #106 from Oleg Endo  ---
Created attachment 36329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36329&action=edit
20040709-2.s with LRA (FAIL)

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

[olegendo at gcc dot gnu.org]

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

--- Comment #107 from Oleg Endo  ---
> > The serious one would be
> > 
> > Running target sh-sim/-m2/-mb
> > FAIL: gcc.c-torture/execute/20040709-2.c   -Os  execution test
> 

I have tried compiling that test case outside of the testsuite with -m2 -mb -Os
with and without LRA.  There are lots of differences in the asm output, but the
LRA version executable runs fine and doesn't abort.

Running the test inside the testsuite fails reliably.  I could reduce it to the 

testZ ();

subtest.

It passes with with
make -k check RUNTESTFLAGS="execute.exp=20040709-2.c
--target_board=sh-sim\{-m2/-mb/-save-temps/-mno-lra}"

It fails with (-mlra enabled by default)
make -k check RUNTESTFLAGS="execute.exp=20040709-2.c
--target_board=sh-sim\{-m2/-mb/-save-temps}"

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

[olegendo at gcc dot gnu.org]

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

--- Comment #108 from Oleg Endo  ---
(In reply to Oleg Endo from comment #107)

The problem is the define_split at sh.md line 893 (the part at 945).  Or
actually, it's sh_find_set_of_reg.  Adding this

diff --git a/gcc/config/sh/sh-protos.h b/gcc/config/sh/sh-protos.h
index 3e4211b..b4866c1 100644
--- a/gcc/config/sh/sh-protos.h
+++ b/gcc/config/sh/sh-protos.h
@@ -199,8 +199,13 @@ sh_find_set_of_reg (rtx reg, rtx_insn* insn, F stepfunc,
 {
   if (BARRIER_P (result.insn))
break;
+
+  if (CALL_P (result.insn))
+   break;
+
   if (!NONJUMP_INSN_P (result.insn))
continue;
+
   if (reg_set_p (reg, result.insn))
{
  result.set_rtx = set_of (reg, result.insn);

Fixes the test case for me.  It seems I should really fix PR 67061, which looks
like the same issue (and the other issue with sh_find_set_of_reg which was
fixed with a modified_between_p).

[Bug c++/67557] 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

--- Comment #6 from Georg Baum  ---
(In reply to Markus Trippelsdorf from comment #4)
> Well, the automatically generated copy constructor is a (special) member
> function.

OK, I see what you mean, but I still do not understand. The automatically
generated default constructor is a special member function as well. Yet calling
it (implicitly by the compiler or explicitly by the programmer in the
initializer list) from a constructor of a derived class is legal. Also,
explicitly calling user defined constructors like in

FontTag::FontTag() : StartTag("") {}

is legal as well (at least this is my understanding and I have seen this many
times in existing code). What is special about a copy constructor that makes
§12.6.2 - 14 apply to it but not to other constructors?

[Bug c/67563] New: verify_flow_info failed

[dcb314 at hotmail dot com]

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

Bug ID: 67563
   Summary: verify_flow_info failed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For trunk gcc dated 20150912

$ ../results/bin/gcc -c -O2 -fexceptions bug228.c
emit_lua.c: In function ‘emit_package.isra.20’:
emit_lua.c:1140:1: error: BB 167 can not throw but has an EH edge
emit_lua.c:1140:1: error: BB 180 can not throw but has an EH edge
emit_lua.c:1140:1: error: BB 192 can not throw but has an EH edge
emit_lua.c:1140:1: error: BB 204 can not throw but has an EH edge
emit_lua.c:1140:1: internal compiler error: verify_flow_info failed
0x722373 verify_flow_info()
../../src/trunk/gcc/cfghooks.c:262
0xa7c019 execute_function_todo
../../src/trunk/gcc/passes.c:1963
0xa7d557 do_per_function
../../src/trunk/gcc/passes.c:1642
0xa7d557 execute_todo
../../src/trunk/gcc/passes.c:2008
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/67563] verify_flow_info failed

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-13
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.2.1, 6.0

--- Comment #1 from Markus Trippelsdorf  ---
static void emit_package (int p1)
{
  int a;
  int b[0];
  a = __fprintf_chk (0, 0, "");
}
void emit_lua () { emit_package (0); }

[Bug ada/62235] segmentation fault on Ada 2012 code

[porton at narod dot ru]

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

--- Comment #6 from Victor Porton  ---
Not fixed in GNAT 5.2.1 20150903 (i586-linux-gnu) (Debian gnat-5 package).
However the exact error message is somehow different.

[Bug ada/62235] segmentation fault on Ada 2012 code

[porton at narod dot ru]

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

Victor Porton  changed:

   What|Removed |Added

Version|5.1.0   |5.2.1
   Severity|normal  |major

[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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #6 from Dominique d'Humieres  ---
> BTW can you confirm that the test case is erroneous
> because it dereferences a NULL pointer?

Well I am pointer challenged thus I cannot understand the logic behind the
lines

str4 => null()
str = '12a56b78'
if(str4 == '12a56b78') call abort()

and

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

I am expecting an error (or a segfault).

> Is that intended?

CCed the author of the test.

[Bug fortran/54224] Warn for unused internal procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #21 from Dominique d'Humieres  ---
> Still open: Comment 13.

Confirmed up to 5.2, but with trunk (6.0) I get

pr54224_3.f90:13:0:

   subroutine s3
^
Warning: 's3' defined but not used [-Wunused-function]
pr54224_3.f90:4:0:

  subroutine s1
^
Warning: 's1' defined but not used [-Wunused-function]
pr54224_3.f90:6:0:

subroutine s2
^
Warning: 's2' defined but not used [-Wunused-function]

This occurred between revisions r224160 (2015-06-05, s1 only) and r224647
(2015-06-19, above warnings).

Closing as FIXED. Please file new PR(s) for new issue(s).

[Bug fortran/54221] [4.8/4.9 Regression] Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54221
Bug 54221 depends on bug 54224, which changed state.

Bug 54224 Summary: Warn for unused internal procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224

   What|Removed |Added

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

[Bug fortran/54221] [4.8/4.9 Regression] Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> I agree that this PR can probably be closed.

Closing as FIXED. Please file new PR(s) for new issue(s).

[Bug target/67061] sh64-elf: internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
Created attachment 36331
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36331&action=edit
Proposed patch

The issue with the function 'sh_find_set_of_reg' has also popped up when
enabling LRA by default on trunk (see PR 55212).

With the attached patch, sh-elf and sh64-elf newlib based toolchains build
successfully.  I'm now testing the patch on sh-elf.

[Bug libstdc++/67096] libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)

[gnugcc at marino dot st]

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

--- Comment #4 from John Marino  ---
Created attachment 36332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36332&action=edit
codecvt/max_length/wchar/4.cc patch

codecvt/max_length/wchar/4.cc test thinks that 6 is the maximum byte size for
UTF-8 and fails if it detects lengths less than 6 bytes.

Of course, the true limit is 4 bytes, so the test needs to be changed from 6 to
4.

It is related to the tests this PR fixed (same problem, different form).

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

[olegendo at gcc dot gnu.org]

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

--- Comment #109 from Oleg Endo  ---
(In reply to Oleg Endo from comment #108)
> 
> It seems I should really fix PR 67061, which
> looks like the same issue (and the other issue with sh_find_set_of_reg which
> was fixed with a modified_between_p).

I have posted a patch for PR 67061 attachment 36331
With that patch

make -k check RUNTESTFLAGS="execute.exp=20040709-2.c
--target_board=sh-sim\{-m2/-mb/-mlra}"

passes the tests.  Maybe it also fixes the std::locale issues.  Kaz, could you
please have a look?

[Bug fortran/67564] New: Segfault on sourced allocattion statement with class(*) arrays

[neil.n.carlson at gmail dot com]

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

Bug ID: 67564
   Summary: Segfault on sourced allocattion statement with
class(*) arrays
   Product: gcc
   Version: 6.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 segfaults on the allocate statement.
Using the trunk version of 20150906.

program main
  type :: any_vector
class(*), allocatable :: x(:)
  end type
  type(any_vector) :: a
  allocate(a%x(2), source=['foo','bar'])
end program

Here's the output:

$ gfortran --version gfortran-bug-20150913A.f90 
GNU Fortran (GCC) 6.0.0 20150906 (experimental)

$ gfortran gfortran-bug-20150913A.f90 
$ ./a.out

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

Backtrace for this error:
#0  0x7F338430C517
#1  0x7F338430CB5E
#2  0x7F338380D95F
#3  0x7F33838677ED
#4  0x400932 in __copy_character_1.3388 at gfortran-bug-20150913A.f90:?
#5  0x400AC6 in MAIN__ at gfortran-bug-20150913A.f90:?
Segmentation fault (core dumped)

[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. I get the following ICE with 5.2 and older

   allocate(a%x(2), source=['foo','bar'])
 1
internal compiler error: Segmentation fault: 11

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> > ((~((index_type) 0) >> GFC_DTYPE_SIZE_SHIFT) << GFC_DTYPE_SIZE_SHIFT)
>
> That code is gone on trunk. Could you test there?

But I see at line 407

#define GFC_DTYPE_SIZE_MASK (-((index_type) 1 << GFC_DTYPE_SIZE_SHIFT))

[Bug fortran/57778] Missing warning for -Wimplicit-procedure for dummy arguments

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
>From Richard Maine's answer at
https://groups.google.com/forum/#!topic/comp.lang.fortran/3idUN6kMjjo it looks
to me that the warning expectation is wrong. Am I making a mistake? If not,
I'll close this PR as INVALID.

[Bug fortran/67543] ICE on associate with improper association

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[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 #7 from Vittorio Zecca  ---
str4 used to point to str so the "logic" seems to check that str4 does
not follow any more str.
But the test is erroneous.

[Bug ada/62235] segmentation fault on Ada 2012 code

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Severity|major   |normal

[Bug fortran/67538] ICE with invalid source allocation

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
> The following code is invalid since the array dimension is missing,
> but since it is an ICE I am reporting it.

This is valid since F2003 (implemented recently by Andre Vehreschild), but it
should not give an ICE.

[Bug target/58864] [4.8/4.9 regression] ICE in connect_traces, at dwarf2cfi.c:NNNN

[d.glazachev at gmail dot com]

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

Denis  changed:

   What|Removed |Added

 CC||d.glazachev at gmail dot com

--- Comment #12 from Denis  ---
This or similar bug still exists in 4.9.3
Can be worked around by -fno-defer-pop

[Bug fortran/67542] ICE on initializing type variable with a longer array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
I don't get any internal compiler error for the test in comment 0 from 4.8 up
to trunk (6.0). However I am surprised that I don't get any error. The
following test

character(4) :: str
str=['a', 'b']
print *, str
end

gives

 str=['a', 'b']
1
Error: Incompatible ranks 0 and 1 in assignment at (1)

[Bug fortran/54224] Warn for unused internal procedures

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #22 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #21)
> Closing as FIXED. Please file new PR(s) for new issue(s).

I'm not a Fortran dev, but I would humbly suggest to add this testcase to the
regression testsuite before closing the bug. Also:

> pr54224_3.f90:6:0:
> 
> subroutine s2
> ^

You will get a more precise column info (and better location for '^') if
Fortran gives a more precise DECL_SOURCE_LOCATION() when generating this tree.

[Bug c++/67545] [concepts] Failure to properly substitute template parameters into requires-clause

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

   Severity|normal  |major

--- Comment #1 from Casey Carter  ---
Raising importance to "major": I have a hunch that this may be the root cause
of some of my other reported bugs.

[Bug fortran/67539] Segmentation fault with elemental defined assignment and scalar function at the RHS

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[Bug c++/67565] New: [concepts] Very slow compile time and high memory usage with complex concept definitions, even if unused

[adrian.wielgosik at gmail dot com]

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

Bug ID: 67565
   Summary: [concepts] Very slow compile time and high memory
usage with complex concept definitions, even if unused
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrian.wielgosik at gmail dot com
  Target Milestone: ---

Example:

template 
concept bool Constructible() {
return false ||
requires (T t) {
{ t.~T() } noexcept;
};
}

template 
concept bool Semiregular() {
return
Constructible() &&
Constructible() &&
Constructible() &&
Constructible() &&
Constructible() &&
Constructible() &&
Constructible();
}

template 
concept bool Sentinel() {
return Semiregular() && Semiregular();
}

template S>
void func(I first, S last) { }

int main(){}


time ./g++trunk -std=c++1z main.cpp

real0m8.855s
user0m7.887s
sys 0m0.896s

It also consumed over 2GB of RAM at peak. Note that the function which checks
for concepts wasn't even called, so no actual concept checks were done.

Simplifying this case any more, like removing "false ||", fixes the problem.

A big chain of "Constructible() &&" may look strange, but it's just a
simplified case - originally I tried to rewrite concepts from Eric Niebler's
Ranges proposal, which could check the same concept multiple times.

[Bug fortran/54224] Warn for unused internal procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #23 from Dominique d'Humieres  ---
> I'm not a Fortran dev, but I would humbly suggest to add this testcase
> to the regression testsuite before closing the bug.

OK. REOPENED.

> Also:
>
> > pr54224_3.f90:6:0:
> > 
> > subroutine s2
> > ^
>
> You will get a more precise column info (and better location for '^')
> if Fortran gives a more precise DECL_SOURCE_LOCATION() when generating this 
> tree.

Could you please elaborate?

[Bug fortran/54221] [4.8/4.9 Regression] Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54221
Bug 54221 depends on bug 54224, which changed state.

Bug 54224 Summary: Warn for unused internal procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224

   What|Removed |Added

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

[Bug c++/67565] [concepts] Very slow compile time and high memory usage with complex concept definitions, even if unused

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Overhead  Command   Shared Object  Symbol
  19.16%  cc1plus   libc-2.20.so   [.] free
  16.21%  cc1plus   libc-2.20.so   [.] malloc
  14.55%  cc1plus   cc1plus[.] cp_tree_equal
  13.80%  cc1plus   libc-2.20.so   [.] malloc_consolidate
  10.52%  cc1plus   libc-2.20.so   [.] _int_malloc
   5.34%  cc1plus   cc1plus[.] decompose_assumptions
   3.81%  cc1plus   cc1plus[.] ggc_set_mark
   3.56%  cc1plus   cc1plus[.] (anonymous
namespace)::term_list::insert
   2.93%  cc1plus   cc1plus[.] dependent_name

[Bug fortran/54224] Warn for unused internal procedures

[manu at gcc dot gnu.org]

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

--- Comment #24 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #23)
> > I'm not a Fortran dev, but I would humbly suggest to add this testcase
> > to the regression testsuite before closing the bug.
> 
> OK. REOPENED.
> 
> > Also:
> >
> > > pr54224_3.f90:6:0:
> > > 
> > > subroutine s2
> > > ^
> >
> > You will get a more precise column info (and better location for '^')
> > if Fortran gives a more precise DECL_SOURCE_LOCATION() when generating this 
> > tree.
> 
> Could you please elaborate?

I don't know the Fortran FE that well, but at some moment it creates this tree
and it sets DECL_SOURCE_LOCATION(). Probably based on some loc->lb->location.
However, that only contains line number info because Fortran does not use
libcpp/line-map.c for tracking column numbers (it only creates new locations
for line changes).

Fully using line-map.c in Fortran is likely to be a lot of work, but it could
mean getting precise macro locations
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53934#c2) and remove some of the
duplication between libcpp and Fortran (tokenizer, file inclusion, etc.)

Nonetheless, as a work-around, you could use:

unsigned int offset = loc->nextc - loc->lb->line;
location = linemap_position_for_loc_and_offset (line_table,
loc->lb->location,
offset));

to create a new location_t with the correct column number and use that for the
tree it creates.

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Tobias Burnus from comment #0)
> Reported by Paul Kapinos at fortran@gcc,
> http://thread.gmane.org/gmane.comp.gcc.fortran/40495
> http://gcc.gnu.org/ml/fortran/2013-03/msg00083.html
> 
> The problem is that libcpp calls an error handler, which is not set in f951.
> 
> 
> Namely,   pfile->cb.error == NULL  but should be point to a function; it has
> the the prototype:
>  bool (*)(cpp_reader *, int, int, source_location, unsigned int, const char
> *,
>   va_list *) 
> C/C++ use:
>in c-opts.c: "cb->error = c_cpp_error;"
> the function is declared in c-family/c-common.c.

Now that Fortran uses the common diagnostics machinery, it should be possible
to either move this function to common code or create a duplicate in the
Fortran FE.

(Even better would be to convert the common diagnostics machinery to a library
and make libcpp depend on it, which will avoid all these conversions from/to
libcpp/FE enums since libcpp could use directly the same diagnostic enums as
the rest of the compiler)

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Depends on||62226

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #2)
> Now that Fortran uses the common diagnostics machinery, it should be
> possible to either move this function to common code or create a duplicate
> in the Fortran FE.

For this function to work, CPP options used by Fortran must be specially
encoded in the *.opt file. See bug 62226.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62226
[Bug 62226] Encode CPP options in lang.opt

[Bug fortran/67538] ICE with invalid source allocation

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> > The following code is invalid since the array dimension is missing,
> > but since it is an ICE I am reporting it.
> 
> This is valid since F2003 (implemented recently by Andre Vehreschild), but
> it should not give an ICE.

Are you sure?

There is no array spec.

real, allocatabe :: x(:)  ! Rank 1
real y
y = 42! Rank 0
allocate(x , source=y)

What are the ubound and lbound of x?

[Bug libstdc++/67096] libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)

[gnugcc at marino dot st]

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

--- Comment #5 from John Marino  ---
Hmmm, thinking about this, I'd bet Linux would FAIL this test.  It probably
does allow 6-bytes (even though it should not) and thus K would return 6.

I don't really have a recommendation -- the standard is pretty clear, 4 bytes
is the maximum for UTF-8, so it probably should fail on Linux.

Or maybe this whole test should just be removed?  What's it really testing that
the other tests haven't already?

[Bug fortran/67538] ICE with invalid source allocation

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> > This is valid since F2003 (implemented recently by Andre Vehreschild), but
> > it should not give an ICE.
>
> Are you sure?
>
> There is no array spec. ...

You are right, the code is invalid.

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

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
According the release notes of gcc 5 (https://gcc.gnu.org/gcc-5/changes.html)
this is by design:

"G++ now allows passing a non-trivially-copyable class via C varargs, which is
conditionally-supported with implementation-defined semantics in the standard.
This uses the same calling convention as a normal value parameter."

and as you already note this behaviour is supported by the C++11 standard.

[Bug libstdc++/67566] New: std::move is in global scope g++ 5.1 -std=c++14

[forest_software at mail dot ru]

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

Bug ID: 67566
   Summary:  std::move is in global scope g++ 5.1
-std=c++14
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: forest_software at mail dot ru
  Target Milestone: ---

std::move is in global scope after #include , conflict with boost::move

example:

main.cpp:

#include 
#include 

using boost::move;

main()
{
  std::string a = "fff";
  std::string b = move(a);
}

Compile:

g++ main.cpp -std=c++14

[Bug libstdc++/64132] [5/6 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Target|hppa-unknown-linux-gnu  |hppa-unknown-linux-gnu,
   ||x86_64-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed|2015-03-18 00:00:00 |2015-09-13
 CC||miyuki at gcc dot gnu.org
   Host|hppa-unknown-linux-gnu  |hppa-unknown-linux-gnu,
   ||x86_64-linux-gnu
 Ever confirmed|0   |1
  Build|hppa-unknown-linux-gnu  |hppa-unknown-linux-gnu,
   ||x86_64-linux-gnu

--- Comment #4 from Mikhail Maltsev  ---
This reproduces on x86_64-linux. Probably it is specific to some configuration
options (because this failure does not show up in test results mailing lists).
configure flags: --enable-languages=c,c++,objc,lto,fortran,go,ada
--prefix=/opt/gcc-6.0.0 --enable-clocale=gnu --with-system-zlib
--with-demangler-in-ld --with-isl=/opt/isl-0.14 --enable-shared
--with-fpmath=sse --enable-multilib --enable-bootstrap --enable-checking=yes
CC=/opt/gcc-5.2.0-fdo/bin/gcc CXX=/opt/gcc-5.2.0-fdo/bin/g++

I recompiled this testcase with "-O0 -ggdb" flags. GDB session (run on build
box):

Starting program:
/home/jenkins/workspace/build-gcc-trunk/build/x86_64-pc-linux-gnu/libstdc++-v3/testsuite/normal1/3.exe
 
3.exe:
/home/jenkins/workspace/build-gcc-trunk/src/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc:39:
void test02(): Assertion `g == ""' failed.

Program received signal SIGABRT, Aborted.
0x771d5107 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x771d5107 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x771d64e8 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x771ce226 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x771ce2d2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00400b55 in test02 () at
/home/jenkins/workspace/build-gcc-trunk/src/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc:39
#5  0x00400baa in main () at
/home/jenkins/workspace/build-gcc-trunk/src/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc:44
(gdb) up 4
#4  0x00400b55 in test02 () at
/home/jenkins/workspace/build-gcc-trunk/src/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc:39
39VERIFY( g == "" );
(gdb) p g
$1 = {static npos = 18446744073709551615, _M_dataplus = {>
= {<__gnu_cxx::new_allocator> = {}, },
_M_p = 0x7fffde30 "\003\003"}, _M_string_length = 2, {
_M_local_buf = "\003\003\000\377\377\177\000\000,\f@\000\000\000\000",
_M_allocated_capacity = 140737471578883}}
(gdb) list
34
35const numpunct& nump_it = use_facet >(loc_it); 
36
37string g = nump_it.grouping();
38
39VERIFY( g == "" );
40  }
41
42  int main()
43  {
(gdb) p nump_it
$2 = (const std::__cxx11::numpunct &) @0x616e00: { =
{}, _M_data = 0x616e20, static id = {_M_index = 3, static
_S_refcount = 46}}
(gdb) p *nump_it._M_data
$3 = { = {_vptr.facet = 0x77dcf218 +16>, _M_refcount = 0, static _S_c_locale =
0x77541ae0, static _S_c_name = "C", static _S_once = 0}, 
  _M_grouping = 0x616ec0 "\003\003", _M_grouping_size = 2, _M_use_grouping =
false, _M_truename = 0x77b90eac "true", _M_truename_size = 4, _M_falsename
= 0x77b90ea6 "false", _M_falsename_size = 5, _M_decimal_point = 44 ',', 
  _M_thousands_sep = 46 '.', _M_atoms_out = '\000' ,
_M_atoms_in = '\000' , _M_allocated = false}
...
(gdb) p *loc_it._M_impl->_M_facets[0]
$10 = {_vptr.facet = 0x77dcf8d0 +16>,
_M_refcount = 1, static _S_c_locale = 0x77541ae0, static _S_c_name = "C",
static _S_once = 0}
(gdb) p *loc_it._M_impl->_M_facets[1]
$11 = {_vptr.facet = 0x77dce6a0 +16>, _M_refcount = 1, static _S_c_locale = 0x77541ae0, static
_S_c_name = "C", static _S_once = 0}
(gdb) p *loc_it._M_impl->_M_facets[2]
$12 = {_vptr.facet = 0x77dd1680 +16>, _M_refcount = 1, static _S_c_locale =
0x77541ae0, static _S_c_name = "C", static _S_once = 0}
(gdb) p *loc_it._M_impl->_M_facets[3]

Also, in my builds it started failing after migration: previous build box had
Debian 7 installed (in OpenVZ container), the current one has Debian 8 (on a
physical box). This migration caused:
+FAIL: 22_locale/messages/13631.cc execution test
+FAIL: 22_locale/messages/members/char/1.cc execution test
+FAIL: 22_locale/messages/members/char/2.cc execution test
+FAIL: 22_locale/messages/members/char/wrapped_env.cc execution test
+FAIL: 22_locale/messages/members/char/wrapped_locale.cc execution test
+FAIL: 22_locale/messages_byname/named_equivalence.cc execution test
+FAIL: 22_locale/numpunct/members/char/3.cc execution test
+FAIL: 22_locale/

[Bug c++/67559] [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

--- Comment #2 from Joel Yliluoma  ---
But when compiling for earlier standard versions that explicitly label this as
undefined behavior, it should at least give a warning.

[Bug target/67061] sh64-elf: internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
(In reply to Oleg Endo from comment #5)
> Created attachment 36331 [details]
> Proposed patch
> 
> The issue with the function 'sh_find_set_of_reg' has also popped up when
> enabling LRA by default on trunk (see PR 55212).
> 
> With the attached patch, sh-elf and sh64-elf newlib based toolchains build
> successfully.  I'm now testing the patch on sh-elf.

No new failures for
make -k check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"

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

[kkojima at gcc dot gnu.org]

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

--- Comment #110 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #109)
> Maybe it also fixes the std::locale issues.  Kaz, could
> you please have a look?

It doesn't fix those failures.  I'll try to bisect that issue.

[Bug libstdc++/67566] std::move is in global scope g++ 5.1 -std=c++14

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
std::move is declared in namespace std as required by the C++ standard. It is
found by ADL. This is not a bug.

[Bug fortran/67460] [5/6 Regression] Spurious: f951: all warnings being treated as errors

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
patch submitted: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00894.html

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2015-09-14
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #7 from Jonathan Wakely  ---
There's nothing invalid about the program, no member function is called on the
object being constructed (except the constructor, but obviously you have to
call a constructor before the object is constructed!)

After x has been constructed its string member has an invalid pointer:

(gdb) p/r  x.tag_
$1 = {static npos = 18446744073709551615, _M_dataplus = {>
= {<__gnu_cxx::new_allocator> = {}, },
_M_p = 0x7fffd380 ""}, _M_string_length = 0, {
_M_local_buf = "\000\001\241Y9\000\000\000Щ\304\367\377\177\000",
_M_allocated_capacity = 246316859648}}
(gdb) p x.tag_._M_local_buf + 0
$2 = 0x7fffd3f0 ""

(gdb) p x.tag_._M_dataplus._M_p
$3 = (std::__cxx11::basic_string,
std::allocator >::pointer) 0x7fffd380 ""


N.B. 0x7fffd380 != 0x7fffd3f0

The code works correctly with -fno-elide-constructors

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #8 from Jonathan Wakely  ---
namespace std
{
struct string
{
  typedef unsigned long size_type;
  const char* _M_p;
  char_M_local_buf[1];

  string(const char* s) : _M_p(_M_local_buf)
  {
__builtin_printf("%p constructed\n", this);
  }

  string(const string& s) : _M_p(_M_local_buf)
  {
__builtin_printf("%p copied from %p\n", this, &s);
  }

  ~string()
  {
__builtin_printf("%p destroyed\n", this);
if (_M_p != _M_local_buf)
  __builtin_abort();
  }
};
}

struct StartTag
{
explicit StartTag(std::string const & tag) : tag_(tag),
keepempty_(false) {}
std::string tag_;
bool keepempty_;
};

StartTag fontToStartTag() { return StartTag(""); }

struct FontTag : public StartTag
{
FontTag() : StartTag(fontToStartTag()) {}
};

int main()
{
FontTag x;
__builtin_printf("%p x.tag_ in main()\n", &x.tag_);
return 0;
}


This prints:

0x7ffdd31bbb60 constructed
0x7ffdd31bbb90 copied from 0x7ffdd31bbb60
0x7ffdd31bbb60 destroyed
0x7ffdd31bbbe0 x.tag_ in main()
0x7ffdd31bbbe0 destroyed
Aborted (core dumped)

Note that the 'this' pointer in the copy constructor is 0x7fffde6c4d20, which
is not the address of x.tag_ and not the address in the destructor.

The string copy constructor sets its _M_p member to point to this->_M_local_buf
using the incorrect value of 'this' and then in the destructor sees _M_p !=
_M_local_buf (which in the real std::string tries to delete[] _M_p which
crashes).

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

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> 0x7ffdd31bbb60 constructed
> 0x7ffdd31bbb90 copied from 0x7ffdd31bbb60
> 0x7ffdd31bbb60 destroyed
> 0x7ffdd31bbbe0 x.tag_ in main()
> 0x7ffdd31bbbe0 destroyed
> Aborted (core dumped)
> 
> Note that the 'this' pointer in the copy constructor is 0x7fffde6c4d20,

Oops, that was an earlier run, in the output above it is 0x7ffdd31bbb90,

> which is not the address of x.tag_ and not the address in the destructor.

the object that gets destroyed is at 0x7ffdd31bbbe0

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

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
This reminds me of PR 62052 but doesn't involve lambdas.

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

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
I tested on trunk. The sanitizer message disappeared.

[Bug fortran/67567] New: pretty-print.h sanitizer detects NULL pointer passed to obstack_grow

[zeccav at gmail dot com]

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

Bug ID: 67567
   Summary: pretty-print.h sanitizer detects NULL pointer passed
to obstack_grow
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While running make check-fortran on submodule_4.f08 the sanitizer complains
that in pretty-print.h:142

obstack_grow (buff->obstack, start, length);

the pointer start == NULL

Most probably length == 0

but I believe it best to fix it by prefixing the statement with "if(length)"

[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

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

--- Comment #4 from Francois-Xavier Coudert  ---
(In reply to Vittorio Zecca from comment #3)
> I tested on trunk. The sanitizer message disappeared.

I'll close the bug, then. A latent bug on an older branch is probably not
enough incentive to backport a fix…

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

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Posted updated patch series:
- https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00794.html
- https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00795.html

FTR, bootstrap and reg-test of this patch series on x86_64 succeeded.