date:20210117

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I guess the primary question is why does it emit any .file directives or
.debug_str when it is compiled with -g -O2 -g0.  That seems like the bug.

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

2021-01-17 Thread kargl at gcc dot gnu.org via Gcc-bugs

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from kargl at gcc dot gnu.org ---
The code uses undefined variables.  With g77, these seem to be initialized to
some value.  If -freal-init=nan is used, the compiled program dies quickly.  In
other words, the bug is in the program not gfortran.

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

2021-01-17 Thread tkoenig at gcc dot gnu.org via Gcc-bugs

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #15 from Thomas Koenig  ---
Just one final remark.

Using gfortran -O2 -Wall FiberAnalysis.f

will give you

FiberAnalysis.f:146:72:

  146 |   if(eincr.gt.0) xnumber=(esfinal-estart)/eincr
  |   
^
Warnung: »estart« may be used uninitialized [-Wmaybe-uninitialized]
FiberAnalysis.f:146:44:

  146 |   if(eincr.gt.0) xnumber=(esfinal-estart)/eincr
  |^
Hinweis: »estart« ist hier deklariert
FiberAnalysis.f:148:9:

  148 |   if(xnumber.gt.500) then
  | ^
Warnung: »xnumber« könnte in dieser Funktion uninitialisiert verwendet werden
[-Wmaybe-uninitialized]


which pretty well shows where problems could occur.

[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments

2021-01-17 Thread shmal_i at mail dot ru via Gcc-bugs

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

Igor CHMAL  changed:

   What|Removed |Added

 CC||shmal_i at mail dot ru

--- Comment #1 from Igor CHMAL  ---
Created attachment 49984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49984&action=edit
compiler

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Jakub Jelinek  ---
Ah, no, the *.s file is generated with -g, but the assembler isn't able to cope
with it.
I'd say that the assembler shouldn't require any directive or flag but just
assemble it.
Anything else seems to be an assembler bug.

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Jakub Jelinek  ---
The assembler has all the information in the assembly, .debug_info section
contains version etc.

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Jakub Jelinek  ---
I'd be for automatic bumping to dwarf5 level if .file 0 is seen, but remember
that it happened and issue an error if .debug_info with version older than 5 is
seen in the file.

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread mark at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Mark Wielaard  ---
I am not sure where the -g -O2 -g0 comes from. I must have missed this in my
testing.

The issue is the .file 0 directive, which is special to gas (only valid with
-gdwarf-5).

It is generated by dwarf2out_finish ():

  /* Output the source line correspondence table.  We must do this
 even if there is no line information.  Otherwise, on an empty
 translation unit, we will generate a present, but empty,
 .debug_info section.  IRIX 6.5 `nm' will then complain when
 examining the file.  This is done late so that any filenames
 used by the debug_info section are marked as 'used'.  */
  switch_to_section (debug_line_section);
  ASM_OUTPUT_LABEL (asm_out_file, debug_line_section_label);
  if (! output_asm_line_debug_info ())
output_line_info (false);
  else if (asm_outputs_debug_line_str ())
{
  /* When gas outputs DWARF5 .debug_line[_str] then we have to
 tell it the comp_dir and main file name for the zero entry
 line table.  */
  const char *comp_dir, *filename0;

  comp_dir = comp_dir_string ();
  if (comp_dir == NULL)
comp_dir = "";

  filename0 = get_AT_string (comp_unit_die (), DW_AT_name);
  if (filename0 == NULL)
filename0 = "";

  fprintf (asm_out_file, "\t.file 0 ");
  output_quoted_string (asm_out_file, remap_debug_filename (comp_dir));
  fputc (' ', asm_out_file);
  output_quoted_string (asm_out_file, remap_debug_filename (filename0));
  fputc ('\n', asm_out_file);
}

So it looks like the asm_outputs_debug_line_str () is wrong:

/* Returns TRUE if we are outputting DWARF5 and the assembler supports
   DWARF5 .debug_line tables using .debug_line_str or we generate
   it ourselves, except for split-dwarf which doesn't have a
   .debug_line_str.  */
static bool
asm_outputs_debug_line_str (void)
{
  if (dwarf_version >= 5
  && ! output_asm_line_debug_info ()
  && DWARF5_USE_DEBUG_LINE_STR)
return true;
  else
{
#if defined(HAVE_AS_GDWARF_5_DEBUG_FLAG) &&
defined(HAVE_AS_WORKING_DWARF_N_FLAG)
  return !dwarf_split_debug_info && dwarf_version >= 5;
#else
  return false;
#endif
}
}

It probably should check debug_info_level > DINFO_LEVEL_NONE.

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Jakub Jelinek  ---
Bootstrap is fine if one uses older binutils.
The thing is that cxx11-ios_failure* is built by hand first with -g -O2 -S,
then the assembly is modified by a script and then it is assembled, and as
older assemblers would fail miserably on assembling .s file containing
.debug_info etc. with -g (-gdwarf-2 passed to assembler), the assembly is
invoked with -g -O2 -c -g0.
I really think this should be fixed solely on the assembler side, and
if needed, we can add a temporary workaround, I guess compiling
cxx11-ios_failure* with -gno-as-loc-support could fix that.

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread hjl.tools at gmail dot com via Gcc-bugs

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

--- Comment #10 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #9)
> Bootstrap is fine if one uses older binutils.
> The thing is that cxx11-ios_failure* is built by hand first with -g -O2 -S,
> then the assembly is modified by a script and then it is assembled, and as
> older assemblers would fail miserably on assembling .s file containing
> .debug_info etc. with -g (-gdwarf-2 passed to assembler), the assembly is
> invoked with -g -O2 -c -g0.
> I really think this should be fixed solely on the assembler side, and
> if needed, we can add a temporary workaround, I guess compiling
> cxx11-ios_failure* with -gno-as-loc-support could fix that.

Assembler option:

 --gdwarf-generate DWARF debugging information. 2 <=  <= 5

both accepts and generates DWARF info.  This decision is made very early.

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread mark at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from Mark Wielaard  ---
Aha, now I see in libstdc++-v3/src/c++11/Makefile.am:

if ENABLE_DUAL_ABI
# Rewrite the type info for __ios_failure.
rewrite_ios_failure_typeinfo = sed -e
'/^_*_ZTISt13__ios_failure:/,/_ZTVN10__cxxabiv120__si_class_type_infoE/s/_ZTVN10__cxxabiv120__si_class_type_infoE/_ZTVSt19__iosfail_type_info/'

cxx11-ios_failure-lt.s: cxx11-ios_failure.cc
$(LTCXXCOMPILE) -S $< -o tmp-cxx11-ios_failure-lt.s
-test -f tmp-cxx11-ios_failure-lt.o && mv -f tmp-cxx11-ios_failure-lt.o
tmp-cxx11-ios_failure-lt.s
$(rewrite_ios_failure_typeinfo) tmp-$@ > $@
-rm -f tmp-$@
cxx11-ios_failure.s: cxx11-ios_failure.cc
$(CXXCOMPILE) -S $< -o tmp-$@
$(rewrite_ios_failure_typeinfo) tmp-$@ > $@
-rm -f tmp-$@

cxx11-ios_failure.lo: cxx11-ios_failure-lt.s
$(LTCXXCOMPILE) -g0 -c $< -o $@
cxx11-ios_failure.o: cxx11-ios_failure.s
$(CXXCOMPILE) -g0 -c $<
endif

Then my workaround of checking for debug_info_level > DINFO_LEVEL_NONE indeed
wouldn't work. It is explicitly generating debuginfo for the assembly file and
then adding -g0 when turning the assembly file into an object file. So that is
too late.

I don't think adding -gno-as-loc-support to the -S invocation will work because
of the definition of asm_outputs_debug_line_str () which is true if
dwarf_version >= 5 && ! output_asm_line_debug_info () &&
DWARF5_USE_DEBUG_LINE_STR. So then it will still generate the .file 0
directive.

Ideally gas wouldn't error on .file 0, but simply ignore it when not generating
DWARF5.

Maybe the simplest workaround for now would be also adding -g0 to the -S
invocations?

[Bug c++/98704] coroutine_handle::done() == false after promise's unhandled_exception() has thrown

2021-01-17 Thread m.krause--- via Gcc-bugs

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

--- Comment #1 from Michael Krause  ---
Created attachment 49985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49985&action=edit
A possible fix?

Would this be the proper way to fix the problem? That is, instead of generating
a simple "promise.unhandled_exception()" call, generate:

 try {
 promise.unhandled_exception();
 } catch(...) {
 resume_fn_ptr = 0; // ensure that done() returns true
 throw;
 }

Seems to fix my problem, but then I don't know the gcc code base; maybe the
change has undesired side effects. If somebody can confirm this is the way to
go, I would be willing to provide a cleaned-up, mergable version including test
cases etc...

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread mark at gcc dot gnu.org via Gcc-bugs

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

--- Comment #12 from Mark Wielaard  ---
On the binutils gas side it could be as simple as turning the error into a
warning:

diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
index a428370ecca..a216bfd6b28 100644
--- a/gas/dwarf2dbg.c
+++ b/gas/dwarf2dbg.c
@@ -1044,7 +1044,7 @@ dwarf2_directive_filename (void)

   if ((offsetT) num < 1 && DWARF2_LINE_VERSION < 5)
 {
-  as_bad (_("file number less than one"));
+  as_warn (_("file number less than one, ignored"));
   ignore_rest_of_line ();
   return NULL;
 }
@@ -1143,7 +1143,8 @@ dwarf2_directive_loc (int dummy ATTRIBUTE_UNUSED)
 {
   if (filenum != 0 || DWARF2_LINE_VERSION < 5)
{
- as_bad (_("file number less than one"));
+ as_warn (_("file number less than one, ignored"));
+ ignore_rest_of_line ();
  return;
}
 }
diff --git a/gas/testsuite/gas/lns/lns-diag-1.l
b/gas/testsuite/gas/lns/lns-diag-1.l
index 1256e85cfcb..d8aa84d9d1a 100644
--- a/gas/testsuite/gas/lns/lns-diag-1.l
+++ b/gas/testsuite/gas/lns/lns-diag-1.l
@@ -1,5 +1,5 @@
 .*: Assembler messages:
-.*:2: Error: file number less than one
+.*:2: Warning: file number less than one, ignored
 .*:3: Error: missing string
 .*:4: Error: file table slot 1 is already occupied.*
 .*:8: Error: unassigned file number 3
@@ -9,7 +9,7 @@
 .*:19: Error: bad or irreducible absolute expression
 .*:23: Error: isa number less than zero
 .*:26: Error: bad or irreducible absolute expression
-.*:26: Error: file number less than one
+.*:26: Warning: file number less than one, ignored
 .*:27: Error: bad or irreducible absolute expression
 .*:28: Error: unknown .loc sub-directive `frobnitz'
 .*:29: Error: unknown .loc sub-directive `frobnitz'

[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments

2021-01-17 Thread dominiq at lps dot ens.fr via Gcc-bugs

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2021-01-17
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from GCC9 up to GCC11. GCC8 vives

Undefined symbols for architecture x86_64:
  "___copy_REAL_4_.3803", referenced from:
  ___vtab_REAL_4_.3802 in ccc5fkCP.o
  "___copy_character_1.3889", referenced from:
  ___vtab_CHARACTER_1_.3888 in ccc5fkCP.o

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #13 from Jakub Jelinek  ---
But then it will warn and not do what it was expected to do.

Anyway, I've rebuilt cc1plus (on a box without new binutils) with hacking up
auto-host.h so that it normally emits .file 0 "..." directive, and with
-gno-as-loc-support it doesn't emit it.  Will try it soon in a koji build where
it failed.

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread hjl.tools at gmail dot com via Gcc-bugs

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

--- Comment #14 from H.J. Lu  ---
Created attachment 49986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49986&action=edit
A patch

How about this assembler patch?

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #15 from Jakub Jelinek  ---
Comment on attachment 49986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49986
A patch

If that works, that would be great.
I can't easily test it right away, but perhaps you could.
Just compile some other libstdc++ source with -g -O2 -c
on gcc configured against latest binutils, save the *.o file and repeat
with -g -O2 -S + assembly by hand without -g* and compare if the readelf -wl
between the two is identical.

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

2021-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #16 from Jakub Jelinek  ---
And the temporary workaround could be
--- libstdc++-v3/src/c++11/Makefile.am.jj   2021-01-04 10:26:02.067970728
+0100
+++ libstdc++-v3/src/c++11/Makefile.am  2021-01-17 17:20:58.580262364 +0100
@@ -141,12 +141,12 @@ if ENABLE_DUAL_ABI
 rewrite_ios_failure_typeinfo = sed -e
'/^_*_ZTISt13__ios_failure:/,/_ZTVN10__cxxabiv120__si_class_type_infoE/s/_ZTVN10__cxxabiv120__si_class_type_infoE/_ZTVSt19__iosfail_type_info/'

 cxx11-ios_failure-lt.s: cxx11-ios_failure.cc
-   $(LTCXXCOMPILE) -S $< -o tmp-cxx11-ios_failure-lt.s
+   $(LTCXXCOMPILE) -gno-as-loc-support -S $< -o tmp-cxx11-ios_failure-lt.s
-test -f tmp-cxx11-ios_failure-lt.o && mv -f tmp-cxx11-ios_failure-lt.o
tmp-cxx11-ios_failure-lt.s
$(rewrite_ios_failure_typeinfo) tmp-$@ > $@
-rm -f tmp-$@
 cxx11-ios_failure.s: cxx11-ios_failure.cc
-   $(CXXCOMPILE) -S $< -o tmp-$@
+   $(CXXCOMPILE) -gno-as-loc-support -S $< -o tmp-$@
$(rewrite_ios_failure_typeinfo) tmp-$@ > $@
-rm -f tmp-$@

--- libstdc++-v3/src/c++11/Makefile.in.jj   2020-12-17 02:29:28.734557483
+0100
+++ libstdc++-v3/src/c++11/Makefile.in  2021-01-17 17:21:27.510931383 +0100
@@ -852,12 +852,12 @@ limits.o: limits.cc
$(CXXCOMPILE) -fchar8_t -c $<

 @ENABLE_DUAL_ABI_TRUE@cxx11-ios_failure-lt.s: cxx11-ios_failure.cc
-@ENABLE_DUAL_ABI_TRUE@ $(LTCXXCOMPILE) -S $< -o tmp-cxx11-ios_failure-lt.s
+@ENABLE_DUAL_ABI_TRUE@ $(LTCXXCOMPILE) -gno-as-loc-support -S $< -o
tmp-cxx11-ios_failure-lt.s
 @ENABLE_DUAL_ABI_TRUE@ -test -f tmp-cxx11-ios_failure-lt.o && mv -f
tmp-cxx11-ios_failure-lt.o tmp-cxx11-ios_failure-lt.s
 @ENABLE_DUAL_ABI_TRUE@ $(rewrite_ios_failure_typeinfo) tmp-$@ > $@
 @ENABLE_DUAL_ABI_TRUE@ -rm -f tmp-$@
 @ENABLE_DUAL_ABI_TRUE@cxx11-ios_failure.s: cxx11-ios_failure.cc
-@ENABLE_DUAL_ABI_TRUE@ $(CXXCOMPILE) -S $< -o tmp-$@
+@ENABLE_DUAL_ABI_TRUE@ $(CXXCOMPILE) -gno-as-loc-support -S $< -o tmp-$@
 @ENABLE_DUAL_ABI_TRUE@ $(rewrite_ios_failure_typeinfo) tmp-$@ > $@
 @ENABLE_DUAL_ABI_TRUE@ -rm -f tmp-$@

[Bug c++/98711] New: internal compiler error on instantiation of c++20 template class with 2 constrained and disabled destructors

2021-01-17 Thread ryan_greenblatt at brown dot edu via Gcc-bugs

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

Bug ID: 98711
   Summary: internal compiler error on instantiation of c++20
template class with 2 constrained and disabled
destructors
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan_greenblatt at brown dot edu
  Target Milestone: ---

```
template  struct A {
  constexpr ~A() requires(false) {}
  constexpr ~A() requires(!true) {}
};

constexpr A a;
```
https://godbolt.org/z/ao59G4

[Bug c++/98711] internal compiler error on instantiation of c++20 template class with 2 constrained and disabled destructors

2021-01-17 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Patrick Palka  ---
Thanks for the bug report.  This is essentially a dup of PR96745, I think.

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

[Bug c++/96745] [concepts] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389

2021-01-17 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ryan_greenblatt at brown dot 
edu

--- Comment #2 from Patrick Palka  ---
*** Bug 98711 has been marked as a duplicate of this bug. ***

[Bug c++/96745] [concepts] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389

2021-01-17 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug middle-end/98709] gcc optimizes bitwise operations, but doesn't optimize logical ones

2021-01-17 Thread glisse at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Marc Glisse  ---
At the end of gimple, we have
  _6 = a_3(D) ^ b_4(D);
  _1 = ~_6;
  _2 = a_3(D) == b_4(D);
  _7 = _1 & _2;
I guess we are missing a simplification of ~(a^b) to a==b for bool (similar to
~(a!=b) be we canonicalize != to ^).

[Bug target/98693] Compiling with -mcmodel=large emits .eh_frame with R_X86_64_PC32

2021-01-17 Thread chorman64 at gmail dot com via Gcc-bugs

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

--- Comment #1 from connor horman  ---
In case they are helpful in confirming the bug, these are the outputs from
continuous integration runs: 
clang+lld (expected case):
https://github.com/PhantomOS/PhantomOS/runs/1717516076
cross gcc+binutils (failing case):
https://github.com/PhantomOS/PhantomOS/runs/1717516064

[Bug c++/98712] New: Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting

2021-01-17 Thread ryan_greenblatt at brown dot edu via Gcc-bugs

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

Bug ID: 98712
   Summary: Incorrect defaulted operator== at compile time and
runtime when declared constexpr and inheriting
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan_greenblatt at brown dot edu
  Target Milestone: ---

```
struct IntHolder {
  int v;
  bool operator==(const IntHolder &) const = default;
};

struct Inherits : IntHolder {
  // without constexpr here the issue goes away...
  constexpr bool operator==(const Inherits &) const = default;
};

#if 0
static_assert(Inherits{1} != Inherits{2});
#else
#include 

int main() {
  // should output true...
  volatile int l = 1;
  std::cout << std::boolalpha << (Inherits{l} != Inherits{2}) << std::endl;
}
#endif
```
https://godbolt.org/z/145dbq

[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments

2021-01-17 Thread shmal_i at mail dot ru via Gcc-bugs

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

--- Comment #3 from Igor CHMAL  ---
thanks’

>Воскресенье, 17 января 2021, 17:17 +03:00 от dominiq at lps dot ens.fr 
>:
> 
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534
>
>Dominique d'Humieresерфтлыэ  changed:
>
>   What |Removed |Added
>
>   Last reconfirmed| |2021-01-17
> Status|UNCONFIRMED |NEW
> Ever confirmed|0 |1
>
>--- Comment #2 from Dominique d'Humieres  ---
>Confirmed from GCC9 up to GCC11. GCC8 vives
>
>Undefined symbols for architecture x86_64:
>  "___copy_REAL_4_.3803", referenced from:
>  ___vtab_REAL_4_.3802 in ccc5fkCP.o
>  "___copy_character_1.3889", referenced from:
>  ___vtab_CHARACTER_1_.3888 in ccc5fkCP.o
>
>--
>You are receiving this mail because:
>You are on the CC list for the bug. 


С уважением,
Игорь ШМАЛЬ
e-mail:  shma...@mail.ru  
+7 (926) 376-76-02

[Bug c/98713] New: Failure to generate branch version of abs if user requested it

2021-01-17 Thread david.bolvansky at gmail dot com via Gcc-bugs

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

Bug ID: 98713
   Summary: Failure to generate branch version of abs if user
requested it
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.bolvansky at gmail dot com
  Target Milestone: ---

int branch_abs(int v) {
return __builtin_expect(v > 0, 1) ? v : -v;
}

GCC -O2 now:

branch_abs:
  mov eax, edi
  neg eax
  cmovs eax, edi
  ret


Expected:
branch_abs:
  mov eax, edi
  test edi, edi
  js .LBB0_1
  ret
.LBB0_1:
  neg eax
  ret


Same for min/max.

[Bug c++/98714] New: [c++14] Nested type with variadic template class argument can't be expanded into using outer variadic types

2021-01-17 Thread ryan_greenblatt at brown dot edu via Gcc-bugs

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

Bug ID: 98714
   Summary: [c++14] Nested type with variadic template class
argument can't be expanded into using outer variadic
types
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan_greenblatt at brown dot edu
  Target Milestone: ---

https://godbolt.org/z/jjqEss
```
template
constexpr int val = 0;

template  struct NestedType {
  template  class Inp>
  using Type = Inp...>;
};

template  struct TakesInt {};

constexpr NestedType::Type a;
```
Happens on all the version of g++ I tried.

[Bug c/98715] New: ICE in make_decl_rtl, at varasm.c

2021-01-17 Thread alserkli at inbox dot ru via Gcc-bugs

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

Bug ID: 98715
   Summary: ICE in make_decl_rtl, at varasm.c
   Product: gcc
   Version: 11.0
   URL: https://godbolt.org/z/z763xG
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alserkli at inbox dot ru
  Target Milestone: ---

:

void f(int n) {
int a[n][n] = {{}};
}

gives on trunk (also gcc 4.9.0, but not 4.8.5):

during RTL pass: expand
: In function 'void f(int)':
:2:22: internal compiler error: in make_decl_rtl, at varasm.c:1427
2 | int a[n][n] = {{}};
  |  ^
0x1cd4199 internal_error(char const*, ...)
???:0
0x6b4a01 fancy_abort(char const*, int, char const*)
???:0
0x13d7265 make_decl_rtl(tree_node*)
???:0
0xc42451 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xc41a1e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xc4f0d1 store_expr(tree_node*, rtx_def*, int, bool, bool)
???:0

[Bug middle-end/98715] ICE in make_decl_rtl, at varasm.c

2021-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
URL|https://godbolt.org/z/z763x |
   |G   |

--- Comment #1 from Andrew Pinski  ---
https://godbolt.org/z/z763xG

[Bug c++/98687] [11 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at cp/name-lookup.c:2729 since r11-6652-g796ead19f85372

2021-01-17 Thread dcb314 at hotmail dot com via Gcc-bugs

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

--- Comment #3 from David Binderman  ---
Another test case:

void a();
namespace b {
using ::a;
}
namespace c {
template  void a();
template  void f(d, e) {
  using b::a;
  using c::a;
}
template  void i(g j, h, e k) { f(j, k); }
} // namespace c
class l {
  double m() const;
};
using c::i;
double l::m() const { i(0, 0, int()); }

[Bug middle-end/98715] ICE in make_decl_rtl with double variable length array (VLA)

2021-01-17 Thread alserkli at inbox dot ru via Gcc-bugs

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

--- Comment #2 from Alexander Klimov  ---
Clang does not think that the code is valid:

error: variable-sized object may not be initialized

[Bug ipa/98222] [11 Regression] ICE at -O3 on x86_64-pc-linux-gnu: verify_cgraph_node failed since r11-4267-g0e590b68fa374365

2021-01-17 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:0f4c8f517b7954e113afb4d5c7212123c8ee2418

commit r11-6756-g0f4c8f517b7954e113afb4d5c7212123c8ee2418
Author: Martin Jambor 
Date:   Sun Jan 17 22:31:09 2021 +0100

ipa: Adjust cgraph verifier to materialization on demand (PR 98222)

after switching to materialization of clones on demand, the verifier
can happen to see edges leading to a clone of a materialized clone.
This means its clone_of is NULL and former_clone_of needs to be
checked in order to verify that the callee is a clone of the original
decl, which it did not do and reported edges to pointing to a wrong
place.

Fixed with the following patch, which has been pre-approved by Honza.
Bootstrapped and tested on x86_64-linux, pushed to master.

Martin

gcc/ChangeLog:

2021-01-15  Martin Jambor  

PR ipa/98222
* cgraph.c (clone_of_p): Check also former_clone_of as we climb
the clone tree.

gcc/testsuite/ChangeLog:

2021-01-15  Martin Jambor  

PR ipa/98222
* gcc.dg/ipa/pr98222.c: New test.

[Bug ipa/98222] [11 Regression] ICE at -O3 on x86_64-pc-linux-gnu: verify_cgraph_node failed since r11-4267-g0e590b68fa374365

2021-01-17 Thread jamborm at gcc dot gnu.org via Gcc-bugs

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Jambor  ---
Fixed.

[Bug debug/98716] New: [11 Regression] sanitizer regressions by r11-6755

2021-01-17 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 98716
   Summary: [11 Regression] sanitizer regressions by r11-6755
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: mark at gcc dot gnu.org
  Target Milestone: ---

On Linux/x86-64 with binutils master branch plus

https://sourceware.org/pipermail/binutils/2021-January/114980.html

r11-6755 caused:

FAIL: c-c++-common/asan/alloca_big_alignment.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_big_alignment.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/heap-overflow-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/heap-overflow-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/null-deref-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/null-deref-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/stack-overflow-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/stack-overflow-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/use-after-free-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/use-after-free-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test

[Bug c++/98717] New: [c++20] variadic concept can't take empty pack

2021-01-17 Thread ryan_greenblatt at brown dot edu via Gcc-bugs

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

Bug ID: 98717
   Summary: [c++20] variadic concept can't take empty pack
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan_greenblatt at brown dot edu
  Target Milestone: ---

```
template
concept True = true;

static_assert(True<>);
```
"error: invalid use concept ‘True<>’"

https://godbolt.org/z/ndfjzj

I'm suprised this hasn't been caught already... (assuming there isn't a
duplicate bug report I missed)

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

2021-01-17 Thread Bahram.shahrooz at uc dot edu via Gcc-bugs

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

--- Comment #16 from Bahram.shahrooz at uc dot edu ---
I spent a good chunk of today to debug.  The culprit was two variables that had
not been set equal to 0.  I get the same results with g77 on Windows, GFortran
on Mac Big Sur, & AbsoftTools ( I downloaded a trial version to help me debug)
on Mac Big Sur

You guys are so helpful. I truly appreciate your time and.

[Bug tree-optimization/98673] pass fre4 inhibit pass dom3 to create much more optimized code

2021-01-17 Thread rjiejie at me dot com via Gcc-bugs

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

--- Comment #3 from jojo  ---
(In reply to jojo from comment #2)
> (In reply to Richard Biener from comment #1)
> > The analysis sounds a bit confused.  What is the transform that DOM cannot
> > do after the transform that FRE does?  There's some older bug about
> > out-of-SSA
> > coalescing issues with loops and liveness of induction variables but it's
> > not clear if this is related (the assembly doesn't show the loop exit 
> > block).
> > 
> > Can you name the loop in the source that is problematic?
> > 
> 
> see this loop:
> 
>   for( i1 = 0 ; i1 < ( numXEntries - 1 ) ; i1++ )
> {
> if( ( loadValue < engLoad[i1+1] ) && ( loadValue >= engLoad[i1]
> ) )
> {
> break ;
> }
> }

Richi: Can you please update Known to work?

[Bug c++/81642] -Wtype-limits should not trigger for defined numbers

2021-01-17 Thread ryan_greenblatt at brown dot edu via Gcc-bugs

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

Ryan Greenblatt  changed:

   What|Removed |Added

 CC||ryan_greenblatt at brown dot 
edu

--- Comment #4 from Ryan Greenblatt  ---
This occurs for c++ templates/constexpr as well. For example:
```
#include 
#include 

template 
constexpr bool bigger_than_max = n > std::numeric_limits::max();

static_assert(!bigger_than_max<0>);
static_assert(bigger_than_max<256>);

```
https://godbolt.org/z/5fG4vE

[Bug c++/81642] -Wtype-limits should not trigger for defined numbers

2021-01-17 Thread ryan_greenblatt at brown dot edu via Gcc-bugs

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

--- Comment #5 from Ryan Greenblatt  ---
(In reply to Ryan Greenblatt from comment #4)
> This occurs for c++ templates/constexpr as well. For example:
> ```
> #include 
> #include 
> 
> template 
> constexpr bool bigger_than_max = n > std::numeric_limits::max();
> 
> static_assert(!bigger_than_max<0>);
> static_assert(bigger_than_max<256>);
> 
> ```
> https://godbolt.org/z/5fG4vE

Oops, actually this doesn't happen on trunk - look like it was fixed recently.

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

2021-01-17 Thread ryan_greenblatt at brown dot edu via Gcc-bugs

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

--- Comment #1 from Ryan Greenblatt  ---
I've also noticed some incorrect compiler errors when trying to default
constexpr operator== in similar circumstances. I think the causes are the
likely the same.

[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs

2021-01-17 Thread florin at iucha dot net via Gcc-bugs

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

florin at iucha dot net changed:

   What|Removed |Added

 CC||florin at iucha dot net

--- Comment #13 from florin at iucha dot net ---
Created attachment 49987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49987&action=edit
a test case that fails in the similar way

Running this program with argument 16, spawns 16 threads but it seems some get
stuck at the latch despite other threads completing (and latch::wait
returning).

Program output, under gdb:

[New Thread 0x77a5a700 (LWP 1112060)] 
[New Thread 0x77259700 (LWP 1112061)] 
[New Thread 0x76a58700 (LWP 1112062)]   
[New Thread 0x76257700 (LWP 1112063)] 
[New Thread 0x75a56700 (LWP 1112064)]   
[New Thread 0x75255700 (LWP 1112065)]   
[New Thread 0x74a54700 (LWP 1112066)]  
[New Thread 0x74253700 (LWP 1112067)]   
[New Thread 0x73a52700 (LWP 1112068)]  
 [New Thread
0x73251700 (LWP 1112069)]   
[New Thread 0x72a50700 (LWP 1112070)]   
[New Thread 0x7224f700 (LWP 1112071)]   
[New Thread 0x71a4e700 (LWP 1112072)]   
[New Thread 0x7124d700 (LWP 1112073)]  
 [New Thread
0x70a4c700 (LWP 1112074)] 
[New Thread 0x7024b700 (LWP 1112075)]   
All 16 threads started
Thread a73f34e0d4ae6a49 started
 Thread
cb3cc899c037915d started
Thread ade34b17621c1815 started 
Thread 7245e72e408faec2 started 
Thread a7089aace412318c started
 Thread
75736a54d10fb0e9 started
Thread 995f48c2014cc0ec started 
Thread 5302d144ddde4d68 started 
Thread b20c0c361ed65c90 started 
Thread ae85377ab49db7c7 started
All threads notified
Thread b20c0c361ed65c90 stopped 
Thread ade34b17621c1815 stopped 
Thread a73f34e0d4ae6a49 stopped 
Thread 5302d144ddde4d68 stopped  
Thread a7089aace412318c stopped   
Thread ae85377ab49db7c7 stopped   
Thread 995f48c2014cc0ec stopped 
Thread 7245e72e408faec2 stopped   
Thread cb3cc899c037915d stopped   
Thread 75736a54d10fb0e9 stopped   
[Thread 0x74253700 (LWP 1112067) exited]
[Thread 0x73251700 (LWP 1112069) exited]  
[Thread 0x73a52700 (LWP 1112068) exited]
[Thread 0x74a54700 (LWP 1112066) exited]
[Thread 0x75255700 (LWP 1112065) exited]   
[Thread 0x75a56700 (LWP 1112064) exited]
[Thread 0x76257700 (LWP 1112063) exited]   
 [Thread
0x76a58700 (LWP 1112062) exited]
[Thread 0x77259700 (LWP 1112061) exited]
[Thread 0x77a5a700 (LWP 1112060) exited]   

# at this point... the program hangs, but threads are still chewing CPU
# Ctrl-C

Thread 1 "synchro" received signal SIGINT, Interrupt.   
__pthread_clockjoin_ex (threadid=140737264289536, thread_return=0x0,
clockid=, abstime=, block=)
 at pthread_join_common.c:145

[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs

2021-01-17 Thread florin at iucha dot net via Gcc-bugs

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

--- Comment #14 from florin at iucha dot net ---
For reference:

$ /opt/gcc11/bin/g++-11 -v
Using built-in specs.
COLLECT_GCC=/opt/gcc11/bin/g++-11
COLLECT_LTO_WRAPPER=/opt/gcc11/libexec/gcc/x86_64-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gcc11
--with-local-prefix=/opt/gcc11 --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --program-suffix=-11 --with-abi=m64
--with-default-libstdcxx-abi=new --with-linker-hash-style=gnu
--with-tune=generic --disable-multilib --disable-nls --disable-vtable-verify
--enable-c99 --enable-checking=release --enable-__cxa_atexit
--enable-default-pie --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-languages=c,c++ --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-long-long --enable-shared
--enable-threads=posix
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210110 (experimental) (GCC)

[Bug c++/82613] Cannot access private definitions in base clause of friend class template

2021-01-17 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/64194] [C++14] for function template with auto return

2021-01-17 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|11.0|10.3

[Bug c++/71879] Error in unevaluated context breaks SFINAE

2021-01-17 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2021-01-18

[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755

2021-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ian at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
And go is also mostly broken.
I think at least libbacktrace needs some DWARF5 work.

[Bug c++/98417] ICE when using C++ modules and -g

2021-01-17 Thread boris at kolpackov dot net via Gcc-bugs

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #1 from Boris Kolpackov  ---
I am also seeing this.

[Bug c++/98718] New: [modules] use of partitions causes ICE in write_macro_maps

2021-01-17 Thread boris at kolpackov dot net via Gcc-bugs

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

Bug ID: 98718
   Summary: [modules] use of partitions causes ICE in
write_macro_maps
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

Created attachment 49988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49988&action=edit
Reproducer

The attached set of translation units causes an internal compiler error:

hello.mxx:5:9: internal compiler error: in write_macro_maps, at
cp/module.cc:16113
5 | export module hello;
  | ^~
0xc60a67 module_state::write_macro_maps(elf_out*, location_map_info&,
module_state_config*, unsigned int*)
../../gcc/gcc/cp/module.cc:16113
0xc659f1 module_state::write(elf_out*, cpp_reader*)
../../gcc/gcc/cp/module.cc:17727
0xc6bbfd finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:19747
0xb8a7a1 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:5178
0xf0b805 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1233

If I replace std::string with const char* and get rid of the 
inclusion, then the ICE disappears. The build transcript is included in the
attached archive.

49 matches

Mail list logo