[Bug c++/98899] ICE: Illegal instruction: 4 "error: could not convert '' from '''" on macOS

[akim.demaille at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Akim Demaille  ---
Created attachment 50094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50094=edit
simple.ii

simple.cc preprocessed

[Bug c++/98899] ICE: Illegal instruction: 4 "error: could not convert '' from '''" on macOS

[akim.demaille at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Akim Demaille  ---
Created attachment 50093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50093=edit
simple.cc

The source that causes the crash.

[Bug c++/98899] New: ICE: Illegal instruction: 4 "error: could not convert '' from '''" on macOS

[akim.demaille at gmail dot com via Gcc-bugs]

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

Bug ID: 98899
   Summary: ICE: Illegal instruction: 4 "error: could not convert
'' from '''" on macOS
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akim.demaille at gmail dot com
  Target Milestone: ---

G++ behaves randomly on this issue.  Sometimes it gives me an error message
that does not seem to be meant for the user:

```
$ g++-mp-10 simple.cc -Wall -c
simple.cc: In instantiation of
'yy::parser::basic_symbol::basic_symbol(typename Base::kind_type, int&&)
[with Base = yy::parser::by_kind; typename Base::kind_type =
yy::parser::token::token_kind_type]':
simple.cc:653:53:   required from here
simple.cc:484:7: error: could not convert '' from ''' not supported by dump_type' to 'bool'
  484 |   basic_symbol (typename Base::kind_type t, int&& v)
  |   ^~~~
simple.cc: In instantiation of
'yy::parser::basic_symbol::basic_symbol(typename Base::kind_type,
std::string&&) [with Base = yy::parser::by_kind; typename Base::kind_type =
yy::parser::token::token_kind_type; std::string =
std::__cxx11::basic_string]':
simple.cc:661:53:   required from here
simple.cc:497:7: error: could not convert '' from ''' not supported by dump_type' to 'bool'
  497 |   basic_symbol (typename Base::kind_type t, std::string&& v)
  |   ^~~~
simple.cc: In instantiation of
'yy::parser::basic_symbol::basic_symbol(yy::parser::basic_symbol&&)
[with Base = yy::parser::by_kind]':
simple.cc:722:41:   required from here
simple.cc:438:7: error: could not convert '' from ''' not supported by dump_type' to 'bool'
  438 |   basic_symbol (basic_symbol&& that)
  |   ^~~~
```

and sometimes it crashes:

```
$ g++-mp-10 simple.cc -Wall -c
simple.cc: In instantiation of
'yy::parser::basic_symbol::basic_symbol(typename Base::kind_type, int&&)
[with Base = yy::parser::by_kind; typename Base::kind_type =
yy::parser::token::token_kind_type]':
simple.cc:653:53:   required from here
simple.cc:484:7: internal compiler error: Illegal instruction: 4
  484 |   basic_symbol (typename Base::kind_type t, int&& v)
  |   ^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

I have tried to reduce the example, but it seems to be quite touchy.

This is:

```
$ g++-mp-10 --version
g++-mp-10 (MacPorts gcc10 10.2.0_4) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

FWIW, clang++ 11 accepts this source.

(I have problems trying to add the attachment, will try when the issue is
created.)

[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'

[jvdelisle at charter dot net via Gcc-bugs]

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

--- Comment #8 from Jerry DeLisle  ---
I agree with your comment #7

[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'

[max.pd at gmx dot de via Gcc-bugs]

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

--- Comment #7 from max.pd at gmx dot de ---
This DEC-F77 specification seems to be very adequate for the -fdec compiler
flag. For general use of the '$' in format expressions (even without the
compiler flag), it would not make much sense. Here it's the current
"ADVANCE='NO'" interpretation for single records that fits well. For multiple
records it would be coherent to have no carriage returns between the records
either.

I've tested it with flang (LLVM) and with the older OpenWatcom Fortran, and
they both behave like expected. They don't write carriage returns between the
records,
when the '$' is given in the format expression.

Of course the behavior changes for internal files. I guess it is standard that
internal files will write each record to a single field of an array. And the
program will abbort with an error, when the array is too small to take all the
records. This seems to be fully implemented in gfortran and works well in all
tests I made.

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[michaeljclark at mac dot com via Gcc-bugs]

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

Michael Clark  changed:

   What|Removed |Added

 CC||michaeljclark at mac dot com

--- Comment #10 from Michael Clark  ---
another data point. I am seeing something similar on x86-64.
SysV x86-64 ABI specifies that _Decimal128 is to be passed in
xmm regs so I believe the stack stores here are redundant.

; cat > dec1.c << EOF
_Decimal128 add_d(_Decimal128 a, _Decimal128 b) { return a + b; }
EOF
; gcc -O2 -S -masm=intel dec1.c 
; cat dec1.s
add_d:
.LFB0:
.cfi_startproc
endbr64
sub rsp, 40
.cfi_def_cfa_offset 48
movaps  XMMWORD PTR [rsp], xmm0
movaps  XMMWORD PTR 16[rsp], xmm1
call__bid_addtd3@PLT
movaps  XMMWORD PTR [rsp], xmm0
add rsp, 40
.cfi_def_cfa_offset 8
ret
.cfi_endproc

[Bug web/98898] New: [wwwdocs] typo in gcc-10 announcements page

[icalder.76d8f at torfree dot net via Gcc-bugs]

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

Bug ID: 98898
   Summary: [wwwdocs] typo in gcc-10 announcements page
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: icalder.76d8f at torfree dot net
  Target Milestone: ---

In this page:

  https://gcc.gnu.org/gcc-10/

At the top, under "July 23, 2020", in the sentence:

  The GNU project and the GCC developers are pleased to announce the release of
GCC 10.1.

Update "10.1" to "10.2", to correspond to the stated release date.

[Bug tree-optimization/98499] [11 Regression] Possibly bad std::string initialization in constructors

[slyfox at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Sergei Trofimovich  ---
(In reply to Jan Hubicka from comment #9)
> Thanks for all the detailed analysis and sorry for getting into this late.
> 
> > Oh, thank you! Only after many printf() attempts it sunk in that 
> > `036t.ealias` is using data from seemingly later `043t.modref1` pass. It is 
> > so confusing!
> 
> This is because it is an inter-procedural analysis.  We compile in
> topological order and propagate info from function to callers.
> 
> Here I think poblem is:
> 
> void Importer::Importer (struct Importer * const this)  
> 
> {   
> 
>   struct string * _1;   
> 
> 
> 
>:  
> 
>   *this_3(D) ={v} {CLOBBER};
> 
>   *this_3(D).base_path = dir_name (); [return slot optimization]
> 
>   return;   
> 
> 
> 
> }   
> 
> 
> We get parm 0 flags: direct noescape nodirectescape
> 
> While dir_name does:
> 
> struct string dir_name ()   
> 
> {   
> 
>:  
> 
>   string::string (_2(D));   
> 
>   return _2(D); 
> 
> 
> 
> }
> and that gets to
> 
> void string::string (struct string * const this)
> 
> {   
> 
>   char[16] * _1;
> 
> 
> 
>:  
> 
>   *this_3(D) ={v} {CLOBBER};
> 
>   _1 = _3(D)->_M_local_buf;
> 
>   *this_3(D)._M_buf = _1;   
> 
>   return;   
> 
> 
> 
> }   
> 
> which indeed conflict with noescape.
> 
> So problem here is that return slot optimized variables are behaving kind of
> like parameters.  Since modref does not track EAF flags for them I think
> your conservative fix makes sense.
> 
> It is also relatively easy to track the EAF flags here, I will try to get
> quick stats on how often this makes difference (and whether we want to add
> trakcing now or next stage1).

Sounds great!

I send a conservative variant of the patch with the test as
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564579.html. I hope I
will not interfere with your possible improvement.

[Bug middle-end/98896] local label displaced with -O2

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #9 from Stas Sergeev  ---
(In reply to Jakub Jelinek from comment #7)
> you need to tell the compiler
> the asm can goto to that label.

Of course the one would wonder what else
could be done to the passed label. :)
Maybe some distance was calculated by
subtracting 2 labels, or alike. Maybe
it wasn't jump.
But why does it help to assume that something
passed to volatile asm, remains unused?
Just wondering.
IMHO at least it deserves a warning.

[Bug c++/82640] gcc doesn't show errors on anonymous local variables

[vanyacpp at gmail dot com via Gcc-bugs]

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

Ivan Sorokin  changed:

   What|Removed |Added

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

--- Comment #1 from Ivan Sorokin  ---
It looks like this issue was fixed in GCC 8. Closing.

[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor

[anthonysharp15 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Anthony Sharp  ---
Okay, so it actually turns out public virtual bases CAN be derived from, since
the C++ spec literally gives an example of just that (e.g. see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf at page 248
[I know it's the draft but I'm poor]).

As such, Visual Studio has no complaints about the following code:

class V {  };
class A : virtual public V {  };
class C : public A {  };

But it spits out warnings for this:

class V {  };
class A : virtual V {  };
class C : public A {  };

The problem is this issue requires such in-depth knowledge of the standard that
it's difficult to form an actual opinion on it. I will do some more research
and then maybe I'll be able to comment more. Overall though it seems the issue
is whether private inheritance affects the accessibility of the destructor
and/or constructor of a virtually-inherited baseclass to other deriving
classes. I could be wrong about that though.

What I will say though is that even without having to dive into the technical
details, the fact that one would not be able to derive from a private virtual
base makes no sense, intuitively speaking. A private base can be derived from.
A virtual base can be derived from. I don't see why it should make any
practical difference that the base might be both virtual and private.

[Bug c++/33661] template methods forget explicit local register asm vars

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||nate at verse dot com

--- Comment #20 from Florian Weimer  ---
*** Bug 58118 has been marked as a duplicate of this bug. ***

[Bug c++/58118] Local variables specified with asm("reg") may not work

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #1 from Florian Weimer  ---
Seems to be a duplicate of bug 33661 and bug 98847.

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

[Bug middle-end/29305] local label-as-value being placed before function prolog

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Stas Sergeev  changed:

   What|Removed |Added

 CC||stsp at users dot 
sourceforge.net

--- Comment #11 from Stas Sergeev  ---
Just for a heads-up.
The solution to that problem was suggested here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896#c7

[Bug middle-end/98896] local label displaced with -O2

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #8 from Stas Sergeev  ---
(In reply to Jakub Jelinek from comment #7)
> It doesn't mean you can't use "r" (&),

Well, if not for Andrew telling exactly that
you can't, both here and in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
then indeed, it doesn't.
Because this seems to work:
---
int main(void)
{
__label__ cont;
asm volatile goto (
"push %0\n"
"ret\n"
::"r"(&):"memory":cont);
cont:
return 0;
}
---

So... is this a correct, documented, supported etc
way of doing things, and it won't disappear in the
next gcc version?
Then perfectly fine.

Thanks for your help!

[Bug middle-end/98896] local label displaced with -O2

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jakub Jelinek  ---
It doesn't mean you can't use "r" (&), but you need to tell the compiler
the asm can goto to that label.
Or of course can just use the rip based addressing yourself in the inline asm,
the label's %X stands just for the label.

[Bug middle-end/98896] local label displaced with -O2

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #6 from Stas Sergeev  ---
(In reply to Jakub Jelinek from comment #5)
> I think Andrew meant asm goto, which you haven't tried.

You are right.
Thanks for mentioning that.
But it doesn't work as well:
---
int main(void)
{
__label__ cont;
asm volatile goto (
"push %l[cont]\n"
"ret\n"
cont);
cont:
return 0;
}
---

$ LC_ALL=C cc -Wall -ggdb3 -O2 -o jmpret2 jmpret2.c -pie -fPIE
/usr/bin/ld: /tmp/cc1UoxnD.o: relocation R_X86_64_32S against `.text.startup'
can not be used when making a PIE object; recompile with -fPIE


And in an asm file we see:
---
#APP
# 4 "jmpret2.c" 1
push .L2#
ret
---


Please compare this to the following:
---
int main(void)
{
__label__ cont;
asm volatile (
"push %0\n"
"ret\n"
::"r"(&));
cont:
return 0;
}
---

And its asm:
---
.L2:
.loc 1 4 5 view .LVU1
leaq.L2(%rip), %rax #, tmp83
#APP
# 4 "jmpret3.c" 1
push %rax   # tmp83
ret
---


So... it seems, only the second case can work,
and indeed does with clang?

[Bug middle-end/98896] local label displaced with -O2

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
I think Andrew meant asm goto, which you haven't tried.  That is the standard
feature that tells the compiler about the possible control flow from the inline
asm, just having & passed to inline asm (or even maybe propagated)
doesn't mean the inline asm may jump there, in such case there is no cfg edge
to the label and labels which are unreachable are just placed somewhere, don't
prevent optimizations etc.

[Bug testsuite/98243] gcc.dg/gomp/simd-2.c etc. FAIL

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:25f303e9a27a0d799f9979446d9f11ed62b8d648

commit r11-6993-g25f303e9a27a0d799f9979446d9f11ed62b8d648
Author: Jakub Jelinek 
Date:   Sat Jan 30 10:52:57 2021 +0100

testsuite: Fix up gomp/simd-{2,3}.c tests [PR98243]

The test (intentionally) is not gcc.dg/vect/, as it needs -fopenmp and uses
OpenMP directives other than simd and therefore can't rely on default
VECTFLAGS and so I think can't safely use vect_int effective target
either.  So, I'm just making sure it is vectorized on x86 and on aarch64
(the
latter as an example of a target that doesn't need any extra options to get
the vectorization).

2021-01-30  Jakub Jelinek  

PR testsuite/98243
* gcc.dg/gomp/simd-2.c: Add -msse2 on x86.  Restrict
scan-tree-dump-times to x86 and aarch64 targets.
* gcc.dg/gomp/simd-3.c: Likewise.

[Bug c++/98895] C++ module generates too many dead code

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Pilar Latiesa  ---
(In reply to cqwrteur from comment #0)

> If those issues cannot be solved, I am sorry, I would only say C++20 modules
> failed completely.

What do you expect from being so offensive? Is this comment necessary at all?
Do you realize that some people have devoted several years of work to have the
feature ready for us to use it for free?

[Bug c++/98885] [modules] forward declaration of classes prevent them from being exported at the point of actual declaration

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Pilar Latiesa  ---
(In reply to Nathan Sidwell from comment #7)

That works. Thanks so much.

When there are several partitions involved it is not entirely clear to me what
declarations are first seen by the compiler compared with the legacy textual
inclusion model, so I assume that the rule would be to annotate every forward
declaration of an exported entity with 'export'.