[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Any update on this David?

[Bug c++/89381] [7/8/9 Regression] Implicit copy constructor cannot be generated after unrelated class definition

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.5.0
   Keywords|diagnostic, needs-reduction |
   Last reconfirmed||2019-02-18
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Implicit copy constructor   |[7/8/9 Regression] Implicit
   |cannot be generated after   |copy constructor cannot be
   |unrelated class definition  |generated after unrelated
   ||class definition
  Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
Reduced:

template
struct base
{
  base() { }
  base(const base&) { }
  base(base&&) { }
  base& operator=(const base&) { return *this; }
  base& operator=(base&&) { return *this; }
};

struct foo : base
{
using base::base;
using base::operator=;
};

//using workaround = decltype(foo{*static_cast(0)});

struct bar
{
bar& operator=(foo ve)
{
value = ve;
return *this;
}

foo value;
};

int main()
{
foo a;
foo b{a};
}


Regressed with r235002

PR c++/70528

* class.c (type_has_constexpr_default_constructor): Return true
for an implicitly declared constructor.

[Bug preprocessor/89380] Multiple items in brace not working on nested macro

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> I think these kind of questions should be handled in gcc-help@ rather than
> here.  Maybe in a standard C forum too.

^^ this,

"How do I do funky things with the preprocessor?" is not a GCC bug.

[Bug preprocessor/89373] macro expansion not counting braces correctly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
You can use a variadic macro that allows multiple preprocessor tokens separated
by commas.

There's no GCC bug here.

[Bug fortran/84387] Defined output does not work for a derived type that has no components

[damian at sourceryinstitute dot org]

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

--- Comment #6 from Damian Rouson  ---
I don't see anything in the standard related to the existence or non-existence
of components in derived-type output.  In case it helps, the NAG and Intel
compilers both print "Hello world!" with the submitted code, but the Cray
compiler prints nothing, which matches gfortran's behavior.  I'll contact Cray
technical support to see if they agree it's a bug.

--- Comment #7 from Damian Rouson  ---
I don't see anything in the standard related to the existence or non-existence
of components in derived-type output.  In case it helps, the NAG and Intel
compilers both print "Hello world!" with the submitted code, but the Cray
compiler prints nothing, which matches gfortran's behavior.  I'll contact Cray
technical support to see if they agree it's a bug.

[Bug fortran/84387] Defined output does not work for a derived type that has no components

[damian at sourceryinstitute dot org]

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

--- Comment #6 from Damian Rouson  ---
I don't see anything in the standard related to the existence or non-existence
of components in derived-type output.  In case it helps, the NAG and Intel
compilers both print "Hello world!" with the submitted code, but the Cray
compiler prints nothing, which matches gfortran's behavior.  I'll contact Cray
technical support to see if they agree it's a bug.

--- Comment #7 from Damian Rouson  ---
I don't see anything in the standard related to the existence or non-existence
of components in derived-type output.  In case it helps, the NAG and Intel
compilers both print "Hello world!" with the submitted code, but the Cray
compiler prints nothing, which matches gfortran's behavior.  I'll contact Cray
technical support to see if they agree it's a bug.

[Bug c++/89382] Segmentation fault when doing (depth recursive) Template Metaprogramming

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>-ftemplate-depth=10

This is why there is a decent limit.
Increase the allocated stack via ulimit.

[Bug fortran/84387] Defined output does not work for a derived type that has no components

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
(In reply to Damian Rouson from comment #4)
> I don't agree that the code submitted in this bug report is non-sensical.
> The submitted example is very useful for code debugging purposes.   I just
> spent a couple of hours trying to isolate this same bug.  Being able to
> print output for a type with no components would have saved me the all the
> time that led to finding this bug report.
> 

Ah! We often don't see the importance of emptyness, or the 'null' case so to
speak. That does make sense to me. How does this fall out w.r.t the Fortran
Standard. Is it explicitly required, processor defined, or our own extension?

[Bug c++/89382] New: Segmentation fault when doing (depth recursive) Template Metaprogramming

[josehidalgo at outlook dot cl]

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

Bug ID: 89382
   Summary: Segmentation fault when doing (depth recursive)
Template Metaprogramming
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josehidalgo at outlook dot cl
  Target Milestone: ---

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

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
$ g++ -Wall -Wextra test.cpp -ftemplate-depth=10
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/89381] New: Implicit copy constructor cannot be generated after unrelated class definition

[nok.raven at gmail dot com]

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

Bug ID: 89381
   Summary: Implicit copy constructor cannot be generated after
unrelated class definition
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic, needs-reduction, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

For some reason `bar` makes `foo` not copy-constructible. It compiles if
you remove `bar`, or force compiler to generate copy-constructor before
`bar` definition.

#include 

struct foo : std::variant
{
using std::variant::variant;
using std::variant::operator=;
};

//using workaround = decltype(foo{*static_cast(0)});

struct bar
{
bar& operator=(foo ve)
{
value = std::move(ve);
return *this;
}

foo value;
};


int main()
{
foo a;
foo b{a};
}


prog.cc: In function 'int main()':
prog.cc:26:12: error: use of deleted function 'constexpr foo::foo(const foo&)'
   26 | foo b{a};
  |^
prog.cc:3:8: note: 'constexpr foo::foo(const foo&)' is implicitly declared as
deleted because 'foo' declares a move constructor or move assignment operator
3 | struct foo : std::variant
  |^~~
1

https://godbolt.org/z/DylgFW

[Bug fortran/84387] Defined output does not work for a derived type that has no components

[damian at sourceryinstitute dot org]

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

--- Comment #4 from Damian Rouson  ---
I don't agree that the code submitted in this bug report is non-sensical. The
submitted example is very useful for code debugging purposes.   I just spent a
couple of hours trying to isolate this same bug.  Being able to print output
for a type with no components would have saved me the all the time that led to
finding this bug report.

Also, there are many uses for an empty derived type that serves as a
polymorphic hook on which to hang various type-bound procedures where the
choice of which procedure gets executed is determined by the dynamic type of
the passed-object dummy argument.  Moreover, if a type with no components
appears one several objects being output, the user might like to see some text
to know that the type was there.  Such types crop up frequently in the Strategy
object-oriented design pattern.

[Bug fortran/68649] [7/8/9 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[dominiq at lps dot ens.fr]

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

--- Comment #26 from Dominique d'Humieres  ---
> > The warnings are gone between revisions r265814 and r265942.
>
> I can confirm that.

> So, are there objections to just committing a test case and
> closing this bug?

My (shallow) understanding of the above thread was that the warning made sense.
If this is still true, then the missing warning is a regression.
If not, why?

[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-02/msg01415.ht
   ||ml

--- Comment #24 from Thomas Koenig  ---
I just checked that the patch at
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01415.html does indeed fix the
test case on POWER9.

[Bug fortran/68649] [7/8/9 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[tkoenig at gcc dot gnu.org]

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

--- Comment #25 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #24)
> The warnings are gone between revisions r265814 and r265942.

I can confirm that.

So, are there objections to just committing a test case and
closing this bug?

[Bug fortran/88299] [F18] COMMON in a legacy module produces bogus warnings in dependent code

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

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

--- Comment #7 from Harald Anlauf  ---
Fixed.

[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
The test case is now rejected with trunk, looks like a recent 9 regression:

ig25@linux-p51k:/tmp> gfortran m_vstring.f90 
m_vstring.f90:24:30:

   24 |   pure function vstring_length ( this ) result ( length )
  |  1
Error: MODULE-PROC procedure at (1) is already declared as EXTERNAL-PROC
procedure
m_vstring.f90:25:43:

   25 | type ( t_vstring ) , intent(in) :: this
  |   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
m_vstring.f90:26:21:

   26 | integer :: length
  | 1
Error: Unexpected data declaration statement in CONTAINS section at (1)
m_vstring.f90:27:27:

   27 | if ( associated ( this%chars ) ) then
  |   1
Error: Symbol 'this' at (1) has no IMPLICIT type
m_vstring.f90:28:26:

   28 |length = SIZE(this%chars)
  |  1
Error: Symbol 'this' at (1) has no IMPLICIT type
m_vstring.f90:29:8:

   29 | else
  |1
Error: Unexpected ELSE statement in CONTAINS section at (1)
m_vstring.f90:30:17:

   30 |length = 0
  | 1
Error: Unexpected assignment statement in CONTAINS section at (1)
m_vstring.f90:31:7:

   31 | endif
  |   1
Error: Expecting END MODULE statement at (1)
m_vstring.f90:32:5:

   32 |   end function vstring_length
  | 1
Error: Expecting END MODULE statement at (1)
m_vstring.f90:10:26:

   10 |   public :: vstring_length
  |  1
Error: Symbol 'vstring_length' at (1) has no IMPLICIT type
m_vstring.f90:17:21:

   17 | character ( len = vstring_length ( this ) ) :: char_string
  | 1
Error: 'vstring_length' at (1) is not a function

[Bug fortran/89077] ICE using * as len specifier for character parameter

[anlauf at gmx dot de]

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

--- Comment #19 from Harald Anlauf  ---
The issues reported in comment #0, #1 and #3 should be fixed on trunk.
The fix for comment #0 has been backported to 7- and 8-branches.

Can the OP please confirm that the reported issues have been fixed?

[Bug fortran/88299] [F18] COMMON in a legacy module produces bogus warnings in dependent code

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Sun Feb 17 21:19:20 2019
New Revision: 268974

URL: https://gcc.gnu.org/viewcvs?rev=268974=gcc=rev
Log:
2019-02-17  Harald Anlauf  

PR fortran/88299
* resolve.c (resolve_common_blocks,resolve_common_vars): Move
check for obsolent COMMON feature in F2018 to better place.

PR fortran/88299
* gfortran.dg/pr88299.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr88299.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/89077] ICE using * as len specifier for character parameter

[anlauf at gcc dot gnu.org]

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

--- Comment #18 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Sun Feb 17 21:14:14 2019
New Revision: 268973

URL: https://gcc.gnu.org/viewcvs?rev=268973=gcc=rev
Log:
2019-02-17  Harald Anlauf  

PR fortran/89077
* decl.c (gfc_set_constant_character_len): Clear original string
representation after padding has been performed to target length.

PR fortran/89077
* gfortran.dg/transfer_simplify_12.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/transfer_simplify_12.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/89380] Multiple items in brace not working on nested macro

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to mdblack98 from comment #5)
> Why can't it be fixed by not counting commas between braces?  That seems to
> be the problem.

Because then GCC will break some valid C code :).  I think you should make a
proposal to the C Language committee if you really want this feature.  NOTE
this feature will break backward compatibility with older standards but maybe
the C committee will agree with it.  NOTE it won't be the default in GCC for a
long time (maybe around 10 years from now) if it gets accepted by the C
standards comittee today.

[Bug preprocessor/89380] Multiple items in brace not working on nested macro

[mdblack98 at yahoo dot com]

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

--- Comment #5 from mdblack98 at yahoo dot com ---
Why can't it be fixed by not counting commas between braces?  That seems to be
the problem.

[Bug preprocessor/89380] Multiple items in brace not working on nested macro

[sch...@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab  ---
You can do dirty things with hiding the comma behind a macro, but don't do this
at home, kids.

[Bug preprocessor/89380] Multiple items in brace not working on nested macro

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
This won't work with macros pain and simple.  There is nothing GCC can solve
here.

Doing this:
FRQ_RNG_HF(1, (MYLIST), 5,100,1,1);
Fixes the macro issue but you are left with:
struct foo myfoo2 = { 1810, 2, ({1,2}), 5, 100, 1, (1) };

Which is invalid code.

[Bug preprocessor/89380] Multiple items in brace not working on nested macro

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
https://stuff.mit.edu/afs/athena/project/rhel-doc/3/rhel-cpp-en-3/macro-pitfalls.html

[Bug preprocessor/89380] Multiple items in brace not working on nested macro

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think these kind of questions should be handled in gcc-help@ rather than
here.  Maybe in a standard C forum too.

[Bug c/89380] New: Multiple items in brace not working on nested macro

[mdblack98 at yahoo dot com]

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

Bug ID: 89380
   Summary: Multiple items in brace not working on nested macro
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdblack98 at yahoo dot com
  Target Milestone: ---

Additional report from bug#89373

#include 

// To see the bug
// gcc -DBUG -c x3.c

// Single item in braces is OK
// Multiple items in braces not OK

#ifdef BUG
#define MYLIST {1,2}
#else
#define MYLIST {1}
#endif

#define FRQ_RNG_160m_REGION1(md,lp,hp,v,a) \
{ 1810, 2, md, (lp), (hp), (v), (a) }

#define FRQ_RNG_HF(r,m,lp,hp,v,a) \
  FRQ_RNG_160m_REGION##r(m, (lp), (hp), (v), (a))


struct foo {
  int band;
  int region;
  int md[4];
  int lp;
  int hp;
  int v;
  int a;
};

struct foo myfoo = {  1,2, MYLIST,4,5,6,7 };

struct foo myfoo2 = FRQ_RNG_HF(1, MYLIST, 5,100,1,1);

int
main()
{
  for(int i=0;i<4;++i) printf("kk %d,%d\n",i,myfoo.md[i]);
  return 0;
}

[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.

[frank.secilia at gmail dot com]

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

--- Comment #5 from Frank Secilia  ---
Created attachment 45744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45744=edit
alternative verbose compiler output

[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.

[frank.secilia at gmail dot com]

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

--- Comment #4 from Frank Secilia  ---
Created attachment 45743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45743=edit
alternative repro case using pointers to method

Here is a similar case using pointers to methods. I'm honestly not sure if this
is even allowed by the standard, but it works as expected with clang.

[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Sun Feb 17 17:53:54 2019
New Revision: 268972

URL: https://gcc.gnu.org/viewcvs?rev=268972=gcc=rev
Log:
PR c++/89356
* g++.dg/abi/mangle68.C: New test.
* g++.dg/cpp0x/decltype69.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/abi/mangle68.C
trunk/gcc/testsuite/g++.dg/cpp0x/decltype69.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Fixed by r268969, I'm adding new tests.

[Bug c++/89315] [9 Regression] Cannot convert to std::initializer_list - fails with gcc9 works with gcc8

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Lars, thanks for the report!

[Bug c++/89315] [9 Regression] Cannot convert to std::initializer_list - fails with gcc9 works with gcc8

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Sun Feb 17 17:25:27 2019
New Revision: 268971

URL: https://gcc.gnu.org/viewcvs?rev=268971=gcc=rev
Log:
PR c++/89315
* g++.dg/cpp0x/initlist114.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist114.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/89315] [9 Regression] Cannot convert to std::initializer_list - fails with gcc9 works with gcc8

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Fixed by r268969, will add the test.

[Bug c++/89217] [9 Regression] ICE tree check: expected constructor, have error_mark in split_nonconstant_init_1

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/89217] [9 Regression] ICE tree check: expected constructor, have error_mark in split_nonconstant_init_1

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Sun Feb 17 16:52:40 2019
New Revision: 268969

URL: https://gcc.gnu.org/viewcvs?rev=268969=gcc=rev
Log:
PR c++/89217 - ICE with list-initialization in range-based for loop.
* constexpr.c (unshare_constructor): No longer static.
* cp-tree.h (unshare_constructor): Declare.
* semantics.c (finish_compound_literal): When dealing with a
non-dependent expression in a template, return the original
expression.  Pass LOOKUP_NO_NARROWING to digest_init_flags.

* g++.dg/cpp0x/range-for37.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for37.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation

[tkoenig at gcc dot gnu.org]

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

--- Comment #23 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #22)

> FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o
> link, -O0 -flto -flto-partition=none -fuse-linker-plugin

These test cases are invalid:


SUBROUTINE int_gen_ti_header_char( hdrbuf, hdrbufsize, itypesize, &
  DataHandle, Element, VarName, Data, code )
  CALL int_gen_ti_header_c ( hdrbuf, hdrbufsize, itypesize, 1, &
 DataHandle, DummyData, DummyCount, code )
END SUBROUTINE int_gen_ti_header_char

certainly does not fit 

void int_gen_ti_header_c_ (char * hdrbuf, int * hdrbufsize,
   int * itypesize, int * typesize,
   int * DataHandle, char * Data,
   int * Count, int * code)
{
  memcpy (typesize, p, sizeof(int)) ;
  memcpy (Data, p, *Count * *typesize) ;
}

so it is a good sign that they are caught now :-)

[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation

[tkoenig at gcc dot gnu.org]

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

--- Comment #22 from Thomas Koenig  ---
Created attachment 45742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45742=edit
Patch that may work, but causes some regressions

The regressions are:

FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o
link, -O0 -flto -flto-partition=none -fuse-linker-plugin
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o
link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects 
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o
link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o
link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o
link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects 
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o
link, -O2 -flto -fuse-linker-plugin
Running
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp
...
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o
link, -O0 -flto -flto-partition=none -fuse-linker-plugin
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o
link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects 
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o
link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o
link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o
link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects 
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o
link, -O2 -flto -fuse-linker-plugin

I will have to see if I can make any sense out of this.

[Bug c++/88826] ICE (segfault) when compiling invalid C++ code with -std=c++2a

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jason at redhat dot com
   Target Milestone|--- |9.0

--- Comment #1 from H.J. Lu  ---
It is caused by r266056.

[Bug c/89379] -Wformat is supposed not to give warning

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
PRIu16 is for printf, you need SCNu16.

[Bug c/89379] New: -Wformat is supposed not to give warning

[lvenkatakumarchakka at gmail dot com]

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

Bug ID: 89379
   Summary: -Wformat is supposed not to give warning
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lvenkatakumarchakka at gmail dot com
  Target Milestone: ---

I have written code as follows:

#include
#include

int main()
{
uint16_t value;
scanf( "%"PRIu16,  );
}

seeing warning

$ gcc foo.c -Wformat
foo.c: In function ‘main’:
foo.c:7:9: warning: format ‘%u’ expects argument of type ‘unsigned int *’, but
argument 2 has type ‘uint16_t *’ {aka ‘short unsigned int *’} [-Wformat=]
  scanf( "%"PRIu16,  );
 ^~~~~
In file included from foo.c:1:
/usr/include/inttypes.h:103:19: note: format string is defined here
 # define PRIu16  "u"

[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #21 from Thomas Koenig  ---
Think I might have something.

[Bug c++/83417] Pointer-to-member template parameter with auto member type dependent container type does not work (C++17)

[pavel.kryukov at phystech dot edu]

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

Pavel I. Kryukov  changed:

   What|Removed |Added

 CC||pavel.kryukov at phystech dot 
edu

--- Comment #1 from Pavel I. Kryukov  ---
The bug is reproduced with GCC 8.2 and trunk: https://godbolt.org/z/zOBJUw