https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92722
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #7 from Andrew Pinski ---
(In reply to Richard Biener from comment #6)
> Well, pch files essentially contain a memory dump of GCCs internal state so
> I very much expect differences for example when address-space randomization
> is tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716
--- Comment #5 from Richard Biener ---
Probably similar cases can be made for loops implementing memcpy/memcmp (what
we pattern-detect in loop distribution).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #6 from Richard Biener ---
Well, pch files essentially contain a memory dump of GCCs internal state so I
very much expect differences for example when address-space randomization is
turned on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92722
Bug ID: 92722
Summary: gcc considers "padding" byte of empty lambda to be
uninitialized
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92650
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92721
Bug ID: 92721
Summary: ICE: canonical types differ for identical types
'int(void*, void*)' and 'int(void*, void*)'
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720
Bug ID: 92720
Summary: cc1 accepts #include /dev/stdin inline
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790
--- Comment #14 from Kewen Lin ---
Yes, I'd like to wait for two weeks to ensure it's safe enough and then
backport to gcc9. Does it sound good?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92635
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92350
--- Comment #3 from Jerry DeLisle ---
(In reply to Tobias Burnus from comment #2)
> For the added text, cf. PR 60148 and
> https://gcc.gnu.org/ml/fortran/2014-03/msg00145.html
>
> I missed that patch when writing this PR because it wasn't posted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92602
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92602
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Nov 28 22:28:59 2019
New Revision: 278821
URL: https://gcc.gnu.org/viewcvs?rev=278821&root=gcc&view=rev
Log:
rs6000: Use memory_operand for all simple {l,st}*brx instructions
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92602
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92719
Bug ID: 92719
Summary: MacOS 10.15 Catalina build fails
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92718
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716
--- Comment #4 from Marc Glisse ---
Yes, the pass that recognizes bswap (unsurprisingly called bswap) happens much
later than inlining in the pipeline. This kind of thing is unavoidable since
cycling through optimization passes is considered unde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92718
--- Comment #1 from Jakub Jelinek ---
Started with r243419.
evrp is computing strange ranges, [0, 1] rather than just [0, 0] for the
iterator. It is true that &a[1] is still valid, but the memset with non-zero
size at that spot or MEM[(struct s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #5 from Markus Dreseler ---
I took Andrew's __DATE__ suggestion as a reason to look at how much the files
actually differ. `cmp -l v1 v2 | wc -l` gives me 692634 differing bytes. This
sounds like the difference is bigger than just som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92718
Bug ID: 92718
Summary: Bogus Wstringop-overflow in __builtin_memset() of an
element of array of size 1 of struct
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #4 from Markus Dreseler ---
> By any chance, is your cc1plus built as PIE? PCH doesn't work in that case.
I don't think so:
# file `find /usr -name cc1plus`
/usr/lib/gcc/x86_64-linux-gnu/9/cc1plus: ELF 64-bit LSB executable, x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #2 from Markus Dreseler ---
> Try using __DATE__ macro and you will see it is not :).
Can't confirm:
# /usr/bin/c++ -D__DATE__=0 -D__TIMESTAMP__=0 -D__TIME__=0 -x c++-header
-include test.hxx -o test.hxx.gch -c test.hxx.cxx && md5su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
--- Comment #1 from Andrew Pinski ---
I don't think this is a bug, __DATE__ is one of the predefined macros and I
think it is included in GCC's precompiled headers.
Really ccache is broken anyways.
>As builds of regular C(++) files are determin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 46558, which changed state.
Bug 46558 Summary: dbgcnt.c messages not marked for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92609
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558
--- Comment #5 from Martin Liška ---
Author: marxin
Date: Thu Nov 28 20:56:51 2019
New Revision: 278820
URL: https://gcc.gnu.org/viewcvs?rev=278820&root=gcc&view=rev
Log:
Translate header for -fdbg-cnt-list.
2019-11-28 Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92609
--- Comment #3 from Martin Liška ---
Author: marxin
Date: Thu Nov 28 20:56:23 2019
New Revision: 278819
URL: https://gcc.gnu.org/viewcvs?rev=278819&root=gcc&view=rev
Log:
Properly use TYPE_MAIN_VARIANT in warn_types_mismatch.
2019-11-28 Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92717
Bug ID: 92717
Summary: precompiled headers non-deterministic
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716
--- Comment #2 from Andrew Pinski ---
Most likely what is happening is the following:
inlining happens twice but the detection of bswap does not happen until after
both inlining so the cost huestric for byteswap function is high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92715
--- Comment #4 from Martin Liška ---
Created attachment 47391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47391&action=edit
Reduced test-case
Fails with:
$ gfortran -O3 -march=znver2 mdbx.f90
mdbx.f90:9:16:
9 | PARAMETER NM=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716
--- Comment #1 from Julius Werner ---
edit: Just noticed that when I implement it as
static inline unsigned int byteswap(unsigned int x)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92715
--- Comment #3 from David Binderman ---
(In reply to Richard Biener from comment #1)
> That CPU is bdver[234], right?
Not sure. Piledriver certainly.
I tried setting -march to each of bdver[234] and the problem still exists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716
Bug ID: 92716
Summary: -Os doesn't inline byteswap function even though it's
a single instruction
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92715
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=91997
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> #1 0x00401272 in foo (Python Exception No type
> named std::__detail::_Hash_node, false>.:
N.B. That's a different error because I'm testing a fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997
--- Comment #4 from Jonathan Wakely ---
Thanks, I can confirm that error. Oddly, it works fine when printing the
variable within its own stack frame:
$ gdb -q -ex "br printf" -ex r -ex up -ex bt -ex down -ex bt -ex cont -ex q
map
Reading symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92715
Richard Biener changed:
What|Removed |Added
Keywords||needs-reduction
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92047
--- Comment #2 from Richard Biener ---
I actually did. Is it fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92714
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92709
--- Comment #2 from fdlbxtqi ---
(In reply to Richard Biener from comment #1)
> The actual error is missing from the log.
Yea. It has no actual error. I have checked that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92709
Richard Biener changed:
What|Removed |Added
Keywords|accepts-invalid |build
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92715
Bug ID: 92715
Summary: error: position plus size exceeds size of referenced
object in ‘bit_field_ref’
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640
--- Comment #9 from frankhb1989 at gmail dot com ---
This seems still problematic.
void test1() {
[]() __attribute__((noreturn)) noexcept [[]] -> int{
return 0; // Warning expected.
}();
}
void test2() {
[]() noexcept [[]] __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997
--- Comment #3 from Rafael Avila de Espindola ---
(In reply to Jonathan Wakely from comment #2)
> Rafael, I'm unable to reproduce this with unordered containers. Do you have
> a testcase?
I was able to reproduce it with 2 files:
$ cat test.cc
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711
--- Comment #3 from Jan Hubicka ---
Proper GCC 9 -fprofile-generate build is 296MB
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/aMGsffWPQ1qzjgj4LIqcwQ/runs/0/artifacts/public/build/target.tar.bz2
So about 5% regression compared to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92714
Bug ID: 92714
Summary: [missed-optimization] aggregate initialization of an
array fills the whole array with zeros first,
including non-zero elements
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #5 from Jerry DeLisle ---
Author: jvdelisle
Date: Thu Nov 28 18:33:20 2019
New Revision: 278817
URL: https://gcc.gnu.org/viewcvs?rev=278817&root=gcc&view=rev
Log:
PR fortran/90374
* io.c (check_format): Allow zero wid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92677
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
seen with trunk 20191128, building an offload compiler targeting
amdgcn-unknown-amdhsa:
during RTL pass: jump
error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335
--- Comment #14 from Jakub Jelinek ---
I think we should remove the __cpp_consteval define until we implement virtual
consteval and should also mention in cxx-status.html that it is only partially
implemented.
I've tried to play with the virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711
Jan Hubicka changed:
What|Removed |Added
CC||mliska at suse dot cz
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190
--- Comment #12 from rsandifo at gcc dot gnu.org
---
Sorry, I was wrong in comment 10. I'd forgotten that the original
point of all this was that, without the clobber, -fipa-ra would
assume that the register isn't clobbered at all. The RA coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711
--- Comment #1 from Jan Hubicka ---
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ObkoHsHHSriQdU0Twc12Wg/runs/0/artifacts/public/build/target.tar.bz2
This is GCC9 build. 310MB, so still a lot bigger than clang, but better than
gcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
Bug ID: 92712
Summary: Performance regression with assumed values
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711
Bug ID: 92711
Summary: GCC 10 libxul.so -fprofile-generate binary is 360MB
while clang needs only 163MB.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92697
--- Comment #2 from Martin Jambor ---
Author: jamborm
Date: Thu Nov 28 15:39:48 2019
New Revision: 278812
URL: https://gcc.gnu.org/viewcvs?rev=278812&root=gcc&view=rev
Log:
cgraph: ifunc resolvers cannot be made local (PR 92697)
2019-11-28 Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92710
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92710
Bug ID: 92710
Summary: [9/10 Regression] Vectoriser generates invalid simd
call for bool arguments
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #7 from fiesh at zefix dot tv ---
And creduce just finished: (I left the ifdef unchanged so it can still be
compiled under clang.)
#ifdef __has_builtin
#define a 1
#endif
template struct d {
typedef b e;
constexpr operator e()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997
--- Comment #2 from Jonathan Wakely ---
Rafael, I'm unable to reproduce this with unordered containers. Do you have a
testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484
Irfan Adilovic changed:
What|Removed |Added
CC||irfanadilovic at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92708
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #24 from Richard Biener ---
(In reply to Tobias Burnus from comment #23)
> I have the feeling that some other use also disagrees between ME and
> FE/Fortran semantics assumptions.
>
> I just run into PR 92703: if one comments the unr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92709
Bug ID: 92709
Summary: Cross Compilation failed for Latest GCC
riscv64-linux-gnu on Linux/WSL2
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: accepts-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92703
--- Comment #2 from Tobias Burnus ---
Actually, w/o checking the finally generated code, I have the feeling that for
*absent* arguments, the wrong code might be generated for:
character → dummy argument is ARRAY_TYPE
derived type + class → dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92704
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92705
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92708
Bug ID: 92708
Summary: [Issue] dynamic_cast unexpected behavior in my code
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92702
Tobias Burnus changed:
What|Removed |Added
Summary|[F2008] (and hence [F2018]) |[F2008] (and hence [F2018])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60228
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92706
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #3 from Andreas Krebbel ---
276.ira:
(insn 6 85 11 2 (set (reg:SI 100 [ f ])
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [2 f+0 S4 A32]))
"t.c":13:8 1372 {*movsi_zarch}
(expr_list:REG_EQUIV (mem/c:SI (symbol_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675
--- Comment #6 from Jonny Grant ---
Is the clearest way to write this as follows?
unsigned int j = (unsigned int)-1;
Likewise for the template example:
U max = (U)-1; // good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
Andreas Krebbel changed:
What|Removed |Added
Priority|P3 |P2
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #2 from Andreas Krebbel ---
Created attachment 47388
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47388&action=edit
Experimental patch
This patch fixes the second testcase. The first one currently doesn't fail on
head.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #1 from Andreas Krebbel ---
Created attachment 47387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47387&action=edit
Another reduced testcase
gcc -O3 -march=z13 t.c -o t
./t
prints "checksum = 0" with head GCC
prints "checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92707
Bug ID: 92707
Summary: type alias on type alias on lambda in unevaluated
context does not work
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #16 from Richard Biener ---
Author: rguenth
Date: Thu Nov 28 12:26:50 2019
New Revision: 278807
URL: https://gcc.gnu.org/viewcvs?rev=278807&root=gcc&view=rev
Log:
2019-11-28 Richard Biener
PR tree-optimization/92645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92704
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
CC||prathamesh3492 at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #15 from Richard Biener ---
Author: rguenth
Date: Thu Nov 28 12:22:04 2019
New Revision: 278806
URL: https://gcc.gnu.org/viewcvs?rev=278806&root=gcc&view=rev
Log:
2019-11-28 Richard Biener
PR tree-optimization/92645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92706
--- Comment #2 from Richard Biener ---
That is, I had the impression that for total scalarization SRA considers both
the accesses of the ultimate sources and the destinations?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92706
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92706
Bug ID: 92706
Summary: SRA confuses FRE
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92705
Bug ID: 92705
Summary: [10 Regression] ICE: Segmentation fault (in
build_new_op_1)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790
Arseny Solokha changed:
What|Removed |Added
Known to work|9.2.1 |
--- Comment #13 from Arseny Solokha -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92704
Bug ID: 92704
Summary: [8/9/10 Regression] ICE: Segmentation fault (in
process_bb)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055
--- Comment #11 from Georg-Johann Lay ---
Author: gjl
Date: Thu Nov 28 10:29:30 2019
New Revision: 278805
URL: https://gcc.gnu.org/viewcvs?rev=278805&root=gcc&view=rev
Log:
Must use push insn to pass varargs arguments of DFmode because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #23 from Tobias Burnus ---
I have the feeling that some other use also disagrees between ME and FE/Fortran
semantics assumptions.
I just run into PR 92703: if one comments the unrelated 'foo', with -O0 one
gets the expected 'stop 2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
Rainer Orth changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 92683, which changed state.
Bug 92683 Summary: [10 Regression] strncmp incorrect result with equal
substrings and non-const bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
What|Removed
1 - 100 of 117 matches
Mail list logo
