date:20230621

[Bug target/109973] [13/14 Regression] Wrong code for AVX2 since 13.1 by combining VPAND and VPTEST since r13-2006-ga56c1641e9d25e

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:5322f009e8f7d1c7a1c9aab7cb4c90c433398fdd

commit r14-2030-g5322f009e8f7d1c7a1c9aab7cb4c90c433398fdd
Author: Roger Sayle 
Date:   Thu Jun 22 07:43:07 2023 +0100

i386: Convert ptestz of pandn into ptestc.

This patch is the next installment in a set of backend patches around
improvements to ptest/vptest.  A previous patch optimized the sequence
t=pand(x,y); ptestz(t,t) into the equivalent ptestz(x,y), using the
property that ZF is set to (X&Y) == 0.  This patch performs a similar
transformation, converting t=pandn(x,y); ptestz(t,t) into the (almost)
equivalent ptestc(y,x), using the property that the CF flags is set to
(~X&Y) == 0.  The tricky bit is that this sets the CF flag instead of
the ZF flag, so we can only perform this transformation when we can
also convert the flags consumer, as well as the producer.

For the test case:

int foo (__m128i x, __m128i y)
{
  __m128i a = x & ~y;
  return __builtin_ia32_ptestz128 (a, a);
}

With -O2 -msse4.1 we previously generated:

foo:pandn   %xmm0, %xmm1
xorl%eax, %eax
ptest   %xmm1, %xmm1
sete%al
ret

with this patch we now generate:

foo:xorl%eax, %eax
ptest   %xmm0, %xmm1
setc%al
ret

At the same time, this patch also provides alternative fixes for
PR target/109973 and PR target/110118, by recognizing that ptestc(x,x)
always sets the carry flag (X&~X is always zero).  This is achieved
both by recognizing the special case in ix86_expand_sse_ptest and with
a splitter to convert an eligible ptest into an stc.

2023-06-22  Roger Sayle  
Uros Bizjak  

gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_sse_ptest): Recognize
expansion of ptestc with equal operands as producing const1_rtx.
* config/i386/i386.cc (ix86_rtx_costs): Provide accurate cost
estimates of UNSPEC_PTEST, where the ptest performs the PAND
or PAND of its operands.
* config/i386/sse.md (define_split): Transform CCCmode UNSPEC_PTEST
of reg_equal_p operands into an x86_stc instruction.
(define_split): Split pandn/ptestz/set{n?}e into ptestc/set{n?}c.
(define_split): Similar to above for strict_low_part destinations.
(define_split): Split pandn/ptestz/j{n?}e into ptestc/j{n?}c.

gcc/testsuite/ChangeLog
* gcc.target/i386/avx-vptest-4.c: New test case.
* gcc.target/i386/avx-vptest-5.c: Likewise.
* gcc.target/i386/avx-vptest-6.c: Likewise.
* gcc.target/i386/pr109973-1.c: Update test case.
* gcc.target/i386/pr109973-2.c: Likewise.
* gcc.target/i386/sse4_1-ptest-4.c: New test case.
* gcc.target/i386/sse4_1-ptest-5.c: Likewise.
* gcc.target/i386/sse4_1-ptest-6.c: Likewise.

[Bug target/110118] Miss CSE optimization for vptest after r14-1466-g3635e8c67e13e3da7e1e23a617dd9952218e93e0

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110118

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:5322f009e8f7d1c7a1c9aab7cb4c90c433398fdd

commit r14-2030-g5322f009e8f7d1c7a1c9aab7cb4c90c433398fdd
Author: Roger Sayle 
Date:   Thu Jun 22 07:43:07 2023 +0100

i386: Convert ptestz of pandn into ptestc.

This patch is the next installment in a set of backend patches around
improvements to ptest/vptest.  A previous patch optimized the sequence
t=pand(x,y); ptestz(t,t) into the equivalent ptestz(x,y), using the
property that ZF is set to (X&Y) == 0.  This patch performs a similar
transformation, converting t=pandn(x,y); ptestz(t,t) into the (almost)
equivalent ptestc(y,x), using the property that the CF flags is set to
(~X&Y) == 0.  The tricky bit is that this sets the CF flag instead of
the ZF flag, so we can only perform this transformation when we can
also convert the flags consumer, as well as the producer.

For the test case:

int foo (__m128i x, __m128i y)
{
  __m128i a = x & ~y;
  return __builtin_ia32_ptestz128 (a, a);
}

With -O2 -msse4.1 we previously generated:

foo:pandn   %xmm0, %xmm1
xorl%eax, %eax
ptest   %xmm1, %xmm1
sete%al
ret

with this patch we now generate:

foo:xorl%eax, %eax
ptest   %xmm0, %xmm1
setc%al
ret

At the same time, this patch also provides alternative fixes for
PR target/109973 and PR target/110118, by recognizing that ptestc(x,x)
always sets the carry flag (X&~X is always zero).  This is achieved
both by recognizing the special case in ix86_expand_sse_ptest and with
a splitter to convert an eligible ptest into an stc.

2023-06-22  Roger Sayle  
Uros Bizjak  

gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_sse_ptest): Recognize
expansion of ptestc with equal operands as producing const1_rtx.
* config/i386/i386.cc (ix86_rtx_costs): Provide accurate cost
estimates of UNSPEC_PTEST, where the ptest performs the PAND
or PAND of its operands.
* config/i386/sse.md (define_split): Transform CCCmode UNSPEC_PTEST
of reg_equal_p operands into an x86_stc instruction.
(define_split): Split pandn/ptestz/set{n?}e into ptestc/set{n?}c.
(define_split): Similar to above for strict_low_part destinations.
(define_split): Split pandn/ptestz/j{n?}e into ptestc/j{n?}c.

gcc/testsuite/ChangeLog
* gcc.target/i386/avx-vptest-4.c: New test case.
* gcc.target/i386/avx-vptest-5.c: Likewise.
* gcc.target/i386/avx-vptest-6.c: Likewise.
* gcc.target/i386/pr109973-1.c: Update test case.
* gcc.target/i386/pr109973-2.c: Likewise.
* gcc.target/i386/sse4_1-ptest-4.c: New test case.
* gcc.target/i386/sse4_1-ptest-5.c: Likewise.
* gcc.target/i386/sse4_1-ptest-6.c: Likewise.

[Bug tree-optimization/110332] [14 regression] ICE in dominated_by_p when building LLVM with -O3

2023-06-21 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110332

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #10 from Richard Biener  ---
Mine.

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

2023-06-21 Thread ctechnodev at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943

Alexander Westbrooks  changed:

   What|Removed |Added

 CC||ctechnodev at gmail dot com

--- Comment #11 from Alexander Westbrooks  ---
(In reply to vegard from comment #10)
> (In reply to kargl from comment #9)
> > (In reply to alig from comment #8)
> > > The problem still persists with GNU Fortran (GCC) 11.1.0.
> > 
> > The problem is likely to persist for the foreseeable future
> > as there is no one left to work on gfortran bugs.  Lacking 
> > a sudden influx of new volunteer contributors, it seems
> > the only way forward is to NOT use parameterized derived 
> > types with gfortran.
> 
> Any news here? I seem to be having this issue with gfortran (Homebrew GCC)
> 12.2.0
> 
> As a side note: I'm somewhat new to the fortran community, but could see
> myself contributing to gfortran in the future. Do you think you could point
> me to where I should read up on contributing?

Hello!

I'm new to the community as well. I have had the same issue with this bug and
first encountered it 5 years ago while working on my thesis. Two weeks ago I
decided to tackle this bug. I have found the issues in the code, and I was able
to successfully compiles the following example. I made sure that the LEN type
parameter condition was enforced as ja...@gcc.gnu.org stated in Comment #6 and
I used inheritance in this example to test the added logic to ensure that a PDT
instance belonged to a PDT template. 

The only things I have left to do is write applicable test cases (which I
haven't done before. I am learning how to use the DejaGNU framework as I work
on this) and obtain some guidance on how to get this code verified by others
and ultimately accepted as fixed code into the compiler. I am reading the
documentation of the GNU Fortran rules and I hope to get the test cases
completed and have the fix under review within the next couple of weeks.

module testmod

public :: foo

type, public :: tough_lvl_0(a, b)
integer, kind :: a = 1
integer, len :: b
contains
procedure :: foo
end type

type, public, EXTENDS(tough_lvl_0) :: tough_lvl_1 (c)
integer, len :: c
contains
procedure :: bar
end type

type, public, EXTENDS(tough_lvl_1) :: tough_lvl_2 (d)
integer, len :: d
contains
procedure :: foobar
end type

contains
subroutine foo(this)
class(tough_lvl_0(1,*)), intent(inout) :: this
end subroutine

subroutine bar(this)
class(tough_lvl_1(1,*,*)), intent(inout) :: this
end subroutine

subroutine foobar(this)
class(tough_lvl_2(1,*,*,*)), intent(inout) :: this
end subroutine

end module

PROGRAM testprogram
USE testmod

TYPE(tough_lvl_0(1,5)) :: test_pdt_0
TYPE(tough_lvl_1(1,5,6))   :: test_pdt_1
TYPE(tough_lvl_2(1,5,6,7)) :: test_pdt_2

CALL test_pdt_0%foo()

CALL test_pdt_1%foo()
CALL test_pdt_1%bar()

CALL test_pdt_2%foo()
CALL test_pdt_2%bar()
CALL test_pdt_2%foobar()


END PROGRAM testprogram

[Bug c++/110344] [C++26] P2738R1 - constexpr cast from void*

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c++/110342] [C++26] P2361R6 - Unevaluated strings

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110342

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-22
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/110332] [14 regression] ICE in dominated_by_p when building LLVM with -O3

2023-06-21 Thread slyfox at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110332

--- Comment #9 from Sergei Trofimovich  ---
(In reply to Andrew Pinski from comment #2)
> Either r14-1981 or r14-1951

Reverting r14-1981-g85107abeb71bbf restores llvm-12 build for me.

[Bug c++/110349] [C++26] P2169R4 - Placeholder variables with no name

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110349

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-22
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug analyzer/106626] Improvements to wording of -Wanalyzer-out-of-bounds

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106626

--- Comment #8 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:0e466e978c728697f18c67c4eace9ba4633f9ef5

commit r14-2029-g0e466e978c728697f18c67c4eace9ba4633f9ef5
Author: David Malcolm 
Date:   Wed Jun 21 21:49:00 2023 -0400

analyzer: add text-art visualizations of out-of-bounds accesses [PR106626]

This patch extends -Wanalyzer-out-of-bounds so that, where possible, it
will emit a text art diagram visualizing the spatial relationship between
(a) the memory region that the analyzer predicts would be accessed, versus
(b) the range of memory that is valid to access - whether they overlap,
are touching, are close or far apart; which one is before or after in
memory, the relative sizes involved, the direction of the access (read vs
write), and, in some cases, the values of data involved.  This diagram
can be suppressed using -fdiagnostics-text-art-charset=none.

For example, given:

int32_t arr[10];

int32_t int_arr_read_element_before_start_far(void)
{
  return arr[-100];
}

it emits:

demo-1.c: In function âint_arr_read_element_before_start_farâ:
demo-1.c:7:13: warning: buffer under-read [CWE-127]
[-Wanalyzer-out-of-bounds]
7 |   return arr[-100];
  |  ~~~^~
  âint_arr_read_element_before_start_farâ: event 1
|
|7 |   return arr[-100];
|  |  ~~~^~
|  | |
|  | (1) out-of-bounds read from byte -400 till byte
-397 but âarrâ starts at byte 0
|
demo-1.c:7:13: note: valid subscripts for âarrâ are â[0]â to
â[9]â

 
â
  âread of âint32_tâ (4 bytes)â
 
â
^
â
â
 
â

ââ¬â¬ââ
  â   â  â  [0]   â  ...   â 
 [9]   â
  âbefore valid range â 
ââ´â´ââ¤
  â   â  ââarrâ (type:
âint32_t[10]â)â
 
â

â
 
âââ¬ââ¤âââ¬âââ¤âââ¬ââ¤
ââ â
  
ââ´® 
 ââ´â®   
â´âââ®
   ââ ï¸  under-read of 4 bytesâ   â396 bytesââsize: 40
bytesâ
  
â°â¯ 
 â°ââ¯   
â°âââ¯

and given:

  #include 

  void
  test_non_ascii ()
  {
char buf[5];
strcpy (buf, "æååã");
  }

it emits:

demo-2.c: In function âtest_non_asciiâ:
demo-2.c:7:3: warning: stack-based buffer overflow [CWE-121]
[-Wanalyzer-out-of-bounds]
7 |   strcpy (buf, "æååã");
  |   ^~~~
  âtest_non_asciiâ: events 1-2
|
|6 |   char buf[5];
|  |^~~
|  ||
|  |(1) capacity: 5 bytes
|7 |   strcpy (buf, "æååã");
|  |   
|  |   |
|  |   (2) out-of-bounds write from byte 5 till byte 12 but
âbufâ ends at byte 5
|
demo-2.c:7:3: note: write of 8 bytes to beyond the end of âbufâ
7 |   strcpy (buf, "æååã");
  |   ^~~~
demo-2.c:7:3: note: valid subscripts for âbufâ are â[0]â to
â[4]â

 
âââ¬ââ¬ââ¬â¬âââ¬â¬â¬â¬â¬â¬â¬âââ
  â [0] â [1] â [2] â[3] â[4] ââ[5] â[6] â[7] â[8]
â[9] â[10]â[11]â [12] â
 
âââ¼ââ¼ââ¼â¼â¤ââ¼â¼â¼â¼â¼â¼â¼âââ¤
  â0xe6 â0x96 â0x87
â0xe5â0xadââ0x97â0xe5â0x8câ0x96â0xe3â0x81â0x91â 0x00 â
 
âââ´ââ´ââ¼â´â´â´â¼â´â´â¼â´â´â¼âââ¤
  â U+6587  âU+5b57 âU+5316âU+3051   
âU+â
 
âââ¼¼âââ¼âââ¼âââ¤
  â   æâ  å   â  å  â  ã   
  â NUL  â
 
âââ´´âââ´âââ´âââ¤
  â  string literal (type: âchar[13]â)   
   â
 

 â â âââ âââââ 
  ââ â
 â â âââ âââââ 
  ââ â
 v v vvv vvvvvvv v
 
âââ¬â¬
  â [0] â  ...   â[4] ââ 
   â
 
âââ´â´âââ

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #8 from Andrew Pinski  ---
(In reply to Jürgen Reuter from comment #7)
> The problem seems really connected to optimization, if I compile our code
> with -g -O0 or -g -O1, everything works ok. Next, I will try to check why it
> is actually failing (my guess, unconfirmed yet, is that some data structures
> are optimized away such that the program runs then on inconsistent data).
> Then I will check that specific commit. We are sure that it was introduced
> within this time frame, because we have a weekly CI that clones gcc, and
> then builds and runs our code and testsuite. That was working on the morning
> of June 12, but failed on the morning of June 19.

Do you know if -fno-tree-vectorizer causes the issue to go away?

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

2023-06-21 Thread segher at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002

--- Comment #9 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #4)
> These die because the struct we're using to check the alignment of uses long
> double as the "big" aligned type.  We could either disable the tests using a
> "dg-require-effective-target longdouble128" or we could use a different more
> aligned type in the struct.  Maybe _Float128 or _Decimal128 or use an
> attribute aligned?   Thoughts?

Maybe just some vector type?  Those have 128-bit alignment even with
-mno-altivec,
right?

> gcc.target/powerpc/pr85657-3.c
> gcc.target/powerpc/signbit-1.c
> pr85657-3.c:38:20: error: unknown type name ‘__ibm128’; did you mean
> ‘__int128’?
> 
> These die because we don't create the type __ibm128 when using
> -mlong-double-64, which seems strange since we do create the __float128 type
> used in the test cases.
> 
> Mike, I assume the __ibm128 type should always be created?

It always should, yes.  Always.  Unconditionally.

[Bug c++/110346] [C++26] P2752R3 - Static storage for braced initializers

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110346

--- Comment #2 from Marek Polacek  ---
Probably resolved by r14-1500-g4d935f52b0d5c0.

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252

--- Comment #6 from Andrew Pinski  ---
*** Bug 110337 has been marked as a duplicate of this bug. ***

[Bug c/110337] Wrong code at -O2/s on x86_64-linux-gnu

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110337

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup of bug 110252.
  if (i_9 >= 0)
goto ; [59.00%]
  else
goto ; [41.00%]
;;succ:   3 [59.0% (guessed)]  count:633507680 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;4 [41.0% (guessed)]  count:440234144 (estimated locally)
(FALSE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 0, count 633507681 (estimated locally)
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [59.0% (guessed)]  count:633507680 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  # RANGE [irange] int [0, 1] NONZERO 0x1
  iftmp.6_10 = i_9 >> 14;
;;succ:   4 [always]  count:633507681 (estimated locally)
(FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 1073741824 (estimated locally), maybe
hot
;;prev block 3, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [always]  count:633507681 (estimated locally)
(FALLTHRU,EXECUTABLE)
;;2 [41.0% (guessed)]  count:440234144 (estimated locally)
(FALSE_VALUE,EXECUTABLE)

i_9 >= 0 ? iftmp.6_10 : 1
Matching expression match.pd:1990, gimple-match-5.cc:23
Matching expression match.pd:1990, gimple-match-5.cc:23
Applying pattern match.pd:5283, gimple-match-4.cc:870
Applying pattern match.pd:1378, gimple-match-3.cc:7714
Applying pattern match.pd:1885, gimple-match-9.cc:1391
Applying pattern match.pd:4745, gimple-match-2.cc:16250
Folded into the sequence:
_4 = i_9 >= 0;
_2 = (int) _4;
_8 = i_9 < 0;
_13 = (int) _8;
_14 = iftmp.6_10 | _13;


The problem is i_9 >> 14 is only [0,1] iff inside the condition.

*** This bug has been marked as a duplicate of bug 110252 ***

[Bug c++/110341] [C++26] P1854R4 - Making non-encodable string literals ill-formed

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110341

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-21
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
It's possible/likely; I haven't actually read the paper yet.  We want to add
any possible testcases.  I should be able to address this by the end of next
week if nobody beats me to it.

[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-21

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c++/110346] [C++26] P2752R3 - Static storage for braced initializers

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110346

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110070,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105838,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110102

--- Comment #1 from Andrew Pinski  ---
`Add that this proposal is already DR’ed in GCC trunk.`

[Bug c++/110341] [C++26] P1854R4 - Making non-encodable string literals ill-formed

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110341

--- Comment #1 from Andrew Pinski  ---
I don't think there is anything to do for this paper:
`GCC exposes the same behavior(the one proposed by this paper) in all language
modes.`

[Bug middle-end/88873] missing vectorization for decomposed operations on a vector type

2023-06-21 Thread roger at nextmovesoftware dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88873

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #5 from Roger Sayle  ---
I have a patch (series) that improves some of the TImode parameter passing
issues with the ABI.  I'll check/investigate whether this fixes DFmode in the
same way that it improves DImode.  I worry that the (hi<<64)|lo idiom might not
be applicable for FP (without SUBREGs), but something similar (with vec_merge)
may resolve this issue during RTL expansion.

[Bug fortran/110360] ABI issue with character,value dummy argument

2023-06-21 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-06-21
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/110360] ABI issue with character,value dummy argument

2023-06-21 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #55380|0   |1
is obsolete||

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 55381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55381&action=edit
Revised patch

This patch actually regtests OK.  The previous one failed on one of the
c_char_tests.

[Bug c++/110340] [C++26] P2621R2 - Remove undefined behavior from lexing

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110340

--- Comment #1 from Andrew Pinski  ---
Full testcase for the first 2 issues raised in the paper:
```
int \\
u\
0\
3\
9\
1 = 0;

#define CONCAT(x,y) x##y

int CONCAT(\,u0393)=0;
```

Testcase for the last one:
```
const char * foo=" // { dg-error "" }
```

as far as I understand from the paper, instead of the above being undefined at
compiletime, the first testcase becomes valid and the last one becomes invalid.
And right now GCC acts according to the paper already so there is not anything
to be done. Maybe add a testcase for these if there is not already one is
enough ...

[Bug fortran/100650] Passing a derived-type array constructor to the reshape intrinsic gives incorrect results

2023-06-21 Thread pault at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100650

Paul Thomas  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-21
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Paul Thomas  ---
(In reply to Damian Rouson from comment #1)
> Here's a shorter reproducer:
> 
> % cat reshape-array-constructor.f90 
>   type foo_t
> integer, allocatable :: bar(:)
>   end type
> 
>   type(foo_t) foo(2,1)
>   integer :: i, j,  n(2,2,1) = reshape([-1,-1,1,1], [2,2,1])
> 
>   foo = reshape([([(foo_t(merge(0, 1, n(:,i,j) > 0)), i=1,2)], j=1,1)],
> [2,1])
>   print *, merge(0, 1, n(:,1,1) > 0), foo(1,1)%bar
>   print *, merge(0, 1, n(:,2,1) > 0), foo(2,1)%bar
> end
> % gfortran reshape-array-constructor.f90 
> % ./a.out
>1   1  -358465392   24440
>0   0  -358465392   24440
> % gfortran --version
> GNU Fortran (Homebrew GCC 13.1.0) 13.1.0
> 
> Another workaround in the above example is to make n a constant array via
> 
> integer, parameter :: n(*,*,*) = reshape([-1,-1,1,1], [2,2,1])

I have played with this a bit. It's a complete mess. Breaking out the inner
array constructor to a temporary produces the same result.

I have put it on my list of TODOs. First finish associate, gather up the last
of the select type bugs and attack PDTs.

Cheers

Paul

[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER

2023-06-21 Thread pault at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Paul Thomas  ---
Fixed on trunk and closing.

I will backport to 13-branch in a few weeks.

Thanks for the report

Paul

[Bug fortran/88688] Incorrect association in SELECT TYPE

2023-06-21 Thread pault at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88688

--- Comment #4 from Paul Thomas  ---
Fixed on trunk and closing.

I will build a composite patch for 13-branch in a few weeks.

Thanks for the report

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

2023-06-21 Thread pault at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 107900, which changed state.

Bug 107900 Summary: Select type with intrinsic type inside associate causes ICE 
/ Segmenation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107900

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/107900] Select type with intrinsic type inside associate causes ICE / Segmenation fault

2023-06-21 Thread pault at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107900

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Paul Thomas  ---
Fixed on trunk and closing.

I will build a composite patch for 13-branch in a few weeks.

Thanks for the report

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

2023-06-21 Thread pault at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 110224, which changed state.

Bug 110224 Summary: Rejects valid: function reference with data pointer result 
as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

2023-06-21 Thread pault at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224

Paul Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from Paul Thomas  ---
Fixed on trunk and closing.

I will build a composite patch for 13-branch in a few weeks.

Thanks for the report

Paul

PS I am going through your gfortran-bugs and find that a good number are fixed.
However, there are some humdingers going back a long way that I will take a
look at, once I am done with associate.

[Bug fortran/110360] ABI issue with character,value dummy argument

2023-06-21 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360

--- Comment #2 from anlauf at gcc dot gnu.org ---
For reference: testcase, cross-checked with NAG 7.1:

! { dg-do run }
! PR fortran/110360

program p
  implicit none
  character, allocatable :: ca
  character, pointer :: cp
  character(kind=4), allocatable :: ca4
  character(kind=4), pointer :: cp4
  integer :: a = 65
  allocate (ca, cp, ca4, cp4)
  ca  =   "c"; cp  =   "d"
  ca4 = 4_"c"; cp4 = 4_"d"
  call val  ("A",char(65))
  call val  ("A",char(a))
  call val4 (4_"A",char(65,kind=4))
  call val4 (4_"A",char(a,kind=4))
  call val  (ca,ca)
  call val  (cp,cp)
  call val4 (ca4,ca4)
  call val4 (cp4,cp4)
  deallocate (ca, cp, ca4, cp4)
contains
  subroutine val (x, c)
character(kind=1):: x
character(kind=1), value :: c
print *, "by value(kind=1): ", c
if (x /= c) stop 1
  end
  subroutine val4 (x, c)
character(kind=4):: x
character(kind=4), value :: c
print *, "by value(kind=4): ", c
if (x /= c) stop 2
  end
end

[Bug tree-optimization/110332] [14 regression] ICE in dominated_by_p when building LLVM with -O3

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110332

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
Another one reduced C testcase, very similar to the previous one but slightly
more reduced:
```
_Bool a;
struct s { int t; } c, d;
unsigned e, f;
unsigned transferValues(struct s *End) {
  unsigned RegIdx = *(a ? &e : &f);
  *End = *(a ? &c : &d);
  return RegIdx;
}
```

[Bug c++/110164] Improve diagnostic for incomplete standard library types due to missing include

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110164

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #4 from Andrew Pinski  ---
Waiting status is for waiting from the reporter of the bug; in this case it is
waiting on approval of the patch rather than waiting on the reporter so
assigned is the correct status.

[Bug fortran/110360] ABI issue with character,value dummy argument

2023-06-21 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360

--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 55380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55380&action=edit
Patch

The attached patch fixes up the case of non-constant string expressions passed
to CHARACTER,VALUE dummy arguments of constant length 1.

[Bug c++/110164] Improve diagnostic for incomplete standard library types due to missing include

2023-06-21 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110164

David Malcolm  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-June/62
   ||1779.html
   Keywords||patch
 Status|ASSIGNED|WAITING
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #3 from David Malcolm  ---
Patch posted here awaiting review:
  https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621779.html

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

2023-06-21 Thread bergner at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002

--- Comment #8 from Peter Bergner  ---
(In reply to Peter Bergner from comment #7)
> There are a few other testsuite regressions due to a linker warning the
> testsuite wouldn't ignore:
> 
> /opt/binutils-power10/bin/ld: /tmp/ccysrhL7.o uses 64-bit long double,
> /lib64/libc.so.6 uses 128-bit long double

Sorry, I shouldn't call these "regressions", since they FAIL on the unpatched
--without-long-double-128 build too.  I just noticed them while scanning the
log files and thought I should mention them.

[Bug target/54089] [SH] Refactor shift patterns

2023-06-21 Thread segher at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089

--- Comment #88 from Segher Boessenkool  ---
(In reply to Oleg Endo from comment #85)
> > +/* { dg-final { scan-assembler 
> > "_f_loop1_rshift:.*mov\.l\\t(\.L\[0-9\]+),(r\[0-9\]+).*sts.l\\tpr,@-r15.*(\.L\[0-9\]+):.*jsr\\t@\\2.*bf\.s\\t\\3.*\\1:\\n\\t\.long\\t___ashiftrt_r4_6.*_f_loop2_rshift:"
> >  { target { ! has_dyn_shift } } } }  */
> 
> Can you try to somehow write this in a simpler way?  Maybe omit some of the
> register number matches, as they don't matter etc.

Do not use double-quoted strings unless you need interpolation?  If you use {}
around the string you do not need to backslash-quote (and double-quote) so much
at all.

[0-9] is \d

whitespace is \s

See the Tcl re_syntax manual page :-)

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

2023-06-21 Thread bergner at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002

--- Comment #7 from Peter Bergner  ---
(In reply to Peter Bergner from comment #6)
> I'm going to test the following to see whether anything bad falls out:
> 
> --- a/gcc/config/rs6000/rs6000-builtin.cc
> +++ b/gcc/config/rs6000/rs6000-builtin.cc
> @@ -710,9 +710,9 @@ rs6000_init_builtins (void)
>   For IEEE 128-bit floating point, always create the type __ieee128.  If
> the
>   user used -mfloat128, rs6000-c.cc will create a define from __float128
> to
>   __ieee128.  */
> -  if (TARGET_LONG_DOUBLE_128 && (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE))
> +  if (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE)
>  {
> -  if (!TARGET_IEEEQUAD)
> +  if (TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD)
> ibm128_float_type_node = long_double_type_node;
>else
> {

So this passes (powerpc64le-linux) bootstrap and regtesting with no regressions
using a --with-long-double-128 build.  Using a --without-long-double-128 build
(ie, long double == double), signbit-1.c now ICEs with:

signbit-1.c: In function ‘do_signbit_if’:
signbit-1.c:8:64: error: unrecognizable insn:
8 | int do_signbit_if (__ibm128 a) { return __builtin_signbit (a); }
  |^
(insn 6 3 7 2 (set (reg:DF 120)
(float_truncate:DF (reg/v:IF 119 [ a ]))) "signbit-1.c":8:41 -1
 (nil))
during RTL pass: vregs
signbit-1.c:8:64: internal compiler error: in extract_insn, at recog.cc:2791

...so it seems we do have some inherent assumptions baked into the backend. :-(
There are a few other testsuite regressions due to a linker warning the
testsuite wouldn't ignore:

/opt/binutils-power10/bin/ld: /tmp/ccysrhL7.o uses 64-bit long double,
/lib64/libc.so.6 uses 128-bit long double

[Bug target/54089] [SH] Refactor shift patterns

2023-06-21 Thread segher at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089

--- Comment #87 from Segher Boessenkool  ---
(In reply to Oleg Endo from comment #53)
> (In reply to Segher Boessenkool from comment #52)
> > There is TARGET_LEGITIMATE_COMBINED_INSN though, which is a workaround for 
> > if
> > you really do not want the instruction combiner to create particular
> > instruction patterns (but it does nothing to prevent other parts of the
> > compiler from doing the same!)
> 
> Thanks for pointing it out.  I knew I missed something recent ;)

g:78e4f1ad4e48, from 2012?  Well, fairly recent, okay :-)

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

2023-06-21 Thread qinzhao at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #44 from qinzhao at gcc dot gnu.org ---
fixed in gcc13 already

[Bug tree-optimization/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

2023-06-21 Thread qinzhao at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832

--- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply to Jakub Jelinek from comment #3)
> > This is intentional, if you embed an aggregate with flex array into another
> > struct and ask not to cross the field boundaries (i.e. bos1), then the size
> > of that field is exactly what is the maximum size.
> 
> As we discussed in PR 107952
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952):
> 
> GCC extension accepts the following two cases:
> 
> **Case 1:
> 
> struct A { char data[1]; };
> struct B { int n; struct A a; };
> 
> as if the a.data[] array is a flex-array.  
> 
> **Case 2: 
> 
> struct C { int n; struct A a; int x; };
> 
> as if a.data[] can be up to 4 elements. 
> 
> So, what's you mean by "not to cross the field boundaries" is for the above
> Case 2? 
> For Case 1, we should treat A.data as flexible array, and then B.A as a
> structure that has flexible array, therefore B.A's size is flexible too. 
> 
> Is my understanding correct?


After discussion, the following patch to clarify the above two cases was
approved:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620122.html

with this clarification, the above case 1 is accepted as a GCC extension, but
case 2 will be deprecated. a warning option -Wflex-array-member-not-at-end is
provided to detect case 2 in the user code. 

please see also PR77650.

[Bug c++/110358] requesting nicer suppression for Wdangling-reference

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110358

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2023-06-21
 Resolution|DUPLICATE   |---

--- Comment #3 from Marek Polacek  ---
Reopening, specializations of class/function templates may need special
handling -- that is, a dedicated attribute.

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

2023-06-21 Thread barry.revzin at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642

--- Comment #10 from Barry Revzin  ---
Check out the report I opened for an example where the #pragma around the whole
class isn't really enough anyway - since you might want to disable the warning
for specializations of class/function templates.

[Bug fortran/110360] New: ABI issue with character,value dummy argument

2023-06-21 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360

Bug ID: 110360
   Summary: ABI issue with character,value dummy argument
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

Consider:

program p
  implicit none
  integer :: a = 65
  call val (char(65))  ! OK
  call val (char(a))   ! random junk
contains
  subroutine val (c)
character, value :: c
print *, "by value: ", c
  end
end

This should print twice

 by value: A
 by value: A

but the second line contains junk, as the tree-dump shows:

  static void val (character(kind=1)[1:1], integer(kind=8));
  static integer(kind=4) a = 65;

  val ("A", 1);
  {
character(kind=1) char.1;

char.1 = (character(kind=1)) a;
val (&char.1, 1);
  }

Clearly, the second case is inconsistent with the ABI, see the prototype, and

https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html

The ABI does not (yet) state how to handle character of length > 1 or variable
length - we'll likely need to pass a pointer to a temporary - but as long as
the dummy has fixed length 1 we should pass the argument by value.

A related issue occurs for actual arguments that are allocatable scalars
(or pointers to scalars).

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642

--- Comment #9 from Marek Polacek  ---
My plan is to allow users to do

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
...
#pragma GCC diagnostic pop

around the *class* itself to suppress the warning, not every use of the class.

Sorry, Carlos and Barry, that I haven't gotten around to it yet.

[Bug d/110359] New: d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435

2023-06-21 Thread ibuclaw at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359

Bug ID: 110359
   Summary: d: Suboptimal codegen for __builtin_expect(cond,
false) since PR96435
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

Since pr96435, both boolean objects *and* expressions have been evaluated in
the following way.

(*(ubyte*)&obj_or_expr) & 1

It has been noted that sometimes this can cause the back-end to optimize in
non-obvious ways - in particular with `__builtin_expect`.

---
double pow(in double x, in ulong p)
{
import gcc.builtins : __builtin_expect;
if (__builtin_expect(p == 0, false))  // 1,2
return 1;
if (__builtin_expect(p == 1, false))  // 3,4
return x;

double s = x;
double v = 1;
for (ulong i = p; i > 1; i >>= 1) // 5
{
v = (i & 0x1) ? s * v : v;
s = s * s;
}
return v * s;
}
---

The first 5 lines of assembly for the above function (corresponding souce line
marked in comments)
---
double example.pow(in double, in ulong):
testrdi, rdi
je  .L6
cmp rdi, 1
je  .L1
jbe .L1
---

The jbe condition looks like it is either redundant, or suboptimal.

This @safe feature could be restricted to just when reading the value of a bool
field that comes from a union.

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642

Andrew Pinski  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #8 from Andrew Pinski  ---
*** Bug 110358 has been marked as a duplicate of this bug. ***

[Bug c++/110358] requesting nicer suppression for Wdangling-reference

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110358

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> I thought there was already a bug recording that there should be a better
> way of supressing Wdangling-reference ...

Yes PR 109642 .

*** This bug has been marked as a duplicate of bug 109642 ***

[Bug c++/110358] requesting nicer suppression for Wdangling-reference

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110358

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
I thought there was already a bug recording that there should be a better way
of supressing Wdangling-reference ...

[Bug c++/110358] New: requesting nicer suppression for Wdangling-reference

2023-06-21 Thread barry.revzin at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110358

Bug ID: 110358
   Summary: requesting nicer suppression for Wdangling-reference
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

As everyone is already aware, Wdangling-reference gives false positives for
reference-semantic classes. The compiler has special cases for the ones it
knows about, but not for mine. So:

template 
struct Span {
T* data_;
int len_;

[[nodiscard]] constexpr auto operator[](int n) const noexcept -> T& {
return data_[n]; }
[[nodiscard]] constexpr auto front() const noexcept -> T& { return
data_[0]; }
[[nodiscard]] constexpr auto back() const noexcept -> T& { return
data_[len_ - 1]; }
};

auto get() -> Span;

auto f() -> int {
int const& a = get().front(); // warning
int const& b = get().back();  // warning
int const& c = get()[0];  // warning

return a + b + c;
}

The suppression for this is to #pragma around all my functions, which is a bit
of a tedious suppression, since this is two prefix lines and one postfix line
(but for libraries it's actually 4 prefix lines because we can't ignore
Wdangling-reference until gcc 13, so need to #ifdef that out).

It'd be nice if we could:

* add an attribute to a class to conditionally suppress the warning
* add an attribute to a function to conditionally suppress the warning
* both

Basically in this case to let me do something like:

template 
struct [[gnu::marek_is_awesome_but_this_warning_has_too_many_false_positives]]
Span {
   // ...
};

And I say conditional so that I can do this (because Optional wants to
suppress the warning, but Optional definitely does not!)

template 
struct
[[gnu::marek_is_awesome_but_this_warning_has_too_many_false_positives(std::is_reference_v)]]
Optional {
   // ...
};

Obviously I am not the best at naming.

[Bug fortran/110350] Intrinsic handling inside nested associate blocks

2023-06-21 Thread kargl at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110350

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||kargl at gcc dot gnu.org
   Last reconfirmed||2023-06-21

--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmed.

As a workaround, mark iargc as an intrinsic via

integer, intrinsic :: iargc

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

2023-06-21 Thread bergner at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002

--- Comment #6 from Peter Bergner  ---
(In reply to Peter Bergner from comment #5)
> The creation of the __ibm128 type is guarded by:
> 
>   if (TARGET_LONG_DOUBLE_128 && (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE))
> 
> Since the __ibm128 type is independent of what long double defaults to, I
> assume the fix is to just remove the TARGET_LONG_DOUBLE_128 test giving us:
> 
>   if (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE)

I'm going to test the following to see whether anything bad falls out:

--- a/gcc/config/rs6000/rs6000-builtin.cc
+++ b/gcc/config/rs6000/rs6000-builtin.cc
@@ -710,9 +710,9 @@ rs6000_init_builtins (void)
  For IEEE 128-bit floating point, always create the type __ieee128.  If
the
  user used -mfloat128, rs6000-c.cc will create a define from __float128 to
  __ieee128.  */
-  if (TARGET_LONG_DOUBLE_128 && (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE))
+  if (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE)
 {
-  if (!TARGET_IEEEQUAD)
+  if (TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD)
ibm128_float_type_node = long_double_type_node;
   else
{

[Bug libstdc++/110357] New: [C++26] P2592R3 Hashing support for std::chrono value classes

2023-06-21 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110357

Bug ID: 110357
   Summary: [C++26] P2592R3 Hashing support for std::chrono value
classes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Depends on: 104167
Blocks: 110339
  Target Milestone: ---

https://wg21.link/P2592R3

This bumps the value of __cpp_lib_chrono which we can't do until the rest of PR
104167 is completed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
[Bug 104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

2023-06-21 Thread bergner at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002

--- Comment #5 from Peter Bergner  ---
(In reply to Peter Bergner from comment #4)
> gcc.target/powerpc/pr85657-3.c
> gcc.target/powerpc/signbit-1.c
> pr85657-3.c:38:20: error: unknown type name ‘__ibm128’; did you mean
> ‘__int128’?
> 
> These die because we don't create the type __ibm128 when using
> -mlong-double-64, which seems strange since we do create the __float128 type
> used in the test cases.
> 
> Mike, I assume the __ibm128 type should always be created?

The creation of the __ibm128 type is guarded by:

  if (TARGET_LONG_DOUBLE_128 && (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE))

Since the __ibm128 type is independent of what long double defaults to, I
assume the fix is to just remove the TARGET_LONG_DOUBLE_128 test giving us:

  if (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE)

Or are there some (bad) inherent assumptions in the backend that IBM double
double support needing a 128-bit long double?


The creation of the __ieee128 type is only guarded by:

  if (TARGET_FLOAT128_TYPE)

[Bug libstdc++/110356] New: [C++26] P2637R3 Member visit

2023-06-21 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110356

Bug ID: 110356
   Summary: [C++26] P2637R3 Member visit
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Depends on: 102609
Blocks: 110339
  Target Milestone: ---

https://wg21.link/P2637R3

We need "deducing this" to implement this in the straightforward way specified
in the proposal.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
[Bug 102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug libstdc++/110355] std::format("{}", 1e-7) returns "1e-07" instead of "1e-7"

2023-06-21 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110355

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-21
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
mine

[Bug libstdc++/110355] New: std::format("{}", 1e-7) returns "1e-07" instead of "1e-7"

2023-06-21 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110355

Bug ID: 110355
   Summary: std::format("{}", 1e-7) returns "1e-07" instead of
"1e-7"
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 110354
  Target Milestone: ---


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110354
[Bug 110354] [C++26] P2587R3 to_string or not to_string

[Bug libstdc++/110354] [C++26] P2587R3 to_string or not to_string

2023-06-21 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110354

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-06-21
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
I think this should only be done for C++26 and up. That means we can use
std::format, exactly as specified by the proposal.

I'll probably work on this, but not immediately.

[Bug libstdc++/110354] New: [C++26] P2587R3 to_string or not to_string

2023-06-21 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110354

Bug ID: 110354
   Summary: [C++26] P2587R3 to_string or not to_string
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 110339
  Target Milestone: ---

https://wg21.link/p2587r3


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug libstdc++/110353] New: [C++26] P1383R2 More constexpr for cmath and complex

2023-06-21 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110353

Bug ID: 110353
   Summary: [C++26] P1383R2 More constexpr for cmath and complex
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Depends on: 105281
Blocks: 110339
  Target Milestone: ---

https://wg21.link/P1383R2


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105281
[Bug 105281] status of constexpr  and  for c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug libstdc++/110352] New: [C++26] P2630R4 submdspan

2023-06-21 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110352

Bug ID: 110352
   Summary: [C++26] P2630R4 submdspan
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Depends on: 107761
Blocks: 110339
  Target Milestone: ---

https://wg21.link/P2630R4


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
[Bug 107761] Implement C++23 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug tree-optimization/110332] [14 regression] ICE in dominated_by_p when building LLVM with -O3

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110332

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-21

--- Comment #7 from Andrew Pinski  ---
Reduced C testcase:
```
struct s { int lie; };
struct s si7, si8;
unsigned u9, u6;
_Bool b3, b4;
unsigned transferValues(struct s *End) {
  unsigned RegIdx;
  unsigned *t = b4 ? &u6 : &u9;
  RegIdx = *t;
  *End = *(b3 ? &si7 : &si8);
  return RegIdx;
}
```

[Bug tree-optimization/110332] [14 regression] ICE in dominated_by_p when building LLVM with -O3

2023-06-21 Thread slyfox at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110332

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #6 from Sergei Trofimovich  ---
I think I see the same ICE on llvm-12 and r14-2009-g864c6471bdc6cd:

cvise produced this thing:

// $ cat a.cpp.cpp
struct SlotIndex { int lie; };
SlotIndex si7, si8;

unsigned u9, u6;
bool b3, b4;
unsigned &value() {
  return b4 ? u6 : u9;
}
void transferValues() {
  unsigned RegIdx;
  SlotIndex End;
  RegIdx = value();
  End = b3 ? si7 : si8;
}

$ g++ -O3  -c a.cpp.cpp -o a.o
during GIMPLE pass: phiprop
a.cpp.cpp: In function 'void transferValues()':
a.cpp.cpp:14:1: internal compiler error: Segmentation fault
   14 | }
  | ^
0x1d74824 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1d74d97 internal_error(char const*, ...)
???:0
0xe9bfdf crash_signal(int)
???:0
0xa851da dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def
const*)
???:0
0x102096b (anonymous namespace)::pass_phiprop::execute(function*)
???:0

$ g++  -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: 
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug target/109989] RISC-V: Missing sign extension with int to float conversion with 64bit soft floats

2023-06-21 Thread palmer at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989

--- Comment #4 from palmer at gcc dot gnu.org ---
I left some cruft in that reproducer, it should have been

volatile float f[2];
int x[2];

void func() {
  x[0] = -1;
  x[1] = 2;

  for (int i = 0; i < 1; ++i)
f[i] = x[i];
}

Not sure what's going on yet, but nothing jumps out in that bisected patch. 
I'm guessing we've just got something wrong with poly/scalar conversion,
there's a bunch of implicit assumptions based around si/di conversions in our
backend and I bet we're violating something there.  That's all been a sticking
point for a while and I think some of the Ventana guys were looking into
cleaning it up, maybe Jeff has a better idea?

[Bug tree-optimization/110332] [14 regression] ICE in dominated_by_p when building LLVM with -O3

2023-06-21 Thread sjames at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110332

--- Comment #5 from Sam James  ---
Created attachment 55379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55379&action=edit
reduced.ii

[Bug target/109989] RISC-V: Missing sign extension with int to float conversion with 64bit soft floats

2023-06-21 Thread palmer at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-21
 Ever confirmed|0   |1
 CC||palmer at gcc dot gnu.org

--- Comment #3 from palmer at gcc dot gnu.org ---
I can confirm this is a bug.  The shortest reproducer I can get is:

$ cat test.c
volatile float f[2];
int x[2];

float fconv(int x);

void func() {
  x[0] = -1;
  x[1] = 2; // Removal of this line avoids the bug

  for (int i = 0; i < 1; ++i)
f[i] = x[i];
}
$ ./toolchain/install/bin/riscv64-unknown-linux-gnu-gcc test.c -S -o-
-march=rv64imac -mabi=lp64 -O1 -ftree-slp-vectorize -funroll-loops
-fdump-rtl-all
...
func:
addisp,sp,-16
sd  ra,8(sp)
li  a0,3
sllira,a0,32
addia0,ra,-1
lui a5,%hi(x)
sd  a0,%lo(x)(a5)
call__floatsisf
lui t0,%hi(f)
sw  a0,%lo(f)(t0)
ld  ra,8(sp)
addisp,sp,16
jr  ra
...

With the bug being that a0 contains a non-ABI-canonical value at the call to
__floatsisf.

[Bug debug/110351] gcc does not recognize gcodeview as debuglevel

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110351

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #3 from Andrew Pinski  ---
.

[Bug debug/110351] gcc does not recognize gcodeview as debuglevel

2023-06-21 Thread fabian_kessler at gmx dot de via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110351

fabian_kessler at gmx dot de  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from fabian_kessler at gmx dot de  
---
Thank you! Is there another flag, or way, to generate pdb files with a mapping
to source files and source line information?

[Bug debug/110351] gcc does not recognize gcodeview as debuglevel

2023-06-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110351

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
GCC 13.1.0 documentation is here:
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Debugging-Options.html


https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html  is the documentation
for the trunk/master branch of GCC (the in development one). In this case it
will most likely become GCC 14.

[Bug debug/110351] New: gcc does not recognize gcodeview as debuglevel

2023-06-21 Thread fabian_kessler at gmx dot de via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110351

Bug ID: 110351
   Summary: gcc does not recognize gcodeview as debuglevel
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fabian_kessler at gmx dot de
  Target Milestone: ---

On https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html the debug option
-gcodeview is described, but when I try to use it gcc emits "error:
unrecognized debug output level ‘codeview’". What or which version of gcc is
required to support this option?

$ gcc --version
gcc.exe (Rev6, Built by MSYS2 project) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/110350] New: Intrinsic handling inside nested associate blocks

2023-06-21 Thread rimvydas.jas at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110350

Bug ID: 110350
   Summary: Intrinsic handling inside nested associate blocks
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

$ cat test_iargc.f90 
program foo
implicit none
integer :: iargc
integer :: z

 associate(x=>z)
  associate(y=>z)
   if(iargc().lt.5) stop 5
  end associate
 end associate
end program
$ gfortran -Wall -Wextra test_iargc.f90 
test_iargc.f90:8:6:

8 |if(iargc().lt.5) stop 5
  |  1
Error: 'iargc' at (1) is not a function

Seems behavior almost the same down to gfortran-4.8
Removing single nested unrelated associate block results in undefined reference
to iargc_()
Removing optional 'integer :: iargc' kind declaration works.

[Bug c++/110347] [OpenMP] private/firstprivate of a C++ member variable mishandled

2023-06-21 Thread burnus at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110347

--- Comment #1 from Tobias Burnus  ---
I note that for the ICE example, the OG13 compiles it without an ICE and has as
result:
  firstprivate(this) map(tofrom:*this [len: 16])
  map(firstprivate:this [pointer assign, bias: 0])

For the main testcase of comment 0, OG13 gives the same result as maineline
(GCC 14).

[Bug c++/110349] New: [C++26] P2169R4 - Placeholder variables with no name

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110349

Bug ID: 110349
   Summary: [C++26] P2169R4 - Placeholder variables with no name
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/110348] New: [C++26] P2741R3 - User-generated static_assert messages

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348

Bug ID: 110348
   Summary: [C++26] P2741R3 - User-generated static_assert
messages
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/110347] New: [OpenMP] private/firstprivate of a C++ member variable mishandled

2023-06-21 Thread burnus at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110347

Bug ID: 110347
   Summary: [OpenMP] private/firstprivate of a C++ member variable
mishandled
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

On the GCC side, this came up at
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596238.html

It was also discussed at length but with a different focus in a couple of
base-language OpenMP spec meetings, albeit Tom was only in one. I did not
quickly find an associated issue, maybe it was only shown on screen without an
associated issue by Kelvin or Deepak. ... I found the OpenMP spec issue → #3343
(see last comment for the result when Tom was there; I filed the issue based on
a previous discussion.)

Currently, we have for (assume a prior enter-data mapping of this[:1] if it
helps):

struct C {
   int a, b, c, d;
   void foo (void) {
 #pragma omp target private (a) firstprivate(b)
  { a = 1; b = 2; c = 3; this->d = 4; }
   }
};
int main() { C c; c.foo(); }


the original dump

{
int D.2925 [value-expr: ((struct C *) this)->a];
int D.2924 [value-expr: ((struct C *) this)->b];
  #pragma omp target map(tofrom:*(struct C *) this [len: 16])
map(firstprivate:(struct C *) this [pointer assign, bias: 0])
firstprivate(D.2924) private(D.2925)
{
  {
<;
<;
;
;
  }
}
}


the gimple dump

void C::foo (struct C * const this)
{
  int a [value-expr: this->a];
  int b [value-expr: this->b];

  #pragma omp target num_teams(-2) thread_limit(0) map(tofrom:this [len:
8][implicit]) map(tofrom:*this [len: 16]) map(firstprivate:this [pointer
assign, bias: 0]) firstprivate(b) private(a)
{
  this->a = 1;
  this->b = 2;
  this->c = 3;
  this->d = 4;
}
}



If I have understood the discussions and rules correctly, the expected result
would be:

{
int D.2925;
int D.2924 = ((struct C *) this)->b;
  #pragma omp target map(tofrom:*(struct C *) this [len: 16])
map(firstprivate:(struct C *) this [pointer assign, bias: 0])
firstprivate(D.2924) private(D.2925)
{
  {
  D.2925 = 1;
  D.2924 = 2;
  ((struct C *) this)->c = 3;
  ((struct C *) this)->d = 4;
  }
}
}

* * *

In terms of the spec, the following takes care of the
'firstprivate(cpp_member_var)' as it wouldn't be otherwise permitted in a
firstprivate:

"--- C++ ---
Unless otherwise specified, a variable that is part of another variable (as an
array element or a structure element) cannot be a variable list item, an
extended list item or locator list item except if the list appears on a clause
that is associated with a construct within a class non-static member function
and the variable is an accessible data member of the object for which the
non-static member function is invoked."
[OpenMP 5.2, 3.2.1 OpenMP Argument Lists [62:1-5])


Otherwise, if a clause should permit to use array sections or
structure-components as list item, that clause needs to explicit permit it. (In
5.2; in 5.1 it was the other way round.)

This wording still does not permit 'firstprivate(this->a)' - only
firstprivate(a).


I assume that for

 #pragma omp target map(this[:1]) firstprivate(a)
  { this->a = 5; a = 7;  printf("%d %d\n", a, this->a); }
  print ("%d\n", a);

the expected result would be: '7 5' and '5'.


* * *


Side remark: The following gives an ICE:

struct C {
   int a, b, c, d;
   void foo (void) {
 #pragma omp target defaultmap(firstprivate)
  { a = 1; b = 2; c = 3; d = 4; }
   }
};


Namely:

internal compiler error: in gimplify_adjust_omp_clauses, at gimplify.cc:13004
4 |  #pragma omp target defaultmap(firstprivate)

* The ICE is new since GCC12

* GCC12+ accepts also 'map(this[:1])' - with the same ICE.
  while GCC11 rejected the latter with:
  'error: ‘this’ allowed in OpenMP only in ‘declare simd’ clauses'

* GCC 11 compiles the version above w/o map(this[:1]) and gimplifies it as
defaultmap(firstprivate) firstprivate(this)
  and in the optimized dump, GCC 11 then has:
.omp_data_arr.1.this = this_2(D); .omp_data_sizes.2[1] = {0};

[Bug c++/110346] New: [C++26] P2752R3 - Static storage for braced initializers

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110346

Bug ID: 110346
   Summary: [C++26] P2752R3 - Static storage for braced
initializers
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/110345] New: [C++26] P2552R3 - On the ignorability of standard attributes

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110345

Bug ID: 110345
   Summary: [C++26] P2552R3 - On the ignorability of standard
attributes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/110344] New: [C++26] P2738R1 - constexpr cast from void*

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344

Bug ID: 110344
   Summary: [C++26] P2738R1 - constexpr cast from void*
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/110343] New: [C++26] P2558R2 - Add @, $, and ` to the basic character set

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343

Bug ID: 110343
   Summary: [C++26] P2558R2 - Add @, $, and ` to the basic
character set
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/110342] New: [C++26] P2361R6 - Unevaluated strings

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110342

Bug ID: 110342
   Summary: [C++26] P2361R6 - Unevaluated strings
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/110341] New: [C++26] P1854R4 - Making non-encodable string literals ill-formed

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110341

Bug ID: 110341
   Summary: [C++26] P1854R4 - Making non-encodable string literals
ill-formed
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:577223aebc7acdd31e62b33c1682fe54a622ae27

commit r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Author: Paul Thomas 
Date:   Wed Jun 21 17:05:58 2023 +0100

Fortran: Fix some bugs in associate [PR87477]

2023-06-21  Paul Thomas  

gcc/fortran
PR fortran/87477
PR fortran/88688
PR fortran/94380
PR fortran/107900
PR fortran/110224
* decl.cc (char_len_param_value): Fix memory leak.
(resolve_block_construct): Remove unnecessary static decls.
* expr.cc (gfc_is_ptr_fcn): New function.
(gfc_check_vardef_context): Use it to permit pointer function
result selectors to be used for associate names in variable
definition context.
* gfortran.h: Prototype for gfc_is_ptr_fcn.
* match.cc (build_associate_name): New function.
(gfc_match_select_type): Use the new function to replace inline
version and to build a new associate name for the case where
the supplied associate name is already used for that purpose.
* resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
associate names with pointer function targets to be used in
variable definition context.
* trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
variables need deferred initialisation of the vptr.
(gfc_trans_deferred_vars): Do the vptr initialisation.
* trans-stmt.cc (trans_associate_var): Ensure that a pointer
associate name points to the target of the selector and not
the selector itself.

gcc/testsuite/
PR fortran/87477
PR fortran/107900
* gfortran.dg/pr107900.f90 : New test

PR fortran/110224
* gfortran.dg/pr110224.f90 : New test

PR fortran/88688
* gfortran.dg/pr88688.f90 : New test

PR fortran/94380
* gfortran.dg/pr94380.f90 : New test

PR fortran/95398
* gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
numbers in the error tests by two and change the text in two.

[Bug fortran/94380] Nested associate+select type blocks cause compiler segfault

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94380

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:577223aebc7acdd31e62b33c1682fe54a622ae27

commit r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Author: Paul Thomas 
Date:   Wed Jun 21 17:05:58 2023 +0100

Fortran: Fix some bugs in associate [PR87477]

2023-06-21  Paul Thomas  

gcc/fortran
PR fortran/87477
PR fortran/88688
PR fortran/94380
PR fortran/107900
PR fortran/110224
* decl.cc (char_len_param_value): Fix memory leak.
(resolve_block_construct): Remove unnecessary static decls.
* expr.cc (gfc_is_ptr_fcn): New function.
(gfc_check_vardef_context): Use it to permit pointer function
result selectors to be used for associate names in variable
definition context.
* gfortran.h: Prototype for gfc_is_ptr_fcn.
* match.cc (build_associate_name): New function.
(gfc_match_select_type): Use the new function to replace inline
version and to build a new associate name for the case where
the supplied associate name is already used for that purpose.
* resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
associate names with pointer function targets to be used in
variable definition context.
* trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
variables need deferred initialisation of the vptr.
(gfc_trans_deferred_vars): Do the vptr initialisation.
* trans-stmt.cc (trans_associate_var): Ensure that a pointer
associate name points to the target of the selector and not
the selector itself.

gcc/testsuite/
PR fortran/87477
PR fortran/107900
* gfortran.dg/pr107900.f90 : New test

PR fortran/110224
* gfortran.dg/pr110224.f90 : New test

PR fortran/88688
* gfortran.dg/pr88688.f90 : New test

PR fortran/94380
* gfortran.dg/pr94380.f90 : New test

PR fortran/95398
* gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
numbers in the error tests by two and change the text in two.

[Bug fortran/107900] Select type with intrinsic type inside associate causes ICE / Segmenation fault

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107900

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:577223aebc7acdd31e62b33c1682fe54a622ae27

commit r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Author: Paul Thomas 
Date:   Wed Jun 21 17:05:58 2023 +0100

Fortran: Fix some bugs in associate [PR87477]

2023-06-21  Paul Thomas  

gcc/fortran
PR fortran/87477
PR fortran/88688
PR fortran/94380
PR fortran/107900
PR fortran/110224
* decl.cc (char_len_param_value): Fix memory leak.
(resolve_block_construct): Remove unnecessary static decls.
* expr.cc (gfc_is_ptr_fcn): New function.
(gfc_check_vardef_context): Use it to permit pointer function
result selectors to be used for associate names in variable
definition context.
* gfortran.h: Prototype for gfc_is_ptr_fcn.
* match.cc (build_associate_name): New function.
(gfc_match_select_type): Use the new function to replace inline
version and to build a new associate name for the case where
the supplied associate name is already used for that purpose.
* resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
associate names with pointer function targets to be used in
variable definition context.
* trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
variables need deferred initialisation of the vptr.
(gfc_trans_deferred_vars): Do the vptr initialisation.
* trans-stmt.cc (trans_associate_var): Ensure that a pointer
associate name points to the target of the selector and not
the selector itself.

gcc/testsuite/
PR fortran/87477
PR fortran/107900
* gfortran.dg/pr107900.f90 : New test

PR fortran/110224
* gfortran.dg/pr110224.f90 : New test

PR fortran/88688
* gfortran.dg/pr88688.f90 : New test

PR fortran/94380
* gfortran.dg/pr94380.f90 : New test

PR fortran/95398
* gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
numbers in the error tests by two and change the text in two.

[Bug fortran/95398] ICE on invalid code

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95398

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:577223aebc7acdd31e62b33c1682fe54a622ae27

commit r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Author: Paul Thomas 
Date:   Wed Jun 21 17:05:58 2023 +0100

Fortran: Fix some bugs in associate [PR87477]

2023-06-21  Paul Thomas  

gcc/fortran
PR fortran/87477
PR fortran/88688
PR fortran/94380
PR fortran/107900
PR fortran/110224
* decl.cc (char_len_param_value): Fix memory leak.
(resolve_block_construct): Remove unnecessary static decls.
* expr.cc (gfc_is_ptr_fcn): New function.
(gfc_check_vardef_context): Use it to permit pointer function
result selectors to be used for associate names in variable
definition context.
* gfortran.h: Prototype for gfc_is_ptr_fcn.
* match.cc (build_associate_name): New function.
(gfc_match_select_type): Use the new function to replace inline
version and to build a new associate name for the case where
the supplied associate name is already used for that purpose.
* resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
associate names with pointer function targets to be used in
variable definition context.
* trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
variables need deferred initialisation of the vptr.
(gfc_trans_deferred_vars): Do the vptr initialisation.
* trans-stmt.cc (trans_associate_var): Ensure that a pointer
associate name points to the target of the selector and not
the selector itself.

gcc/testsuite/
PR fortran/87477
PR fortran/107900
* gfortran.dg/pr107900.f90 : New test

PR fortran/110224
* gfortran.dg/pr110224.f90 : New test

PR fortran/88688
* gfortran.dg/pr88688.f90 : New test

PR fortran/94380
* gfortran.dg/pr94380.f90 : New test

PR fortran/95398
* gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
numbers in the error tests by two and change the text in two.

[Bug fortran/88688] Incorrect association in SELECT TYPE

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88688

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:577223aebc7acdd31e62b33c1682fe54a622ae27

commit r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Author: Paul Thomas 
Date:   Wed Jun 21 17:05:58 2023 +0100

Fortran: Fix some bugs in associate [PR87477]

2023-06-21  Paul Thomas  

gcc/fortran
PR fortran/87477
PR fortran/88688
PR fortran/94380
PR fortran/107900
PR fortran/110224
* decl.cc (char_len_param_value): Fix memory leak.
(resolve_block_construct): Remove unnecessary static decls.
* expr.cc (gfc_is_ptr_fcn): New function.
(gfc_check_vardef_context): Use it to permit pointer function
result selectors to be used for associate names in variable
definition context.
* gfortran.h: Prototype for gfc_is_ptr_fcn.
* match.cc (build_associate_name): New function.
(gfc_match_select_type): Use the new function to replace inline
version and to build a new associate name for the case where
the supplied associate name is already used for that purpose.
* resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
associate names with pointer function targets to be used in
variable definition context.
* trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
variables need deferred initialisation of the vptr.
(gfc_trans_deferred_vars): Do the vptr initialisation.
* trans-stmt.cc (trans_associate_var): Ensure that a pointer
associate name points to the target of the selector and not
the selector itself.

gcc/testsuite/
PR fortran/87477
PR fortran/107900
* gfortran.dg/pr107900.f90 : New test

PR fortran/110224
* gfortran.dg/pr110224.f90 : New test

PR fortran/88688
* gfortran.dg/pr88688.f90 : New test

PR fortran/94380
* gfortran.dg/pr94380.f90 : New test

PR fortran/95398
* gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
numbers in the error tests by two and change the text in two.

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:577223aebc7acdd31e62b33c1682fe54a622ae27

commit r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Author: Paul Thomas 
Date:   Wed Jun 21 17:05:58 2023 +0100

Fortran: Fix some bugs in associate [PR87477]

2023-06-21  Paul Thomas  

gcc/fortran
PR fortran/87477
PR fortran/88688
PR fortran/94380
PR fortran/107900
PR fortran/110224
* decl.cc (char_len_param_value): Fix memory leak.
(resolve_block_construct): Remove unnecessary static decls.
* expr.cc (gfc_is_ptr_fcn): New function.
(gfc_check_vardef_context): Use it to permit pointer function
result selectors to be used for associate names in variable
definition context.
* gfortran.h: Prototype for gfc_is_ptr_fcn.
* match.cc (build_associate_name): New function.
(gfc_match_select_type): Use the new function to replace inline
version and to build a new associate name for the case where
the supplied associate name is already used for that purpose.
* resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
associate names with pointer function targets to be used in
variable definition context.
* trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
variables need deferred initialisation of the vptr.
(gfc_trans_deferred_vars): Do the vptr initialisation.
* trans-stmt.cc (trans_associate_var): Ensure that a pointer
associate name points to the target of the selector and not
the selector itself.

gcc/testsuite/
PR fortran/87477
PR fortran/107900
* gfortran.dg/pr107900.f90 : New test

PR fortran/110224
* gfortran.dg/pr110224.f90 : New test

PR fortran/88688
* gfortran.dg/pr88688.f90 : New test

PR fortran/94380
* gfortran.dg/pr94380.f90 : New test

PR fortran/95398
* gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
numbers in the error tests by two and change the text in two.

[Bug c++/110340] New: [C++26] P2621R2 - Remove undefined behavior from lexing

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110340

Bug ID: 110340
   Summary: [C++26] P2621R2 - Remove undefined behavior from
lexing
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:caf0892eea67349d9a1e44590c3440768136fe2b

commit r14-2021-gcaf0892eea67349d9a1e44590c3440768136fe2b
Author: Paul Thomas 
Date:   Wed Jun 21 17:01:57 2023 +0100

Fortran: Seg fault passing string to type cptr dummy [PR108961].

2023-06-21  Paul Thomas  

gcc/fortran
PR fortran/108961
* trans-expr.cc (gfc_conv_procedure_call): The hidden string
length must not be passed to a formal arg of type(cptr).

gcc/testsuite/
PR fortran/108961
* gfortran.dg/pr108961.f90: New test.

[Bug libstdc++/110339] Implement C++26 library features

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339

Marek Polacek  changed:

   What|Removed |Added

   Keywords||meta-bug
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-21
  Alias||c++26-lib

[Bug libstdc++/110339] New: Implement C++26 library features

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339

Bug ID: 110339
   Summary: Implement C++26 library features
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

A meta bug to track the overall progress of C++26 features in the C++ standard
library.

[Bug c++/110338] Implement C++26 language features

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338

Marek Polacek  changed:

   What|Removed |Added

   Keywords||meta-bug
  Alias||c++26-core
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-21
 Status|UNCONFIRMED |NEW

[Bug c++/110338] New: Implement C++26 language features

2023-06-21 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338

Bug ID: 110338
   Summary: Implement C++26 language features
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

A meta bug to track the overall progress of C++26 features in the C++ FE.

[Bug preprocessor/109704] #pragma {push,pop}_macro broken for identifiers that contain dollar signs at nonfirst positions

2023-06-21 Thread lhyatt at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #3 from Lewis Hyatt  ---
We are also not handling UTF-8 identifiers for push_macro and pop_macro
pragmas. I was going to try to add this sometime, which would naturally handle
the case of $ as well.

[Bug c/110337] New: Wrong code at -O2/s on x86_64-linux-gnu

2023-06-21 Thread shaohua.li at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110337

Bug ID: 110337
   Summary: Wrong code at -O2/s on x86_64-linux-gnu
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

This seems to be a recent regression on GCC -O2/s

$ cat a.c
int printf(const char *, ...);
int a, e;
static short b = 3, f;
long c;
char d;
short g() {
  e = a;
  for (; a != 4;)
return 39570 + d + b;
  return 0;
}
int main() {
  int h;
  f = g();
  int i = f;
  h = i < 0 ? i : i >> 14;
  c = b && h;
  printf("%d\n", (int)c);
}
$
$ gcc-tk -O0 a.c && ./a.out
1
$ gcc-tk -O2 a.c && ./a.out
-1
$

[Bug middle-end/110018] Missing vectorizable_conversion(unsigned char -> double) for BB vectorizer

2023-06-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110018

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:b9401c3a323c59705eca177bf72c13c0d2f462b6

commit r14-2020-gb9401c3a323c59705eca177bf72c13c0d2f462b6
Author: Uros Bizjak 
Date:   Wed Jun 21 16:34:39 2023 +0200

vect: Add testcases for unsigned conversions [PR110018]

Also test convresions with unsigned types.

PR target/110018

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr110018-1.c: Use explicit signed types.
* gcc.target/i386/pr110018-2.c: New test.

[Bug tree-optimization/110243] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

2023-06-21 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243

--- Comment #4 from Richard Biener  ---
There's now a single strip_offset left in IVOPTs, the problematic one.  That
one
isn't trivial to convert to split_constant_offset since that only deals with
pointer or sizetype quantities in a way that's reasonable for this place.

There's the opportunity to generalize split_constant_offset to work on
other (unsigned) "base" types.  I think that's the most reasonable thing to
do.

[Bug middle-end/106081] missed vectorization

2023-06-21 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081

Richard Biener  changed:

   What|Removed |Added

 Depends on||96208

--- Comment #5 from Richard Biener  ---
PR96208 is the SLP of non-grouped loads.  We now can convert short -> double
and we get with the grouped load hacked and -march=znver3:

.L2:
vmovdqu (%rax), %ymm0
vpermq  $27, -24(%rdi), %ymm10
addq$32, %rax
subq$32, %rdi
vpshufb %ymm7, %ymm0, %ymm0
vpermpd $85, %ymm10, %ymm9
vpermpd $170, %ymm10, %ymm8
vpermpd $255, %ymm10, %ymm6
vpmovsxwd   %xmm0, %ymm1
vextracti128$0x1, %ymm0, %xmm0
vbroadcastsd%xmm10, %ymm10
vcvtdq2pd   %xmm1, %ymm11
vextracti128$0x1, %ymm1, %xmm1
vpmovsxwd   %xmm0, %ymm0
vcvtdq2pd   %xmm1, %ymm1
vfmadd231pd %ymm10, %ymm11, %ymm5
vfmadd231pd %ymm9, %ymm1, %ymm2
vcvtdq2pd   %xmm0, %ymm1
vextracti128$0x1, %ymm0, %xmm0
vcvtdq2pd   %xmm0, %ymm0
vfmadd231pd %ymm8, %ymm1, %ymm4
vfmadd231pd %ymm6, %ymm0, %ymm3
cmpq%rax, %rdx
jne .L2

that is, the 'short' data type forces a higher VF to us and the splat
codegen I hacked in is sub-optimal still.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96208
[Bug 96208] non-grouped load can be SLP vectorized for 2-element vectors case

[Bug tree-optimization/96208] non-grouped load can be SLP vectorized for 2-element vectors case

2023-06-21 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96208

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-21
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|non-power-of-2 group size   |non-grouped load can be SLP
   |can be vectorized for   |vectorized for 2-element
   |2-element vectors case  |vectors case
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Richard Biener  ---
typedef struct {
double m1, m2, m3, m4, m5;
} the_struct_t;

double bar1 (the_struct_t*);

double foo (double* k, unsigned int n, the_struct_t* the_struct)
{
unsigned int u;
the_struct_t result;
for (u=0; u < n; u++, k--) {
result.m1 += (*k)*the_struct[u].m1;
result.m2 += (*k)*the_struct[u].m2;
result.m3 += (*k)*the_struct[u].m3;
result.m4 += (*k)*the_struct[u].m4;
}
return bar1 (&result);
}

This has come up again as part of PR110062

[Bug middle-end/88873] missing vectorization for decomposed operations on a vector type

2023-06-21 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88873

Richard Biener  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
  Component|tree-optimization   |middle-end
   Keywords||ra

--- Comment #4 from Richard Biener  ---
So we "like"

v2df bar (v2df a, v2df b, v2df c)
{
  vector(2) double vect__4.19;
  vect__4.19_19 = .FMA (b_10(D), a_11(D), c_9(D)); [tail call]
  return vect__4.19_19;
}

but foo has the usual ABI issues:

struct s_t foo (struct s_t a, struct s_t b, struct s_t c)
{
  vector(2) double vect__4.13;
  vector(2) double vect__1.12;
  vector(2) double vect__3.9; 
  vector(2) double vect__2.6;
  struct s_t D.4355;
  vect__1.12_14 = MEM  [(double *)&c];
  vect__2.6_12 = MEM  [(double *)&b];
  vect__3.9_13 = MEM  [(double *)&a];
  vect__4.13_15 = .FMA (vect__2.6_12, vect__3.9_13, vect__1.12_14);
  MEM  [(double *)&D.4355] = vect__4.13_15;
  return D.4355;
}

where the argument passing / return value handling gets us

foo:
vmovq   %xmm3, %rax
vmovq   %xmm0, -24(%rsp)
vpinsrq $1, %rax, %xmm2, %xmm7
vmovq   %xmm5, %rax
vmovq   %xmm1, -16(%rsp)
vmovapd %xmm7, %xmm6
vpinsrq $1, %rax, %xmm4, %xmm2
vmovq   %xmm4, -40(%rsp)
vfmadd132pd -24(%rsp), %xmm2, %xmm6
vmovq   %xmm5, -32(%rsp)
vmovapd %xmm6, -56(%rsp)
vmovsd  -48(%rsp), %xmm1
vmovsd  -56(%rsp), %xmm0
ret

that's very weird, we also seem to half-way clean up things but fail to
eliminate the useless vmovq   %xmm5, -32(%rsp) spill for example.

The IBM folks who want to use SRA-style analysis at RTL expansion time
might in the end deal with this as well.

We expand to

(insn 2 21 3 2 (set (reg:DF 91)
(reg:DF 20 xmm0 [ a ])) "t2.c":8:1 -1
 (nil))
(insn 3 2 4 2 (set (reg:DF 92)
(reg:DF 21 xmm1 [ a+8 ])) "t2.c":8:1 -1
 (nil))
(insn 4 3 5 2 (set (reg:TI 90)
(const_int 0 [0])) "t2.c":8:1 -1
 (nil))
(insn 5 4 6 2 (set (subreg:DF (reg:TI 90) 0)
(reg:DF 91)) "t2.c":8:1 -1
 (nil))
(insn 6 5 7 2 (set (subreg:DF (reg:TI 90) 8)
(reg:DF 92)) "t2.c":8:1 -1
 (nil))

so we're using TImode pseudos because the aggregate has TImode but the
accesses should tell us that V2DFmode would be a way better choice
(or alternatively V2DImode in case float modes are too dangerous).

The actual single use is then

(insn 23 20 24 2 (set (reg:V2DF 85 [ vect__4.13 ])
(fma:V2DF (subreg:V2DF (reg/v:TI 93 [ b ]) 0)
(subreg:V2DF (reg/v:TI 89 [ a ]) 0)
(subreg:V2DF (reg/v:TI 97 [ c ]) 0))) "t2.c":9:18 -1
 (nil))

and of course IRA/LRA are not able to deal with this situation nicely,
possibly because of the subreg sets of the TImode pseudo which we
do not split (well, we can't).  We could possibly use STV to handle
some of this though(?)

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

2023-06-21 Thread amacleod at redhat dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251

--- Comment #5 from Andrew Macleod  ---
hmm. yeah. its triggering some kind of pathological edge evaluation between
GORI and cache updating.

There is a long sequence of dependent stmts, presumably the unrolled loop, and
a sequential series of conditions.. ie:
  _4 = (short unsigned int) c.2_1;
  _5 = _4 + 65535;
  a_lsm.19_30 = a;
  _49 = _4 + 65534;
  _12 = _5 & _49;
  _46 = _12 + 65535;
  _48 = _12 & _46;
  _59 = _48 + 65535;
  _60 = _48 & _59;
<...>
if (_12 != 0)
if (_48 != 0)
if (_60 != 0)
<...>
note the interdependence of say _48 and _12.  
Evaluating _48 evaluates _12 and _46.  _46 evaluates _12 as well, and then it
continues..  
Edge evaluation still has no caching, so its calculated as required.  This is
causing a cascading exponential growth of edge evaluations the further we go.

Caching outgoing edge evaluations should resolve this, as would identifying the
situation with 2 operands that have an interdependence and evaluating them
together rather than independently, thus removing the exponential explosion.

still considering...

.

1 2 >

1 - 100 of 131 matches

Mail list logo