[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap

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

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

--- Comment #3 from Hongtao Liu  ---
Created attachment 58066
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58066=edit
reproduced testcase

gfortran -O2 -march=x86-64-v4 -fvect-cost-model=cheap.

[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #4 from Kewen Lin  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Kewen Lin from comment #2)
> > As https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843#c8, we may need some
> > similar handling like r14-6440-g4b421728289e6f.
> 
> Note rs6000_emit_epilogue mostly handles eh_returns so it might not be as
> hard as other targets.

Yes, making a patch.

[Bug c++/114884] New: GCC rejects valid deduction using deduction guide

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 114884
   Summary: GCC rejects valid deduction using deduction guide
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following valid program afaik is rejected by gcc but accepted by clang and
msvc: https://godbolt.org/z/85sjenzrn

```
#include 
#include 
#include 
#include 
#include 
#include 

template
class Vec
{
C elems;
public:

Vec(const std::initializer_list& init)
{

}

};
template Vec(const std::initializer_list& vec) ->
Vec>;
template
Vec(C) -> Vec;

int main()
{
Vec v0({1, 4, 7});
}
```

GCC says

```
:20:93: error: template argument 2 is invalid
   20 | template Vec(const std::initializer_list& vec) ->
Vec>;
  |
^
:20:94: error: template argument 2 is invalid
   20 | template Vec(const std::initializer_list& vec) ->
Vec>;
  |
 ^~
:20:94: error: template argument 2 is invalid
:20:94: error: template argument 2 is invalid
:20:70: error: invalid template-id
   20 | template Vec(const std::initializer_list& vec) ->
Vec>;
  | 
^~~
:20:75: error: template argument 1 is invalid
   20 | template Vec(const std::initializer_list& vec) ->
Vec>;
  |
  ^
:20:75: error: template argument 1 is invalid
:20:75: error: template argument 1 is invalid
:20:75: error: template argument 1 is invalid
:20:66: error: invalid template-id
   20 | template Vec(const std::initializer_list& vec) ->
Vec>;
  |  ^~~
:20:96: error: missing template arguments before ';' token
   20 | template Vec(const std::initializer_list& vec) ->
Vec>;
  |
   ^
:20:96: error: expected '>' before ';' token
:20:96: error: trailing return type 'Vec<...auto...>' of deduction
guide is not a specialization of 'Vec'
: In function 'int main()':
:26:9: error: 'Vec<...auto...> v0' has incomplete type
   26 | Vec v0({1, 4, 7});
  | ^~
Compiler returned: 1
```

[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap

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

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

--- Comment #2 from Hongtao Liu  ---
(In reply to Andrew Pinski from comment #1)
> Can you reduce the fortran code down for the ICE? It should not be hard, you
> can use delta even.

Let me try.

[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap

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

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

--- Comment #1 from Andrew Pinski  ---
Can you reduce the fortran code down for the ICE? It should not be hard, you
can use delta even.

[Bug tree-optimization/114883] [14 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|521.wrf_r ICE with -O2  |[14 Regression] 521.wrf_r
   |-march=sapphirerapids   |ICE with -O2
   |-fvect-cost-model=cheap |-march=sapphirerapids
   ||-fvect-cost-model=cheap
   Keywords||ice-on-valid-code
   Target Milestone|--- |14.0

[Bug tree-optimization/114883] New: 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap

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

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

Bug ID: 114883
   Summary: 521.wrf_r ICE with -O2 -march=sapphirerapids
-fvect-cost-model=cheap
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liuhongt at gcc dot gnu.org
  Target Milestone: ---

during GIMPLE pass: vect
dump file: module_cam_mp_ndrop.fppized.f90.179t.vect
module_cam_mp_ndrop.fppized.f90:33:27:

   33 |   subroutine dropmixnuc(lchnk, ncol, ncldwtr,tendnd, temp,omega,  &
  |   ^
internal compiler error: in vect_transform_reduction, at tree-vect-loop.cc:8506
0x8c8009 vect_transform_reduction(_loop_vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, gimple**, _slp_tree*)
/iusers/liuhongt/work/gcc-14/gcc/tree-vect-loop.cc:8506
0x2959895 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/iusers/liuhongt/work/gcc-14/gcc/tree-vect-stmts.cc:13447
0x185a31a vect_transform_loop_stmt
/iusers/liuhongt/work/gcc-14/gcc/tree-vect-loop.cc:11561
0x18794e2 vect_transform_loop(_loop_vec_info*, gimple*)
/iusers/liuhongt/work/gcc-14/gcc/tree-vect-loop.cc:12087
0x18c3544 vect_transform_loops
/iusers/liuhongt/work/gcc-14/gcc/tree-vectorizer.cc:1006
0x18c3bc3 try_vectorize_loop_1
/iusers/liuhongt/work/gcc-14/gcc/tree-vectorizer.cc:1152
0x18c3bc3 try_vectorize_loop
/iusers/liuhongt/work/gcc-14/gcc/tree-vectorizer.cc:1182
0x18c4224 execute
/iusers/liuhongt/work/gcc-14/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.


vect dump, vectorization for reduction of COND_MIN and ICE.

 9014  MEM  [(real(kind=8) *)vectp.2627_3771] =
vect__458.2626_3767;
 9015  vect_tinv_1357.2629_3773 = vect__453.2615_3744 + vect__458.2626_3766;
 9016  vect_tinv_1357.2629_3774 = vect__453.2615_3745 + vect__458.2626_3767;
 9017  tinv_1357 = _453 + _458;
 9018  mask__2039.2630_3776 = vect_vec_iv_.2598_3718 == vect_cst__3775;
 9019  _2039 = k.864_1980 == prephitmp_3150;
 9020  mask_patt_3658.2631_3777 = [vec_unpack_lo_expr] mask__2039.2630_3776;
 9021  mask_patt_3658.2631_3778 = [vec_unpack_hi_expr] mask__2039.2630_3776;
 9022  vect_patt_3659.2632_3781 = .COND_ADD (mask_patt_3658.2631_3777,
vect_tinv_1357.2629_3773, vect_cst__3779, vect_cst__3780);
 9023  vect_patt_3659.2632_3782 = .COND_ADD (mask_patt_3658.2631_3778,
vect_tinv_1357.2629_3774, vect_cst__3779, vect_cst__3780);
 9024  tinv_1766 = 0.0;
 9025  mask_patt_3660.2633_3783 = [vec_unpack_lo_expr] mask__2039.2630_3776;
 9026  mask_patt_3660.2633_3784 = [vec_unpack_hi_expr] mask__2039.2630_3776;
 9027  vect_patt_3661.2634_3786 = .COND_ADD (mask_patt_3660.2633_3783,
vect_patt_3659.2632_3781, vect_cst__3785, vect_tinv_1357.2629_3773);
 9028  vect_patt_3661.2634_3787 = .COND_ADD (mask_patt_3660.2633_3784,
vect_patt_3659.2632_3782, vect_cst__3785, vect_tinv_1357.2629_3774);
 9029  tinv_1359 = 0.0;
 9030  mask__2017.2635_3789 = vect_patt_3661.2634_3786 > vect_cst__3788;
 9031  mask__2017.2635_3790 = vect_patt_3661.2634_3787 > vect_cst__3788;
 9032  _2017 = tinv_1359 > 9.99974752427078783512115478515625e-7;
 9033  vect_dtt_1360.2636_3793 = .COND_RDIV (mask__2017.2635_3789,
vect_cst__3791, vect_patt_3661.2634_3786, vect_cst__3792);
 9034  vect_dtt_1360.2636_3794 = .COND_RDIV (mask__2017.2635_3790,
vect_cst__3791, vect_patt_3661.2634_3787, vect_cst__3792);
 9035  dtt_1360 = 0.0;
 9036  M.287_1361 = .COND_MIN (_2017, dtt_1360, dtmin_1992, dtmin_1992);
 9037  _459 = k.864_1980 + 1;
 9038  vectp.2602_3727 = vectp.2602_3729 + 32;
 9039  vectp.2606_3733 = vectp.2606_3735 + 32;
 9040  vectp.2611_3740 = vectp.2611_3742 + 32;
 9041  vectp.2616_3747 = vectp.2616_3749 + 32;
 9042  vectp.2618_3752 = vectp.2618_3754 + 32;
 9043  vectp.2627_3769 = vectp.2627_3771 + 32;
 9044  if (_459 > prephitmp_3150)
 9045goto ; [11.00%]
 9046  else
 9047goto ; [89.00%]
 9048


Part of source code in  module_cam_mp_ndrop.fppized.f90, the ICE loop.

 630 do k=1,pver
 631km1=max0(k-1,1)
 632ekkp(k)=zn(k)*ekk(k)*zs(k)
 633ekkm(k)=zn(k)*ekk(k-1)*zs(km1)
 634tinv=ekkp(k)+ekkm(k)
 635
 636if(k.eq.pver)tinv=tinv+surfratemax
 637! rce-comment -- tinv is the sum of all first-order-loss-rates
 638!for the layer.  for most layers, the activation loss rate
 639!(for interstitial particles) is accounted for by the loss by
 640!turb-transfer to the layer above.
 641!k=pver is special, and the loss rate for activation within
 642!the layer must be added to tinv.  if not, the time step
 643!can be too big, and explmix can produce negative values.
 

[Bug middle-end/61118] [11/12/13/14/15 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

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

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

--- Comment #33 from Andrew Pinski  ---
(In reply to Paul Eggert from comment #32)
> Created attachment 58065 [details]
> Run "gunzip t.i.gz; gcc -O2 -S -Wclobbered t.i" to reproduce the false
> positives
> 
> I ran into this bug today when compiling GNU Emacs with gcc (GCC) 14.0.1
> 20240411 (Red Hat 14.0.1-0) on x86-64 (Fedora 40). I didn't see it with
> earlier GCC releases so I thought I'd attach a test case, derived from
> Emacs. Compile with:

It is there for GCC 11.4.1 for me:
[apinski@xeond2 upstream-gcc-new]$ gcc ~/src/t.i -S -O2 -S -Wclobbered
-fdump-tree-optimized
/home/apinski/src/t.i: In function ‘internal_lisp_condition_case’:
/home/apinski/src/t.i:7969:15: warning: variable ‘sym’ might be clobbered by
‘longjmp’ or ‘vfork’ [-Wclobbered]
 7969 |   Lisp_Object sym = XSYMBOL_WITH_POS (a)->sym;
  |   ^~~
/home/apinski/src/t.i:94273:43: warning: argument ‘var’ might be clobbered by
‘longjmp’ or ‘vfork’ [-Wclobbered]
94273 | internal_lisp_condition_case (Lisp_Object var, Lisp_Object bodyform,
  |   ^~~
[apinski@xeond2 upstream-gcc-new]$ gcc ~/src/t.i -S -O2 -S -Wclobbered
-fdump-tree-optimized --version
gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3)
Copyright (C) 2021 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 middle-end/61118] [11/12/13/14/15 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Paul Eggert  changed:

   What|Removed |Added

 CC||eggert at cs dot ucla.edu

--- Comment #32 from Paul Eggert  ---
Created attachment 58065
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58065=edit
Run "gunzip t.i.gz; gcc -O2 -S -Wclobbered t.i" to reproduce the false
positives

I ran into this bug today when compiling GNU Emacs with gcc (GCC) 14.0.1
20240411 (Red Hat 14.0.1-0) on x86-64 (Fedora 40). I didn't see it with earlier
GCC releases so I thought I'd attach a test case, derived from Emacs. Compile
with:

gunzip t.i
gcc -O2 -S -Wclobbered t.i

and the incorrect diagnostics are:

t.i: In function ‘internal_lisp_condition_case’:
t.i:7969:15: warning: variable ‘sym’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Wclobbered]
 7969 |   Lisp_Object sym = XSYMBOL_WITH_POS (a)->sym;
  |   ^~~
t.i:94273:43: warning: argument ‘var’ might be clobbered by ‘longjmp’ or
‘vfork’ [-Wclobbered]
94273 | internal_lisp_condition_case (Lisp_Object var, Lisp_Object bodyform,
  |   ^~~

[Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #10 from Paul Eggert  ---
Created attachment 58064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58064=edit
"gunzip u.i" then "gcc -O2 -S -fanalyzer u.i" to see how much memory GCC uses

I'm having more trouble with this when using gcc (GCC) 14.0.1 20240411 (Red Hat
14.0.1-0) on x86-64. I am now getting "gcc: fatal error: Killed signal
terminated program cc1" when compiling Emacs xdisp.c. To reproduce the problem,
run

gunzip u.i
gcc -O2 -S -fanalyzer u.i

with the attached file u.i.gz. GCC keeps allocating more and more virtual
memory, almost all via brk (wouldn't mmap be better? but I digress) until it
goes past 10 GB and exhausts my little machine's swap space (7.7G of zram).

I didn't see this problem with GCC 13 on Fedora 39, so in some sense I suppose
this is a regression. Maybe there's a new memory leak of some sort? Or perhaps
it's just -fanalyzer doing new checks for GCC 14.

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Neil Carlson  ---
Thanks Harald for hunting this down!

I've tested your patch on master with -fsanitize=address against my library
that turned up these errors and it all looks good now. Is it possible to back
port this to the 12 branch?

[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752

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

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

Paul Thomas  changed:

   What|Removed |Added

  Attachment #58054|0   |1
is obsolete||

--- Comment #14 from Paul Thomas  ---
Created attachment 58063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58063=edit
Fix for this PR

Hi Jakub and Orion,

It took me a little while to reduce the problem to the testcase below. It goes
to the list as soon as regtesting is done.

The offending bit of code has been constrained even more than previously and
the return with empty_stmt (input_location) has been removed. It, apparently,
can make var_decls disappear.

Regards

Paul

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 072adf3fe77..0280c441ced 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -1720,6 +1720,7 @@ gfc_trans_class_init_assign (gfc_code *code)
   gfc_se dst,src,memsz;
   gfc_expr *lhs, *rhs, *sz;
   gfc_component *cmp;
+  gfc_symbol *sym;

   gfc_start_block ();

@@ -1736,18 +1737,25 @@ gfc_trans_class_init_assign (gfc_code *code)
   /* The _def_init is always scalar.  */
   rhs->rank = 0;

-  /* Check def_init for initializers.  If this is a dummy with all default
- initializer components NULL, return NULL_TREE and use the passed value as
- required by F2018(8.5.10).  */
-  if (!lhs->ref && lhs->symtree->n.sym->attr.dummy)
+  /* Check def_init for initializers.  If this is an INTENT(OUT) dummy with
all
+ default initializer components NULL, return NULL_TREE and use the passed
+ value as required by F2018(8.5.10).  */
+  sym = code->expr1->expr_type == EXPR_VARIABLE ? code->expr1->symtree->n.sym
+   : NULL;
+  if (code->op != EXEC_ALLOCATE
+  && sym && sym->attr.dummy
+  && sym->attr.intent == INTENT_OUT)
 {
-  cmp = rhs->ref->next->u.c.component->ts.u.derived->components;
-  for (; cmp; cmp = cmp->next)
+  if (!lhs->ref && lhs->symtree->n.sym->attr.dummy)
{
- if (cmp->initializer)
-   break;
- else if (!cmp->next)
-   return build_empty_stmt (input_location);
+ cmp = rhs->ref->next->u.c.component->ts.u.derived->components;
+ for (; cmp; cmp = cmp->next)
+   {
+ if (cmp->initializer)
+   break;
+ else if (!cmp->next)
+   return NULL_TREE;
+   }
}
 }

diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index c34e0b4c0cd..d355009fa5e 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -7262,11 +7262,12 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist
*omp_allocate)
{
  /* Use class_init_assign to initialize expr.  */
  gfc_code *ini;
- ini = gfc_get_code (EXEC_INIT_ASSIGN);
+ ini = gfc_get_code (EXEC_ALLOCATE);
  ini->expr1 = gfc_find_and_cut_at_last_class_ref (expr, true);
  tmp = gfc_trans_class_init_assign (ini);
  gfc_free_statements (ini);
- gfc_add_expr_to_block (, tmp);
+ if (tmp != NULL_TREE)
+   gfc_add_expr_to_block (, tmp);
}
   else if ((init_expr = allocate_get_initializer (code, expr)))
{
diff --git a/gcc/testsuite/gfortran.dg/pr114959.f90
b/gcc/testsuite/gfortran.dg/pr114959.f90
new file mode 100644
index 000..5cc3c052c1d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114959.f90
@@ -0,0 +1,33 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+!
+! Fix the regression caused by r14-9752 (fix for PR112407)
+! Contributed by Orion Poplawski  
+! Problem isolated by Jakub Jelinek   and further
+! reduced here.
+!
+module m
+  type :: smoother_type
+integer :: i
+  end type
+  type :: onelev_type
+class(smoother_type), allocatable :: sm
+class(smoother_type), allocatable :: sm2a
+  end type
+contains
+  subroutine save_smoothers(level,save1, save2)
+Implicit None
+type(onelev_type), intent(inout) :: level
+class(smoother_type), allocatable , intent(inout) :: save1, save2
+integer(4) :: info
+
+info  = 0
+! r14-9752 causes the 'stat' declaration from the first ALLOCATE statement
+! to disappear, which triggers an ICE in gimplify_var_or_parm_decl. The
+! second ALLOCATE statement has to be present for the ICE to occur.
+allocate(save1, mold=level%sm,stat=info)
+allocate(save2, mold=level%sm2a,stat=info)
+  end subroutine save_smoothers
+end module m
+! Two 'stat's from the allocate statements and two from the final wrapper.
+! { dg-final { scan-tree-dump-times "integer\\(kind..\\) stat" 4 "original" }
}

[Bug go/114581] go.test/test/fixedbugs/issue22881.go FAILs

[ian at airs dot com via Gcc-bugs]

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

--- Comment #1 from Ian Lance Taylor  ---
The behavior is different under gdb because gdb resends the signal.  The
program then sees it with an si_code field of SI_USER, which causes it to act
differently.

[Bug analyzer/114882] New: Two -fanalyzer false positives after realloc grows buffer

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 114882
   Summary: Two -fanalyzer false positives after realloc grows
buffer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 58062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58062=edit
Run "gcc -O2 -fanalyzer -S v.i" to see the false positives

This is gcc (GCC) 14.0.1 20240411 (Red Hat 14.0.1-0) on x86-64. I ran into this
problem when compiling GNU Emacs's etags.c program. A simplified version of the
problem is attached.

-fanalyzer issues two false-positive diagnostics for the same source line.
Either GCC's analyzer is confused about how realloc works, or it is confused
about buffer size calculations, or both.

To reproduce the problem, compile the attached program v.i with:

gcc -O2 -fanalyzer -S v.i

This program calls realloc in a common way when growing a buffer. The original
Emacs code doubles the buffer size when reallocating; in this simplified
version the code merely adds 1 to the buffer size when reallocating. Either
way, GCC incorrectly warns about out-of-bounds writes and about accessing
uninitialized storage.

I plan to work around the problem for now by disabling
-Wanalyzer-use-of-uninitialized-value when compiling etags.c.

Here are the diagnostics from the above GCC invocation. They're all false
positives.

v.i: In function ‘oemacs_etags_readline_internal’:
v.i:30:26: warning: use of uninitialized value ‘p[-1]’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   30 |   if (buffer < p && p[-1] == '\r')
  | ~^~~~
  ‘oemacs_etags_readline_internal’: events 1-13
|
|   11 |   if (!buffer)
|  |  ^
|  |  |
|  |  (1) following ‘false’ branch (when ‘buffer’ is non-NULL)...
|..
|   14 |   char *pend = p + buf_size;
|  | 
|  | |
|  | (2) ...to here
|..
|   18 |   if (p == pend)
|  |  ~
|  |  |
|  |  (3) following ‘true’ branch (when ‘p == pend’)...
|   19 | {
|   20 |   size_t new_buf_size = buf_size + 1;
|  |  
|  |  |
|  |  (4) ...to here
|   21 |   if (new_buf_size < buf_size)
|  |  ~
|  |  |
|  |  (5) following ‘false’ branch (when ‘buf_size <=
new_buf_size’)...
|   22 | __builtin_abort ();
|   23 |   buffer = realloc (buffer, new_buf_size);
|  |~~
|  ||
|  |(6) ...to here
|  |(7) when ‘realloc’ succeeds, moving buffer
|  |(8) region created on heap here
|   24 |   if (!buffer)
|  |  ~
|  |  |
|  |  (9) following ‘false’ branch (when ‘buffer’ is
non-NULL)...
|   25 | __builtin_abort ();
|   26 |   p = buffer + buf_size;
|  |   ~
|  | |
|  | (10) ...to here
|..
|   30 |   if (buffer < p && p[-1] == '\r')
|  |  ~  ~
|  |  |   |
|  |  |   (12) ...to here
|  |  |   (13) use of uninitialized value ‘p[-1]’
here
|  |  (11) following ‘true’ branch (when ‘buffer < p’)...
|
v.i:32:12: warning: heap-based buffer overflow [CWE-122]
[-Wanalyzer-out-of-bounds]
   32 |   *p++ = c;
  |   ~^~~
  ‘oemacs_etags_readline_internal’: events 1-10
|
|   10 |   char *buffer = malloc (buf_size);
|  |  ^
|  |  |
|  |  (1) capacity: 1 byte
|   11 |   if (!buffer)
|  |  ~
|  |  |
|  |  (2) following ‘false’ branch (when ‘buffer’ is non-NULL)...
|..
|   14 |   char *pend = p + buf_size;
|  |   
|  | |
|  | (3) ...to here
|..
|   18 |   if (p == pend)
|  |  ~
|  |  |
|  |  (4) following ‘false’ branch (when ‘p != pend’)...
|  |  (8) following ‘false’ branch (when ‘p != pend’)...
|..
|   30 |   if (buffer < p && p[-1] == '\r')
|  |  ~
|  |  |
|  |  (5) ...to here
|  |  (6) 

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #58048|0   |1
is obsolete||
  Attachment #58056|0   |1
is obsolete||
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #9 from anlauf at gcc dot gnu.org ---
Created attachment 58061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58061=edit
Corrected patch

This fixes the issue for scalar and array assignments and does not regress
on intrinsic types when compiling with -fsanitize=address.

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

Nicolas Boulenguez  changed:

   What|Removed |Added

  Attachment #58028|0   |1
is obsolete||

--- Comment #24 from Nicolas Boulenguez  ---
Created attachment 58060
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58060=edit
timeval timespec: merge all definitions, select 32 or 64 bits variants on glibc

Hello.

The second issue is caused by glibc implementing (on architectures where time_t
was 32 bits by default)
  gettimeofday
  __gettimeofday64
and #defining gettimeofday __gettimeofday64 if __USE_TIME_BITS64.
Ada, ignoring this, was still importing the 32 bits version.

The attached archive patches all such issues as far as I know.
The patch has been tested on x86_64-linux-gnu (time_t64 is the default) and
arm-linux-gnueabihf (time_t64 is affected by __USE_TIME_BITS64).

[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC

[ian at airs dot com via Gcc-bugs]

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

--- Comment #8 from Ian Lance Taylor  ---
This is a register allocator problem, not a Go problem.  I've opened
https://gcc.gnu.org/PR114881.  It's an updated version of
https://gcc.gnu.org/PR53125.

[Bug rtl-optimization/114881] New: Very slow compilation on SPARC

[ian at airs dot com via Gcc-bugs]

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

Bug ID: 114881
   Summary: Very slow compilation on SPARC
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
  Target Milestone: ---

Created attachment 58059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58059=edit
Test case

This is repeat of PR 53125, which was closed in 2012.

The attached test case is a conversion to C of a machine generated test case in
Go (the machine generated Go source is in
gcc/testsuite/go.test/test/cmplxdivide1.go).

When I compile this test case without optimization on an x86_64 GNU/Linux
system, it takes 9.7 seconds.  With -O2 it takes 4.9 seconds.

When I compile this test case without optimization on a SPARC Solaris 2.11
system, it takes 3 minutes 30 seconds.  With -O2 it takes 2 minutes 30 seconds.

The SPARC machine is slower than the x86_64 machine.  But it's not that much
slower.  The time difference is extreme.

In -ftime-report on the SPARC system, most of the time is:

 integrated RA  :  33.43 ( 16%)   0.05 (  4%)  33.56 ( 16%)
   12M ( 14%)
 LRA hard reg assignment: 144.62 ( 70%)   0.35 ( 30%) 145.52 ( 70%)
0  (  0%)

[Bug analyzer/114880] New: analyzer: False positive Wanalyzer-fd-use-after-close when open returns the same fd

[alan.coopersmith at oracle dot com via Gcc-bugs]

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

Bug ID: 114880
   Summary: analyzer: False positive Wanalyzer-fd-use-after-close
when open returns the same fd
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: alan.coopersmith at oracle dot com
  Target Milestone: ---

Created attachment 58058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58058=edit
dup2.c test case

I've hit this originally with gcc 13.2 when building xfs with -fanalyzer.

I extracted this simplified test case from
https://gitlab.freedesktop.org/xorg/app/xfs/-/blob/master/os/daemon.c
and when built with "gcc -fanalyzer -c dup2.c" it reports:

dup2.c:30:9: warning: ‘dup2’ on closed file descriptor ‘0’
[-Wanalyzer-fd-use-after-close]
   30 | if (dup2 (0, 1) == -1) {
  | ^~~
  ‘DetachStdio’: events 1-6
|
|   10 | close (0);
|  | ^
|  | |
|  | (1) closed here
|..
|   18 | if (nullfd == -1) {
|  |~
|  ||
|  |(2) following ‘false’ branch (when ‘nullfd != -1’)...
|..
|   22 | if (nullfd != 0) {
|  |~
|  ||
|  |(3) ...to here
|  |(4) following ‘false’ branch (when ‘nullfd == 0’)...
|..
|   30 | if (dup2 (0, 1) == -1) {
|  | ~~~
|  | |
|  | (5) ...to here
|  | (6) ‘dup2’ on closed file descriptor ‘0’; ‘close’ was at
(1)
|

dup2.c:34:9: warning: ‘dup2’ on closed file descriptor ‘0’
[-Wanalyzer-fd-use-after-close]
   34 | if (dup2 (0, 2) == -1) {
  | ^~~
  ‘DetachStdio’: events 1-8
|
|   10 | close (0);
|  | ^
|  | |
|  | (1) closed here
|..
|   18 | if (nullfd == -1) {
|  |~
|  ||
|  |(2) following ‘false’ branch (when ‘nullfd != -1’)...
|..
|   22 | if (nullfd != 0) {
|  |~
|  ||
|  |(3) ...to here
|  |(4) following ‘false’ branch (when ‘nullfd == 0’)...
|..
|   30 | if (dup2 (0, 1) == -1) {
|  |
|  |||
|  ||(5) ...to here
|  |(6) following ‘false’ branch...
|..
|   34 | if (dup2 (0, 2) == -1) {
|  | ~~~
|  | |
|  | (7) ...to here
|  | (8) ‘dup2’ on closed file descriptor ‘0’; ‘close’ was at
(1)
|

But in both these cases if it followed the ‘nullfd == 0’ path as it claims,
then 0 is a valid fd returned from "nullfd = open ("/dev/null", O_RDWR);"

(This test case also returns other false positives, covered by other bugs
such as bug 113329.)

[Bug analyzer/113329] analyzer: False positive analyzer-fd-use-without-check with dup2()

[alan.coopersmith at oracle dot com via Gcc-bugs]

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

--- Comment #2 from Alan Coopersmith  ---
I've hit this as well with gcc 13.2 when building xfs with -fanalyzer.

I extracted this test case from
https://gitlab.freedesktop.org/xorg/app/xfs/-/blob/master/os/daemon.c
and when built with "gcc -fanalyzer -c dup2.c" it reports:

dup2.c: In function ‘DetachStdio’:
dup2.c:23:13: warning: ‘dup2’ on possibly invalid file descriptor ‘0’
[-Wanalyzer-fd-use-without-check]
   23 | if (dup2(nullfd, 0) == -1) {
  | ^~~
  ‘DetachStdio’: events 1-6
|
|   10 | close (0);
|  | ^
|  | |
|  | (1) closed here
|..
|   18 | if (nullfd == -1) {
|  |~
|  ||
|  |(2) following ‘false’ branch (when ‘nullfd != -1’)...
|..
|   22 | if (nullfd != 0) {
|  |~
|  ||
|  |(3) ...to here
|  |(4) following ‘true’ branch (when ‘nullfd != 0’)...
|   23 | if (dup2(nullfd, 0) == -1) {
|  | ~~~
|  | |
|  | (5) ...to here
|  | (6) ‘0’ could be invalid
|

[Bug analyzer/113329] analyzer: False positive analyzer-fd-use-without-check with dup2()

[alan.coopersmith at oracle dot com via Gcc-bugs]

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

Alan Coopersmith  changed:

   What|Removed |Added

 CC||alan.coopersmith at oracle dot 
com

--- Comment #1 from Alan Coopersmith  ---
Created attachment 58057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58057=edit
dup2.c test case

[Bug tree-optimization/114876] [11/12/13/14 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||6.4.0
  Known to fail||7.1.0
Summary|-fprintf-return-value   |[11/12/13/14 Regression]
   |mishandles %lc with a '\0'  |-fprintf-return-value
   |argument.   |mishandles %lc with a '\0'
   ||argument.
   Target Milestone|--- |11.5

--- Comment #2 from Andrew Pinski  ---
>From format_character in gimple-ssa-sprintf.cc:
  if (min == 0 && max == 0)
{
  /* The NUL wide character results in no bytes.  */
  res.range.max = 0;
  res.range.likely = 0;
  res.range.unlikely = 0;
}


Which indirectly was introduced with r7-3167-g88d0c3f0a1448e .

[Bug middle-end/114877] [11/12/13/14/15 Regression] wrong-code for frexp(NAN, )

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||9.5.0
  Known to work||4.2.0
   Target Milestone|--- |11.5
Summary|wrong-code for frexp(NAN,   |[11/12/13/14/15 Regression]
   |) |wrong-code for frexp(NAN,
   ||)
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-28
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
frexp folding was introduced with r0-79285-g7a2a25ab4f30cc for GCC 4.3.0 which
had the issue

BUT we produced good code until GCC 10.1.0 which changed the behavior of ccp
here.

[Bug libstdc++/114879] New: std::ios::sync_with_stdio(false) triggers undefined behaviour of fflush(stdin)

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

Bug ID: 114879
   Summary: std::ios::sync_with_stdio(false) triggers undefined
behaviour of fflush(stdin)
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: campbell+gcc-bugzilla at mumble dot net
  Target Milestone: ---

std::ios::sync_with_stdio(false) creates a stdio_filebuf over stdin with mode
in:

 182 new (_cin) stdio_filebuf(stdin, ios_base::in);

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B98/ios_init.cc;h=ace94b992b5ac7559352f5e7e94c67f64317bd9d;hb=c891d8dc23e1a46ad9f3e757d09e57b500d40044#l182

The stdio_filebuf constructor for these parameter types passes the arguments on
to __basic_file::sys_open:

 158   this->_M_file.sys_open(__f, __mode);

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/ext/stdio_filebuf.h;h=98b8fa2a095acf190237887d4e21394212d1f38a;hb=c891d8dc23e1a46ad9f3e757d09e57b500d40044#l158

With these parameter types, __basic_file::sys_open will, in turn, pass
stdin to fflush in this case, and will only actually open the file if fflush
succeeds:

 216 do
 217   __err = fflush(__file);
 218 while (__err && errno == EINTR);
 219 errno = __save_errno;
 220 if (!__err)
 221   {
 222 _M_cfile = __file;
 223 _M_cfile_created = false;
 224 __ret = this;
 225   }

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/config/io/basic_file_stdio.cc;h=27c2ad2afe3ade7284ec9d487b74d3d04dd756f4;hb=c891d8dc23e1a46ad9f3e757d09e57b500d40044#l216

But stdin is an input stream, not an output or update stream.  And calling
fflush on an input stream is undefined behaviour in standard C:

> If stream points to an output stream or an update stream in which
> the most recent operation was not input, the fflush function causes
> any unwritten data for that stream to be delivered to the host
> environment to be written to the file; otherwise, the behavior is
> undefined.
> 
> (ISO C11 and ISO C17, Sec. 7.21.5.2 `The fflush function')

On NetBSD 9, what fflush(stdin) does depends on whether fd 0 is open for
writing or not:

- If fd 0 is open for writing (unlikely but possible), it will write a buffer's
worth of heap garbage to fd 0.
- If fd 0 is not open for writing (more likely), fflush will fail with EBADF,
causing __basic_file::sys_open to fail, after which although
std::cin.good() will initially return true, std::cin will otherwise be
nonfunctional (https://gnats.NetBSD.org/58206).

Fix: Don't call fflush if the mode is input.

(This bug first appeared no later than GCC 7, which NetBSD 9 ships with and
where I found the bug, and still appears in GCC 13.2.0, as quoted in the code
above.)

[Bug c++/114652] g++ fails to compile the ceres-solver-2.2.0 project: error: use of built-in trait '__remove_cvref(_Tp)' in function signature; use library traits instead

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

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

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

[Bug c++/114878] GCC fails with an error on armv7: use of built-in trait '__remove_cvref(_InIter1)' in function signature; use library traits instead

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is a bug in libc++ that comes from freebsd. It has already been fixed
upstream too. See pr 114652 for the commit where it was fixed which freebsd
needs to backport.

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

[Bug c++/114878] New: GCC fails with an error on armv7: use of built-in trait '__remove_cvref(_InIter1)' in function signature; use library traits instead

[yuri at tsoft dot com via Gcc-bugs]

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

Bug ID: 114878
   Summary: GCC fails with an error on armv7: use of built-in
trait '__remove_cvref(_InIter1)' in function
signature; use library traits instead
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yuri at tsoft dot com
  Target Milestone: ---

2 projects where the problem occurs:
* https://karlsruhemis.github.io/
* https://github.com/Artelnics/opennn

The failure occurs on FreeBSD, only on the armv7 architecture.

Here is the FreeBSD bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278630

Here is a sample failure log:
https://pkg-status.freebsd.org/ampere1/data/140releng-armv7-quarterly/1b931669de11/logs/kamis-2.1.log

[Bug libstdc++/114866] [14/15 Regression] & out_ptr in freestanding

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-28
 Ever confirmed|0   |1
Summary| & out_ptr in   |[14/15 Regression] 
   |freestanding|& out_ptr in freestanding
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jonathan Wakely  ---
Yes, this is a regression, and should be fixed in the gcc-14 branch.

[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #20 from Iain Sandoe  ---
fixed on open branches (needed on earlier if maintained).

[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

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

commit r11-11393-gee2f7a02371aba24f6db6231ae862cd2248bf45f
Author: Francois-Xavier Coudert 
Date:   Sat Aug 19 23:22:06 2023 +0200

Testsuite: fix analyzer tests on Darwin

On macOS, system headers redefine by default some macros (memcpy,
memmove, etc) to checked versions, which defeats the analyzer. We
want to turn this off.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042

gcc/testsuite/ChangeLog:

PR analyzer/104042
* gcc.dg/analyzer/analyzer.exp: Pass -D_FORTIFY_SOURCE=0 on Darwin.

(cherry picked from commit ce33bbfcbc7dd3afc6c96fb48a19ed00f0c598ce)

[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059

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

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

--- Comment #19 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

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

commit r11-11385-ga1b0ace9737a40957bfb298de22066d8ee9a6603
Author: Iain Sandoe 
Date:   Sat Jan 6 10:52:38 2024 +

Darwin: Fix constant CFString code-gen [PR105522].

Although this only fires for one of the Darwin sub-ports, it is latent
elsewhere, it is also a regression c.f. the Darwin system compiler.

In the code we imported from an earlier branch, CFString objects (which
are constant aggregates) are constructed as CONST_DECLs.  Although our
current documentation suggests that these are reserved for enumeration
values, in fact they are used elsewhere in the compiler for constants.
This includes Objective-C where they are used to form NSString constants.

In the particular case, we take the address of the constant and that
triggers varasm.cc:decode_addr_constant, which does not currently support
CONST_DECL.

If there is a general intent to allow/encourage wider use of CONST_DECL,
then we should fix decode_addr_constant to look through these and evaluate
the initializer (a two-line patch, but I'm not suggesting it for stage-4).

We also need to update the GCC internals documentation to allow for the
additional uses.

This patch is Darwin-local and fixes the problem by making the CFString
constants into regular variable but TREE_CONSTANT+TREE_READONLY. I plan
to back-port this to the open branches once it has baked a while on trunk.

Since, for Darwin, the Objective-C default is to construct constant
NSString objects as CFStrings; this will also cover the majority of cases
there (this patch does not make any changes to Objective-C NSStrings).

PR target/105522

gcc/ChangeLog:

* config/darwin.c (machopic_select_section): Handle C and C++
CFStrings.
(darwin_rename_builtins): Move this out of the CFString code.
(darwin_libc_has_function): Likewise.
(darwin_build_constant_cfstring): Create an anonymous var to
hold each CFString.
* config/darwin.h (ASM_OUTPUT_LABELREF): Handle constant
CFstrings.

Signed-off-by: Iain Sandoe 
(cherry picked from commit aecc0d4ba73d0810334b351da1e67232cea450d3)

[Bug target/112959] install.tex needs updates on FreeBSD

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

https://gcc.gnu.org/g:507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb

commit r15-24-g507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb
Author: Gerald Pfeifer 
Date:   Sun Apr 28 14:59:14 2024 +0200

doc: Remove references to FreeBSD 7 and older

FreeBSD 7 has been end of life for years and current GCC most likely
would not build there anymore anyways.

gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: Remove references to
FreeBSD 7 and older.

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #7 from GCC Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

https://gcc.gnu.org/g:507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb

commit r15-24-g507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb
Author: Gerald Pfeifer 
Date:   Sun Apr 28 14:59:14 2024 +0200

doc: Remove references to FreeBSD 7 and older

FreeBSD 7 has been end of life for years and current GCC most likely
would not build there anymore anyways.

gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: Remove references to
FreeBSD 7 and older.

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

[gerald at pfeifer dot com via Gcc-bugs]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com

--- Comment #18 from Gerald Pfeifer  ---
(In reply to Andrew Pinski from comment #17)
> Testing the removal of the code from the driver.

Thanks! Looking into building on FreeBSD 13.2 with LLD (base system)
instead of GNU ld (ports) I ran into this again, which is really ... 
surprising for a naive user.

It would be great to tackle this once and for all.

[Bug libstdc++/114866] & out_ptr in freestanding

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org,
   ||jwakely.gcc at gmail dot com

--- Comment #2 from Arsen Arsenović  ---
I read the out_ptr proposal a while back but if memory serves right, I see no
reason why we couldn't add it to our freestanding extensions in GCC 15.

Jonatnan, is this something we should fix+backport also (rather than the full
feature, just add HOSTED to the outptr FTM test and put that in 14)?  It could
be considered a regression that  fails to compile.

[Bug c/114877] New: wrong-code for frexp(NAN, )

[leni536 at gmail dot com via Gcc-bugs]

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

Bug ID: 114877
   Summary: wrong-code for frexp(NAN, )
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leni536 at gmail dot com
  Target Milestone: ---

arch: x86_64
command line arguments: -std=c17 -O2 -pedantic-errors

#include 
#include 

int frexp_test(bool b) {
if (b) {
int x;
(void)frexp(NAN, );
int y = x;
return y - x;
}
return 42;
}

https://godbolt.org/z/a1cn4cPqr

Observed behavior:

gcc optimizes the above function to always return 42 regardless of the value of
`b`. `frexp_test(true)` has defined behavior and must return 0.

Expected behavior:

The C standard seems to be unambiguous that an unspecified value is written to
`x` when `frexp` is called. Therefore `frexp_test(true)` has defined behavior
and must return 0.


GCC's semantics of `frexp(NAN, )` seems to be that it doesn't write to `x` at
all. This is a valid optimization of `x` is not uninitialized, this would be
equivalent to `*x = *x`, so the unspecified value produce by `frexp` can be the
same value that was already there. However this isn't valid when `x` was not
initialized in the first place and subsequent optimizations treat `x` as still
uninitialized.

[Bug libstdc++/114866] & out_ptr in freestanding

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #1 from Jiang An  ---
It seems that the primary tempate of __is_shared_ptr should be made available
in freestanding mode.

[Bug tree-optimization/114876] -fprintf-return-value mishandles %lc with a '\0' argument.

[bruno at clisp dot org via Gcc-bugs]

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

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #1 from Bruno Haible  ---
What does *printf of %lc with a (wint_t) '\0' argument do?

Note that the published POSIX:2018 still has a wrong description: Its
description requires *printf to produce 0 characters.

This was wrong in ISO C as well. It has been corrected in ISO C 23 § 7.23.6.1,
in the meeting from 2023-06-20 to 2023-06-23. See
https://www.open-std.org/JTC1/sc22/wg14/www/docs/n3167.pdf  section GB-141 page
23, 24. The decision ("option 1") is detailed in
https://www.open-std.org/JTC1/sc22/wg14/www/docs/n3148.doc row GB-141 page 34,
35:
  "Option 1 (require a NUL) - change the text to:
   If an l length modifier is present, the wint_t argument is converted
   as if by a call to the wcrtomb function with a pointer to storage of
   at least MB_CUR_MAX bytes, the wint_t argument converted to wchar_t,
   and an initial shift state."
This description requires *printf to produce 1 NUL character.

Then, the Austin Group followed suit and, through
https://austingroupbugs.net/view.php?id=1647 , decided that POSIX will use the
same definition:
  "If an l (ell) qualifier is present, the wint_t argument shall be converted
   to a multi-byte sequence as if by a call to wcrtomb( ) with the wint_t
   argument converted to wchar_t and an initial shift state, and the
   resulting bytes written."

This aligns the POSIX behaviour with what glibc was doing all the time, namely
to produce 1 NUL character.

[Bug tree-optimization/114876] New: -fprintf-return-value mishandles %lc with a '\0' argument.

[collin.funk1 at gmail dot com via Gcc-bugs]

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

Bug ID: 114876
   Summary: -fprintf-return-value  mishandles %lc with a '\0'
argument.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: collin.funk1 at gmail dot com
  Target Milestone: ---

I noticed some test failures in some Gnulib test cases earlier [1].

I'm using Fedora 40's GCC 14.0 package.

$ uname -a
Linux fedora 6.8.7-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 17 19:21:08
UTC 2024 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-14.0.1-20240411/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240411 (Red Hat 14.0.1-0) (GCC) 

$ ldd --version
ldd (GNU libc) 2.39

Here is a test program:

===
int
main (void)
{
  char buffer[5000];
  wint_t ch = (wint_t) '\0';
  int result = sprintf (buffer, "%lc%lc%lc%lc", ch, ch, ch, ch);
  printf ("%d\n", result);
  return 0;
}
===

I believe that this program should print 4. POSIX states "Upon successful
completion, the sprintf() function shall return the number of bytes written to
s, excluding the terminating null byte." So in total 5 '\0' characters written
to the buffer and 4 returned because the extra terminating one is excluded.

Here is some runs with different optimization settings:

# -O0 passes.
$ make
gcc -Wall -Wextra -g -O0  -o a.out main.c
./a.out
4

# -01 fails, likewise for -O2 and -O3.
$ make
gcc -Wall -Wextra -g -O1  -o a.out main.c
./a.out
0

# -O0 -fprintf-return-value passes.
$ make
gcc -Wall -Wextra -g -O0 -fprintf-return-value -o a.out main.c
./a.out
4

# -01 -fprintf-return-value fails.
$ make
gcc -Wall -Wextra -g -O1 -fprintf-return-value -o a.out main.c
./a.out
0

# -O1 -fno-printf-return-value passes, likewise for -O2 and -O3 with
-fno-printf-return-value.
$ make
gcc -Wall -Wextra -g -O1 -fno-printf-return-value -o a.out main.c
./a.out
4

I also built a barebones gcc-13.2 compiler from the tarball on the GNU FTP
server. It seems to behave in the same way.

$ gcc-13.2 -v
Using built-in specs.
COLLECT_GCC=gcc-13.2
COLLECT_LTO_WRAPPER=/home/collin/.local/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/collin/.local
--program-suffix=-13.2 --enable-languages=c,c++ --enable-threads=posix
--enable-linker-build-id --disable-multilib --disable-multiarch
--with-tune=generic --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (GCC) 

I've never submitted a GCC bug, so please let me know if you need any more
information. Thanks!

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00453.html

[Bug target/44793] [11/12/13/14/15 Regression] libgcc does not include t-ppccomm on rtems

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME
 CC||linkw at gcc dot gnu.org

--- Comment #26 from Kewen Lin  ---
libgcc/config.host on gcc-11 has:

powerpc-*-rtems*)
  tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr
rs6000/t-crtstuff t-crtstuff-p  ic t-fdpbit"
  extra_parts="$extra_parts crtbeginS.o crtendS.o crtbeginT.o ecrti.o
ecrtn.o ncrti.o ncrtn.o"
  ;;

I think this had been fixed already by r0-119741-g6f28886030623a.

Please feel free to reopen it if it still occurs on active releases. Thanks!

[Bug target/58684] powerpc uses only unordered floating-point compares

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:6e95dca31c6b4688e0f0a25c9c3aa8a0bedc9056

commit r15-20-g6e95dca31c6b4688e0f0a25c9c3aa8a0bedc9056
Author: Alexandre Oliva 
Date:   Sun Apr 28 04:30:24 2024 -0300

xfail fetestexcept test - ppc always uses fcmpu

gcc.dg/torture/pr91323.c tests that a compare with NaNf doesn't set an
exception using builtin compare intrinsics, and that it does when
using regular compare operators.

That doesn't seem to be expected to work on powerpc targets.  It fails
on GNU/Linux, it's marked to be skipped on AIX, and a similar test,
gcc.dg/torture/pr93133.c, has the execution test xfailed for all of
powerpc*-*-*.

In this test, the functions that use intrinsics for the compare end up
with the same code as the one that uses compare operators, using
fcmpu, a floating compare that, unlike fcmpo, does not set the invalid
operand exception for quiet NaN.  I couldn't find any evidence that
the rs6000 backend ever outputs fcmpo.  Therefore, I'm adding the same
execution xfail marker to this test.


for  gcc/testsuite/ChangeLog

PR target/58684
* gcc.dg/torture/pr91323.c: Expect execution fail on
powerpc*-*-*.

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #19 from Li Pan  ---
Thanks Juzhe.  Here is another example

-
#include 

extern size_t get_new_vl ();

size_t
__attribute__((noinline))
get_vl (size_t *c)
{
  size_t vl = c[0] + c[1];

  return vl;
}

vbool64_t
test_fail_2 (vuint64m1_t a, unsigned long b, size_t *c)
{
  return __riscv_vmsne_vx_u64m1_b64 (a, b, get_vl (c));
}
---

test_fail_2:   
   
   [30/37834]
addisp,sp,-16
sd  ra,8(sp)
sd  s0,0(sp)
csrrt0,vlenb
sub sp,sp,t0
vs1r.v  v1,0(sp)
sub sp,sp,t0
vs1r.v  v2,0(sp)
sub sp,sp,t0
vs1r.v  v3,0(sp)
sub sp,sp,t0
vs1r.v  v4,0(sp)
sub sp,sp,t0
vs1r.v  v5,0(sp)
sub sp,sp,t0
vs1r.v  v6,0(sp)
sub sp,sp,t0
vs1r.v  v7,0(sp)
sub sp,sp,t0
vs1r.v  v24,0(sp)
sub sp,sp,t0
vs1r.v  v25,0(sp)
sub sp,sp,t0
vs1r.v  v26,0(sp)
sub sp,sp,t0
vs1r.v  v27,0(sp)
sub sp,sp,t0
vs1r.v  v28,0(sp)
sub sp,sp,t0   
   
 vs1r.v  v29,0(sp) 
   
   
  sub sp,sp,t0
vs1r.v  v30,0(sp)
sub sp,sp,t0
vs1r.v  v31,0(sp)
csrrt0,vlenb
sub sp,sp,t0
vs1r.v  v8,0(sp)
mv  s0,a0
mv  a0,a1
callget_vl
vl1re64.v   v8,0(sp)
vsetvli zero,a0,e64,m1,ta,ma
vmsne.vxv0,v8,s0
csrrt0,vlenb
add sp,sp,t0
csrrt0,vlenb
vl1re64.v   v31,0(sp)
add sp,sp,t0
vl1re64.v   v30,0(sp)
add sp,sp,t0
vl1re64.v   v29,0(sp)
add sp,sp,t0
vl1re64.v   v28,0(sp)
...

As I understand, these callee saved vector registers are not required if the
function body doesn't pollute these registers.  Only the polluted registers
need to go in/out stack.

However, it is somehow one optimization here, we can consider to improve this
in GCC-15 if my understanding is correct.

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #18 from JuzheZhong  ---
(In reply to Li Pan from comment #17)
> According to the V abi, looks like the asm code tries to save/restore the
> callee-saved registers when there is a call in function body.
> 
> | Name| ABI Mnemonic | Meaning  | Preserved across
> calls?
> =
> 
> | v0  |  | Argument register| No
> | v1-v7   |  | Callee-saved registers   | Yes
> | v8-v23  |  | Argument registers   | No
> | v24-v31 |  | Callee-saved registers   | Yes

I see, https://godbolt.org/z/7bx1EEdGn
When we use 44 instead of get_vl (), the load/store instructions are gone.

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #17 from Li Pan  ---
According to the V abi, looks like the asm code tries to save/restore the
callee-saved registers when there is a call in function body.

| Name| ABI Mnemonic | Meaning  | Preserved across
calls?
=
| v0  |  | Argument register| No
| v1-v7   |  | Callee-saved registers   | Yes
| v8-v23  |  | Argument registers   | No
| v24-v31 |  | Callee-saved registers   | Yes