https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #11 from pmatos at gcc dot gnu.org ---
(In reply to David Malcolm from comment #10)
> Should be fixed by the above commit.
David, does this mean the analyzer has C++ support now or just that this
specific bug is fixed in-tree?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
--- Comment #38 from Andrew Pinski ---
(In reply to Wilco from comment #37)
> (In reply to Andrew Pinski from comment #36)
> > MIPS is still broken. I might look into MIPS brokenness next week.
>
> Yes it seems builtin_longjmp has the exact sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93697
Bug ID: 93697
Summary: pr93661.c does not warn on (32-bit) powerpc-linux
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93696
Bug ID: 93696
Summary: AVX512VPOPCNTDQ writemask intrinsics produce incorrect
results
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93661
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695
Bug ID: 93695
Summary: Allocation and freeing memory for array members in
loops is not handled properly by the analyzer
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052
Kewen Lin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052
--- Comment #16 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:4d2248bec5d22061ab252724bd59d45c8a47e009
commit r10-6591-g4d2248bec5d22061ab252724bd59d45c8a47e009
Author: Kewen Lin
Date: Tue Feb 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675
--- Comment #2 from Mateusz Pusz ---
Thanks!
Mat
śr., 12 lut 2020, 01:09 użytkownik cvs-commit at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> napisał:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675
>
> --- Comment #1 from CVS Commits --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694
--- Comment #1 from Roland Illig ---
double space:
> architecture \"name\"
unnecessarily verbose:
> Specify that the output file should be generated for architecture "name"
Why not simply: Generate output file for the named architecture.
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694
Bug ID: 93694
Summary: Inconsistent grammar in darwin.opt
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93692
--- Comment #3 from Andrew Pinski ---
The documentation does describe more what super means :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93626
--- Comment #2 from Yibiao Yang ---
(In reply to Martin Liška from comment #1)
> I would not recommend combining --coverage and a sanitizer.
Thanks for the suggestion. Yes, this is an abnormal combination.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93692
--- Comment #2 from Andrew Pinski ---
Note there is a -fdump-analyzer-supergraph so it looks like there is a copy and
paste issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93693
Bug ID: 93693
Summary: [GCOV] incorrect coverage when compiled with option
'-fsanitize=undefined' for function defined inside
other function
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93692
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93692
Bug ID: 93692
Summary: Possible typo: supergraph vs. callgraph
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #25 from Rich Felker ---
I think standards-conforming excess precision should be forced on, and added to
C++; there are just too many dangerous ways things can break as it is now. If
you really think this is a platform of dwindling re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
David Malcolm changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #9 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:91f993b7e31ce85676148dca180bc0d827d4245e
commit r10-6590-g91f993b7e31ce85676148dca180bc0d827d4245e
Author: David Malcolm
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #8 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:35e24106fc1b782e70f8339e0a1321a2bc7a7f15
commit r10-6588-g35e24106fc1b782e70f8339e0a1321a2bc7a7f15
Author: David Malcolm
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93212
--- Comment #6 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:35e24106fc1b782e70f8339e0a1321a2bc7a7f15
commit r10-6588-g35e24106fc1b782e70f8339e0a1321a2bc7a7f15
Author: David Malcolm
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93682
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 11 Feb 2020, bugdal at aerifal dot cx wrote:
> I think the underlying issue here is just that -mpc64 (along with -mpc32) is
> just hopelessly broken and should be documented as such.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #24 from joseph at codesourcery dot com ---
On Tue, 11 Feb 2020, ch3root at openwall dot com wrote:
> So, yeah, it seems integers have to be stable. OTOH, now that there is sse and
> there is -fexcess-precision=standard floating-poin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93690
Florian Schiffmann changed:
What|Removed |Added
CC||floschiffmann at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #13 from Segher Boessenkool ---
nonzero_bits is not reliable. We also cannot really do what you propose
here, all of this is done for *every* combination.
We currently generate
(set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93690
--- Comment #2 from Florian Schiffmann ---
Hi Steve,
the complication here is that it is not the type with the assignment that is a
vector but the Outer type. The type with assignment is a scalar member of the
vector type. Hence the first questi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:d6ef77e023cfe0bb3b12b88ae46b77da356d7f85
commit r10-6586-gd6ef77e023cfe0bb3b12b88ae46b77da356d7f85
Author: Jason Merrill
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93683
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93683
--- Comment #4 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:9a5338e57db1cda13fa788b0e0debbcf99a475d6
commit r10-6585-g9a5338e57db1cda13fa788b0e0debbcf99a475d6
Author: Martin Sebor
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93691
Bug ID: 93691
Summary: Type bound assignment causes too many finalization of
derived type when part of other type
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681
Alexander Cherepanov changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93690
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=93689
--- Comment #5 from Marek Polacek ---
Actually the issue might be just one, even the gimplifier ICE seems to be
caused by a CAST_EXPR leaking where it should not. Maybe we fail to substitute
default arguments in lambdas in a template parameter l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93683
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93689
--- Comment #4 from Marek Polacek ---
That's hard to say without really understanding what the issue is, but I'm
afraid this might not be the best first issue -- it involves some pretty
convoluted features, plus it seems there are two issues (tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93690
Bug ID: 93690
Summary: Type Bound Generic Assignment Bug Using Intrinsic
Assignments
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93689
--- Comment #3 from malle at umich dot edu ---
@Marek Polacek do you (or anyone) think this is a good first issue? I am
curious to try contributing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #12 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #11)
> (The original problem I have an idea for -- don't generate a parallel of
> two SETs with equal SET_SRC -- but that doesn't handle the new case).
For the n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93689
--- Comment #2 from Marek Polacek ---
The test was rejected with various errors, then with
r9-4045-g0c1e0d63fe0ceabbd04384070f3b59f8bf50de09 we got this ICE:
93689.C: In function ‘int f() [with auto Z = main()::{}]’:
93689.C:5:13: internal compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #11 from Segher Boessenkool ---
(The original problem I have an idea for -- don't generate a parallel of
two SETs with equal SET_SRC -- but that doesn't handle the new case).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #10 from Segher Boessenkool ---
One of the first things combine tries is
Trying 7 -> 8:
7: r96:SI=r104:SI&0xe
REG_DEAD r104:SI
8: r99:DI=sign_extend(r96:SI)
...
Successfully matched this instruction:
(set (reg/v:SI 96 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93689
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93191
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93689
Bug ID: 93689
Summary: ICE with default argument in lambda used as non type
template argument
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
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=93688
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93687
--- Comment #1 from Andrew Pinski ---
*** Bug 93688 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93688
Bug ID: 93688
Summary: Add mcf thread model to GCC on windows for supporting
C++11 std::thread?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93687
Bug ID: 93687
Summary: Add mcf thread model to GCC on windows for supporting
C++11 std::thread?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93684
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93684
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #12 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388
--- Comment #5 from David Malcolm ---
(In reply to David Binderman from comment #4)
> I tried out -fanalyzer with all the C code under gcc/testsuite.
>
> There are 35368 C source code files. 234 crashes so far.
>
> Here are the first ten:
Than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93683
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93683
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
--- Comment #7 from fdlbxtqi ---
I mean it is a bug.
constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}
int main()
{
constexpr auto w(f());
}
I mean this is UB so it should not compile. However, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93686
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93686
Bug ID: 93686
Summary: [9/10 Regression] ICE in gfc_match_data, at
fortran/decl.c:702
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685
Bug ID: 93685
Summary: [9/10 Regression] ICE in gfc_constructor_append_expr,
at fortran/constructor.c:135
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93684
Bug ID: 93684
Summary: [8/9/10 Regression] ICE in cp_lexer_consume_token, at
cp/parser.c:1120
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93683
Bug ID: 93683
Summary: [10 Regression] ICE in ao_ref_init_from_ptr_and_size,
at tree-ssa-alias.c:714
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
--- Comment #7 from Peter Bergner ---
Here's the minimal test case using options -O3 -mcpu=power8
-fstack-protector-strong:
void bar();
char b;
void
foo (void)
{
char a;
int d = b;
char *e = &a;
while (d)
*e++ = --d;
bar ();
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
--- Comment #5 from Marek Polacek ---
We might get away with just avoiding value-init in a template:
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -4520,7 +4520,7 @@ build_vec_init (tree base, tree maxindex, tree init,
We do need to keep goi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93374
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93669
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93649
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93657
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93374
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:a60d98890bba58649c26c2fc0c6f28cd6073aaaf
commit r10-6582-ga60d98890bba58649c26c2fc0c6f28cd6073aaaf
Author: David Malcolm
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93669
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:a0e4929b0461226722d6d08b1fdc2852b9100b75
commit r10-6581-ga0e4929b0461226722d6d08b1fdc2852b9100b75
Author: David Malcolm
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93649
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:cd28b75921354c64fd4c8a1c238991e522abc38e
commit r10-6580-gcd28b75921354c64fd4c8a1c238991e522abc38e
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93657
--- Comment #4 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:5e17c1bdadbbd5606d869b1178ed3e653f931cda
commit r10-6579-g5e17c1bdadbbd5606d869b1178ed3e653f931cda
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Wilco changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
--- Comment #4 from Marek Polacek ---
A bit shorter test:
struct P {
int x = 0;
};
template
struct S {
S() { new P[2][2]; }
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #16 from Arnd Bergmann ---
Right, I was on the releases/gcc-9 branch, not HEAD. Sorry about the confusion.
I applied your fix and have a working 9.2 build that can build the kernel now.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #159 from Peter Bisroev ---
(In reply to dave.anglin from comment #157)
> On 2020-02-11 12:27 p.m., peter.bisroev at groundlabs dot com wrote:
> > Just to confirm though, using gcc 4.7.4 that I have previously compiled with
> > aCC th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #158 from Peter Bisroev ---
(In reply to dave.anglin from comment #156)
> On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> > However the above can be compiled with -O0 with the same compiler. So I
> > changed
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93634
--- Comment #1 from Cassio Neri ---
FYI, this is what clang trunk generates:
imull $-1431655765, %edi, %eax # imm = 0xAAAB
addl $1431655764, %eax # imm = 0x5554
rorl %eax
cmpl $715827882, %eax # imm = 0x2AAA
setb %al
retq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
--- Comment #6 from Peter Bergner ---
So we are in an infinite loop in process_address() calling process_address_1().
I've hacked in some code to ICE if we loop for too long and I'm currently
using creduce to minimize the test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #157 from dave.anglin at bell dot net ---
On 2020-02-11 12:27 p.m., peter.bisroev at groundlabs dot com wrote:
> Just to confirm though, using gcc 4.7.4 that I have previously compiled with
> aCC that adequately passed 'make check' tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #156 from dave.anglin at bell dot net ---
On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> However the above can be compiled with -O0 with the same compiler. So I
> changed
> my build line to use -O0 as well:
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #15 from Alexander Monakov ---
This should not be reproducible with current HEAD because the assert was simply
eliminated. If GCC master definitely fails, can you please provide the exact
diagnostic?
As for 9.2 this is sadly expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #155 from Peter Bisroev ---
(In reply to dave.anglin from comment #154)
> On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> > We already know that we currently cannot compile stage1 with -O0 as it
> > causes
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93682
--- Comment #2 from Rich Felker ---
I think the underlying issue here is just that -mpc64 (along with -mpc32) is
just hopelessly broken and should be documented as such. It could probably be
made to work, but there are all sorts of issues like fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #154 from dave.anglin at bell dot net ---
On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> We already know that we currently cannot compile stage1 with -O0 as it causes
> binaries to become huge and we get PCREL21
test.c
during RTL pass: mach
lz4_decompress.c:10:1: internal compiler error: in sel_target_adjust_priority,
at sel-sched.c:3334
10 | }
Reproduced both with 9.2 and current HEAD
$ ia64-linux-gcc --version
ia64-linux-gcc (GCC) 9.2.1 20200211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085
--- Comment #8 from Andreas Schwab ---
Yes, nothing has changed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676
--- Comment #3 from Marek Polacek ---
We hit this assert in build_value_init:
/* The AGGR_INIT_EXPR tweaking below breaks in templates. */
gcc_assert (!processing_template_decl
|| (SCALAR_TYPE_P (type) || TREE_CODE (type) == A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #23 from Alexander Cherepanov ---
(In reply to Alexander Monakov from comment #10)
> Also note that both the original and the reduced testcase can be tweaked to
> exhibit the surprising transformation even when -fexcess-precision=stan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #22 from Alexander Cherepanov ---
(In reply to jos...@codesourcery.com from comment #11)
> Yes, I agree that any particular conversion to integer executed in the
> abstract machine must produce some definite integer value for each
>
p;
./a.out
one = 0
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--
---
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--
-
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--
All the same but the computation of `i` is hoisted from the `if` in the
133t.pre pass so dom3 doesn't have a chance to fold it.
Another interesting aspect:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
--- C
1 - 100 of 169 matches
Mail list logo
