https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103571
--- Comment #4 from Uroš Bizjak ---
(In reply to Hongyu Wang from comment #3)
> So we may need to support V8HFmode in VALID_SSE2_REG_MODE if we don't want
> to modify those function_args and function_value stuff.
We have V8HFmode moves for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103571
Hongyu Wang changed:
What|Removed |Added
CC||wwwhhhyyy333 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94776
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
Richard Biener changed:
What|Removed |Added
CC||harrywong at live dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88550
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86344
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81847
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963
Richard Biener changed:
What|Removed |Added
CC||linuxsquirrel.dev at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57715
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93809
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83469
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103596
Andrew Pinski changed:
What|Removed |Added
Known to work||7.5.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103596
Andrew Pinski changed:
What|Removed |Added
Summary|[11/12 Regression] ICE: |[9/10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103596
Bug ID: 103596
Summary: [11/12 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83469
--- Comment #3 from Andrew Pinski ---
(In reply to Marek Polacek from comment #1)
> (gdb) p type
> $4 =
> (gdb) p class_key
> $5 = union_type
>
> Should we allow such a combination?
Yes. The code change here will also fix PR 93809.
Let me try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95873
--- Comment #2 from Andrew Pinski ---
The warning is invalid in this case anyways so even though there is a
duplicated warning it only happens with valid code which should not warn at
all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93809
--- Comment #4 from Andrew Pinski ---
*** Bug 95873 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95873
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 67013, which changed state.
Bug 67013 Summary: [DR569] Compilation error for well-formed program with empty
declaration in the global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96068
Andrew Pinski changed:
What|Removed |Added
CC||anders.granlund.0 at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90107
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90107
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.6.4
Summary|rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66892
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.5
Summary|[DR355] Fix of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66892
Andrew Pinski changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95610
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66892
Andrew Pinski changed:
What|Removed |Added
Alias||cwg355
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44400
Andrew Pinski changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91013
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100868
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
Andrew Pinski changed:
What|Removed |Added
Summary|accepts invalid |[DR1310] accepts invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103571
--- Comment #2 from Hongtao.liu ---
>
> Also, baz iz highly un-optimal for 32bit targets.
Yes, it needs to be fixed, note w/ -mavx512fp16 codegen for baz is optimal on
32-bit target, maybe related to vector_mode_supported_p, but then why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
--- Comment #11 from Andrew Pinski ---
Someone who has better understanding of the C++ standard should answer the
question if this is valid or not because I don't understand all of the specific
rules rules which are in play here. Especially when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103554
--- Comment #8 from Hongtao.liu ---
> but the x86 backend chooses to not let the vectorizer compare costs with
> different vector sizes but instead asks it to pick the first working
> solution from the vector of modes to consider (and in that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
--- Comment #10 from Andrew Pinski ---
Oh this:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#318
In a lookup in which the constructor is an acceptable lookup result, if the
nested-name-specifier nominates a class C and the name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40294
--- Comment #4 from Andrew Pinski ---
*** Bug 33659 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33659
--- Comment #3 from Andrew Pinski ---
This is actually valid code, the class name is injected and can be used in this
context (the last one is used to name the constructor otherwise).
Dup of bug 40294 which is recording all of the valid cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40294
Andrew Pinski changed:
What|Removed |Added
Resolution|DUPLICATE |INVALID
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
Andrew Pinski changed:
What|Removed |Added
Host|i386-portbld-freebsd6.2 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
--- Comment #8 from Andrew Pinski ---
DR 147 is definitely the defect report here.
Reading the new text still gives me questions about the case if typename is
used:
If the nested-name-specifier nominates a class C, and the name specified after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89642
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-12-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
Andrew Pinski changed:
What|Removed |Added
CC||vgheorgh at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66350
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
Andrew Pinski changed:
What|Removed |Added
CC||ahuszagh at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82347
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
Andrew Pinski changed:
What|Removed |Added
CC||johelegp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103564
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103564
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Maybe there is defect report in this area.
Note even the original testcase MSVC accepts too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103564
--- Comment #1 from Andrew Pinski ---
Hmm, this is not really concept related, because GCC/ICC/MSVC all accept the
following too:
struct base { };
template
void f(void)
{
typename T::base a;
};
int main(void)
{
f();
}
--- CUT
While
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103566
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103569
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103594
--- Comment #2 from Andrew Pinski ---
Created attachment 51937
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51937=edit
Rewrite ix86_call_use_plt_p to be better
Here is a rewrite and adds the check for FUNCTION_DECL before calling of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103594
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103186
Andrew Pinski changed:
What|Removed |Added
CC||mortenkschou at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103595
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103186
--- Comment #9 from Andrew Pinski ---
Just lambdas as default is needed really, reduced testcase:
struct f
{
template
f(const T1&){}
};
template class A {
public:
void foo(A a, const f& fn = [](){}) { }
void bar(A a) { foo(a); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103595
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103595
--- Comment #1 from Andrew Pinski ---
typeinfo name for A::foo(A, std::function const&)::{default
arg#1}::{lambda()#1}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103595
Bug ID: 103595
Summary: [11 Regression] std::function parameter with default
value lambda, fails with error redefinition of 'const
char _ZT... []'
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103594
Andrew Pinski changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103594
Bug ID: 103594
Summary: [12 Regression] ICE in get, at cgraph.h:1335
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70782
--- Comment #3 from Andrew Pinski ---
For the memset/memcpy version, I wonder if we should convert:
MEM[(char * {ref-all})] = _10;
...
MEM [(char * {ref-all})] = _8;
Into using BIT_FIELD_REF.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57009
--- Comment #2 from Andrew Pinski ---
(In reply to Marc Glisse from comment #1)
> union A { double d; unsigned long long i; };
> bool f(double x){
> A a; a.d = x;
> unsigned long long inf = 0x7ff0;
> return (a.i & inf) != inf;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26546
--- Comment #4 from Andrew Pinski ---
Without the uninitialized variable even LLVM produces the same assembly code.
Is there really anything more to opimize here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:c9543403c19fdc3c3b5a8db8546340de085bd14e
commit r12-5815-gc9543403c19fdc3c3b5a8db8546340de085bd14e
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29756
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #17 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95740
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103584
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103558
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103492
--- Comment #7 from Andrew Pinski ---
reduced testcase for clang's warning:
struct f
{
unsigned a:2;
unsigned b:(32-2);
};
int g(struct f *b)
{
switch (b->a)
{
case 0:
return 2;
case 1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103558
Iain Buclaw changed:
What|Removed |Added
CC||doko at debian dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103582
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
--- Comment #26 from joseph at codesourcery dot com ---
It's hard to define something that is sufficiently general to be useful
but doesn't expose too much of the details of GCC's internal data
structures for describing standard formats. %b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291
--- Comment #7 from joseph at codesourcery dot com ---
I don't think TREE_OVERFLOW should be introduced in folding expressions
that didn't have undefined behavior in the original source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103593
Andrew Pinski changed:
What|Removed |Added
Known to work||10.3.0
Summary|Naming the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103588
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103593
Bug ID: 103593
Summary: Naming the constructor of a template class without
using the injected-class-name causes parse error with
C++20
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103591
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103545
--- Comment #1 from CVS Commits ---
The master branch has been updated by Paul Clarke :
https://gcc.gnu.org/g:325c6163a33af91264d1b7817a45b8425d5e6a4f
commit r12-5814-g325c6163a33af91264d1b7817a45b8425d5e6a4f
Author: Paul A. Clarke
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103562
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861
--- Comment #13 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Andrew Pinski from comment #10)
> > GCC 10+ started to reject the code just the same as CLANG does.
>
> Clang doesn't reject it, libc++ does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103583
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103565
--- Comment #4 from cqwrteur ---
(In reply to Andrew Pinski from comment #3)
> The tree level looks good:
> _6 = (long long unsigned int) carry_1(D);
> _13 = .ADD_OVERFLOW (a_3(D), _6);
> temp_7 = REALPART_EXPR <_13>;
> _14 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103565
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103592
--- Comment #1 from hubicka at kam dot mff.cuni.cz ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
> [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
note that fatigue2 is polyhedron, not spec...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103565
--- Comment #2 from Andrew Pinski ---
The difference is just argument and return register differences (and maybe a
register allocation issue).
That is the extra instructions are:
for add_carry_pattern_test:
movzx edi, dil
mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103591
--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested fix:
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2bf21434a42..52bc5af7542 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6075,6 +6075,15 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103587
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103591
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103589
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-12-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103588
--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested patch:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 5762c8d92d4..5f9ed17f919 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -2403,11 +2403,9 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103592
Bug ID: 103592
Summary: fatigue2 benchmarks on zen runs 43% faster with
-fno-tree-vectorize -fno-tree-slp-vectorize
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103588
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-12-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-12-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103591
Bug ID: 103591
Summary: ICE in gfc_compare_string, at fortran/arith.c:1119
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103590
Bug ID: 103590
Summary: ICE: find_array_spec(): Missing spec
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103589
Bug ID: 103589
Summary: ICE in gfc_match_varspec, at fortran/primary.c:2551
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
1 - 100 of 220 matches
Mail list logo
