https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
--- Comment #1 from bzsurr at protonmail dot com ---
(In reply to bzsurr from comment #0)
> Looking at the following code gcc calls the _char*_ overload, according to
> the standard the string literal is of type const array of char, so the non
> c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577
--- Comment #2 from Iain Sandoe ---
Created attachment 48710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48710&action=edit
hacky patch that fixes the output for fat and thin LTO
This is pretty non-elegant - essentially duplicating the L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #3 from Martin Liška ---
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #4 from Martin Liška ---
Created attachment 48711
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48711&action=edit
Reproducer LTO bytecode
I think it would be easy to reproduce by LTO LTRANS .o file:
$ git co f8ca4dd657f767c5f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95575
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> Ah, for some reason I thought that moving the dejagnu .exp scripts from
> top-level gdc.test to one per each subdirectory would remove the need fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #5 from Martin Liška ---
The problematic STMT is:
(gdb) p debug_gimple_stmt(orig_stmt_info->stmt)
_22 = (boolean) _21;
which comes from:
(gdb) p debug_bb(bb)
[count: 0]:
_8 ={v} __gnat_dir_separator;
# DEBUG SR.1076 => _8
_9 ={v} _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95600
Bug ID: 95600
Summary: [11 regression] tree-prof/indir-call-prof-2.c fails on
armeb-linux-gnueabihf since r11-830
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95600
--- Comment #1 from Martin Liška ---
> Since r11-830 (g:85bce484d37fdda9c7eadb9bdcdb1ded891462bb), I've noticed
The revision is likely bad?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494
Martin Liška changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95600
Martin Liška changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95572
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #7 from Richard Biener ---
So Ada does
/* In Ada, we use an unsigned 8-bit type for the default boolean type. */
boolean_type_node = make_unsigned_type (8);
TREE_SET_CODE (boolean_type_node, BOOLEAN_TYPE);
but somehow in lto1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95601
Bug ID: 95601
Summary: Remove workaround for GDB PR in
pass_partition_blocks::gate
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95598
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95477
Iain Sandoe changed:
What|Removed |Added
CC||lewissbaker.opensource@gmai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95591
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #8 from Eric Botcazou ---
Well, the middle-end provides build_nonstandard_boolean_type to build boolean
types with arbitrary precision so it cannot assume they have precision 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95599
Iain Sandoe changed:
What|Removed |Added
Keywords||wrong-code
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #9 from rguenther at suse dot de ---
On Tue, 9 Jun 2020, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
>
> --- Comment #8 from Eric Botcazou ---
> Well, the middle-end provides build_nonst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93624
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95446
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95375
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95602
Bug ID: 95602
Summary: [10/11 Regression] Wrong code w/ -O0
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:862b9b225fba6cf3c63234206f2dbc47f1ab5350
commit r11-1114-g862b9b225fba6cf3c63234206f2dbc47f1ab5350
Author: Martin Liska
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95365
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:452283bd060eb9bae41199b4b5e7266155d40e12
commit r11-1115-g452283bd060eb9bae41199b4b5e7266155d40e12
Author: Martin Liska
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95365
--- Comment #4 from Martin Liška ---
All right, I can live with the changed names of the files..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95602
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #10 from Eric Botcazou ---
> Yeah, that was for vector components. Not that I like it much. Can
> the middle-end assume that the Ada boolean types only contain 0 or 1
> or are there other values that are supposed to be well-defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95570
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95569
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95562
Martin Liška changed:
What|Removed |Added
Known to work||9.3.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95603
Bug ID: 95603
Summary: [11 Regression] sanitizer_linux.cpp:1880:16: error:
missing terminating ' character
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95502
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95501
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95603
--- Comment #1 from Jakub Jelinek ---
Didn't r11-1083-g942a384ef9f38777df25b2bfa421ce6a07553a98 fix this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95603
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95603
--- Comment #3 from Zdenek Sojka ---
Thanks, all the rounds with asking at gcc-help, waiting for reply, and even
recompiling this morning took too much time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95560
Martin Liška changed:
What|Removed |Added
Host|x86_64-w64-mingw32 |
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95604
Bug ID: 95604
Summary: LTO doesn't pick up -fcf-protection flag for the link
step
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95605
Bug ID: 95605
Summary: LTO and object files generated by dtrace -G
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95604
--- Comment #1 from H.J. Lu ---
(In reply to Matthias Klose from comment #0)
> Building the example from PR93966 with the -fcf-protection flag in the
> compile step, but not in the link step, I get the error triggered by the -z
> option.
>
> $ c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95605
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95604
--- Comment #2 from Matthias Klose ---
Really? The documentation states:
The macro "__CET__" is defined when -fcf-protection is used.
so it's a preprocessor option as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95604
--- Comment #3 from H.J. Lu ---
(In reply to Matthias Klose from comment #2)
> Really? The documentation states:
>
> The macro "__CET__" is defined when -fcf-protection is used.
>
> so it's a preprocessor option as well?
__CET__ check isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95560
--- Comment #4 from Bernd Edlinger ---
don't know if it helps, but with -Wshadow=compatible-local
the regression begins probably earlier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81058
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95605
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95605
--- Comment #3 from Matthias Klose ---
dtrace -G calls gcc to generate the .o file, and you can use the CC and CFLAGS
environment vars to inject the options you need. Ugly, but you can avoid that
by passing the appropriate options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95560
Martin Liška changed:
What|Removed |Added
Summary|[10/11 Regression] ICE in |[8/9/10/11 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95154
Andreas Schwab changed:
What|Removed |Added
Target|ia64-*-*,*-*-darwin*|ia64-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95562
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95056
Alex Coplan changed:
What|Removed |Added
Last reconfirmed||2020-06-09
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #5 from gcc at pkh dot me ---
I'd like to point out that this regression impacts badly a production app.
We're using this pattern to compare an input vector of floats to a vector of
zeros, but the comparison always returns 0 now, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93979
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2020-06-09
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
--- Comment #3 from Jonathan Wakely ---
gcc/cp/typeck.c does:
if (cxx_dialect >= cxx11)
pedwarn (loc, OPT_Wwrite_strings,
"ISO C++ forbids converting a string constant to %qT",
totype);
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94235
Pedro Alves changed:
What|Removed |Added
CC||palves at redhat dot com
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95056
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606
Bug ID: 95606
Summary: [10/11 regression] conflicts with
std::is_constructible
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94235
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95215
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579
kuzniar95 at o2 dot pl changed:
What|Removed |Added
CC||kuzniar95 at o2 dot pl
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95138
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95347
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95215
--- Comment #2 from John Donners ---
thanks for reviewing this. Indeed, the compiler bug does not occur when using
the intelmicemul target:
gfortran -foffload=x86_64-intelmicemul-linux-gnu -g -fopenmp -O3 bla.f90
/lib/../lib64/crt1.o: In functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95567
--- Comment #1 from Barry Revzin ---
To follow up on this, it's not the operator<=> being virtual that's significant
but rather the class itself being polymorphic. This exhibits the same behavior:
#include
struct B {
B(int i) : i(i) {}
VIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95469
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95599
--- Comment #3 from Lewis Baker ---
I don't think that whether or not the awaitables or operands to co_yield are
captured by reference / aliased should play into the sequencing of calls to the
destructor.
The destructors of temporaries should al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95599
--- Comment #4 from Iain Sandoe ---
(In reply to Lewis Baker from comment #3)
> Also, I'm not sure why GCC is evaluating the second operand to operator,()
> first and why it is constructing resource{1} _after_ the coroutine has
> suspended. Noth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95607
Bug ID: 95607
Summary: Inconsistent treating of default argument
instantiation as immediate context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95608
Bug ID: 95608
Summary: c++20 wrong code for defaulted equality comparison on
array member variables
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:ef41587df9839d1dfc77dbc48a0830e42b36626e
commit r11-1122-gef41587df9839d1dfc77dbc48a0830e42b36626e
Author: Jason Merrill
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609
Bug ID: 95609
Summary: span could have better layout
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95581
--- Comment #6 from Bill Seurer ---
I tried the patch and it allowed me to build gcc on a power7 system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94377
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-06-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95581
--- Comment #7 from Iain Sandoe ---
(In reply to Bill Seurer from comment #6)
> I tried the patch and it allowed me to build gcc on a power7 system.
but AFAIU the discussion - the builtin has the wrong signature (and needs to be
fixed)?
or did I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95610
Bug ID: 95610
Summary: GCC fails to get global variable via "::" in class
specifier
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84245
--- Comment #5 from G. Steinmetz ---
A few more disrupted cases :
$ cat z03.f90
select type (n%&
$ cat z04.f90
select type (n%m&
$ cat z05.f90
select type (n(
$ cat z06.f90
select type (n(&
$ cat z07.f90
select type (n(m
$ cat z08.f90
sele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95611
Bug ID: 95611
Summary: ICE in access_attr_decl, at fortran/decl.c:9075
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95612
Bug ID: 95612
Summary: [9/10/11 Regression] ICE in gfc_check_pointer_assign,
at fortran/expr.c:4274
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95581
Martin Sebor changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #8 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95613
Bug ID: 95613
Summary: ICE in main_block_label, at tree-cfg.c:1455
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614
Bug ID: 95614
Summary: ICE in build_field, at fortran/trans-common.c:301
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95611
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95613
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-06-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-06-09
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95612
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85270
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95615
Bug ID: 95615
Summary: [coroutines] Coroutine frame and promise is leaked if
exception thrown from promise.initial_suspend()
Product: gcc
Version: 10.1.1
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95612
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95616
Bug ID: 95616
Summary: [coroutines] coroutines with potentially-throwing
'co_await promise.final_suspend()' expressions should
be ill-formed
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95615
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2020-06-09
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95616
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2020-06-09
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95588
--- Comment #1 from Nick Desaulniers ---
In https://bugs.llvm.org/show_bug.cgi?id=41467#c4, the code owner for Clang
seems to indicate that we could move the warnings for narrowing prints (ie.
printing an `int` with `%hh`) to a new warning flag w
1 - 100 of 131 matches
Mail list logo
