[Bug target/99293] Built-in vec_splat generates sub-optimal code for -mcpu=power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293 Michael Meissner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/99293] Built-in vec_splat generates sub-optimal code for -mcpu=power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293 --- Comment #3 from Michael Meissner --- Created attachment 50947 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50947=edit Proposed patch
[Bug inline-asm/100921] Inline assembly use of struct not counted as use for store elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100921
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
__asm__ __volatile__("call consumer" : : "D"());
You are just passing the address of the variable. You either need "m"(v)
there, a simple "memory" might work too.
See PR 36639, and PR 93952. There are others.
[Bug inline-asm/100921] New: Inline assembly use of struct not counted as use for store elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100921
Bug ID: 100921
Summary: Inline assembly use of struct not counted as use for
store elision
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: ethereal at ethv dot net
Target Milestone: ---
The following functions do not compile to the same result: (example is for
x86_64)
extern "C" void consumer(int *);
void example1() {
int v;
// this store will be elided as `v` is somehow never considered "read"
v = 0x12345; // some special constant
__asm__ __volatile__("call consumer" : : "D"());
// random value has now been used
}
void example2() {
int v;
// this store is _not_ elided, it's kept around
// even though the behaviour should be identical to example1
v = 0x12345;
consumer();
}
The use of `call` is not special, this appears to happen with any inline
assembly, including e.g. `mov`, `lgdt`, and `fld`. However, in both cases the
variable is "used" in the same way (taking the address of an initialized
variable), but are treated differently.
Various GCC versions tested (11.1, 9.3, 7.5, 6.4) all produce the same output.
clang outputs differently, and with the expected result for various versions
(3.3, 5.0, 12.0). Here's a godbolt link: https://godbolt.org/z/dWhx3zfse
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 --- Comment #7 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #6) > And LWG 3403 was fixed by r12-1228. Hey, Jonathan, thank you for your contribution to gcc. Regarding the implementation of LWG 3403, the return type of __int128 is unsigned. I don't know if this is a typo.
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma | |il/gcc-patches/2021-May/571 | |055.html| --- Comment #19 from Andrew Pinski --- First patch for this was committed as r12-1152. The second patch for this was posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571800.html .
[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195 --- Comment #6 from Andrew Pinski --- Note the loop based one is a little more complex due to the way GCC IR handles overflow being wrapping or undefined; I am just going to fix the case where overflow is defined as wrapping. The other case needs more work and maybe even a huge change in the IR handling.
[Bug tree-optimization/100864] (a&!b) | b is not opimized to a | b for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864 --- Comment #4 from Andrew Pinski --- (In reply to Richard Biener from comment #3) > You can possibly merge it with the That is where I put it already, the ... was actually that part. Obviously this was not a patch just showing what was done. > > by using sth like logical_inverted_value (you want bit_inverted_value), > > Also you don't need > > (for cmp (tcc_comparison) > (for icmp (tcc_comparison) > > but just > > (for cmp (tcc_comparison) >icmp (inverted_tcc_comparison) >ncmp (inverted_tcc_comparison_with_nans)) > ... >(if (ic == icmp || ic == ncmp) > ... > > right? Does not work as there would be many of the same patterns with the above for loop as inverted_tcc_comparison and inverted_tcc_comparison_with_nans have a non empty intersection. The reason why it worked for the other usage of inverted_tcc_comparison/inverted_tcc_comparison_with_nans is because it was the resulting pattern rather than the matching pattern.
[Bug c++/84476] [[nodiscard]] ignored on virtual functions accessed through pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84476 --- Comment #6 from Martin Sebor --- The same problem applies to attribute noreturn (but not deprecated). Clang, ICC, and Visual C++ behave as expected in both cases, suggesting GCC should change.
[Bug c/100920] New: bogus warn on -Wscalar-storage-order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100920
Bug ID: 100920
Summary: bogus warn on -Wscalar-storage-order
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: george.thopas at gmail dot com
Target Milestone: ---
/*
* trying to use -Wscalar-storage-order on latest git version
*
* https://gcc.gnu.org/g:401bd4adcfda9965363b1ac3ba7e1580f15d6883
*
* below test exposes what looks like 2 wrong warnings
* a warning on an union where everything is big-endian
* a warning on type less void pointer
*
* gcc -Werror test.c
*
* Thanks
*/
include
struct s_1 {
int val;
} __attribute__((scalar_storage_order("big-endian")));
typedef struct s_1 t_1;
struct s_2 {
char val;
} __attribute__((scalar_storage_order("big-endian")));
typedef struct s_2 t_2;
struct s12 {
t_1 a[1];
t_2 b[1];
} __attribute__((scalar_storage_order("big-endian")));
typedef struct s12 t_s12;
/* Warning while everything is big-endian */
union u12 {
t_1 a[1];
t_2 b[1];
} __attribute__((scalar_storage_order("big-endian")));
typedef union u12 t_u12;
int main(void)
{
/* warning while assigning from a type less void pointer */
t_s12 *msg1 = __builtin_alloca(10);
t_u12 *msg2 = __builtin_alloca(10);
msg1->a[0].val=0;
msg2->a[0].val=0;
return 0;
[Bug c++/100919] multiple -Wdeprecated-declarations on a call to a deprecated member function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100919 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.1.0, 12.0, ||4.9.4, 8.3.0, 9.1.0 Keywords||diagnostic --- Comment #1 from Martin Sebor --- The problem goes as far back as I can see (4.9 issues just one duplicate warning, starting with 5.0 GCC issues three).
[Bug c++/100919] New: multiple -Wdeprecated-declarations on a call to a deprecated member function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100919
Bug ID: 100919
Summary: multiple -Wdeprecated-declarations on a call to a
deprecated member function pointer
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The test case below shows that G++ issues three identical warnings for a single
call to function through a member pointer (both with [[deprecated]] or
__attribute__ ((deprecated))). It should issue one one warning, same as for
direct calls.
$ cat t.C && gcc -S -Wall t.C
struct A
{
[[deprecated]] int f ();
[[deprecated]] int (*pf) ();
};
void f (A *p)
{
p->f (); // one warning (good)
}
void g (A *p)
{
p->pf (); // three warnings (bug)
}
t.C: In function ‘void f(A*)’:
t.C:9:8: warning: ‘int A::f()’ is deprecated [-Wdeprecated-declarations]
9 | p->f (); // one warning (good)
| ~^~
t.C:3:22: note: declared here
3 | [[deprecated]] int f ();
| ^
t.C: In function ‘void g(A*)’:
t.C:14:6: warning: ‘A::pf’ is deprecated [-Wdeprecated-declarations]
14 | p->pf (); // three warnings (bug)
| ^~
t.C:4:24: note: declared here
4 | [[deprecated]] int (*pf) ();
|^~
t.C:14:6: warning: ‘A::pf’ is deprecated [-Wdeprecated-declarations]
14 | p->pf (); // three warnings (bug)
| ^~
t.C:4:24: note: declared here
4 | [[deprecated]] int (*pf) ();
|^~
t.C:14:6: warning: ‘A::pf’ is deprecated [-Wdeprecated-declarations]
14 | p->pf (); // three warnings (bug)
| ^~
t.C:4:24: note: declared here
4 | [[deprecated]] int (*pf) ();
|^~
[Bug c++/70057] duplicate integer overflow diagnostic in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70057 Martin Sebor changed: What|Removed |Added Known to fail|5.3.0, 6.3.0, 7.0 |10.2.0, 11.1.0, 12.0, ||5.5.0, 6.4.0, 7.2.0, 8.3.0, ||9.1.0 Last reconfirmed|2017-02-27 00:00:00 |2021-6-4 --- Comment #4 from Martin Sebor --- Reconfirming with GCC 11.1.
[Bug tree-optimization/58073] Suboptimal optimisation of ((x & 0x70) == 0x00 || (x & 0x70) == 0x10 || (x & 0x70) == 0x20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58073 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > > And maybe even one like this (which will solve the issue sooner): > > (bit_ior > (cmp (bit_and @0 INTEGER_CST@2) INTEGER_CST@3) > (cmp @0 INTEGER_CST@5))) Note the final INTEGER_CST has to be 0 I think but you get the idea.
[Bug c/69972] duplicate integer overflow diagnostic in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69972 Martin Sebor changed: What|Removed |Added Last reconfirmed|2016-02-29 00:00:00 |2021-6-4 Known to fail||10.2.0, 11.0, 6.3.0, 7.0.1, ||8.3.0, 9.3.0 --- Comment #5 from Martin Sebor --- Reconfirmed with GCC 11.
[Bug target/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-06-04 Component|libstdc++ |target Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- This sounds like it is still picking up the wrong libstdc++ really. Can you disassemble (objdump -dr) ~/usr/lib64/libstdc++.so.6 to see which vsnprintf is used there? Also can you set LD_LIBRARY_PATH to ~/usr/lib64/ rather than using LD_PRELOAD and see if that works. The other thing to do use LD_DEBUG to figure out which libstdc++ is being used really.
[Bug tree-optimization/58073] Suboptimal optimisation of ((x & 0x70) == 0x00 || (x & 0x70) == 0x10 || (x & 0x70) == 0x20) on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58073
--- Comment #6 from Andrew Pinski ---
#define shift 4
return ((mask(d) == (0x0 << shift)) ||
(mask(d) == (0x1 << shift)) ||
(mask(d) == (0x2 << shift)));
static inline unsigned mask(const struct dentry *dentry)
{
return dentry->d_flags & (0x7 << shift);
}
ifcombine does:
_4 = _5 & 112; // this was already there.
_8 = _4 == 16;
_7 = _4 == 0;
_9 = _7 | _8;
_10 = _4 == 32;
_11 = _9 | _10;
Which is correct.
reassoc1 does:
_4 = _5 & 112;
_8 = _4 == 16;
_1 = _4 & 4294967279; // -17 or ~16
_13 = _1 == 0;
_7 = _4 == 0;
_10 = _4 == 32;
_11 = _10 | _13;
and that is where it messes up, it misses reassocation of all three ands
together. And _4 & 4294967279 removes bit 7 from the original and.
Final output:
_4 = _5 & 112; // 0b111
_1 = _5 & 96; // 0b110
_13 = _1 == 0; // 0b000
_10 = _4 == 32;// 0b010
_11 = _10 | _13;
So we need have another pattern for something like this:
(bit_ior
(cmp (bit_and @0 INTEGER_CST@2) INTEGER_CST@3)
(cmp (bit_and @0 INTEGER_CST@4) INTEGER_CST@5))
And maybe even one like this (which will solve the issue sooner):
(bit_ior
(cmp (bit_and @0 INTEGER_CST@2) INTEGER_CST@3)
(cmp @0 INTEGER_CST@5)))
[Bug tree-optimization/51781] Missed optimization for ==/!= comparison type-sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51781 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- Mine. Psedu-match.pd code (needs expansion of some stuff but the general idea is there) (for (cmp ne eq) (cmp (convert @0) (bit_and @1 INTEGER_CST@2) (if (TYPE_UNSIGNED(@0) && @2 == maskforprecissionoftype(@0)) (cmp @0 (convert:TYPE(@0) @1))
[Bug tree-optimization/68557] Missed x86 peephole optimization for multiplying by a bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68557 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Mine.
[Bug ipa/67014] builtin_tolower is inefficient.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67014
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |ipa
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-04
--- Comment #1 from Andrew Pinski ---
tolower is defined in the header file as:
extern __inline __attribute__ ((__gnu_inline__)) int
__attribute__ ((__nothrow__ , __leaf__)) tolower (int __c)
{
return __c >= -128 && __c < 256 ? (*__ctype_tolower_loc ())[__c] : __c;
}
So __builtin_tolower is not using that inline function. So this is a front-end
issue where the the two function decls are not being merged into one or is an
inliner issue.
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 --- Comment #21 from Eduard Rozenberg --- @ppalka Huge thanks for this fix - it's working well for me. Very happy to see the patch applied with no problems to gcc 10.3.0, because it could take several years until the OS and Nvidia support gcc 11 or 12. Otherwise I would have had to move back to gcc 10.2.0 and build custom kernels for quite some time. Tested as follows: * Rebuilt Slackware gcc 10.3.0 packages with the patch for `pt.c` * Built Nvidia nccl-tests - build succeeded (was failing before the patch) * Built latest pytorch git with Nvidia support - build succeeded (was failing before the patch)
[Bug tree-optimization/65412] sequence of ifs not turned into a switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65412
--- Comment #4 from Andrew Pinski ---
clang decides at 4 to change it to a switch statement while GCC takes a few
extra ifs to change it. Again this is heuristics at work.
#define B(y) void f##y(void);
#define B10(y) B(y##0) B(y##1) B(y##2) \
B(y##3) B(y##4) B(y##5) \
B(y##6) B(y##7) B(y##8) \
B(y##9)
B10(1)
#define A(y) else if (x == y) f##y();
void f10(int x)
{
if (0) ;
A(11)
A(12)
A(13)
A(14)
}
[Bug tree-optimization/65412] sequence of ifs not turned into a switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65412
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |10.0
Last reconfirmed|2015-12-28 00:00:00 |2021-6-4
--- Comment #3 from Andrew Pinski ---
>From *.iftoswitch on the trunk:
;; Canonical GIMPLE case clusters: 0 1 2 3 4 5
So I looked and this is fixed but not for the low if count.
Take:
#define B(y) void f##y(void);
#define B10(y) B(y##0) B(y##1) B(y##2) \
B(y##3) B(y##4) B(y##5) \
B(y##6) B(y##7) B(y##8) \
B(y##9)
#define B100(y) B10(y##0) B10(y##1) B10(y##2) \
B10(y##3) B10(y##4) B10(y##5) \
B10(y##6) B10(y##7) B10(y##8) \
B10(y##9)
B10(1)
B100(1)
#define A(y) else if (x == y) f##y();
#define A10(y) A(y##0) \
A(y##1) \
A(y##2) \
A(y##3) \
A(y##4) \
A(y##5) \
A(y##6) \
A(y##7) \
A(y##8) \
A(y##9)
#define A100(y) A10(y##0) \
A10(y##1) \
A10(y##2) \
A10(y##3) \
A10(y##4) \
A10(y##5) \
A10(y##6) \
A10(y##7) \
A10(y##8) \
A10(y##9)
void f10(int x)
{
if (0) ;
A10(1)
}
void f100(int x)
{
if (0) ;
A100(1)
}
--- CUT
f100 is converted while f10 is not. This is a heuristics at work to see if it
is better as a jump table vs if statements.
https://godbolt.org/z/ofWGb5aKn for reference.
Clang decides (I don't know if they lower switches back to if statements) to do
the switch for all cases.
So we can close this as fixed.
[Bug fortran/95502] ICE in gfc_check_do_variable, at fortran/parse.c:4446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95502 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-June/056133.html
[Bug c++/100918] [9/10/11/12 Regression] Naming a destructor as a qualified template-id results in bogus access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918 Patrick Palka changed: What|Removed |Added Known to work||8.5.0 Known to fail||10.3.0, 11.1.0, 9.4.0 Target Milestone|--- |9.5 Summary|Naming a destructor as a|[9/10/11/12 Regression] |qualified template-id |Naming a destructor as a |results in bogus access |qualified template-id |error |results in bogus access ||error
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 --- Comment #6 from Jonathan Wakely --- And LWG 3403 was fixed by r12-1228. I plan to backport these three patches too. Thanks for all the bug reports like this!
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3e5f2425f80aedd00f28235022a2755eb46f310d commit r12-1227-g3e5f2425f80aedd00f28235022a2755eb46f310d Author: Jonathan Wakely Date: Fri Jun 4 20:25:39 2021 +0100 libstdc++: Fix helper concept for ranges::data [PR 100824] We need to decay the result of t.data() before checking if it's a pointer. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100824 * include/bits/ranges_base.h (__member_data): Use __decay_copy. * testsuite/std/ranges/access/data.cc: Add testcase from PR.
[Bug c++/100918] Naming a destructor as a qualified template-id results in bogus access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-06-04 Status|UNCONFIRMED |ASSIGNED
[Bug c++/100918] Naming a destructor as a qualified template-id results in bogus access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918
--- Comment #1 from Patrick Palka ---
We began rejecting this starting with r9-4879.
If we replace the explicit specialization of Inner::~Inner with a generic
definition
struct Outer {
public:
template
struct Inner { ~Inner(); };
};
template
Outer::Inner::~Inner() {}
Outer::Inner x;
then we started to reject this version after r11-1350.
[Bug middle-end/100905] [OpenMP] ICE in convert_nonlocal_omp_clauses, at tree-nested.c:1514 with 'omp loop' in Fortran internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100905 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Tobias Burnus --- FIXED.
[Bug c++/100918] New: Naming a destructor as a qualified template-id results in bogus access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918
Bug ID: 100918
Summary: Naming a destructor as a qualified template-id results
in bogus access error
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
The following testcase:
struct Outer {
template
struct Inner { ~Inner(); };
};
template<>
Outer::Inner::~Inner() {}
is rejected with
: In destructor ‘Outer::Inner::~Inner() [with T = int]’:
:7:21: error: ‘template struct Outer::Inner’ is inaccessible
within this context
:3:12: note: declared here
[Bug c++/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809 Michael Meissner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Michael Meissner --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571942.html
[Bug testsuite/100168] Test gcc.dg/pr56727-2.c fails on power10 code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100168 Michael Meissner changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Last reconfirmed||2021-06-04 --- Comment #1 from Michael Meissner --- This is has been submitted with the patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570688.html
[Bug fortran/100917] Bind(c): errors handling long double real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 50946 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50946=edit C code for bind(c)
[Bug fortran/100917] New: Bind(c): errors handling long double real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917 Bug ID: 100917 Summary: Bind(c): errors handling long double real Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50945 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50945=edit Fortran code showing problem Hi All! Wrong type and kind on handling long double real. Since kind is not related to elem_len there seems to be no way to infer it. Seen on: GNU Fortran (GCC) 10.3.1 20210526 GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210529 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/100916] Bind(c): CFI_type_other unimplemented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100916 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 50944 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50944=edit C code for bind(c)
[Bug fortran/100916] New: Bind(c): CFI_type_other unimplemented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100916 Bug ID: 100916 Summary: Bind(c): CFI_type_other unimplemented. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50943=edit Fortran code showing problem Hi All! As per standard non C interoperability types get CFI_type_other. Seen on: GNU Fortran (GCC) 10.3.1 20210526 GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210529 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/100915] Bind(c): failure handling C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100915 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 50942 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50942=edit C code for bind(c)
[Bug fortran/100915] New: Bind(c): failure handling C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100915 Bug ID: 100915 Summary: Bind(c): failure handling C_FUNPTR Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50941 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50941=edit Fortran code showing problem Hi All! Wrong type, kind and elem_len confuses CFI_address. Seen on: GNU Fortran (GCC) 10.3.1 20210526 GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210529 (experimental) Thank you very much. Best regards, José Rui
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 --- Comment #4 from Jonathan Wakely --- Ah yes, the __member_data and __adl_data concepts aren't decaying the result types.
[Bug fortran/100914] Bind(c): errors handling complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 50940 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50940=edit C code for bind(c)
[Bug fortran/100914] New: Bind(c): errors handling complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914 Bug ID: 100914 Summary: Bind(c): errors handling complex Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50939 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50939=edit Fortran code showing problem Hi All! Wrong type and kind with complex intrinsic type, causing failure at CFI_Address. Seen on: GNU Fortran (GCC) 10.3.1 20210526 GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210529 (experimental) Thank you very much. Best regards, José Rui
[Bug c/100913] New: cppcheck: 2 * pointless new assignments in the parser ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100913 Bug ID: 100913 Summary: cppcheck: 2 * pointless new assignments in the parser ? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- 1. trunk.git/gcc/c/c-parser.c:15600:12: style: Variable 'iterators' is assigned a value that is never used. [unreadVariable] git blame says: trunk.git/g9a5de4d5af1c gcc/c/c-parser.c (Tobias Burnus 2021-05-28 10:01:19 +0200 15600) iterators = NULL_TREE; 2. gcc/cp/parser.c:37830:12: style: Variable 'iterators' is assigned a value that is never used. [unreadVariable] Possible duplicate.
[Bug middle-end/100905] [OpenMP] ICE in convert_nonlocal_omp_clauses, at tree-nested.c:1514 with 'omp loop' in Fortran internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100905 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c7070b31e12c18905ed0a60aaedd7a071aab5c60 commit r12-1226-gc7070b31e12c18905ed0a60aaedd7a071aab5c60 Author: Tobias Burnus Date: Fri Jun 4 20:52:33 2021 +0200 OpenMP: Handle bind clause in tree-nested.c [PR100905] PR middle-end/100905 gcc/ChangeLog: * tree-nested.c (convert_nonlocal_omp_clauses, convert_local_omp_clauses): Handle OMP_CLAUSE_BIND. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/loop-3.f90: New test.
[Bug d/100882] ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- Fix committed and backported.
[Bug d/100882] ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:b81bb0a6025588ac752cd78cce74ecf0d9ab4494 commit r9-9569-gb81bb0a6025588ac752cd78cce74ecf0d9ab4494 Author: Iain Buclaw Date: Fri Jun 4 19:38:26 2021 +0200 d: Fix ICE in gimplify_var_or_parm_decl, at gimplify.c:2755 (PR100882) Constructor calls for temporaries were reusing the TARGET_EXPR_SLOT of a TARGET_EXPR for an assignment, which later got passed to `build_assign', which stripped away the outer TARGET_EXPR, leaving a reference to a lone temporary with no declaration. This stripping away of the TARGET_EXPR also discarded any cleanups that may have been assigned to the expression as well. So now the reuse of TARGET_EXPR_SLOT has been removed, and `build_assign' now constructs assignments inside the TARGET_EXPR_INITIAL slot. This has also been extended to `return_expr', to deal with possibility of a TARGET_EXPR being returned. gcc/d/ChangeLog: PR d/100882 * d-codegen.cc (build_assign): Construct initializations inside TARGET_EXPR_INITIAL. (compound_expr): Remove intermediate expressions that have no side-effects. (return_expr): Construct returns inside TARGET_EXPR_INITIAL. * expr.cc (ExprVisitor::visit (CallExp *)): Remove useless assignment to TARGET_EXPR_SLOT. gcc/testsuite/ChangeLog: PR d/100882 * gdc.dg/pr100882a.d: New test. * gdc.dg/pr100882b.d: New test. * gdc.dg/pr100882c.d: New test. * gdc.dg/pr100882d.d: New test. (cherry picked from commit e8761d4c21b5f4cc1c5612be9bf952a07c8a2238)
[Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
Bug ID: 100912
Summary: powerpc64le: ieee128 long double incorrectly printed
when using shared libstdc++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: msc at linux dot ibm.com
Target Milestone: ---
Steps to reproduce:
- Build gcc with IEEE128 as the default long double format (using GCC source
revision cb6e6d5faa3f817435b6f203226fa5969d7a7264).
~/build/gcc> ~/src/gcc/configure --prefix=/home/mscastanho/usr
--with-long-double-128 --with-long-double-format=ieee
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu --enable-languages=c++ --with-glibc-version=2.33
--disable-bootstrap CC=gcc-11 CXX=g++-11
~/build/gcc> make && make install
~/build/gcc> /home/mscastanho/usr/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/mscastanho/usr/bin/g++
COLLECT_LTO_WRAPPER=/home/mscastanho/usr/libexec/gcc/powerpc64le-linux-gnu/12.0.0/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: /home/mscastanho/src/gcc/configure
--prefix=/home/mscastanho/usr --with-long-double-128
--with-long-double-format=ieee --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
--enable-languages=c++ --with-glibc-version=2.33 --disable-bootstrap CC=gcc-11
CXX=g++-11
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210604 (experimental) (GCC)
- Build and run simple test program with the new compiler and libstdc++
~/build/gcc> cat ~/test-ieee128.cpp
#include
using namespace std;
int main () {
long double n = 1.0L;
cout << n << endl;
return 0;
}
~/build/gcc> /home/mscastanho/usr/bin/g++ -g ~/test-ieee128.cpp -o test-shared
~/build/gcc> LD_PRELOAD=~/usr/lib64/libstdc++.so.6 ./test-shared
6.95326e-310
Here I'd expect "1" to be printed.
If the same program is statically linked to libstdc++, it works as expected:
mscastanho@yanny4:~/build/gcc> /home/mscastanho/usr/bin/g++ -g
-static-libstdc++ ~/test-ieee128.cpp -o test-static
mscastanho@yanny4:~/build/gcc> ./test-static
1
After running the two programs side-by-side under gdb, I found out they are
actually calling two different symbols for vsnprintf on std::__convert_from_v.
Dynamically linked binary:
>>> disas _ZSt16__convert_from_vRKP15__locale_structPciPKcz
Dump of assembler code for function
_ZSt16__convert_from_vRKP15__locale_structPciPKcz:
0x77d19340 <+0>: addis r2,r12,37
0x77d19344 <+4>: addir2,r2,-14912
=> 0x77d19348 <+8>: mflrr0
0x77d1934c <+12>:std r29,-24(r1)
0x77d19350 <+16>:std r30,-16(r1)
0x77d19354 <+20>:mr r29,r6
0x77d19358 <+24>:std r31,-8(r1)
0x77d1935c <+28>:mr r30,r5
0x77d19360 <+32>:mr r31,r4
0x77d19364 <+36>:std r0,16(r1)
0x77d19368 <+40>:stdur1,-64(r1)
0x77d1936c <+44>:std r7,128(r1)
0x77d19370 <+48>:std r8,136(r1)
0x77d19374 <+52>:std r10,152(r1)
0x77d19378 <+56>:std r9,144(r1)
0x77d1937c <+60>:ld r3,0(r3)
0x77d19380 <+64>:bl 0x77d09b60
<06bf.plt_call.__uselocale@@GLIBC_2.17>
0x77d19384 <+68>:ld r2,24(r1)
0x77d19388 <+72>:mr r5,r29
0x77d1938c <+76>:mr r4,r30
0x77d19390 <+80>:addir6,r1,128
0x77d19394 <+84>:mr r9,r3
0x77d19398 <+88>:mr r3,r31
0x77d1939c <+92>:mr r30,r9
0x77d193a0 <+96>:bl 0x77d112a0
<06bf.plt_call.vsnprintf@@GLIBC_2.17><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
0x77d193a4 <+100>: ld r2,24(r1)
0x77d193a8 <+104>: mr r31,r3
0x77d193ac <+108>: mr r3,r30
0x77d193b0 <+112>: bl 0x77d09b60
<06bf.plt_call.__uselocale@@GLIBC_2.17>
0x77d193b4 <+116>: ld r2,24(r1)
0x77d193b8 <+120>: addir1,r1,64
0x77d193bc <+124>: mr r3,r31
0x77d193c0 <+128>: ld r0,16(r1)
0x77d193c4 <+132>: ld r29,-24(r1)
0x77d193c8 <+136>: ld r30,-16(r1)
0x77d193cc <+1
[Bug d/100882] ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:dcc5cf980af747941b32fd16c1d6a07177a1a404 commit r10-9891-gdcc5cf980af747941b32fd16c1d6a07177a1a404 Author: Iain Buclaw Date: Fri Jun 4 19:38:26 2021 +0200 d: Fix ICE in gimplify_var_or_parm_decl, at gimplify.c:2755 (PR100882) Constructor calls for temporaries were reusing the TARGET_EXPR_SLOT of a TARGET_EXPR for an assignment, which later got passed to `build_assign', which stripped away the outer TARGET_EXPR, leaving a reference to a lone temporary with no declaration. This stripping away of the TARGET_EXPR also discarded any cleanups that may have been assigned to the expression as well. So now the reuse of TARGET_EXPR_SLOT has been removed, and `build_assign' now constructs assignments inside the TARGET_EXPR_INITIAL slot. This has also been extended to `return_expr', to deal with possibility of a TARGET_EXPR being returned. gcc/d/ChangeLog: PR d/100882 * d-codegen.cc (build_assign): Construct initializations inside TARGET_EXPR_INITIAL. (compound_expr): Remove intermediate expressions that have no side-effects. (return_expr): Construct returns inside TARGET_EXPR_INITIAL. * expr.cc (ExprVisitor::visit (CallExp *)): Remove useless assignment to TARGET_EXPR_SLOT. gcc/testsuite/ChangeLog: PR d/100882 * gdc.dg/pr100882a.d: New test. * gdc.dg/pr100882b.d: New test. * gdc.dg/pr100882c.d: New test. * gdc.dg/pr100882d.d: New test. (cherry picked from commit e8761d4c21b5f4cc1c5612be9bf952a07c8a2238)
[Bug d/100882] ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:83f932f23cae74344ec9e67c76faf2f014857992 commit r11-8512-g83f932f23cae74344ec9e67c76faf2f014857992 Author: Iain Buclaw Date: Fri Jun 4 19:38:26 2021 +0200 d: Fix ICE in gimplify_var_or_parm_decl, at gimplify.c:2755 (PR100882) Constructor calls for temporaries were reusing the TARGET_EXPR_SLOT of a TARGET_EXPR for an assignment, which later got passed to `build_assign', which stripped away the outer TARGET_EXPR, leaving a reference to a lone temporary with no declaration. This stripping away of the TARGET_EXPR also discarded any cleanups that may have been assigned to the expression as well. So now the reuse of TARGET_EXPR_SLOT has been removed, and `build_assign' now constructs assignments inside the TARGET_EXPR_INITIAL slot. This has also been extended to `return_expr', to deal with possibility of a TARGET_EXPR being returned. gcc/d/ChangeLog: PR d/100882 * d-codegen.cc (build_assign): Construct initializations inside TARGET_EXPR_INITIAL. (compound_expr): Remove intermediate expressions that have no side-effects. (return_expr): Construct returns inside TARGET_EXPR_INITIAL. * expr.cc (ExprVisitor::visit (CallExp *)): Remove useless assignment to TARGET_EXPR_SLOT. gcc/testsuite/ChangeLog: PR d/100882 * gdc.dg/pr100882a.d: New test. * gdc.dg/pr100882b.d: New test. * gdc.dg/pr100882c.d: New test. * gdc.dg/torture/pr100882.d: New test. (cherry picked from commit e8761d4c21b5f4cc1c5612be9bf952a07c8a2238)
[Bug d/100882] ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:df3fbd5957f12927a459a2686f4eee55f66ec2f4 commit r12-1225-gdf3fbd5957f12927a459a2686f4eee55f66ec2f4 Author: Iain Buclaw Date: Fri Jun 4 19:38:26 2021 +0200 d: Fix ICE in gimplify_var_or_parm_decl, at gimplify.c:2755 (PR100882) Constructor calls for temporaries were reusing the TARGET_EXPR_SLOT of a TARGET_EXPR for an assignment, which later got passed to `build_assign', which stripped away the outer TARGET_EXPR, leaving a reference to a lone temporary with no declaration. This stripping away of the TARGET_EXPR also discarded any cleanups that may have been assigned to the expression as well. So now the reuse of TARGET_EXPR_SLOT has been removed, and `build_assign' now constructs assignments inside the TARGET_EXPR_INITIAL slot. This has also been extended to `return_expr', to deal with possibility of a TARGET_EXPR being returned. gcc/d/ChangeLog: PR d/100882 * d-codegen.cc (build_assign): Construct initializations inside TARGET_EXPR_INITIAL. (compound_expr): Remove intermediate expressions that have no side-effects. (return_expr): Construct returns inside TARGET_EXPR_INITIAL. * expr.cc (ExprVisitor::visit (CallExp *)): Remove useless assignment to TARGET_EXPR_SLOT. gcc/testsuite/ChangeLog: PR d/100882 * gdc.dg/pr100882a.d: New test. * gdc.dg/pr100882b.d: New test. * gdc.dg/pr100882c.d: New test. * gdc.dg/torture/pr100882.d: New test.
[Bug fortran/100911] Bind(c): failure handling C_PTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100911 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 50938 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50938=edit C code for bind(c)
[Bug fortran/100911] New: Bind(c): failure handling C_PTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100911 Bug ID: 100911 Summary: Bind(c): failure handling C_PTR Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50937 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50937=edit Fortran code showing problem Hi All! Wrong type and kind and crash due to division by zero (elem_len==0) Seen on: GNU Fortran (GCC) 10.3.1 20210526 GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210529 (experimental) Thank you very much. Best regards, José Rui
[Bug target/100909] [12 Regression] powerpc64le: Regression causing unexpected error with IBM long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100909
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
CC||bergner at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||segher at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-04
--- Comment #1 from Peter Bergner ---
Confirmed. creduce on the attached test case gives me:
bergner@pike:~/gcc/BUGS/PR100909$ cat pr100909.i
void __attribute__((__optimize__("O2"))) a() { }
bergner@pike:~/gcc/BUGS/PR100909$
/home/bergner/gcc/build/gcc-fsf-mainline-pr100799-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr100799-debug/gcc -S
-mlong-double-128 -mabi=ibmlongdouble pr100909.i
pr100909.i:1:1: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’
1 | void __attribute__((__optimize__("O2"))) a() { }
| ^~~~
pr100909.i: In function ‘a’:
pr100909.i:1:1: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’
pr100909.i:1:1: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’
pr100909.i:1:42: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’
1 | void __attribute__((__optimize__("O2"))) a() { }
| ^
pr100909.i:1:42: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’
[Bug fortran/100910] Bind(c): errors handling long double complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 50936 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50936=edit C code for bind(c)
[Bug fortran/100910] New: Bind(c): errors handling long double complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910 Bug ID: 100910 Summary: Bind(c): errors handling long double complex Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50935 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50935=edit Fortran code showing problem Hi All! Errors handling kind due to kind not being realted to elem_len. Seen on: GNU Fortran (GCC) 10.3.1 20210526 GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210529 (experimental) Thank you very much. Best regards. José Rui
[Bug middle-end/100908] asan clobberes register asm variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100908 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- (In reply to Andreas Krebbel from comment #1) > https://gcc.gnu.org/pipermail/gcc/2021-June/236269.html Yes this will help solve the limitations which are already mentioned in the manual: Warning: In the above example, be aware that a register (for example r0) can be call-clobbered by subsequent code, including function calls and library calls for arithmetic operators on other variables (for example the initialization of p2). In this case, use temporary variables for expressions between the register assignments:
[Bug fortran/99839] [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and committed on 11-, 10- and 9-branch. Closing. Thanks for the report!
[Bug fortran/99839] [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e912880888f9529eb44e3456c4753fc556c63812 commit r9-9568-ge912880888f9529eb44e3456c4753fc556c63812 Author: Harald Anlauf Date: Fri Jun 4 19:23:48 2021 +0200 Fortran - ICE in inline_matmul_assign Restrict inlining of matmul to those cases where assignment to the result array does not need special treatment. gcc/fortran/ChangeLog: PR fortran/99839 * frontend-passes.c (inline_matmul_assign): Do not inline matmul if the assignment to the resulting array if it is not of canonical type (real/integer/complex/logical). gcc/testsuite/ChangeLog: PR fortran/99839 * gfortran.dg/inline_matmul_25.f90: New test. (cherry picked from commit bee8619ad0ac3bd27b7c8dc5819b83a5e8e147a0)
[Bug middle-end/100908] asan clobberes register asm variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100908 --- Comment #1 from Andreas Krebbel --- https://gcc.gnu.org/pipermail/gcc/2021-June/236269.html
[Bug c/100909] New: powerpc64le: Regression causing unexpected error with IBM long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100909 Bug ID: 100909 Summary: powerpc64le: Regression causing unexpected error with IBM long double Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tuliom at ascii dot art.br Target Milestone: --- Created attachment 50934 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50934=edit Pre-processed s_modff128-ifunc.c file from glibc I've recently started seeing this regression while building glibc on powerpc64le: gcc -m64 test.i -c -mlong-double-128 -mabi=ibmlongdouble /home/tuliom/tmp/at-build-tray/at15.0-0-alpha.suse-15_ppc64le_ppc64le/builds/glibc_1-64/math/s_modff128-ifunc.c:8:1: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’ 8 | DECL_ALIAS_s_modf (modf); | ^~ Notice that both parameters are being passed to GCC. I've bisected this issue to: commit ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e Author: Martin Liska Date: Wed Mar 10 15:12:31 2021 +0100 Improve global state for options. gcc/c-family/ChangeLog: PR tree-optimization/92860 PR target/99592 * c-attribs.c (handle_optimize_attribute): Save target node before calling parse_optimize_options and save it in case it changes. * c-pragma.c (handle_pragma_target): Similarly for pragma. (handle_pragma_pop_options): Likewise here. gcc/ChangeLog: PR tree-optimization/92860 PR target/99592 * optc-save-gen.awk: Remove exceptions. I can still reproduce it with commit ee9548b36a7f.
[Bug c++/100893] Template argument conversion fails for dependant constant function pointer template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100893 Patrick Palka changed: What|Removed |Added Keywords||rejects-valid Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed for GCC 12, thanks for the bug report!
[Bug c++/100893] Template argument conversion fails for dependant constant function pointer template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100893 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6f8c9691495ad5a307db98dc19c3296ee4e6de64 commit r12-1224-g6f8c9691495ad5a307db98dc19c3296ee4e6de64 Author: Patrick Palka Date: Fri Jun 4 14:08:26 2021 -0400 c++: top-level cv-quals on type of NTTP [PR100893] Here, we're rejecting the specialization of g with T=A, F= in param4.C below due to a spurious constness mismatch between the type of the template argument and the substituted type of the parm F (the latter has a top-level const). Note that this mismatch doesn't occur with object pointers because in that case a call to perform_qualification_conversions from convert_nontype_argument implicitly adds a top-level const to the argument (via a cast) to match. This however seems to be a manifestation of a more general conformance issue: we're not dropping top-level cv-quals on the substituted type of an NTTP as per [temp.param]/6 (we only do so at parse time in process_template_parm). So this patch makes convert_template_argument drop top-level cv-quals accordingly. PR c++/100893 gcc/cp/ChangeLog: * pt.c (convert_template_argument): Strip top-level cv-quals on the substituted type of a non-type template parameter. gcc/testsuite/ChangeLog: * g++.dg/template/param4.C: New test. * g++.dg/template/param5.C: New test. * g++.dg/cpp1z/nontype-auto19.C: New test. * g++.dg/cpp2a/concepts-decltype.C: Don't expect that the deduced type of a decltype(auto) NTTP has top-level cv-quals.
[Bug middle-end/100593] [ELF] -fno-pic: Use GOT to take address of an external default visibility function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593 --- Comment #11 from Fangrui Song --- (In reply to Alexander Monakov from comment #10) > Is there something wrong or undesirable with making this under -fno-plt (or > the noplt attribute as in your example)? > > (after all, it is a kind of PLT-avoidance transformation, just for > addressing rather than direct calling/jumping) -fno-plt is generally undesired due to longer branch instructions and performance lost when the branch target is defined in the exe/so when the linker is gold/ld.lld (they cannot optimize jmp *got to jmp target) For non-x86, -fno-plt doesn't exist at all. If implemented, there requires many more instructions which are certainly undesirable. So -fno-plt can never be a default. Using GOT to take the address of an external function in -fno-pic is just a better default. I want the behavior to become the behavior, so it should not be under -fno-plt.
[Bug c/100618] Add a -fno-semantic-interposition variant which allows variable interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100618 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Fangrui Song --- Clang 13 -fno-semantic-interposition will be mostly consistent with GCC -fno-semantic-interposition. It looked like a misunderstand from my side.
[Bug middle-end/100908] New: asan clobberes register asm variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100908 Bug ID: 100908 Summary: asan clobberes register asm variables Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Target Milestone: --- Created attachment 50933 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50933=edit Testcase Compiling the testcase with either: gcc -O3 t1.c -o t -fsanitize=address --param asan-instrumentation-with-call-threshold=0 or gcc -O3 t1.c -o t -fsanitize=kernel-address -lasan aborts because dereferencing y triggers the address sanitizer to introduce a function call. That a function call might clobber registers assigned with register asm is a documented limitation of the register asm construct: https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html However, in combination with the address sanitizer this becomes even less obvious making even the most experienced kernel developers trip over it: https://lkml.org/lkml/2020/10/23/908 For IBM Z quite a few cases like this have been reported to me. Here just one I could find quickly: https://lore.kernel.org/patchwork/patch/1413907/ Btw. clang appears to handle this more gracefully and preserves the value of the variable around function calls. The attached testcase works fine with clang. I think it would be much better to find a solution which allows to directly name hard registers as inline assembly constraints. I'll post an RFC on the mailing list.
[Bug fortran/99839] [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:df45c5b83447a06e6b15c729807a17409c39ddff commit r10-9890-gdf45c5b83447a06e6b15c729807a17409c39ddff Author: Harald Anlauf Date: Fri Jun 4 19:23:48 2021 +0200 Fortran - ICE in inline_matmul_assign Restrict inlining of matmul to those cases where assignment to the result array does not need special treatment. gcc/fortran/ChangeLog: PR fortran/99839 * frontend-passes.c (inline_matmul_assign): Do not inline matmul if the assignment to the resulting array if it is not of canonical type (real/integer/complex/logical). gcc/testsuite/ChangeLog: PR fortran/99839 * gfortran.dg/inline_matmul_25.f90: New test. (cherry picked from commit bee8619ad0ac3bd27b7c8dc5819b83a5e8e147a0)
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 50932 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50932=edit C code for bind(c)
[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
--- Comment #20 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:5357ab75dedef403b0eebf9277d61d1cbeb5898f
commit r12-1223-g5357ab75dedef403b0eebf9277d61d1cbeb5898f
Author: Patrick Palka
Date: Fri Jun 4 13:46:53 2021 -0400
c++: tsubst_function_decl and excess arg levels [PR100102]
Here, when instantiating the dependent alias template
duration::__is_harmonic with args={{T,U},{int}}, we find ourselves
substituting the function decl _S_gcd. Since we have more arg levels
than _S_gcd has parm levels, an old special case in tsubst_function_decl
causes us to unwantedly reduce args to its innermost level, yielding
args={int}, which leads to a nonsensical substitution into the decl
context and eventually a crash.
The comment for this special case refers to three examples for which we
ought to see more arg levels than parm levels here, but none of the
examples actually demonstrate this. In the first example, when
defining S::f(U) parms_depth is 2 and args_depth is 1, and
later when instantiating say S::f both depths are 2. In the
second example, when substituting the template friend declaration
parms_depth is 2 and args_depth is 1, and later when instantiating f
both depths are 1. Finally, the third example is invalid since we can't
specialize a member template of an unspecialized class template like
that.
Given that this reduction code seems no longer relevant for its
documented purpose and that it causes problems as in the PR, this patch
just removes it. Note that as far as bootstrap/regtest is concerned,
this code is dead; the below two tests would be the first to reach it.
PR c++/100102
gcc/cp/ChangeLog:
* pt.c (tsubst_function_decl): Remove old code for reducing
args when it has excess levels.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alias-decl-72.C: New test.
* g++.dg/cpp0x/alias-decl-72a.C: New test.
[Bug fortran/100907] New: Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 Bug ID: 100907 Summary: Bind(c): failure handling wide character Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50931 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50931=edit Fortran code showing problem Hi All! Fails in too many different ways... Should work at least as CFI_type_other... Seen on: GNU Fortran (GCC) 10.3.1 20210526 (ICE) GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210529 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/100906] Bind(c): failure handling character with len/=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 50930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50930=edit C code for bind(c)
[Bug fortran/99839] [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2fdca7cfda7d49f3b252e79acc5933d764e7b77d commit r11-8511-g2fdca7cfda7d49f3b252e79acc5933d764e7b77d Author: Harald Anlauf Date: Fri Jun 4 19:23:48 2021 +0200 Fortran - ICE in inline_matmul_assign Restrict inlining of matmul to those cases where assignment to the result array does not need special treatment. gcc/fortran/ChangeLog: PR fortran/99839 * frontend-passes.c (inline_matmul_assign): Do not inline matmul if the assignment to the resulting array if it is not of canonical type (real/integer/complex/logical). gcc/testsuite/ChangeLog: PR fortran/99839 * gfortran.dg/inline_matmul_25.f90: New test. (cherry picked from commit bee8619ad0ac3bd27b7c8dc5819b83a5e8e147a0)
[Bug fortran/100906] New: Bind(c): failure handling character with len/=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906 Bug ID: 100906 Summary: Bind(c): failure handling character with len/=1 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50929 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50929=edit Fortran code showing problem Hi All! Failures (mostly mixing kind with len) on handling character with length greater than 1. Seen on: GNU Fortran (GCC) 10.3.1 20210526 (ICE) GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210529 (experimental) Thank you very much. Best regards, José Rui
[Bug c/100783] [10/11 Regression] ICE on attribute nonnull and erroneous type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100783 Martin Sebor changed: What|Removed |Added Known to fail|12.0| Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE on |on attribute nonnull and|attribute nonnull and |erroneous type |erroneous type --- Comment #5 from Martin Sebor --- Fixed in GCC 12.
[Bug fortran/99839] [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bee8619ad0ac3bd27b7c8dc5819b83a5e8e147a0 commit r12-1222-gbee8619ad0ac3bd27b7c8dc5819b83a5e8e147a0 Author: Harald Anlauf Date: Fri Jun 4 19:23:48 2021 +0200 Fortran - ICE in inline_matmul_assign Restrict inlining of matmul to those cases where assignment to the result array does not need special treatment. gcc/fortran/ChangeLog: PR fortran/99839 * frontend-passes.c (inline_matmul_assign): Do not inline matmul if the assignment to the resulting array if it is not of canonical type (real/integer/complex/logical). gcc/testsuite/ChangeLog: PR fortran/99839 * gfortran.dg/inline_matmul_25.f90: New test.
[Bug c/100783] [10/11/12 Regression] ICE on attribute nonnull and erroneous type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100783 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:5328cad24f7460a39b2def12bb9b62be36c92a54 commit r12-1221-g5328cad24f7460a39b2def12bb9b62be36c92a54 Author: Martin Sebor Date: Fri Jun 4 11:21:51 2021 -0600 PR c/100783 - ICE on -Wnonnull and erroneous type gcc/c-family/ChangeLog: PR c/100783 * c-attribs.c (positional_argument): Bail on erroneous types. gcc/c/ChangeLog: PR c/100783 * c-objc-common.c (print_type): Handle erroneous types. gcc/testsuite/ChangeLog: PR c/100783 * gcc.dg/nonnull-6.c: New test.
[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-04
[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 --- Comment #5 from Jonathan Wakely --- (In reply to M Welinder from comment #2) > I think the current magic-pointer code could be improved with something like > > template>> > bool operator< (..., T) = delete; Or another constructor for the __cmp_cat::__unspec type. I did try that at one point. The current code was the least bad solution of several that I tried. I didn't notice the -Wzero-as-null-pointer-constant warning because it's not enabled by default (because it's about coding style, not correctness).
[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 Jonathan Wakely changed: What|Removed |Added CC||headch at gmail dot com --- Comment #4 from Jonathan Wakely --- *** Bug 99778 has been marked as a duplicate of this bug. ***
[Bug c++/99778] Spurious -Wzero-as-null-pointer-constant on three-way comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99778 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- I'm closing this as a dup of the newer PR 100903 because that has more discussion. *** This bug has been marked as a duplicate of bug 100903 ***
[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 --- Comment #3 from Jonathan Wakely --- This is a dup of PR 99778
[Bug middle-end/100905] [OpenMP] ICE in convert_nonlocal_omp_clauses, at tree-nested.c:1514 with 'omp loop' in Fortran internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100905 --- Comment #1 from Tobias Burnus --- Tendative patch: --- a/gcc/tree-nested.c +++ b/gcc/tree-nested.c @@ -1484,6 +1484,7 @@ convert_nonlocal_omp_clauses (tree *pclauses, struct walk_stmt_info *wi) case OMP_CLAUSE_AUTO: case OMP_CLAUSE_IF_PRESENT: case OMP_CLAUSE_FINALIZE: + case OMP_CLAUSE_BIND: case OMP_CLAUSE__CONDTEMP_: case OMP_CLAUSE__SCANTEMP_: break;
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824
--- Comment #3 from 康桓瑋 ---
Another trivial issue is that LWG 3403 is not implemented and the
ranges::data is missing the decay-copy part, making it unable to work with
the following type.
struct A { int*&& data(); };
[Bug tree-optimization/100732] [11 Regression] ICE on sprintf %s with integer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100732 Martin Sebor changed: What|Removed |Added Summary|[11/12 Regression] ICE with |[11 Regression] ICE on |-Wall: in |sprintf %s with integer |ao_ref_init_from_ptr_and_ra |argument |nge, at | |tree-ssa-alias.c:824 since | |r11-959-gb825a22890740f34 | Known to fail|12.0| --- Comment #5 from Martin Sebor --- Fixed in GCC 12.0.
[Bug tree-optimization/100732] [11/12 Regression] ICE with -Wall: in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.c:824 since r11-959-gb825a22890740f34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100732 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:9816f509db4966fcb90ed3baab72cc6cd901f06c commit r12-1219-g9816f509db4966fcb90ed3baab72cc6cd901f06c Author: Martin Sebor Date: Fri Jun 4 10:49:06 2021 -0600 PR middle-end/100732 - ICE on sprintf %s with integer argument gcc/ChangeLog: PR middle-end/100732 * gimple-fold.c (gimple_fold_builtin_sprintf): Avoid folding calls with either source or destination argument of invalid type. * tree-ssa-uninit.c (maybe_warn_pass_by_reference): Avoid checking calls with arguments of invalid type. gcc/testsuite/ChangeLog: PR middle-end/100732 * gcc.dg/tree-ssa/builtin-snprintf-11.c: New test. * gcc.dg/tree-ssa/builtin-snprintf-12.c: New test. * gcc.dg/tree-ssa/builtin-sprintf-28.c: New test. * gcc.dg/tree-ssa/builtin-sprintf-29.c: New test. * gcc.dg/uninit-pr100732.c: New test.
[Bug middle-end/100905] New: [OpenMP] ICE in convert_nonlocal_omp_clauses, at tree-nested.c:1514 with 'omp loop' in Fortran internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100905 Bug ID: 100905 Summary: [OpenMP] ICE in convert_nonlocal_omp_clauses, at tree-nested.c:1514 with 'omp loop' in Fortran internal procedure Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Created attachment 50928 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50928=edit foo.f90 Long version of the testcase: https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/loop/test_loop_order_concurrent.F90 The following testcase works when the '!$omp loop' is in the main program or a separate (module) procedure – but it ICEs when it is an internal procedure: # gfortran foo.f90 -fopenmp internal compiler error: in convert_nonlocal_omp_clauses, at tree-nested.c:1514 0x7118d7 convert_nonlocal_omp_clauses ../../repos/gcc-trunk-commit/gcc/tree-nested.c:1514 0xf455ed convert_nonlocal_reference_stmt ../../repos/gcc-trunk-commit/gcc/tree-nested.c:1708
[Bug c/100719] missing -Wvla-parameter on a mismatch in second parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100719 Martin Sebor changed: What|Removed |Added Known to fail|12.0| --- Comment #3 from Martin Sebor --- Fixed in GCC 12.
[Bug c/100719] missing -Wvla-parameter on a mismatch in second parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100719 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:c6503fa93b5565c922f76611a55b0a53cd940a5f commit r12-1218-gc6503fa93b5565c922f76611a55b0a53cd940a5f Author: Martin Sebor Date: Fri Jun 4 10:35:27 2021 -0600 PR c/100719 - missing -Wvla-parameter on a mismatch in second parameter gcc/ChangeLog: * attribs.c (init_attr_rdwr_indices): Use VLA bounds in the expected order. (attr_access::vla_bounds): Also handle VLA bounds. gcc/c-family/ChangeLog: * c-warn.c (warn_parm_array_mismatch): Check TREE_PURPOSE to test for element presence. gcc/testsuite/ChangeLog: * gcc.dg/Wvla-parameter-10.c: New test. * gcc.dg/Wvla-parameter-11.c: New test.
[Bug libgcc/100904] New: [9/10/11 Regression] Wrong line location #include error "No such file or directory" – line + 1 [traditional mode as used by gfortran]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100904 Bug ID: 100904 Summary: [9/10/11 Regression] Wrong line location #include error "No such file or directory" – line + 1 [traditional mode as used by gfortran] Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Working: GCC 6 Failing since: GCC 7 * * * echo '#include "nonExisting.h"' > file.c echo '#include "nonExisting.h"' > file.F90 will give the wrong error location with: gfortran file.F90 or gcc -traditional-cpp file.c Namely: file.c:2:2: fatal error: nonExisting.h: No such file or directory Expected: Some line location in line 1. For instance, GCC 6 shows: file.c:1:0: fatal error: nonExisting.h: No such file or directory #include "nonexisting.h" * * * NOTE: gfortran only supports the traditional mode (as Fortran syntax and C syntax does not mix well without additional cpp tweaking). In C/C++, it works in non-traditional mode.
[Bug tree-optimization/100778] [11/12 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 --- Comment #7 from Gabrielle Hugo --- Dear Richard, Thanks a lot for confirming the bug, and for posting similar issue bugfix. Will be interesting to understand why SLP vectorization is still too aggressive. Gabrielle
[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 --- Comment #2 from M Welinder --- IMHO, nullptr_t would not be an improvement here. We would still have the combination of: (1) Correct usage causing a warning (2) The warning hinting at using the incorrect nullptr instead. (3) po>> bool operator< (..., T) = delete; This would at least take care of (3). (Template magic applied to resolve the ambiguity of what to do with literal 0. There might be a better way.)
[Bug libstdc++/100889] Wrong param type for std::atomic_ref<_Tp*>::wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889 Thomas Rodgers changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/100637] [i386] Vectorize 4-byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637 --- Comment #9 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:8d7dae0eb366a88a1baba1857ecc54c09e4a520e commit r12-1215-g8d7dae0eb366a88a1baba1857ecc54c09e4a520e Author: Uros Bizjak Date: Fri Jun 4 17:37:15 2021 +0200 i386: Add init pattern for V2HI vectors [PR100637] 2021-06-03 Uroš Bizjak gcc/ PR target/100637 * config/i386/i386-expand.c (ix86_expand_vector_init_duplicate): Handle V2HI mode. (ix86_expand_vector_init_general): Ditto. Use SImode instead of word_mode for logic operations when GET_MODE_SIZE (mode) < UNITS_PER_WORD. (expand_vec_perm_even_odd_1): Assert that V2HI mode should be implemented by expand_vec_perm_1. (expand_vec_perm_broadcast_1): Assert that V2HI and V4HI modes should be implemented using standard shuffle patterns. (ix86_vectorize_vec_perm_const): Handle V2HImode. Add V4HI and V2HI modes to modes, implementable with shuffle for one operand. * config/i386/mmx.md (*punpckwd): New insn_and_split pattern. (*pshufw_1): New insn pattern. (*vec_dupv2hi): Ditto. (vec_initv2hihi): New expander. gcc/testsuite/ PR target/100637 * gcc.dg/vect/slp-perm-9.c (dg-final): Adjust dumps for vect32 targets.
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ee9548b36a7f17e8a63585b58f340c93dcba95d8 commit r12-1214-gee9548b36a7f17e8a63585b58f340c93dcba95d8 Author: Jonathan Wakely Date: Fri Jun 4 15:59:38 2021 +0100 libstdc++: Fix value categories used by ranges access CPOs [PR 100824] The implementation of P2091R0 was incomplete, so that some range access CPOs used perfect forwarding where they should not. This fixes it by consistently operating on lvalues. Some additional changes that are not necessary to fix the bug: Modify the __as_const helper to simplify its usage. Instead of deducing the value category from its argument, and requiring callers to forward the argument as the correct category, add a non-deduced template parameter which is used for the value category and accept the argument as an lvalue. This means callers say __as_const(t) instead of __as_const(std::forward(t)). Always use an lvalue reference type as the template argument for the _S_noexcept helpers, so that we only instantiate one specialization for lvalues and rvalues of the same type. Move some helper concepts and functions from namespace std::__detail to ranges::__cust_access, to be consistent with the ranges::begin CPO. This ensures that the __adl_begin concept and the _Begin::operator() function are in the same namespace, so unqualified lookup is consistent and the poison pills for begin are visible to both. Simplified static assertions for arrays, because the expression a+0 is already ill-formed for an array of incomplete type. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100824 * include/bits/iterator_concepts.h (__detail::__decay_copy) (__detail::__member_begin, __detail::__adl_begin): Move to namespace ranges::__cust_access. (__detail::__ranges_begin): Likewise, and rename to __begin. Remove redundant static assertion. * include/bits/ranges_base.h (_Begin, _End, _RBegin, _REnd): Use lvalue in noexcept specifier. (__as_const): Add non-deduced parameter for value category. (_CBegin, _CEnd, _CRBegin, _CREnd, _CData): Adjust uses of __as_const. (__member_size, __adl_size, __member_empty, __size0_empty): (__eq_iter_empty, __adl_data): Use lvalue objects in requirements. (__sentinel_size): Likewise. Add check for conversion to unsigned-like. (__member_data): Allow non-lvalue types to satisfy the concept, but use lvalue object in requirements. (_Size, _SSize): Remove forwarding to always use an lvalue. (_Data): Likewise. Add static assertion for arrays. * testsuite/std/ranges/access/cdata.cc: Adjust expected behaviour for rvalues. Add negative tests for ill-formed expressions. * testsuite/std/ranges/access/data.cc: Likewise. * testsuite/std/ranges/access/empty.cc: Adjust expected behaviour for rvalues. * testsuite/std/ranges/access/size.cc: Likewise.
[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- http://eel.is/c++draft/cmp.categories.pre#example-1 lists nullptr_t as an example of a type that satisfies the requirements. GCC does not reject 0, just can emit a non-default warning about it if you enable that warning.
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757
--- Comment #10 from Christophe Lyon ---
The problem is in vec-common.md:
(define_expand "vcond_mask_"
[(set (match_operand:VDQWH 0 "s_register_operand")
(if_then_else:VDQWH
(match_operand: 3 "s_register_operand")
(match_operand:VDQWH 1 "s_register_operand")
(match_operand:VDQWH 2 "s_register_operand")))]
"ARM_HAVE__ARITH
&& !TARGET_REALLY_IWMMXT
&& (! || flag_unsafe_math_optimizations)"
{
if (TARGET_NEON)
{
emit_insn (gen_neon_vbsl (mode, operands[0], operands[3],
operands[1], operands[2]));
}
else if (TARGET_HAVE_MVE)
{
emit_insn (gen_mve_vpselq (VPSELQ_S, mode, operands[0],
operands[1], operands[2], operands[3]));
}
else
gcc_unreachable ();
DONE;
})
For MVE, we pass operands[3] to mve_vpselq, but it has the same vector mode as
the other operands while vpselq expects a 16-bit mask (HI mode) suitable for
VPR.P0
[Bug middle-end/100898] [9/10/11/12 Regression] ICE with -O2: in gimple_call_arg_ptr, at gimple.h:3264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100898 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 50927 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50927=edit gcc12-pr100898.patch Untested fix.
[Bug middle-end/100898] [9/10/11/12 Regression] ICE with -O2: in gimple_call_arg_ptr, at gimple.h:3264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100898 Jakub Jelinek changed: What|Removed |Added Summary|ICE with -O2: in|[9/10/11/12 Regression] ICE |gimple_call_arg_ptr, at |with -O2: in |gimple.h:3264 |gimple_call_arg_ptr, at ||gimple.h:3264 Keywords||ice-checking, ||ice-on-valid-code Component|c |middle-end CC||jakub at gcc dot gnu.org Version|tree-ssa|12.0 Last reconfirmed||2021-06-04 Ever confirmed|0 |1 Target Milestone|--- |9.5 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Started to ICE with most likely r0-88576-g726a989a8b74bf238a96029860bcf7ba14eff317
[Bug libstdc++/100903] New: Bogus "zero as null pointer constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903
Bug ID: 100903
Summary: Bogus "zero as null pointer constant" warning
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 50926
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50926=edit
Preprocesses source code
g++ emits a bogus warning when a std::partial_ordering value is compared
to a literal 0. See also bug 95242.
The standard is crazy-strict here. Anything other than a literal 0 is
undefined behaviour. Allowed: 0, 0LL, 0'0'0'0, 0x0. No good: +0, nullptr,
(void*)0, 0+0, '\0', (0,nullptr). gcc incorrectly allows nullptr and
(0,nullptr), but rejects the others.
The library tries to do that with a construct that mainly allows null pointer
constants. That leads to the warning when you actually supply the 0 you are
supposed to.
Suggestion: just use an int argument. That's wrong in different ways (and
might cause warnings with 0LL which is allowed), but it matches 0 better.
Doing this right is likely to require compiler support.
# cat uuu.C
#include
int
foo(std::partial_ordering po)
{
return po < 0;
}
# g++ -Wall -std=gnu++20 -Wzero-as-null-pointer-constant -c uuu.C
uuu.C: In function ‘int foo(std::partial_ordering)’:
uuu.C:6:15: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
6 | return po < 0;
| ^
# g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/11.1.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/11.1.0/lib/gcc/x86_64-suse-linux/11.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-11.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/11.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.36.1/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.36.1/bin/ld --enable-link-mutex
--enable-gnu-indirect-functions --enable-linux-futex --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new
x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.0 (GCC)
[Bug target/100820] [12 regression] bootstrap hangs during stage2 on power 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100820 seurer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from seurer at gcc dot gnu.org --- Fixed now
[Bug c/100902] pointer attachment issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100902 Jakub Jelinek changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||cltang at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- As mentioned on gcc-patches, it is also unclear if it will DTRT for dependent map clauses in templates.
