[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue

2021-06-04 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824

--- Comment #8 from Jonathan Wakely  ---
Doh yes, that's just a brain fart

[Bug rtl-optimization/88770] Redundant load opt. or CSE pessimizes code

2021-06-04 Thread peter at cordes dot ca via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88770

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #2 from Peter Cordes  ---
Note that mov r64, imm64 is a 10-byte instruction, and can be slow to read from
the uop-cache on Sandybridge-family.

The crap involving OR is clearly sub-optimal, but *if* you already have two
spare call-preserved registers across this call, the following is actually
smaller code-size:

movabs  rdi, 21474836483
mov rbp, rdi
movabs  rsi, 39743127552
mov rbx, rsi
calltest
mov rdi, rbp
mov rsi, rbx
calltest


This is more total uops for the back-end though (movabs is still single-uop,
but takes 2 entries the uop cache on Sandybridge-family;
https://agner.org/optimize/).  So saving x86 machine-code size this way does
limit the ability of out-of-order exec to see farther, if the front-end isn't
the bottleneck.  And it's highly unlikely to be worth saving/restoring two regs
to enable this.  (Or to push rdi / push rsi before call, then pop after!)

Setting up the wrong value and then fixing it twice with OR is obviously
terrible and never has any advantage, but the general idea to CSE large
constants isn't totally crazy.  (But it's profitable only in such limited cases
that it might not be worth looking for, especially if it's only helpful at -Os)

[Bug target/99293] Built-in vec_splat generates sub-optimal code for -mcpu=power10

2021-06-04 Thread meissner at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread meissner at gcc dot gnu.org via Gcc-bugs
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&action=edit
Proposed patch

[Bug inline-asm/100921] Inline assembly use of struct not counted as use for store elision

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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"(&v));

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

2021-06-04 Thread ethereal at ethv dot net via Gcc-bugs
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"(&v));
// 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(&v);
}

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

2021-06-04 Thread hewillk at gmail dot com via Gcc-bugs
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

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread msebor at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread george.thopas at gmail dot com via Gcc-bugs
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

2021-06-04 Thread msebor at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread msebor at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread msebor at gcc dot gnu.org via Gcc-bugs
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)

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread msebor at gcc dot gnu.org via Gcc-bugs
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++

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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.

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread ed.gcc at pobox dot com via Gcc-bugs
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

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread anlauf at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread ppalka at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread redi at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread ppalka at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread ppalka at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread burnus at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread ppalka at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread meissner at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread meissner at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=edit
C code for bind(c)

[Bug fortran/100917] New: Bind(c): errors handling long double real

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=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.

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=edit
C code for bind(c)

[Bug fortran/100916] New: Bind(c): CFI_type_other unimplemented.

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=edit
C code for bind(c)

[Bug fortran/100915] New: Bind(c): failure handling C_FUNPTR

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread redi at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=edit
C code for bind(c)

[Bug fortran/100914] New: Bind(c): errors handling complex

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=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 ?

2021-06-04 Thread dcb314 at hotmail dot com via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread ibuclaw at gdcproject dot org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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++

2021-06-04 Thread msc at linux dot ibm.com via Gcc-bugs
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 &

[Bug d/100882] ICE in gimplify_var_or_parm_decl, at gimplify.c:2755

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=edit
C code for bind(c)

[Bug fortran/100911] New: Bind(c): failure handling C_PTR

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread bergner at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=edit
C code for bind(c)

[Bug fortran/100910] New: Bind(c): errors handling long double complex

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread anlauf at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread krebbel at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread tuliom at ascii dot art.br via Gcc-bugs
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&action=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

2021-06-04 Thread ppalka at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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=&f in
param4.C below due to a spurious constness mismatch between the type of
the template argument &f 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

2021-06-04 Thread i at maskray dot me via Gcc-bugs
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

2021-06-04 Thread i at maskray dot me via Gcc-bugs
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

2021-06-04 Thread krebbel at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=edit
C code for bind(c)

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread jrfsousa at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread msebor at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread redi at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread redi at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread redi at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread redi at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread redi at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread burnus at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread hewillk at gmail dot com via Gcc-bugs
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

2021-06-04 Thread msebor at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread burnus at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread msebor at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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]

2021-06-04 Thread burnus at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread gabrielle.hugo at cern dot ch via Gcc-bugs
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

2021-06-04 Thread terra at gnome dot org via Gcc-bugs
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

2021-06-04 Thread rodgertq at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread jakub at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread clyon at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread jakub at gcc dot gnu.org via Gcc-bugs
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&action=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

2021-06-04 Thread jakub at gcc dot gnu.org via Gcc-bugs
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

2021-06-04 Thread terra at gnome dot org via Gcc-bugs
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&action=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)

  1   2   >