[Bug middle-end/23872] .original dump weirdness

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 57968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57968=edit
Patch set that I will be submitting once GCC 15 opens up

[Bug target/114732] ge can't be reversed to unlt for bcd compares

[guihaoc at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from HaoChen Gui  ---
(In reply to Segher Boessenkool from comment #3)
> 1001, 0101, 0011 I mean of course.
> 
> In some ways CCmode models this better than CCFPmode, but we do not actually
> model
> the SO bit (bit 3) at all in CCmode.  It is a nice feature of CCmode (that we
> actually use as fundamental, in the backend code) that CCmode always has
> exactly
> one of three bits "hot" (and CCFPmode always one of four).  Bit 3 (SO) in
> CCmode
> is treated as not being part of the CC really, but an extra thing.  This
> doesn't
> work all that well of course.
> 
> So we really need st least three CC modes:
> 
> -- Exactly one of bits 0..3 hot, like CCFPmode;
> -- Exactly one of bits 0..2 hot, bit 3 independently set, like CCmode (and
>that independent bit 3 modeled nicely as well, unlike what we have), and
>also like in the BCD insns;
> -- Bit 0 is all-true, bit 2 is all-false, like in the vcmp* insns.
> 
> Do we need some other CC mode as well?  Doe we want separately named CC modes
> for the different variants of this (like the integer CC mode vs. the BCD
> one)?
> We already have a separate CCUNSmode which is exactly like CCmode, as far as
> the hardware cares, but the meaning is different (for CCUNS the LT and GT
> bits
> are set based on an unsigned integer compare, not a signed one).  There also
> is CCEQmode, which has only bit 2 valid (we use it for constructing one CR
> bit
> from others, like with cror or crnot).

Thanks for your comment. We also have VSX scalar test data class (xststdc*
insns) which use bit 0 as sign and bit 2 as matched. I think they can share
with vcmp* insns.

Could you advice if rtl code "unorder" is suitable for bcd overflow and invalid
bit test? Or we need to create UNSPECs for overflow and invalid bit test.
Thanks.

[Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Gejoe from comment #4)
> Thanks Andrew for the info.
> 
> So, does this mean that every program which was compiled earlier with one
> step (ie. gcc --coverage srcfile.c)  of gcc/g++ will have to be split to 2
> steps using -c option first and then processing the '.o' file ? Is this
> change documented in the GCC gcov manual well ?
> https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html
> 
> I just happened to see that example today in the "Invoking Gcov" section and
> was thinking if this has to be done going forward for all recent gcc
> versions (post 11.0) or is just confined to version 11.x gcc.

No it was changed for all versions post GCC 11+ (including GCC 11).

[Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0

[gejoed at rediffmail dot com via Gcc-bugs]

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

--- Comment #5 from Gejoe  ---
my previous message is after seeing this change :
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/doc/gcov.texi;h=22e42da2ea66db568e6c563c4f2e619fe2c9ae92;hp=61250c9407e1d0e49a693d0fcc4e4c38d0e6afff;hb=452283bd060eb9bae41199b4b5e7266155d40e12;hpb=862b9b225fba6cf3c63234206f2dbc47f1ab5350

[Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0

[gejoed at rediffmail dot com via Gcc-bugs]

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

--- Comment #4 from Gejoe  ---
Thanks Andrew for the info.

So, does this mean that every program which was compiled earlier with one step
(ie. gcc --coverage srcfile.c)  of gcc/g++ will have to be split to 2 steps
using -c option first and then processing the '.o' file ? Is this change
documented in the GCC gcov manual well ?
https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html

I just happened to see that example today in the "Invoking Gcov" section and
was thinking if this has to be done going forward for all recent gcc versions
(post 11.0) or is just confined to version 11.x gcc.

[Bug testsuite/114744] test case gcc.target/powerpc/builtins-6-p9-runnable.c fails

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-17
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Kewen Lin  ---
This is very very likely a test issue, due to endianness which the load vector
should consider. I'll have a look.

[Bug middle-end/114700] middle-end optimization generates causes -fsanitize=undefined not to happen in some cases

[lin1.hu at intel dot com via Gcc-bugs]

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

--- Comment #20 from Hu Lin  ---
Created attachment 57967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57967=edit
A new version

When I tested this patch, I met another question. g++.dg/ubsan/vla-1.C will
raise a ICE without (TREE_TYPE (@2) == ssizetype at match.pd:3497.

In the original step, GCC generates the intermediate language using variables
declared in other blocks. Like _5 = _1 + 1, this led to the ICE in 022t.ssa. I
don't know if it is a bug, and I didn't find a test to raise this ICE on trunk.
So I add a condition to avoid this optimization in this case, any other
comments on my newly added conditions?



I paste some information that I think is important.

vla-1.C.005t.original:

The original line 12 is 
__builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, (unsigned
long) ((ssizetype) SAVE_EXPR ));

The current is
__builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, (unsigned
long) (((ssizetype) SAVE_EXPR  - 1) + 1));


vla-1.C.006t.gimple
original:
 22   i.0 = i;
 23   if (i.0 <= 0) goto ; else goto ;
 24   :
 25   _1 = (unsigned long) i.0;
 26   __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0,
_1);
 27   goto ;
 28   :
 29   :
 30   _2 = (ssizetype) i.0;
 31   _3 = _2 - 1;

current:
 22   i.0 = i;
 23   if (i.0 <= 0) goto ; else goto ;
 24   :
 25   _1 = (ssizetype) i.0;
 26   _2 = _1 - 1;
 27   _3 = _2 + 1;
 28   _4 = (unsigned long) _3;
 29   __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0,
_4);
 30   goto ;
 31   :
 32   :
 33   _5 = _1 - 1;


vla-1.C.015t.cfg
original:
 37   int i.0;
 38
 39:
 40   saved_stack.5 = __builtin_stack_save ();
 41   i.0 = i;
 42   if (i.0 <= 0)
 43 goto ; [INV]
 44   else
 45 goto ; [INV]
 46
 47:
 48   _1 = (unsigned long) i.0;
 49   __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, _1);
 50
 51:
 52   _2 = (ssizetype) i.0;
 53   _3 = _2 - 1;

current:
 37   int i.0;
 38
 39:
 40   saved_stack.5 = __builtin_stack_save ();
 41   i.0 = i;
 42   if (i.0 <= 0)
 43 goto ; [INV]
 44   else
 45 goto ; [INV]
 46
 47:
 48   _1 = (ssizetype) i.0;
 49   _2 = _1 - 1;
 50   _3 = _2 + 1;
 51   _4 = (unsigned long) _3;
 52   __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, _4);
 53
 54:
 55   _5 = _1 - 1;
 56   _6 = (sizetype) _5;
 57   D.3273 = _6;

[Bug middle-end/23872] .original dump weirdness

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> With the example in PR 86698 with the patches I will be posting, gcc now
> does:
> ```
> ;; Function f (null)
> ;; enabled by -tree-original
> 
> 
> {
>   int x = z++ , y;
> 
>   DECL_EXPR;
>   return x;
> }
> 
> ```
> 
> I am still deciding if we want to print out the DECL_INIT for the DECL_EXPR
> or not. But this seems like a reasonible output so far.

Oh there is still some confusion around the printing of the DECL_INIT for the
decl. Let me fix that ...

[Bug middle-end/23872] .original dump weirdness

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Andrew Pinski  ---
With the example in PR 86698 with the patches I will be posting, gcc now does:
```
;; Function f (null)
;; enabled by -tree-original


{
  int x = z++ , y;

  DECL_EXPR;
  return x;
}

```

I am still deciding if we want to print out the DECL_INIT for the DECL_EXPR or
not. But this seems like a reasonible output so far.

[Bug middle-end/86698] Misleading .original (generic) dump-file contents

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> The semicolon comes from print_declaration So this is just a dup of bug
> 23872 in the end.
> 
> *** This bug has been marked as a duplicate of bug 23872 ***

Actually the semicolon didn't come from there but from COMPOUND_EXPR (but
anyways I am fixing both).

[Bug c/23872] .original dump weirdness

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org

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

[Bug middle-end/86698] Misleading .original (generic) dump-file contents

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Pinski  ---
The semicolon comes from print_declaration So this is just a dup of bug 23872
in the end.

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

[Bug preprocessor/114748] [14 Regression] libcpp aclocal.m4 and configure incorrectly regenerated

[arsen at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Arsen Arsenović  ---
hm, that's odd, my local machine can also regenerate to Cristophes version also
today.. I wonder why it did not back then.. what should we do about it?

[Bug rtl-optimization/114729] RISC-V SPEC2017 507.cactu excessive spillls with -fschedule-insns

[vineetg at gcc dot gnu.org via Gcc-bugs]

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

Vineet Gupta  changed:

   What|Removed |Added

   Last reconfirmed|2024-04-15 00:00:00 |2024-4-16

--- Comment #9 from Vineet Gupta  ---
So I stared with the reg being spilled (a1)

.L2:
beq a1,zero,.L5# if j[1] == 0
li  a2,1
ble a6,s11,.L2# if j[0] < 1
sd  a1,8(sp)# spill (save)


.L3:   # inner loop start
   ...

blt  a2,a6,.L3# inner loop end

ld  a1,8(sp)# spill (restore)
j   .L2

Next was zooming into the inner loop where a1 is being used/clobbered by sched1
and not w/o sched1 with my rudimentary define, use, dead annotation.

--
-fschedule-insns (NOK)   | -fno-schedule-insns (OK)
--
1-def  lda5,%lo(u)(s0) #u, u | 1-def   lda5,%lo(u)(t6)  # u, u
2-def  srliw a0,a5,16| 2-def   srliw s10,a5,16
3-def  srli  a1,a5,32| 1-use   sha5,%lo(_Z1sv)(a4)
1-use  sha5,%lo(_Z1sv)(a3)   | 2-dead  shs10,%lo(_Z1sv+2)(a4)
  ---insn1---| 3-def   srli  s10,a5,32
1-use  srli  a5,a5,48| 1-use   srli  a5,a5,48
  ---insn2---| 1-dead  sha5,%lo(_Z1sv+6)(a4)
2-dead sha0,%lo(_Z1sv+2)(a3) |  ---insn1---
3-dead sha1,%lo(_Z1sv+4)(a3) |  ---insn2---
1-dead sha5,%lo(_Z1sv+6)(a3) | 3-dead  shs10,%lo(_Z1sv+4)(a4)

The problem seems to be longer live range of 2-def (on left side). If it was
used/dead right afte, 3-def won't need a new register.

With that insight, I can now start looking into the sched1 dumps of the
corresponding BB.

;;   10--> b  0: i  35 r170#0=[r242+low(`u')] 
:alu:@GR_REGS+1(1)@FP_REGS+0(0)
;;   11--> b  0: i  79 r209=[r229+low(`f')]   
:alu:GR_REGS+0(0)FP_REGS+1(1)
;;   12--> b  0: i  76 r141=fix(r206) 
:alu:@GR_REGS+1(1)@FP_REGS+0(-1)
;;   13--> b  0: i  46 r180=zxt(r170,0x10,0x10)   
:alu:@GR_REGS+1(1)@FP_REGS+0(0)
;;   14--> b  0: i  55 r188=r170 0>>0x20  
:alu:GR_REGS+1(1)FP_REGS+0(0)
;;   15--> b  0: i  81 r210=r141<<0x3 
:alu:GR_REGS+1(0)FP_REGS+0(0)
;;   16--> b  0: i  82 r211=r143+r210 
:alu:GR_REGS+1(0)FP_REGS+0(0)
;;   17--> b  0: i  44 [r230+low(`_Z1sv')]=r170#0 
:alu:@GR_REGS+0(0)@FP_REGS+0(0)
;;   18--> b  0: i  65 r197=r170 0>>0x30  
:alu:GR_REGS+1(0)FP_REGS+0(0)
;;   19--> b  0: i  54 [r230+low(const(`_Z1sv'+0x2))]=r180#0  
:alu:@GR_REGS+0(-1)@FP_REGS+0(0)
;;   20--> b  0: i  64 [r230+low(const(`_Z1sv'+0x4))]=r188#0  
:alu:GR_REGS+0(-1)FP_REGS+0(0)
;;   21--> b  0: i  73 [r230+low(const(`_Z1sv'+0x6))]=r197#0  
:alu:GR_REGS+0(-1)FP_REGS+0(0)

[Bug preprocessor/114748] [14 Regression] libcpp aclocal.m4 and configure incorrectly regenerated

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-04-16
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
r14-5424-gdb50aea6259545 didn't properly regenerate aclocal.m4.

[Bug tree-optimization/114749] New: [14] RISC-V rv64gcv ICE: in vectorizable_load, at tree-vect-stmts.cc

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114749
   Summary: [14] RISC-V rv64gcv ICE: in vectorizable_load, at
tree-vect-stmts.cc
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 57966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57966=edit
-freport-bug output

Testcase:
extern int a[];
extern char b[];
int c = 24;
_Bool d[24][24][24];
_Bool (*e)[24][24] = d;
int main() {
  for (short f = 0; f < 24; f += 3)
for (unsigned g = 0; g < (char)c; g += 2) {
  a[f] = 0;
  b[g] |= ({ e[f][f][f]; });
}
}

Backtrace:
> /scratch/tc-testing/tc-apr-15/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -fwhole-program -O3 -mrvv-vector-bits=zvl red.c -o red.out
during GIMPLE pass: vect
./red.c: In function 'main':
./red.c:6:5: internal compiler error: in vectorizable_load, at
tree-vect-stmts.cc:10239
6 | int main() {
  | ^~~~
0xbd26d1 vectorizable_load
../../../gcc/gcc/tree-vect-stmts.cc:10239
0x26dc7b7 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
../../../gcc/gcc/tree-vect-stmts.cc:13274
0x15ec172 vect_analyze_loop_operations
../../../gcc/gcc/tree-vect-loop.cc:2208
0x15ec172 vect_analyze_loop_2
../../../gcc/gcc/tree-vect-loop.cc:3041
0x15ede80 vect_analyze_loop_1
../../../gcc/gcc/tree-vect-loop.cc:3481
0x15ee619 vect_analyze_loop(loop*, vec_info_shared*)
../../../gcc/gcc/tree-vect-loop.cc:3639
0x16362f4 try_vectorize_loop_1
../../../gcc/gcc/tree-vectorizer.cc:1066
0x16362f4 try_vectorize_loop
../../../gcc/gcc/tree-vectorizer.cc:1182
0x1636c1c execute
../../../gcc/gcc/tree-vectorizer.cc:1298
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Discovered/tested using r14-9976-gf8409c3109d (not bisected)

Found via fuzzer.

[Bug preprocessor/114748] [14 Regression] libcpp aclocal.m4 and configure incorrectly regenerated

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Version|unknown |14.0
Summary|libcpp aclocal.m4 and   |[14 Regression] libcpp
   |configure incorrectly   |aclocal.m4 and configure
   |regenerated |incorrectly regenerated
   Target Milestone|--- |14.0

--- Comment #3 from Andrew Pinski  ---
This is a regression from GCC 13.1.0 release. Tracking down when it changed ...

[Bug preprocessor/114748] libcpp aclocal.m4 and configure incorrectly regenerated

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
So I went back to the gcc 9.1.0 release and aclocal there didn't change and
didn't have the include for override.m4 . I am trying to figure out where this
changed ...

[Bug libfortran/112364] calloc used incorrectly

[peter0x44 at disroot dot org via Gcc-bugs]

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

Peter Damianov  changed:

   What|Removed |Added

 CC||peter0x44 at disroot dot org

--- Comment #14 from Peter Damianov  ---
../../gcc/gcc/../libgcc/libgcov-util.c: In function 'void tag_counters(unsigned
int, int)':
../../gcc/gcc/../libgcc/libgcov-util.c:214:59: warning: 'void* calloc(size_t,
size_t)' sizes specified with 'sizeof' in the earlier argument and not in the
later argument [-Wcalloc-transposed-args]
  214 |   k_ctrs[tag_ix].values = values = (gcov_type *) xcalloc (sizeof
(gcov_type),
  |  
^~
../../gcc/gcc/../libgcc/libgcov-util.c:214:59: note: earlier argument should
specify number of elements, later size of each element

../../gcc/gcc/../libgcc/libgcov-util.c: In function 'void
topn_to_memory_representation(gcov_ctr_info*)':
../../gcc/gcc/../libgcc/libgcov-util.c:529:43: warning: 'void* calloc(size_t,
size_t)' sizes specified with 'sizeof' in the earlier argument and not in the
later argument [-Wcalloc-transposed-args]
  529 | = (struct gcov_kvp *)xcalloc (sizeof (struct gcov_kvp), n);
  |   ^~~~
../../gcc/gcc/../libgcc/libgcov-util.c:529:43: note: earlier argument should
specify number of elements, later size of each element

I found a two more instances of this in libgcov-util.c

Personally I don't agree with this warning at all, it's FAR too spammy for what
it is, considering it never actually catches a real defect, but rather a minor
style choice that (IMO) does not affect readability in any case. Whether I see
sizeof in the first or second argument doesn't affect my understanding of the
code.

In a static analyzer, fine, but I think in GCC, no.

But I guess the same solution should be taken for this one, too, if it's an
issue in libgfortran also.

[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jerry DeLisle  ---
Created attachment 57965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57965=edit
Preliminary patch to fix several issues.

The attached patch is very preliminary and appears to fix the X format issue
and does some code factoring. I have yet to explore the same situation with TR
following the 19 '.' printed.  This also fixes the problem with embedded
garbage in the output.

It does regression test with the new test cases, so getting close.

[Bug preprocessor/114748] libcpp aclocal.m4 and configure incorrectly regenerated

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
The last time aclocal.m4 had an include for override.m4 was
r9-3776-g22e052725189a4 .  Are you sure you are using the correct
autoconf/automake version?

[Bug modula2/114745] const cast causes ICE

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r14-9998-geadd05d5601063bd0c7ef6c3606b4eeb856d57d7
Author: Gaius Mulley 
Date:   Tue Apr 16 23:08:43 2024 +0100

PR modula2/114745: const cast causes ICE

This patch allows SYSTEM.CAST to be used during a const expression and
prevents an ICE.

gcc/m2/ChangeLog:

PR modula2/114745
* gm2-compiler/M2Code.mod (DumpLangDecl): Replace with ...
(GetDumpDecl): ... this.
(DumpLangGimple): Replace with ...
(GetDumpGimple): ... this.
* gm2-compiler/M2GenGCC.mod:
* gm2-compiler/M2LangDump.mod (GetDumpLangQuadFilename): Replace
with ...
(GetDumpQuadFilename): ... this.
(GetDumpLangDeclFilename): Replace with ...
(GetDumpDeclFilename): ... this.
(GetDumpLangGimpleFilename): Replace with ...
(GetDumpGimpleFilename): ... this.
* gm2-compiler/M2Options.def (GetDumpLangDeclFilename): New
procedure function.
(GetDumpDeclFilename): Ditto.
(SetDumpLangDeclFilename): New procedure.
(SetDumpDeclFilename): Ditto.
(GetDumpLangQuadFilename): New procedure function.
(GetDumpQuadFilename): Ditto
(SetDumpLangQuadFilename): New procedure.
(SetDumpQuadFilename): Ditto.
(GetDumpLangGimpleFilename): New procedure function.
(GetDumpGimpleFilename): Ditto.
(SetDumpLangGimpleFilename): New procedure.
(SetDumpGimpleFilename): Ditto.
(GetDumpLangGimple): New procedure function.
(SetM2Dump): New procedure.
(GetDumpGimple): New procedure function.
(GetDumpQuad): Ditto.
(GetDumpDecl): Ditto.
* gm2-compiler/M2Options.mod (DumpLangDeclFilename): Remove.
(DumpLangQuadFilename): Ditto.
(DumpLangGimpleFilename): Ditto.
(DumpDeclFilename): New variable.
(DumpQuadFilename): Ditto.
(DumpGimpleFilename): Ditto.
(DebugTraceTree): New variable.
(SetQuadDebugging): Rewrite.
(GetDumpLangDeclFilename): Replace with ...
(GetDumpDeclFilename): ... this.
(SetDumpLangQuadFilename): Replace with ...
(SetDumpQuadFilename): ... this.
(GetDumpLangGimpleFilename): Replace with ...
(GetDumpGimpleFilename): ... this.
(SetDumpLangGimpleFilename): Replace with ...
(SetDumpGimpleFilename): ... this.
(GetDumpLangGimple): Remove.
(MatchDump): New procedure function.
(SetM2Dump): New procedure.
(GetDumpGimple): New procedure function.
(GetDumpQuad): Ditto.
(GetDumpDecl): Ditto.
(GetDumpLangGimple): Ditto.
* gm2-compiler/M2Quads.mod (BreakAtQuad): Assigned to 140.
(BuildTypeCoercion): Add ConstExpr parameter.
Check for const parameter in a const expression.
Create a constant temporary if in a const expression.
(BuildCastFunction): Pass ConstExpr to BuildTypeCoercion.
(BuildFunctionCall): Pass ConstExpr to BuildTypeCoercion.
* gm2-compiler/PCSymBuild.mod (buildConstFunction): Test for Cast
and call InitConvert.
(ErrorConstFunction): Add CAST to the error message.
* gm2-compiler/SymbolTable.mod (GetConstStringContent): Remove
unused procedure.
* gm2-gcc/m2decl.cc (m2decl_DeclareKnownConstant): Copy value
and change type of value.
* gm2-gcc/m2options.h (M2Options_GetDumpLangDeclFilename): Remove.
(M2Options_SetDumpLangDeclFilename): Ditto.
(M2Options_GetDumpLangQuadFilename): Ditto.
(M2Options_SetDumpLangQuadFilename): Ditto.
(M2Options_GetDumpLangGimpleFilename): Ditto.
(M2Options_SetDumpLangGimpleFilename): Ditto.
(M2Options_GetDumpLangGimple): Ditto.
(M2Options_GetDumpDeclFilename): New function.
(M2Options_SetDumpDeclFilename): Ditto.
(M2Options_GetDumpQuadFilename): Ditto.
(M2Options_SetDumpQuadFilename): Ditto.
(M2Options_GetDumpGimpleFilename): Ditto.
(M2Options_SetDumpGimpleFilename): Ditto.
(M2Options_SetM2Dump): Ditto.
(M2Options_GetDumpGimple): Ditto.
* gm2-gcc/m2pp.cc (GM2): New define.
(m2pp_type_lowlevel): Remove linefeed.
(m2pp_identifier): Add type description for const.
(m2pp_assignment): Display lhs/rhs types.
(m2pp_dump_gimple): Replace GetDumpLangGimple with GetDumpGimple.
* gm2-lang.cc (ENABLE_QUAD_DUMP_ALL): 

[Bug other/114748] New: libcpp aclocal.m4 and configure incorrectly regenerated

[clyon at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 114748
   Summary: libcpp aclocal.m4 and configure incorrectly
regenerated
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Running either 'autoreconf' or 'aclocal -I ../config' in libcpp/ generates
aclocal.m4 and configure scripts with slightly different contents from what is
currently in the repo:

diff --git a/libcpp/aclocal.m4 b/libcpp/aclocal.m4
index 4fc81709622..4d898ea2c97 100644
--- a/libcpp/aclocal.m4
+++ b/libcpp/aclocal.m4
@@ -26,6 +26,7 @@ m4_include([../config/lib-ld.m4])
 m4_include([../config/lib-link.m4])
 m4_include([../config/lib-prefix.m4])
 m4_include([../config/nls.m4])
+m4_include([../config/override.m4])
 m4_include([../config/po.m4])
 m4_include([../config/progtest.m4])
 m4_include([../config/warnings.m4])
diff --git a/libcpp/configure b/libcpp/configure
index 8a38c0546e3..930f2d59307 100755
--- a/libcpp/configure
+++ b/libcpp/configure
@@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu



+
+
+
 ac_aux_dir=
 for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do
   if test -f "$ac_dir/install-sh"; then


Are these files incorrect in the repo?

I tried to remove ../config/override.m4 and run either 'autoreconf' or 'aclocal
-I ../config', then the result is the same as what is in the repo: override.m4
is not needed by libcpp, but still analyzed by aclocal, and it does have a
sligh effect when generating configure.


Is the fix to commit the above differences, or is there another recipe to
regenerate these files?

[Bug target/114747] [13 only] [RISC-V RVV] Wrong SEW set for mixed-size intrinsics

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.3

[Bug c++/114747] New: [RISC-V RVV] Wrong SEW set for mixed-size intrinsics

[wojciech_mula at poczta dot onet.pl via Gcc-bugs]

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

Bug ID: 114747
   Summary: [RISC-V RVV] Wrong SEW set for mixed-size intrinsics
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wojciech_mula at poczta dot onet.pl
  Target Milestone: ---

This is a distilled procedure from simdutf project:

---
#include 
#include 
#include 

size_t convert_latin1_to_utf16le(const char *src, size_t len, char16_t *dst) {
  char16_t *beg = dst;
  for (size_t vl; len > 0; len -= vl, src += vl, dst += vl) {
vl = __riscv_vsetvl_e8m4(len);
vuint8m4_t v = __riscv_vle8_v_u8m4((uint8_t*)src, vl);
__riscv_vse16_v_u16m8((uint16_t*)dst, __riscv_vzext_vf2_u16m8(v, vl), vl);
  }
  return dst - beg;
}
---

When compiled with gcc 13.2.0 with flags "-march=rv64gcv -O2" it sets a wrong
SEW:

---
convert_latin1_to_utf16le(char const*, unsigned long, char16_t*):
beq a1,zero,.L4
mv  a4,a2
.L3:
vsetvli a5,a1,e8,m4,ta,ma  # set SEW=8
vle8.v  v8,0(a0)
sllia3,a5,1
vzext.vf2   v24,v8 # illegal instruction, as SEW/2 < 8
sub a1,a1,a5
vse16.v v24,0(a4)
add a0,a0,a5
add a4,a4,a3
bne a1,zero,.L3
sub a0,a4,a2
sraia0,a0,1
ret
.L4:
li  a0,0
ret
---

The trunk available on godbold.org (riscv64-unknown-linux-gnu-g++ 14.0.1
20240415) emits vsetvli with e16 argument, which seems to be fine.

[Bug ipa/108383] g++ ICE with -O3 and -flto and -fdeclone-ctor-dtor on simple function

[peter0x44 at disroot dot org via Gcc-bugs]

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

Peter Damianov  changed:

   What|Removed |Added

 CC||peter0x44 at disroot dot org

--- Comment #7 from Peter Damianov  ---
I believe I'm encountering this same bug with cppcheck, when building with
-flto -Os.

during GIMPLE pass: alias
lib/check64bit.h: In member function 'classInfo':
lib/check64bit.h:81:17: internal compiler error: in binds_to_current_def_p, at
symtab.cc:2497
   81 | std::string classInfo() const override {
  | ^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

This is with gcc 13.2.0

ext  := $(shell find externals -mindepth 1 -type d)
src  := $(shell find cli lib externals -name '*.cpp')
obj  := $(src:.cpp=.o)
CXXFLAGS := -w -Os -Ilib $(addprefix -I,$(ext)) -flto=auto
cppcheck.exe: $(obj)
x86_64-w64-mingw32-g++ -s -o $@ $(obj) -lshlwapi -flto=auto -Os -s

Place this makefile in the root of the repo, and run it.
(there is an existing one that didn't work for me, hence I named it
"cppcheck.mak")

make -f cppcheck.mak

Hope this helps!

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #30 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r14-9997-gf438acf7ce2e6cb862cf62f2543c36639e2af233
Author: Tamar Christina 
Date:   Tue Apr 16 20:56:26 2024 +0100

testsuite: Fix data check loop on vect-early-break_124-pr114403.c

The testcase had the wrong indices in the buffer check loop.

gcc/testsuite/ChangeLog:

PR tree-optimization/114403
* gcc.dg/vect/vect-early-break_124-pr114403.c: Fix check loop.

[Bug driver/114330] needs_preprocessing field of struct compiler is unused

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
The most annoying part of this is the struct compiler is initialized by
*/lang-specs.h and it looks like I missed one and the error message is not so
obvious where the issue is.

[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
We're running into code in primary.cc modified at r14-9489-g3fd46d859cda10
which checks for inquiry references.

CC'ing Paul.

[Bug target/114741] [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Tamar Christina  ---
and the exact armv9-a cost model you quoted, also does the right codegen.
https://godbolt.org/z/obafoT6cj

There is just an inexplicable penalty being applied to the r->r alternative.

[Bug target/114741] [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #5 from Tamar Christina  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Wilco from comment #2)
> > It looks like the underlying bug is '^' being incorrectly treated like '?'
> > in record_reg_classes (which is never used during reload). Fixing that
> > results in the expected code being generated in all cases. It looks this
> > issue was introduced in the original commit
> > d1457701461d5a49ca6b5d8a6d1c83a37a6dc771
> 
> static const struct cpu_regmove_cost generic_armv9_a_regmove_cost =
> {
>   1, /* GP2GP  */
>   /* Spilling to int<->fp instead of memory is recommended so set
>  realistic costs compared to memmov_cost.  */
>   3, /* GP2FP  */
>   2, /* FP2GP  */
>   2 /* FP2FP  */
> };
> 
> 
> Note these costs are broken.
> TARGET_REGISTER_MOVE_COST  has this to say about the special value 2:
> ```
> If reload sees an insn consisting of a single set between two hard
> registers, and if TARGET_REGISTER_MOVE_COST applied to their classes returns
> a value of 2, reload does not check to ensure that the constraints of the
> insn are met. Setting a cost of other than 2 will allow reload to verify
> that the constraints are met. You should do this if the ‘movm’ pattern’s
> constraints do not allow such copying.
> ```
> 
> The way I implemented this for thunderx was have GP2GP being cost of 2 and
> then be relative from there. That gave better code generation in general and
> even less spilling. I know I wrote about this before too.

I don't think this is related to this at all
the old generic costs, which armv8 was taken from doesn't use 2, and is broken
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/tuning_models/generic.h#L42
generic-armv8-a doesn't use 2 and is broken
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/tuning_models/generic_armv8_a.h#L43
neoverse-n2 uses 2 and isn't broken
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/tuning_models/neoversen2.h

I think the issue is what Wilco mentioned before. 
The GCC docs claim that ^ shouldn't affect initial costing/IRA, but it clearly
does.

it's penalizing the r->r alternative during initial costing and not just during
lra if a reload is needed.

so the question to Vlad is it correct that ^ is treated the same way as ?
during initial costing? i.e. it's penalizing the alternative.

[Bug driver/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #17 from Andrew Pinski  ---
Testing the removal of the code from the driver.

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-04-16

--- Comment #11 from Andrew Pinski  ---
Testing removal of this part from the driver.

[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Reduced testcase:

program main
  implicit complex(z)
  z2%re = 1.
  z2%im = 2.
end

[Bug fortran/113793] malloc abort on character allocate with source argument

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14.

Thanks for the report!

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #33 from Jakub Jelinek  ---
It regresses
g++.dg/coroutines/torture/co-await-16-template-traits.C
g++.dg/cpp0x/pr89403.C
g++.dg/tree-ssa/pr46228.C
g++.dg/torture/pr104601.C
g++.dg/torture/pr89303.C
g++.dg/torture/pr91606.C
on i686-linux, so I'll need to work on this some more.

[Bug modula2/114745] const cast causes ICE

[gaius at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 57964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57964=edit
Proposed fix

Here is a proposed patch and the example test run:

$ gm2 -fiso -c -I. -I../ Dictionary.mod -fsources
Compiling: Dictionary.mod
Pass 0: lexical analysis, parsing, modules and associated filenames
   Module SYSTEM   :
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.1/m2/m2iso/SYSTEM.def [m2iso]
   Module M2RTS:
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.1/m2/m2iso/M2RTS.def [m2iso]
   Module RTExceptions :
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.1/m2/m2pim/RTExceptions.def
[m2pim]
   Module Dictionary   : ./Dictionary.def
   Module Dictionary   : Dictionary.mod
   Module String   : ../String.def
   Module Proc : ./Proc.def
   Module Storage  :
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.1/m2/m2iso/Storage.def [m2iso]
   Module StrBlank : ./StrBlank.def
Pass 1: scopes, enumerated types, imports and exports
Pass 2: constants and types
Pass C: aggregate constants
Pass 3: quadruple generation
Pass 4: gcc tree generation
symbols to gcc trees
statements to gcc trees
gcc trees given to the gcc backend

$ gm2 -fiso constcast.mod 
$

[Bug target/114741] [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Wilco from comment #2)
> It looks like the underlying bug is '^' being incorrectly treated like '?'
> in record_reg_classes (which is never used during reload). Fixing that
> results in the expected code being generated in all cases. It looks this
> issue was introduced in the original commit
> d1457701461d5a49ca6b5d8a6d1c83a37a6dc771

static const struct cpu_regmove_cost generic_armv9_a_regmove_cost =
{
  1, /* GP2GP  */
  /* Spilling to int<->fp instead of memory is recommended so set
 realistic costs compared to memmov_cost.  */
  3, /* GP2FP  */
  2, /* FP2GP  */
  2 /* FP2FP  */
};


Note these costs are broken.
TARGET_REGISTER_MOVE_COST  has this to say about the special value 2:
```
If reload sees an insn consisting of a single set between two hard registers,
and if TARGET_REGISTER_MOVE_COST applied to their classes returns a value of 2,
reload does not check to ensure that the constraints of the insn are met.
Setting a cost of other than 2 will allow reload to verify that the constraints
are met. You should do this if the ‘movm’ pattern’s constraints do not allow
such copying.
```

The way I implemented this for thunderx was have GP2GP being cost of 2 and then
be relative from there. That gave better code generation in general and even
less spilling. I know I wrote about this before too.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Vincent Lefèvre from comment #17)
> (In reply to Jonathan Wakely from comment #13)
> > -fexcess-precision does affect constants.
> 
> Indeed, and this is a bug, as -fexcess-precision=fast was not meant to make
> general programs less accurate (but to possibly keep more precision
> internally, avoiding costly conversions, even in cases where this is
> forbidden). See bug 114746.

No that is NOT true.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #17 from Vincent Lefèvre  ---
(In reply to Jonathan Wakely from comment #13)
> -fexcess-precision does affect constants.

Indeed, and this is a bug, as -fexcess-precision=fast was not meant to make
general programs less accurate (but to possibly keep more precision internally,
avoiding costly conversions, even in cases where this is forbidden). See bug
114746.

[Bug c/114746] New: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Bug ID: 114746
   Summary: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast
reduces the precision of floating-point constants
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

-fexcess-precision was added to resolve bug 323, so that with
-fexcess-precision=standard, after an assignment or a cast, the value is
converted to its semantic type; this conversion makes the program slower, hence
-fexcess-precision=fast to have faster programs *without sacrificing their
accuracy* in average (except for programs that are based on such a conversion).
Said otherwise, the values may be kept with more precision than normally
expected.

Thus it is not expected that -fexcess-precision=fast reduces the precision of a
value.

However, with FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the
precision of floating-point constants compared to what is specified by the
standard. This is a much worse issue.

Testcase:

#include 
#include 

int main (void)
{
  printf ("FLT_EVAL_METHOD = %d\n", FLT_EVAL_METHOD);
  printf ("%La\n%La\n", 1e-8L, (long double) 1e-8);
  printf ("%a\n%a\n", (double) 1e-8, (double) 1e-8f);
  return 0;
}

With GCC 14.0.1 20240330 (experimental) [master r14-9728-g6fc84f680d0] using
-m32 -fexcess-precision=fast, I get:

FLT_EVAL_METHOD = 2
0xa.bcc77118461cefdp-30
0xa.bcc77118461dp-30
0x1.5798ee2308c3ap-27
0x1.5798eep-27

instead of the expected output (e.g. by using -fexcess-precision=standard)

FLT_EVAL_METHOD = 2
0xa.bcc77118461cefdp-30
0xa.bcc77118461cefdp-30
0x1.5798ee2308c3ap-27
0x1.5798ee2308c3ap-27

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #16 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #15)
> There is no bug, the compiler implements what the standard says for the
> FLT_EVAL_METHOD == 2 case.

I agree. I meant this *invalid* bug.

[Bug c/114723] ICE when checking for type compatibility with structure that contains flexible array member (C23)

[luigighiron at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Halalaluyafail3  ---
(In reply to Richard Biener from comment #1)
> This seems to be fixed recently?

I just tested the code on godbolt again, and it doesn't seem to generate an ICE
anymore. However, it does seem to generate "incompatible" which seems to be
incorrect unless there is something that I missed in the standard which would
make these types incompatible.

[Bug fortran/114467] f951: internal compiler error: Segmentation fault

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to thomas from comment #3)
> (In reply to anlauf from comment #1)
> > Can you attached a self-contained reproducer?
> > 
> > The traceback looks familiar.  Are you by chance using an associate
> > construct?  There has been a fix backported from 14-mainline to 13-branch
> > after the release of 13.2, so it might have been fixed in the meantime.
> > 
> > (Likely a dup of pr109948).
> 
> Just to be on the safe side, would gcc 13.2.0 from 2023-07-27 be the right
> version to test?

No.  The backport was applied to 13-branch on 2023-08-27.

I'd recommend to use a more recent snapshot of 13-branch.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
There is no bug, the compiler implements what the standard says for the
FLT_EVAL_METHOD == 2 case.
If you want in that mode a constant guaranteed to be in double precision, you
need to explicitly cast the constant to double, otherwise it will have long
double precision with type of double and that extra precision is only rounded
to double precision on casts and assignments.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #14 from Vincent Lefèvre  ---
This bug is about "double/float constant evaluation" (and it has been marked as
a duplicate of a bug precisely on this subject), not about the rules that are
applied *after* this evaluation.

[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||rejects-valid
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Priority|P3  |P4
   Last reconfirmed||2024-04-16

--- Comment #3 from anlauf at gcc dot gnu.org ---
We fail to figure out that z2 is complex.

Adding
  complex z2
avoid the issues.

Not really a regression except for the ICE, since we falsely rejected the code
up to 13.

[Bug fortran/113793] malloc abort on character allocate with source argument

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:48024a99e3c2ae522d0026eedd591390506b68ca

commit r14-9996-g48024a99e3c2ae522d0026eedd591390506b68ca
Author: Harald Anlauf 
Date:   Sat Apr 13 19:09:24 2024 +0200

Fortran: ALLOCATE of fixed-length CHARACTER with SOURCE/MOLD [PR113793]

F2008 requires for ALLOCATE with SOURCE= or MOLD= specifier that the kind
type parameters of allocate-object and source-expr have the same values.
Add compile-time diagnostics for different character length and a runtime
check (under -fcheck=bounds).  Use length from allocate-object to prevent
heap corruption and to allow string padding or truncation on assignment.

gcc/fortran/ChangeLog:

PR fortran/113793
* resolve.cc (resolve_allocate_expr): Reject ALLOCATE with SOURCE=
or MOLD= specifier for unequal length.
* trans-stmt.cc (gfc_trans_allocate): If an allocatable character
variable has fixed length, use it and do not use the source length.
With bounds-checking enabled, add a runtime check for same length.

gcc/testsuite/ChangeLog:

PR fortran/113793
* gfortran.dg/allocate_with_source_29.f90: New test.
* gfortran.dg/allocate_with_source_30.f90: New test.
* gfortran.dg/allocate_with_source_31.f90: New test.

[Bug target/114741] [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-16
 Status|UNCONFIRMED |NEW
 CC||pinskia at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug other/114738] [14 Regression] Default DOCUMENTATION_ROOT_URL vs. release branches

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
.

[Bug target/114732] ge can't be reversed to unlt for bcd compares

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Segher Boessenkool  ---
(Or, at-most-one-hot, that is!)

[Bug target/114732] ge can't be reversed to unlt for bcd compares

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Segher Boessenkool  ---
(In reply to Segher Boessenkool from comment #3)
> -- Bit 0 is all-true, bit 2 is all-false, like in the vcmp* insns.

(And bits 1 and 3 are set to zeroes for those insns.  So it is all one-hot
there
as well.  But the meaning is different.)

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #32 from Jakub Jelinek  ---
Created attachment 57963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57963=edit
gcc14-pr113208.patch

Ah, I shouldn't call expand_or_defer* in that function, that has been called
already earlier and causes e.g. redefined_extern_inline.

[Bug target/114741] [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

[wilco at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Wilco  ---
It looks like the underlying bug is '^' being incorrectly treated like '?' in
record_reg_classes (which is never used during reload). Fixing that results in
the expected code being generated in all cases. It looks this issue was
introduced in the original commit d1457701461d5a49ca6b5d8a6d1c83a37a6dc771

[Bug sanitizer/114743] ICE in build_check_stmt at asan.cc:2707 while compiling gcc.dg/ubsan/pr112709-2.c with -fsanitize=address

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2024-04-16
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jakub Jelinek  ---
Created attachment 57962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57962=edit
gcc14-pr114743.patch

Untested fix.

[Bug c/92880] Documentation for Built-in Vector-Extensions should mention C99 Fixed-width ints as base types

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #7 from Andrew Pinski  ---
Documentation has been updated to include typedefs (though not using typedefs
as an example).

[Bug libstdc++/57585] New --enable-clocale model using POSIX 2008

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
Created attachment 57961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57961=edit
Add --enable-clocale=ieee_1003.1-2008

This is an initial prototype of a new clocale model.

The wide string info needs to be transcoded from the narrow string info,
because unlike Glibc, POSIX doesn't provide wide character versions of
nl_langinfo items like _NL_WMON_1

[Bug c/92880] Documentation for Built-in Vector-Extensions should mention C99 Fixed-width ints as base types

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:8eddd87da2dd01c841f9742f973f65ebe0a88e71

commit r14-9994-g8eddd87da2dd01c841f9742f973f65ebe0a88e71
Author: Andrew Pinski 
Date:   Mon Apr 15 17:13:36 2024 -0700

Document that vector_size works with typedefs [PR92880]

This just adds a clause to make it more obvious that the vector_size
attribute extension works with typedefs.
Note this whole section needs a rewrite to be a similar format as other
extensions. But that is for another day.

gcc/ChangeLog:

PR c/92880
* doc/extend.texi (Using Vector Instructions): Add that
the base_types could be a typedef of them.

Signed-off-by: Andrew Pinski 

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #31 from Jakub Jelinek  ---
Created attachment 57960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57960=edit
gcc14-pr113208.patch

Here is my attempt to optimize it in the C++ FE.
The ICE is gone and for pr113208_0.C compiled with -std=c++20 -O1
-fkeep-inline-functions it emits the desirable
_ZN6vectorI12QualityValueEC2ERKS1_ ctor in the
_ZN6vectorI12QualityValueEC5ERKS1_ comdat group as well as an alias to it.
But, compared to e.g. 13.2.1, the alias is for some reason no longer inlined
into _ZN1kC2ERKS_ call.
Honza, any ideas what I'm doing wrong?

[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Created attachment 57959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57959=edit
F90 source code

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Jonathan Wakely  ---
-fexcess-precision does affect constants.

With -fexcess-precision=standard, assignments and casts discard excess
precision which may otherwise be present in arithmetic expressions and
constants. With -fexcess-precision=fast the excess precision might be retained
even after casts and assignments, or it might be discarded at other points.

But in both cases, a floating constant might have excess precision. Whether
that excess precision is discarded, and when it's discarded, is affected by
-fexcess-precision.

[Bug target/114741] [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

[wilco at gcc dot gnu.org via Gcc-bugs]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #1 from Wilco  ---
This example always goes wrong:

void foo2(unsigned *p)
{
*p &= 1;
}

Eg. with -mcpu=neoverse-v1:

ldr s31, [x0]
and z31.s, z31.s, #1
str s31, [x0]
ret

This doesn't make any sense since there are usually fewer vector units than
integer ALUs, and the typically have higher latency.

[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #1 from kargls at comcast dot net ---
Please attach a the source code.

[Bug target/113790] [14 Regression][riscv64] ICE in curr_insn_transform, at lra-constraints.cc:4294 since r14-4944-gf55cdce3f8dd85

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #4 from Andreas Schwab  ---
*** Bug 114255 has been marked as a duplicate of this bug. ***

[Bug target/114255] [RISC-V] [RVV] unable to find a register to spill

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #2 from Andreas Schwab  ---


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

[Bug modula2/114745] const cast causes ICE

[gaius at gcc dot gnu.org via Gcc-bugs]

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-16

--- Comment #1 from Gaius Mulley  ---
wrong test program (above).  The test which causes the ICE can be reduced to
the example here:

MODULE constcast ;

FROM SYSTEM IMPORT CAST ;

CONST Nil = CAST (PROC, NIL) ;

BEGIN
END constcast.

$ gm2 -fiso constcast.mod
cc1gm2: internal compiler error: symbol out of bounds
0x840837 m2linemap_internal_error
../../gcc/m2/gm2-gcc/m2linemap.cc:253
0x90b74b M2Emit_InternalError
m2/gm2-compiler-boot/M2Emit.c:102
0x86fa8b M2Error_InternalError
m2/gm2-compiler-boot/M2Error.c:2651
0x8d117b GetPsym
m2/gm2-compiler-boot/SymbolTable.c:4610
0x8d117b GetPsym
m2/gm2-compiler-boot/SymbolTable.c:4599
0x8d117b SymbolTable_IsSubrange
m2/gm2-compiler-boot/SymbolTable.c:18569
0x865587 M2Base_IsOrdinalType
m2/gm2-compiler-boot/M2Base.c:3195
0x8c05bf TypeToMeta
m2/gm2-compiler-boot/PCSymBuild.c:1173
0x8c05bf TypeToMeta
m2/gm2-compiler-boot/PCSymBuild.c:1152
0x8c13d7 buildConstFunction
m2/gm2-compiler-boot/PCSymBuild.c:1233
0x8c13d7 PCSymBuild_PushConstFunctionType
m2/gm2-compiler-boot/PCSymBuild.c:2698
0x8f5ebb ConstructorOrConstActualParameters
m2/gm2-compiler-boot/PCBuild.c:4460
0x8f5ebb ConstSetOrQualidentOrFunction
m2/gm2-compiler-boot/PCBuild.c:4508
0x8f5ebb ConstFactor
m2/gm2-compiler-boot/PCBuild.c:4251
0x8f5f3b ConstTerm
m2/gm2-compiler-boot/PCBuild.c:4085
0x8f6203 UnaryOrConstTerm
m2/gm2-compiler-boot/PCBuild.c:3977
0x8f6203 SimpleConstExpr
m2/gm2-compiler-boot/PCBuild.c:3929
0x8f648f ConstExpression
m2/gm2-compiler-boot/PCBuild.c:3812
0x8f66e7 ConstantDeclaration
m2/gm2-compiler-boot/PCBuild.c:3772
0x8f925f Declaration
m2/gm2-compiler-boot/PCBuild.c:7471
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/114740] i686-linux-gnu-g++ does not interpret floating point literals as double

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
It certainly does affect constants.

[Bug c++/114740] i686-linux-gnu-g++ does not interpret floating point literals as double

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #3 from Vincent Lefèvre  ---
(In reply to Jonathan Wakely from comment #1)
> See the first item at https://gcc.gnu.org/gcc-13/changes.html#cxx

The mention of -fexcess-precision in this item is unclear, because it does not
affect constants (or this is a real bug). I suspect that it means "evaluation
method" (FLT_EVAL_METHOD).

[Bug modula2/114745] New: const cast causes ICE

[gaius at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 114745
   Summary: const cast causes ICE
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

As reported on the gm2 mailing list performing a cast in a const expression
causes an ICE.  The large original example from the mailing list has been
reduced to this smaller example:

MODULE tinyindr ;

FROM SYSTEM IMPORT WORD, BYTE ;

TYPE
   File = RECORD
 lastWord: WORD ;
 lastByte: BYTE ;
  END ;

PROCEDURE Create (VAR f: File) ;
BEGIN
   WITH f DO
  lastWord := WORD (0) ;
  lastByte := BYTE (0)
   END
END Create ;


VAR
   foo: File ;
BEGIN
   Create (foo)
END tinyindr.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #12 from Vincent Lefèvre  ---
(In reply to Søren Jæger Hansen from comment #10)
> -fexcess-precision=fast it is for now then, thanks again for fast feedback.

-fexcess-precision is unrelated. Its goal is to choose whether GCC conforms to
the standard, i.e. reduces the precision for assignments and casts (*only* in
these cases, thus constants are not concerned), or generates faster but
non-conforming code.

[Bug testsuite/114744] test case gcc.target/powerpc/builtins-6-p9-runnable.c fails

[seurer at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
also gcc 11

[Bug testsuite/99731] g++.dg/modules/alias-1_a.H: error: failed to read compiled module: No such file or directory

[vvinayag at arm dot com via Gcc-bugs]

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

vvinayag at arm dot com changed:

   What|Removed |Added

 CC||vvinayag at arm dot com

--- Comment #3 from vvinayag at arm dot com ---
(In reply to H.J. Lu from comment #2)
> (In reply to Nathan Sidwell from comment #1)
> > How repeatable is this?
> 
> Close to 100%.

Is there an update on these failures?
I have also seen these failures and have not understood the cause.

[Bug rtl-optimization/114729] RISC-V SPEC2017 507.cactu excessive spillls with -fschedule-insns

[law at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Jeffrey A. Law  ---
I didn't even notice you had that testcase attached!

I haven't done a deep dive, but the first thing that jumps out is the number of
instructions in the ready queue, most likely because of the addressing of
objects in static storage.  The highparts alone are going to take ~18 GPRs for
the loop.

[Bug testsuite/114744] New: test case gcc.target/powerpc/builtins-6-p9-runnable.c fails

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 114744
   Summary: test case gcc.target/powerpc/builtins-6-p9-runnable.c
fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

gcc.target/powerpc/builtins-6-p9-runnable.c fails only on power 9 BE for gcc
12, 13, and trunk (14).

FAIL: gcc.target/powerpc/builtins-6-p9-runnable.c  -O0  execution test
FAIL: gcc.target/powerpc/builtins-6-p9-runnable.c  -O1  execution test
FAIL: gcc.target/powerpc/builtins-6-p9-runnable.c  -O2  execution test
FAIL: gcc.target/powerpc/builtins-6-p9-runnable.c  -O3  execution test
FAIL: gcc.target/powerpc/builtins-6-p9-runnable.c  -Os  execution test
FAIL: gcc.target/powerpc/builtins-6-p9-runnable.c execution test

(gdb) run 
Starting program: /home/seurer/gcc/git/build/gcc-12/builtins-6-p9-runnable.exe 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=,
no_tid=) at pthread_kill.c:44
44  pthread_kill.c: No such file or directory.
(gdb) where
#0  __pthread_kill_implementation (threadid=, signo=, no_tid=) at pthread_kill.c:44
#1  0x77c90bb4 in __GI_raise (sig=) at
../sysdeps/posix/raise.c:26
#2  0x77c7490c in __GI_abort () at abort.c:79
#3  0x16e8 in main () at
/home/seurer/gcc/git/gcc-12/gcc/testsuite/gcc.target/powerpc/builtins-6-p9-runnable.c:434



  vec_xst_len (store_data_sc, address_sc, len);

  if (result_wrong_sc (vec_sc_expected1, vec_sc_result1))
{
#ifdef DEBUG
   printf("Error: vec_xst_len, len = %d, sc result does not match expected
result\n", len);
   print_sc (vec_sc_expected1, vec_sc_result1);
#else
   abort();  // line 434
#endif
}




Compiling it with -DDEBUG:

seurer@nilram:~/gcc/git/build/gcc-12$ ./builtins-6-p9-runnable.exe 
Error: vec_xl_len(), len = 8, vec_s128_result1[0] = 0 0; vec_s128_expected1[0]
= 0 0
Error: vec_xl_len(), len = 8, vec_u128_result1[0] = 0; vec_u128_expected1[0] =
0
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[0] = 1;
vec_uc_expected1[0] = 16
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[1] = 2;
vec_uc_expected1[1] = 15
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[2] = 3;
vec_uc_expected1[2] = 14
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[3] = 4;
vec_uc_expected1[3] = 13
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[4] = 5;
vec_uc_expected1[4] = 12
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[5] = 6;
vec_uc_expected1[5] = 11
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[6] = 7;
vec_uc_expected1[6] = 10
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[7] = 8;
vec_uc_expected1[7] = 9
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[8] = 9;
vec_uc_expected1[8] = 8
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[9] = 10;
vec_uc_expected1[9] = 7
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[10] =
11; vec_uc_expected1[10] = 6
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[11] =
12; vec_uc_expected1[11] = 5
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[12] =
13; vec_uc_expected1[12] = 4
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[13] =
14; vec_uc_expected1[13] = 3
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[14] =
15; vec_uc_expected1[14] = 2
Error: pre/post initialzation vec_xl_len_r(), len = 16, vec_uc_result1[15] =
16; vec_uc_expected1[15] = 1

[Bug rtl-optimization/114729] RISC-V SPEC2017 507.cactu excessive spillls with -fschedule-insns

[law at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jeffrey A. Law  ---
Yes, there are different algorithms.  I looked at them a while back when we
first noticed the problems with spilling and x264.  There was very little
difference for specint when we varied the algorithms.  I didn't look at specfp
at the time IIRC.

[Bug target/114732] ge can't be reversed to unlt for bcd compares

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Segher Boessenkool  ---
1001, 0101, 0011 I mean of course.

In some ways CCmode models this better than CCFPmode, but we do not actually
model
the SO bit (bit 3) at all in CCmode.  It is a nice feature of CCmode (that we
actually use as fundamental, in the backend code) that CCmode always has
exactly
one of three bits "hot" (and CCFPmode always one of four).  Bit 3 (SO) in
CCmode
is treated as not being part of the CC really, but an extra thing.  This
doesn't
work all that well of course.

So we really need st least three CC modes:

-- Exactly one of bits 0..3 hot, like CCFPmode;
-- Exactly one of bits 0..2 hot, bit 3 independently set, like CCmode (and
   that independent bit 3 modeled nicely as well, unlike what we have), and
   also like in the BCD insns;
-- Bit 0 is all-true, bit 2 is all-false, like in the vcmp* insns.

Do we need some other CC mode as well?  Doe we want separately named CC modes
for the different variants of this (like the integer CC mode vs. the BCD one)?
We already have a separate CCUNSmode which is exactly like CCmode, as far as
the hardware cares, but the meaning is different (for CCUNS the LT and GT bits
are set based on an unsigned integer compare, not a signed one).  There also
is CCEQmode, which has only bit 2 valid (we use it for constructing one CR bit
from others, like with cror or crnot).

[Bug sanitizer/114743] ICE in build_check_stmt at asan.cc:2707 while compiling gcc.dg/ubsan/pr112709-2.c with -fsanitize=address

[pheeck at gcc dot gnu.org via Gcc-bugs]

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

Filip Kastl  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug sanitizer/114743] New: ICE in build_check_stmt at asan.cc:2707 while compiling gcc.dg/ubsan/pr112709-2.c with -fsanitize=address

[pheeck at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 114743
   Summary: ICE in build_check_stmt at asan.cc:2707 while
compiling gcc.dg/ubsan/pr112709-2.c with
-fsanitize=address
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: aarch64-gnu-linux

Compiling the GCC testsuite testcase gcc.dg/ubsan/pr112709-2.c with
-fsanitize=address on an aarch64 cross compiler results in an ICE

aarch64-linux-gnu-gcc gcc.dg/ubsan/pr112709-2.c -fsanitize=address

during GIMPLE pass: asan0
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/ubsan/pr112709-2.c:
In function ‘freddy’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/ubsan/pr112709-2.c:53:1:
internal compiler error: Segmentation fault
   53 | freddy (int x, int *y, struct S *p)
  | ^~
0xd9dc7f crash_signal
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/toplev.cc:319
0xa7b205 edge_before_returns_twice_call
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/gimple-iterator.cc:987
0xa7bee7 gsi_safe_insert_before(gimple_stmt_iterator*, gimple*)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/gimple-iterator.cc:1055
0xdb514b build_check_stmt
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/asan.cc:2707
0xdb72b7 instrument_derefs
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/asan.cc:2830
0xdb8173 maybe_instrument_call
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/asan.cc:3083
0xdb8173 transform_statements
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/asan.cc:3138
0xdb838b asan_instrument
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/asan.cc:4282
0xdb838b execute
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/asan.cc:4323
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


aarch64-linux-gnu-gcc -v

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/aarch64-linux-gnu/14.0.1/lto-wrapper
Target: aarch64-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=aarch64-linux-gnu
--with-as=/usr/bin/aarch64-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240414 (experimental)
62a0ef0d02cbb74cd865c1db2ecb7ca1b11f87cd (GCC)

[Bug libstdc++/114742] invalid use of '__ieee128' in and

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
Mathias noted that still fails with -mcpu=power7

Checking for _ARCH_PWR8 or __POWER8_VECTOR__ instead works.

[Bug libstdc++/114742] invalid use of '__ieee128' in and

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-16
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I think we need something like this in 

#ifndef __VSX__
# undef _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT
#endif

Otherwise we might set the ALT128_COMPAT macro during configure, but then it
becomes invalidated during compilation of user code if they "downgrade" to
something that doesn't support ieee128, using -mcpu=power6 and/or
-mlong-double-64

[Bug libstdc++/114742] New: invalid use of '__ieee128' in and

[mkretz at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 114742
   Summary: invalid use of '__ieee128' in 
and 
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkretz at gcc dot gnu.org
  Target Milestone: ---

https://compiler-explorer.com/z/K3GYY7Msc

Testcase:

#include 
#include 

Compile on power64le with -O2 -std=c++23 -mcpu=power6 and optionally with 
-mlong-double-64

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

[rdapp at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Robin Dapp  ---
Ok, it looks like we do 5 iterations with the last one being length-masked to
length 2 and then in the "live extraction" phase use "iteration 6".

[Bug tree-optimization/114736] [13 Regression] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[prathamesh3492 at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from prathamesh3492 at gcc dot gnu.org ---
Hi Richard,
Thanks for the quick fix! I verified it now compiles the test-case with -O3
-mcpu=neoverse-v2. I suppose this will need backporting to gcc-13 branch. The
test compiles OK with gfortran-12.

Thanks,
Prathamesh

[Bug libstdc++/57585] New --enable-clocale model using POSIX 2008

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> Separately, it would be good to provide a libintl-based implementation of
> std::messages, for targets where that's not part of glibc.

Although the POSIX catopen/catclose/catgets one might be good enough, once we
support https://cplusplus.github.io/LWG/lwg-defects.html#2028 so that
messages_base::catalog is large enough to store a nl_catd.

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

[rdapp at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Robin Dapp  ---
> probably -fwhole-program is enough, -flto not needed(?)

Yes, -fwhole-program is sufficient.

> 
>   # vectp_g.248_1401 = PHI 
> ...
>   _1411 = .SELECT_VL (ivtmp_1409, POLY_INT_CST [2, 2]);
> ..
>   vect__193.250_1403 = .MASK_LEN_LOAD (vectp_g.248_1401, 32B, { -1, ... },
> _1411, 0);
>   vect__194.251_1404 = -vect__193.250_1403;
>   vect_iftmp.252_1405 = (vector([2,2]) long int) vect__194.251_1404;
> 
>   # vect_iftmp.252_1406 = PHI 
>   # loop_len_1427 = PHI <_1411(5)>
> ...
>   _1407 = loop_len_1427 + 18446744073709551615;
>   _1408 = .VEC_EXTRACT (vect_iftmp.252_1406, _1407);
>   iftmp.3_1204 = _1408;
> 
> is stored to b[15].  Doesn't look too odd to me.

At the assembly equivalent of

>   vect__193.250_1403 = .MASK_LEN_LOAD (vectp_g.248_1401, 32B, { -1, ... },
> _1411, 0); 

we load [3 3] (=f) instead of [0 0] (=g).  f is located after g in memory and
register a3 is increased before the loop latch.  We then re-use a3 to load the
last two elements of g but actually read the first two of f.

[Bug target/114741] [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |14.0

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gnu.ojxq8 at dralias dot com

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

[Bug c++/114740] i686-linux-gnu-g++ does not interpret floating point literals as double

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup.

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

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #11 from Andrew Pinski  ---
.

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

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sjh at schilling dot dk

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

[Bug gcov-profile/114735] Gcov not working with gcc version 11.4.0

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
The "fix" was to how to build to be able to use gcov. Basically you build to an
object file first and then link the object file to get the old behavior and the
behavior that gcov expects.

[Bug c++/114740] i686-linux-gnu-g++ does not interpret floating point literals as double

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jonathan Wakely  ---
See the first item at https://gcc.gnu.org/gcc-13/changes.html#cxx

[Bug target/114741] New: [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

[nsz at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 114741
   Summary: [14 regression] aarch64 sve: unnecessary fmov for
scalar int bit operations
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

void foo(unsigned i, unsigned *p)
{
*p = i & 1;
}

with gcc -march=armv8-a+sve -O2 compiles to

foo:
fmovs31, w0
and z31.s, z31.s, #1
str s31, [x1]
ret

instead of

foo:
and w0, w0, 1
str w0, [x1]
ret

it is wrong with -mcpu=generic but good e.g. with -mcpu=neoverse-v1

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #21 from Alejandro Colomar  ---
It would be interesting to learn why MSVC gets it right.  Maybe there's a
deterministic way to avoid this warning.  Although maybe it's just that they're
doing heuristics.

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #20 from Alejandro Colomar  ---
H, I like the _Generic() to assert the type.  Thanks!

With that, I find it more acceptable.  At least I don't need to use GNU
extensions, and the cast is coupled with the verification of the type.  It's a
bit repetitive, but acceptable.

I agree that using heuristics to fix this would be bad.

Feel free to close as WONTFIX.

Have a lovely day!
Alex


Below is the program using _Generic() to assert the type.


alx@debian:~/tmp/c$ cat g.c
#include 
#include 
#include 
#include 


#define a2i(TYPE, n, s, endp, base, min, max) \
({\
_Generic((TYPE) 0,\
long:   a2sl(_Generic(n, TYPE *: (long *) n), s,
endp, base, min, max), \
int:a2si(_Generic(n, TYPE *:  (int *) n), s,
endp, base, min, max)  \
);\
})


#define a2sl(n, s, endp, base, min, max)  \
( \
_Generic(endp,\
const char **:  a2sl_c,   \
char **:a2sl_nc,  \
void *: a2sl_nc   \
)(n, s, endp, base, min, max) \
)

#define a2si(n, s, endp, base, min, max)  \
( \
_Generic(endp,\
const char **:  a2si_c,   \
char **:a2si_nc,  \
void *: a2si_nc   \
)(n, s, endp, base, min, max) \
)


static inline int a2sl_c(long *restrict n, const char *s,
const char **restrict endp, int base, long min, long max);
static inline int a2si_c(int *restrict n, const char *s,
const char **restrict endp, int base, int min, int max);

static inline int a2sl_nc(long *restrict n, const char *s,
char **restrict endp, int base, long min, long max);
static inline int a2si_nc(int *restrict n, const char *s,
char **restrict endp, int base, int min, int max);


static inline int
a2sl_c(long *restrict n, const char *s,
const char **restrict endp, int base, long min, long max)
{
return a2sl_nc(n, s, (char **) endp, base, min, max);
}


static inline int
a2si_c(int *restrict n, const char *s,
const char **restrict endp, int base, int min, int max)
{
return a2si_nc(n, s, (char **) endp, base, min, max);
}


static inline int
a2sl_nc(long *restrict n, const char *s,
char **restrict endp, int base, long min, long max)
{
int  status;

*n = strtoi(s, endp, base, min, max, );
if (status != 0) {
errno = status;
return -1;
}
return 0;
}


static inline int
a2si_nc(int *restrict n, const char *s,
char **restrict endp, int base, int min, int max)
{
int  status;

*n = strtoi(s, endp, base, min, max, );
if (status != 0) {
errno = status;
return -1;
}
return 0;
}


int
main(void)
{
time_t  t;

a2i(time_t, , "42", NULL, 0, 0, 10);
}
alx@debian:~/tmp/c$ cc -Wall -Wextra g.c -S
alx@debian:~/tmp/c$

[Bug c++/114740] New: i686-linux-gnu-g++ does not interpret floating point literals as double

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

Bug ID: 114740
   Summary: i686-linux-gnu-g++ does not interpret floating point
literals as double
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu.ojxq8 at dralias dot com
  Target Milestone: ---

Starting with i686-linux-gnu-g++-13, including 14, a floating point literal
appears to be no longer interpreted as double.

i686-linux-gnu-g++-12, and earlier, as well as clang, work fine.

Steps to reproduce:

$ echo 'int main() { return double(1e-8) == 1e-8; }' > a.cpp
$ i686-linux-gnu-g++-13 -std=c++03 test.cpp && ./a.out ; echo $?
0
$ i686-linux-gnu-g++-12 -std=c++03 test.cpp && ./a.out ; echo $?
1

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #19 from Martin Uecker  ---
It would still work for other arguments that are used in the active branch, but
not arguments you may not use in active branch or other subexpressions not used
in the active branch.

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #18 from Martin Uecker  ---

In theory, we could do something like this, but note that this also has
undesirable consequences: This would turn off all such warnings also in
expressions passed as macro arguments, i.e. this would substantially reduce
type safety for expressions you pass to your 'a2i' macro and also affect other
sub expressions one might have inside the implementation of such macros. We
could try to be smart and find heuristics to avoid this, but then it already
gets more difficult. 

I personally find the version with the casts acceptable. I would suggest o
implement the type tests also using _Generic instead of using the builtin. For
example, you could do something like:

#define a2i(TYPE, ...) \
 _Generic((n),  \
 long: a2sl(_Generic((n), TYPE: (long*)(n), s, endp, base, min, max), \
 ...)

[Bug libgomp/92840] [OpenACC] Disallow 'acc_unmap_data' for everything other than 'acc_map_data'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Thomas Schwinge  ---
As determined during patch review, there's still an unresolved issue:

On 2024-04-16T17:12:17+0800, Chung-Lin Tang  wrote:
> If we continue to use k->refcount itself as the flag holder of map type, I 
> guess we will not be able to directly determine whether it is a
> structured or dynamic adjustment at that point. Probably need a new field 
> entirely.

[Bug libgomp/92840] [OpenACC] Disallow 'acc_unmap_data' for everything other than 'acc_map_data'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||cltang at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
commit r14-9991-ga7578a077ed8b64b94282aa55faf7037690abbc5 "OpenACC 2.7: Adjust
acc_map_data/acc_unmap_data interaction with reference counters"