[Bug fortran/113254] Option -fallow-invalid-boz does not help with sample code

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

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to mecej4 from comment #2)
> Created attachment 57001 [details]
> Program source that is handled correctly when -fallow-invalid-boz is
> specified

Correctly?  It is not the same as the initial case.

For [B'0111',B'1011', ...], each of the BOZ is an ac-value.
See the Fortran standards for the constraints that I already cited.
A BOZ cannot be an ac-value.  It is typeless.  Should gfortran convert
B'0111' to 127 or 1.77964905E-43?  Remember a BOZ is typeless,
and prior to F2023, the RHS is evaluated without regard to the type and
kind of the LHS.

For the new case of [char(B'0111'),char(B'1011'), ...], the
BOZ are actual arguments to some intrinsic subprogram.  These BOZ are
not ac-values.  The error message(s) actually tells you that this is invalid.
Gfortran accepts these actual-argument BOZ with the -fallow-invalid-boz,
because older versions of gfortran would convert a BOZ to an integer upon
reading the BOZ from the source code.  The actual argument of char() happens
to be of type integer, so you got lucky!

Consider the equally egregious example:

   program bozz
  implicit none
  real, parameter :: x = sin(B'0111')
  print *, x
   end program

% gfcx -o z a.f90
a.f90:4:28:

4 |real, parameter :: x=sin(B'0111')
  |1
Error: A BOZ literal constant at (1) cannot appear as an actual argument in a
function reference

% gfcx -o z a.f90 -fallow-invalid-boz
a.f90:4:28:

4 |real, parameter :: x=sin(B'0111')
  |1
Error: A BOZ literal constant at (1) cannot appear as an actual argument in a
function reference

[integer ::  B'0111',B'1011', ...] is F2023 standard conforming.
gfortran does not currently support this new feature of F2023.  It should
not be too hard to support F2023, but that would require someone to either
provide a patch or provide funding for someone else to provide the patch.

[Bug fortran/113254] Option -fallow-invalid-boz does not help with sample code

[xecej4 at outlook dot com via Gcc-bugs]

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

--- Comment #2 from mecej4  ---
Created attachment 57001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57001&action=edit
Program source that is handled correctly when -fallow-invalid-boz is specified

[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)

[gcc at octaforge dot org via Gcc-bugs]

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

--- Comment #8 from Daniel Kolesa  ---
I tried an experiment: I canceled the build after initial generation of
insn-recog.cc and patched the offending part with logic from a stage-2
insn-recog.cc I managed to previously capture:

```
--- insn-recog.cc.orig  2024-01-07 04:46:19.328295337 +0100
+++ insn-recog.cc   2024-01-07 04:41:52.025630846 +0100
@@ -41675,11 +41675,12 @@
   break;
 }
   operands[0] = x3;
-  if (!gpc_reg_operand (operands[0], E_SImode)
+  if (GET_CODE (x2) != MEM
   || GET_MODE (x2) != E_SImode)
 return -1;
   x4 = XEXP (x2, 0);
-  if (GET_MODE (x4) != E_SImode)
+  if (GET_CODE (x4) != PLUS
+  || GET_MODE (x4) != E_SImode)
 return -1;
   switch (GET_CODE (x2))
 {
```

This allowed all 3 stages to finish building. It results in lots of failed
comparisons for stage2 and stage3 files though, and is obviously not a workable
solution.

[Bug c++/113256] New: False -Wdangling-reference positive

[pdimov at gmail dot com via Gcc-bugs]

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

Bug ID: 113256
   Summary: False -Wdangling-reference positive
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

The following code
```
#include 
#include 

template auto bind( M T::* pm, A a )
{
return [=]( auto&& x ) -> M const& { return x.*pm; };
}

template struct arg {};

arg<1> _1;

int main()
{
std::pair pair;
int const& x = bind( &std::pair::first, _1 )( pair );
assert( &x == &pair.first );
}
```
(https://godbolt.org/z/a555MMTqo)

(reduced from a Boost.Bind test case)

causes

```
:16:16: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
   16 | int const& x = bind( &std::pair::first, _1 )( pair );
  |^
```

with GCC 13.2 (but not trunk).

There are indeed two temporaries created in that full expression, but `int
const&` can't possibly bind to any of them.

[Bug fortran/113254] Option -fallow-invalid-boz does not help with sample code

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
-fallow-invalid-boz is not a panacea for invalid Fortran.

F2018 has

   F2018:C7110 (R770) If type-spec is omitted, each ac-value expression
   in the array-constructor shall have the same declared type and kind
   type parameters.

   F2018:C7111 (R770) If type-spec specifies an intrinsic type, each ac-value
   expression in the array-constructor shall be of an intrinsic type that
   is in type conformance with a variable of type type-spec as specified in
   Table 10.8.

As a BOZ is typeless, it therefore cannot be in an array constructor.
Even if you had added a type-spec such as '[integer :: ...]'.

F2023 does allow a BOZ in an array constructor, with the following constraints:

   F2023:C7126 If an ac-value is a boz-literal-constant, type-spec shall
   appear and shall specify type integer or real.

   F2023:C7127 If an ac-value is a boz-literal-constant and type-spec
   specifies type real, the boz-literal-constant shall be a valid internal
   representation for the specified kind of real.

Your code lacks a type-spec, so C7126 kicks in.  Even with a type-spec,
as this is a new F2023 feature, gfortran does not currently support a BOZ
in an array-constructor.

Adding this capability would be a good introduction to contributing to
gfortran development.

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED
   Target Milestone|--- |14.0

--- Comment #10 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-6975-g8c5d00f8291d718ef64c742b9c971e16f75e5074
Author: Jonathan Wakely 
Date:   Wed Dec 13 09:45:44 2023 +

libstdc++: Avoid conflicting declaration in eh_call.cc [PR112997]

r14-1527-g2415024e0f81f8 changed the parameter of the
__cxa_call_terminate definition, but there's also a declaration in
unwind-cxx.h which should have been changed too.

libstdc++-v3/ChangeLog:

PR libstdc++/112997
* libsupc++/unwind-cxx.h (__cxa_call_terminate): Change first
parameter to void*.

[Bug c++/102780] Checking constraints using large fold expression is slow

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:7d11d813583efad652c83c7631ef8d6d18489119

commit r14-6974-g7d11d813583efad652c83c7631ef8d6d18489119
Author: Jonathan Wakely 
Date:   Wed Dec 6 18:32:21 2023 +

libstdc++: Remove dg-timeout-factor from test

As the comment notes, the increased timeout was needed because of PR
102780, but that was fixed long ago.

libstdc++-v3/ChangeLog:

* testsuite/20_util/variant/87619.cc: Remove dg-timeout-factor.

[Bug target/113255] [11/12/13/14 Regression] wrong code with -O2 -mtune=k8

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
  Known to fail||10.2.0
   Last reconfirmed||2024-01-06
  Known to work||10.1.0
  Component|c   |target
 Ever confirmed|0   |1
Summary|wrong code with -O2 |[11/12/13/14 Regression]
   |-mtune=k8   |wrong code with -O2
   ||-mtune=k8
 Status|UNCONFIRMED |NEW

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

This looks to be a target issue.
`-O2 -mtune=k8  -mstringop-strategy=libcall` works but
`-O2 -mtune=k8  -mstringop-strategy=rep_8byte` does not.

[Bug c/113255] New: wrong code with -O2 -mtune=k8

[mednafen at sent dot com via Gcc-bugs]

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

Bug ID: 113255
   Summary: wrong code with -O2 -mtune=k8
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mednafen at sent dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

Created attachment 57000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57000&action=edit
test case

Linux x86_64

$ /usr/local/gcc-13.2.0/bin/gcc -Wall -O2 -o sprite sprite.c && ./sprite
1

$ /usr/local/gcc-13.2.0/bin/gcc -Wall -O2 -mtune=k8 -o sprite sprite.c &&
./sprite
0
Aborted


The problem appears to have started around version 10.2.0.

[Bug tree-optimization/113239] [13 regression] After 822a11a1e64, bogus -Warray-bounds warnings in std::vector

[dimitry--- via Gcc-bugs]

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

--- Comment #3 from Dimitry Andric  ---
Alright, I can confirm that adding --param=vrp1-mode=vrp makes the warning go
away. However, this option is no longer recognized by gcc-14-6924-g00dea7e8c41.
I assume the ranger mode is now the default, and the older mode is no longer
supported.

[Bug tree-optimization/113239] [13 regression] After 822a11a1e64, bogus -Warray-bounds warnings in std::vector

[dimitry--- via Gcc-bugs]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #2 from Dimitry Andric  ---
I reduced a preprocessed version of the test case to a more minimal version,
which does not include the full  header. Bisecting with the
preprocessed and reduced test case again shows that it regressed with commit
e7310e24b1c0ca67b1bb507c1330b2bf39e59e32 ("Make ranger vrp1 default").

New test case:

// g++ -std=c++17 -Wall -O2 -c pr113239-preproc.cpp

struct __is_move_iterator
{
  enum
  {
__value
  };
};
template  struct __normal_iterator
{
  _Iterator _M_current;
  __normal_iterator (_Iterator __i) : _M_current (__i) {}
  _Iterator
  base ()
  {
return _M_current;
  }
};
template 
bool
operator== (__normal_iterator<_Iterator, _Container> __lhs,
__normal_iterator<_Iterator, _Container> __rhs)
{
  return __lhs.base () == __rhs.base ();
}
template 
_Iterator __niter_base (__normal_iterator<_Iterator, _Container>);
struct __copy_move
{
  template 
  static void
  __assign_one (_Tp __to, _Up __from)
  {
*__to = *__from;
  }
  template 
  static _Up *
  __copy_m (_Tp *__last, _Up *__result)
  {
_Tp __first;
long _Num = __last - &__first;
__assign_one (__result, &__first);
return __result + _Num;
  }
};
template 
_OI
__copy_move_a2 (_II __last, _OI __result)
{
  return __copy_move::__copy_m (__last, __result);
}
template 
_OI
__copy_move_a1 (_II __last, _OI __result)
{
  return __copy_move_a2<_IsMove> (__last, __result);
}
template 
_OI
__copy_move_a (_II __last, _OI __result)
{
  _OI __trans_tmp_1
  = __copy_move_a1<_IsMove> (__niter_base (__last), __result);
  return __trans_tmp_1;
}
template 
void
copy (_II __last, _OI __result)
{
  __copy_move_a<__is_move_iterator::__value> (__last, __result);
}
template  struct __new_allocator
{
# 125
"/home/dim/ins/gcc-14-6924-g00dea7e8c41/include/c++/14.0.0/bits/new_allocator.h"
3
  unsigned char *
  allocate (long __n)
  {

if (alignof (char))

  std::align_val_t __al ((sizeof (_Tp), __al));

return static_cast (operator new (__n));
  }
};
template  struct allocator_traits;
template  struct allocator_traits<__new_allocator<_Tp> >
{
  using allocator_type = __new_allocator<_Tp>;
  using pointer = _Tp *;
  using const_pointer = _Tp *;
  using size_type = long;
  template  using rebind_alloc = __new_allocator<_Up>;
  static pointer
  allocate (allocator_type __a, size_type __n)
  {
return __a.allocate (__n);
  }
};
struct __alloc_traits : allocator_traits<__new_allocator >
{
  struct rebind
  {
typedef rebind_alloc other;
  };
};
struct __uninitialized_copy
{
  template 
  static __uninit_copy (_InputIterator __last, _ForwardIterator __result)
  {
copy (__last, __result);
  }
};
template 
uninitialized_copy (_InputIterator __last, _ForwardIterator __result)
{
  __uninitialized_copy::__uninit_copy (__last, __result);
}
template 
__uninitialized_copy_a (_InputIterator, _InputIterator __last,
_ForwardIterator __result, _Tp)
{
  uninitialized_copy (__last, __result);
}
struct _Vector_base
{
  typedef __alloc_traits::rebind::other _Tp_alloc_type;
  typedef __alloc_traits::pointer pointer;
  struct _Vector_impl_data
  {
pointer _M_start;
pointer _M_finish;
  };
  struct _Vector_impl : _Tp_alloc_type, _Vector_impl_data
  {
_Vector_impl (_Tp_alloc_type);
  };
  _Vector_base (long __n, __new_allocator __a) : _M_impl (__a)
  {
_M_impl._M_start = _M_allocate (__n);
  }
  _Vector_impl _M_impl;
  pointer
  _M_allocate (unsigned long __n)
  {
return __n ? __alloc_traits::allocate (_M_impl, __n) : pointer ();
  }
};
struct vector : _Vector_base
{
  typedef __normal_iterator<__alloc_traits::const_pointer, int> const_iterator;
  vector ();
  _Tp_alloc_type __trans_tmp_5;
  vector (vector &__x) : _Vector_base (__x.size (), __trans_tmp_5)
  {
_Tp_alloc_type __trans_tmp_4;
const_iterator __trans_tmp_2 = 0, __trans_tmp_3 = 0;
__uninitialized_copy_a (__trans_tmp_2, __trans_tmp_3, _M_impl._M_start,
__trans_tmp_4);
  }
  const_iterator
  begin ()
  {
return _M_impl._M_start;
  }
  const_iterator
  end ()
  {
return _M_impl._M_finish;
  }
  size () { return _M_impl._M_finish - _M_impl._M_start; }
  empty () { return begin () == end (); }
};
struct frame_t
{
  frame_t () : pts_ (0), timescale_ (0), data_ () {}
  long pts_;
  int timescale_;
  vector data_;
};
struct frame_source_t
{
  virtual frame_t get ();
};
struct frame_filter_t : frame_source_t
{
  frame_t
  get ()
  {
if (current_frame_.data_.empty ())
  return current_frame_;
  }
  frame_t current_frame_;
};
create_frame_filter () { frame_filter_t (); }

// EOT

With gcc-13-3595-g7b1cdca6d6d:

$ ~/ins/gcc-13-3595-g7b1cdca6d6d/bin/g++ -std=c++17 -O2 -Wall

[Bug sanitizer/105347] [12/13/14 Regression] Failed to build from source on FreeBSD 11.* due to using nonexistent sha224.h

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html

So basically <= FreeBSD 12 is no longer supported

[Bug fortran/113254] New: Option -fallow-invalid-boz does not help with sample code

[xecej4 at outlook dot com via Gcc-bugs]

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

Bug ID: 113254
   Summary: Option -fallow-invalid-boz does not help with sample
code
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xecej4 at outlook dot com
  Target Milestone: ---

Created attachment 56999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56999&action=edit
Fortran program to illustrate no benefit from -fallow-invalid-boz

The -fallow-invalid-boz option is described to have this purpose: "... allows a
BOZ literal constant to appear where the Fortran standard would otherwise
prohibit its use". 

The option appears to have no effect on the attached test program, and the
error message is the same with or without -fallow-invalid-boz. (I am also using
-fmax-errors=1.)

[Bug analyzer/102671] -Wanalyzer-null-dereference false positive when compiling GNU Emacs

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

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

--- Comment #6 from Paul Eggert  ---
(In reply to Paul Eggert from comment #4)
> Created attachment 56996 [details]
> marker.i example from GNU Emacs
> 
> Here is another example of the problem, taken from bleeding-edge GNU Emacs

Ooops, please ignore this marker.i example; I included it by mistake here. This
was work product while I was working on bug 113253. The xselect.i example
should be good.

[Bug analyzer/113253] New: gcc -g causes -fanalyzer to issue false positive

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

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

Bug ID: 113253
   Summary: gcc -g causes -fanalyzer to issue false positive
   Product: gcc
   Version: 13.2.1
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 56998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56998&action=edit
marker1.i file illustrating -fanalyzer -g bug

This is a weird one, taken from bleeding-edge GNU Emacs, compiled with gcc
(GCC) 13.2.1 20231205 (Red Hat 13.2.1-6) on x86-64. Compile the attached with:

gcc -O2 -S -g -fanalyzer marker1.i

I get the following diagnostic, which is a false positive. If I do not use the
gcc's "-g" option, the compile is clean with no diagnostics.

marker1.i: In function ‘set_marker_internal’:
marker1.i:17754:7: warning: check of ‘(long unsigned int)buffer +
18446744073709551611’ for NULL after already dereferencing it
[-Wanalyzer-deref-before-check]
17752 |   if (NILP (position)
  |   ~~~
17753 |   || (MARKERP (position) && !XMARKER (position)->buffer)
  |   ~~
17754 |   || !b)
  |   ^
  ‘set_marker_restricted’: events 1-2
|
|17803 | set_marker_restricted (Lisp_Object marker, Lisp_Object position,
|  | ^
|  | |
|  | (1) entry to ‘set_marker_restricted’
|..
|17806 |   return set_marker_internal (marker, position, buffer,
|  |  ~~
|  |  |
|  |  (2) calling ‘set_marker_internal’ from
‘set_marker_restricted’
|17807 |1
|  |~
|17808 |);
|  |~
|
+--> ‘set_marker_internal’: events 3-4
   |
   |17743 | set_marker_internal (Lisp_Object marker, Lisp_Object
position,
   |  | ^~~
   |  | |
   |  | (3) entry to ‘set_marker_internal’
   |..
   |17749 |   struct buffer *b = live_buffer (buffer);
   |  |  ~
   |  |  |
   |  |  (4) inlined call to ‘live_buffer’ from
‘set_marker_internal’
   |
   +--> ‘live_buffer’: event 5
  |
  |17737 |   struct buffer *b = decode_buffer (buffer);
  |  |  ^~
  |  |  |
  |  |  (5) calling ‘decode_buffer’
from ‘set_marker_internal’
  |
‘decode_buffer’: events 6-9
  |
  |11274 | decode_buffer (Lisp_Object b)
  |  | ^
  |  | |
  |  | (6) entry to ‘decode_buffer’
  |11275 | {
  |11276 |   return NILP (b) ?
(current_thread->m_current_buffer) : (CHECK_BUFFER (b), XBUFFER (b));
  |  | 
~~~
  |  | 
  |  |
  |  | 
  |  (8) ...to here
  |  | 
  |  (9) calling ‘CHECK_BUFFER’ from ‘decode_buffer’
  |  | 
  (7) following ‘false’ branch (when ‘b’ is non-NULL)...
  |
  +--> ‘CHECK_BUFFER’: event 10
 |
 |10892 | CHECK_BUFFER (Lisp_Object x)
 |  | ^~~~
 |  | |
 |  | (10) entry to ‘CHECK_BUFFER’
 |
 +--> ‘CHECK_BUFFER’: event 11
|
|10894 |   CHECK_TYPE (BUFFERP (x),
builtin_lisp_symbol (346), x);
|  |   ^
|  |   |
|  |   (11) inlined call to
‘BUFFERP’ from ‘CHECK_BUFFER’
|
+--> ‘BUFFERP’: event 12
   |
   |10889 |   return PSEUDOVECTORP (a,
PVEC_BUFFER);
 

[Bug libgomp/113192] [11/12/13/14 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory

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

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

--- Comment #3 from John David Anglin  ---
export FLOCK=/home/dave/gnu/gcc/gcc/libgomp/testsuite/flock
in my build script works around configure issue.

[Bug analyzer/102671] -Wanalyzer-null-dereference false positive when compiling GNU Emacs

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

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

--- Comment #5 from Paul Eggert  ---
Created attachment 56997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56997&action=edit
xselect.i example from GNU Emacs

Attached is another example taken from bleeding-edge GNU Emacs, compiled with
gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0 on x86-64. Compile with:

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

and the incorrect output is:

xselect.i: In function ‘x_get_local_selection’:
xselect.i:81397:58: warning: dereference of NULL ‘dpyinfo’ [CWE-476]
[-Wanalyzer-null-dereference]
81397 | local_value = assq_no_quit (selection_symbol,
dpyinfo->terminal->Vselection_alist);
  |   ~~~^~
  ‘Fx_get_local_selection’: events 1-2
|
|83313 | __attribute__((section (".subrs"))) static union Aligned_Lisp_Subr
Sx_get_local_selection = {{{ PVEC_SUBR << PSEUDOVECTOR_AREA_BITS }, { .a2 =
Fx_get_local_selection }, 0, 2, "x-get-local-selection", {0}, 0}}; Lisp_Object
Fx_get_local_selection
|  |   
   
  
^~
|  |   
   
   |
|  |   
   
   (1)
entry to ‘Fx_get_local_selection’
|..
|83318 |   CHECK_SYMBOL (target);
|  |   ~
|  |   |
|  |   (2) calling ‘CHECK_SYMBOL’ from ‘Fx_get_local_selection’
|
+--> ‘CHECK_SYMBOL’: events 3-4
   |
   | 7282 | (CHECK_SYMBOL) (Lisp_Object x)
   |  |  ^~~~
   |  |  |
   |  |  (3) entry to ‘CHECK_SYMBOL’
   | 7283 | {
   | 7284 |   CHECK_TYPE (SYMBOLP (x), builtin_lisp_symbol (1360), x);
   |  |   ~
   |  |   |
   |  |   (4) inlined call to ‘CHECK_TYPE’ from ‘CHECK_SYMBOL’
   |
   +--> ‘CHECK_TYPE’: event 5
  |
  | 3127 |   ((ok) ? (void) 0 : wrong_type_argument (predicate,
x));
  |  |  
~^
  |  ||
  |  |(5) following ‘true’ branch...
  |
   <--+
   |
 ‘CHECK_SYMBOL’: event 6
   |
   | 7285 | }
   |  | ^
   |  | |
   |  | (6) ...to here
   |
<--+
|
  ‘Fx_get_local_selection’: events 7-8
|
|83318 |   CHECK_SYMBOL (target);
|  |   ^
|  |   |
|  |   (7) returning to ‘Fx_get_local_selection’ from ‘CHECK_SYMBOL’
|83319 |   Lisp_Object v = value; CHECK_CONS (v);
|  |  ~~
|  |  |
|  |  (8) calling ‘CHECK_CONS’ from
‘Fx_get_local_selection’
|
+--> ‘CHECK_CONS’: events 9-10
   |
   | 7468 | CHECK_CONS (Lisp_Object x)
   |  | ^~
   |  | |
   |  | (9) entry to ‘CHECK_CONS’
   | 7469 | {
   | 7470 |   CHECK_TYPE (CONSP (x), builtin_lisp_symbol (443), x);
   |  |   ~
   |  |   |
   |  |   (10) inlined call to ‘CHECK_TYPE’ from ‘CHECK_CONS’
   |
   +--> ‘CHECK_TYPE’: event 11
  |
  | 3127 |   ((ok) ? (void) 0 : wrong_type_argument (predicate,
x));
  |  |  
~^
  |  ||
  |  |(11) following ‘false’ branch...
  |
   <--+
   |
 ‘CHECK_CONS’: event 12
   |
   | 7471 | }
   |  | ^
   |  | |
   |  | (12) ...to here
   |
<--+
|
  ‘Fx_get_local_selection’: events 13-14
|
|83319 |   Lisp_Object v = value; CHECK_CONS (v);
|  |  ^~
|  |  |
|  |  (13) returning to
‘Fx_get_local_selection’ from ‘CHECK_CONS’
|83320 |   name = XCAR (v); v = XCDR (v); CHECK_CONS (v);
|  |  ~~
|  |  

[Bug analyzer/102671] -Wanalyzer-null-dereference false positive when compiling GNU Emacs

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

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

--- Comment #4 from Paul Eggert  ---
Created attachment 56996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56996&action=edit
marker.i example from GNU Emacs

Here is another example of the problem, taken from bleeding-edge GNU Emacs
compiled with gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0. Reproduce the bug via:

gcc -O2 -S -fanalyzer marker.i

The incorrect output (false positive) is:

marker.i: In function ‘BUF_ZV’:
marker.i:11203:6: warning: dereference of NULL ‘buf’ [CWE-476]
[-Wanalyzer-null-dereference]
11203 |: NILP (((buf)->zv_marker_)) ? buf->zv
  |  ^~
  ‘set_marker_restricted’: events 1-2
|
|17941 | set_marker_restricted (Lisp_Object marker, Lisp_Object position,
|  | ^
|  | |
|  | (1) entry to ‘set_marker_restricted’
|..
|17944 |   return set_marker_internal (marker, position, buffer,
|  |  ~~
|  |  |
|  |  (2) calling ‘set_marker_internal’ from
‘set_marker_restricted’
|17945 |1
|  |~
|17946 |);
|  |~
|
+--> ‘set_marker_internal’: events 3-4
   |
   |17882 | set_marker_internal (Lisp_Object marker, Lisp_Object
position,
   |  | ^~~
   |  | |
   |  | (3) entry to ‘set_marker_internal’
   |..
   |17888 |   struct buffer *b = live_buffer (buffer);
   |  |  ~
   |  |  |
   |  |  (4) inlined call to ‘live_buffer’ from
‘set_marker_internal’
   |
   +--> ‘live_buffer’: event 5
  |
  |17877 |   return BUFFER_LIVE_P (b) ? b :
  |  |  ~~^
  |  ||
  |  |(5) following ‘false’
branch...
  |17878 | ((void *)0)
  |  | ~~~
  |
   <--+
   |
 ‘set_marker_internal’: event 6
   |
   |cc1:
   | (6): ...to here
   |
 ‘set_marker_internal’: event 7
   |
   |17889 |   CHECK_MARKER (marker);
   |  |   ^
   |  |   |
   |  |   (7) calling ‘CHECK_MARKER’ from ‘set_marker_internal’
   |
   +--> ‘CHECK_MARKER’: event 8
  |
  |17584 | CHECK_MARKER (Lisp_Object x)
  |  | ^~~~
  |  | |
  |  | (8) entry to ‘CHECK_MARKER’
  |
  +--> ‘CHECK_MARKER’: event 9
 |
 |17586 |   CHECK_TYPE (MARKERP (x),
builtin_lisp_symbol (974), x);
 |  |   ^
 |  |   |
 |  |   (9) inlined call to ‘MARKERP’
from ‘CHECK_MARKER’
 |
 +--> ‘MARKERP’: event 10
|
| 8374 |   return PSEUDOVECTORP (x,
PVEC_MARKER);
|  |  ^
|  |  |
|  |  (10) inlined call to
‘PSEUDOVECTORP’ from ‘MARKERP’
|
+--> ‘PSEUDOVECTORP’: event 11
   |
   | 6413 |   return (TAGGEDP ((a),
Lisp_Vectorlike) && union vectorlike_header *) ((uintptr_t) XLP ((a)) -
(uintptr_t) ((Lisp_Word_tag) (Lisp_Vectorlike) << (((0x7fffL
   |  | 
^~~
   |  |
 |
   |  |
 (11) following ‘true’ branch...
   | 6414 | >> (3 - 1)) / 2 <
   |  | ~   
   | 6415 | (9223372036854775807L)
   |  | ~~  

[Bug sanitizer/113244] Potential thread sanitizer false positive with future exception

[gcc-bugzilla at mhxnet dot de via Gcc-bugs]

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

--- Comment #2 from Marcus Holland-Moritz  ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is because libstdc++.so is NOT instrumented for TSAN.

This is certainly possible.

Is there documentation available on how to build a suitably instrumented
libstdc++.so?

I've spent a few hours now trying to build

- all of gcc-13.2/gcc-12.3
- only libstdc++-v3 from gcc-13.2/gcc-12.3

with the following flags:

  CFLAGS="-fsanitize=thread -g -O2 -fno-omit-frame-pointer"
  CXXFLAGS="-fsanitize=thread -g -O2 -fno-omit-frame-pointer"
  LDFLAGS="-fsanitize=thread"

All of my attempts failed due to strange errors (which I can list here more
systematically if desired). A "plain" gcc build with no sanitizer-specific
compiler/linker flags works just fine.

Given that "libstdc++.so is NOT instrumented for TSAN" is a frequent response
to similar false positive reports, I'm somewhat surprised by the lack of easily
discoverable information on how to build an instrumented library. It also makes
me wonder how useful the thread sanitizer (maybe other sanitizers as well) is
at all without such an instrumented library. If an instrumented library is a
requirement for `-fsanitize=thread` to work properly, there should probably
exist a `configure` option to automatically build the required instrumented
library versions (and ideally the right version would be used when linking with
`-fsanitize=thread`).

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #16 from Arsen Arsenović  ---
(In reply to Jason Merrill from comment #14)
> It would certainly be possible to recognize this situation (all enumerators
> handled) and suppress the -Wreturn-type warning even though we can't in
> general assume that we can't get other values of the enumeration.  With the
> ability to explicitly request warnings in this situation with another flag. 
> I don't know how much work that would be.

can't we assume that following the aforementioned
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766 ?  at least
in C++>=17 (and, this bug should either be hijacked or remade for C++,
probably)

[Bug libstdc++/113241] [13/14 Regression] Unguarded use of __is_convertible built-in

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Fixed for 13.3

[Bug fortran/96724] Bogus warnings with the repeat intrinsic and the flag -Wconversion-extra

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Pushed as r14-6970-g723bd722d616bb.

For unknown reasons I do not see any mail generated for bugzilla,
so I am adding the info here:


Fortran: bogus warnings with REPEAT intrinsic and -Wconversion-extra [PR96724]

gcc/fortran/ChangeLog:

PR fortran/96724
* iresolve.cc (gfc_resolve_repeat): Force conversion to
gfc_charlen_int_kind before call to gfc_multiply.

gcc/testsuite/ChangeLog:

PR fortran/96724
* gfortran.dg/repeat_8.f90: New test.

Co-authored-by: José Rui Faustino de Sousa 


@José: thanks for the original patch, and sorry that it took so long
to take care of it.

Closing.

[Bug libstdc++/113241] [13/14 Regression] Unguarded use of __is_convertible built-in

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

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

--- Comment #2 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:4c66513656775d551db36b53c253cf236f0eeba8

commit r13-8194-g4c66513656775d551db36b53c253cf236f0eeba8
Author: Jonathan Wakely 
Date:   Fri Jan 5 12:03:22 2024 +

libstdc++: Do not use __is_convertible unconditionally [PR113241]

The new __is_convertible built-in should only be used after checking
that it's supported.

libstdc++-v3/ChangeLog:

PR libstdc++/113241
* include/std/type_traits (is_convertible_v): Guard use of
built-in with preprocessor check.

(cherry picked from commit 57fa5b60bbbf8038b8a699d2bcebd2a9b2e29aa4)

[Bug libstdc++/113200] std::char_traits::move is not constexpr when the argument is a string literal

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:22601c1c25652c71c8bab4707866c020d6dad79a

commit r13-8193-g22601c1c25652c71c8bab4707866c020d6dad79a
Author: Jonathan Wakely 
Date:   Wed Jan 3 15:01:09 2024 +

libstdc++: Fix std::char_traits::move [PR113200]

The current constexpr implementation of std::char_traits::move relies
on being able to compare the pointer parameters, which is not allowed
for unrelated pointers. We can use __builtin_constant_p to determine
whether it's safe to compare the pointers directly. If not, then we know
the ranges must be disjoint and so we can use char_traits::copy to
copy forwards from the first character to the last. If the pointers can
be compared directly, then we can simplify the condition for copying
backwards to just two pointer comparisons.

libstdc++-v3/ChangeLog:

PR libstdc++/113200
* include/bits/char_traits.h (__gnu_cxx::char_traits::move): Use
__builtin_constant_p to check for unrelated pointers that cannot
be compared during constant evaluation.
* testsuite/21_strings/char_traits/requirements/113200.cc: New
test.

(cherry picked from commit 15cc291887dc9dd92b2c93f4545e20eb6c190122)

[Bug c/113252] No -Wtype-limits on comparaisons against type max values

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 56995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56995&action=edit
(non-preprocessed) testcase

[Bug sanitizer/113251] [14 Regression] ICE on gcc.dg/asan/pr63845.c on i686-linux since r14-6946

[iii at linux dot ibm.com via Gcc-bugs]

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

Ilya Leoshkevich  changed:

   What|Removed |Added

 CC||iii at linux dot ibm.com

--- Comment #1 from Ilya Leoshkevich  ---
I can reproduce this manually and will work on a fix.

Surprisingly, this does not show in my test results. I.e.:

$ make check-gcc RUNTESTFLAGS="asan.exp=pr63845.c --debug"
=== gcc Summary ===

# of expected passes7

$ cat gcc/testsuite/gcc/gcc.sum

PASS: gcc.dg/asan/pr63845.c   -O0  (test for excess errors)
PASS: gcc.dg/asan/pr63845.c   -O1  (test for excess errors)
PASS: gcc.dg/asan/pr63845.c   -O2  (test for excess errors)
PASS: gcc.dg/asan/pr63845.c   -O3 -g  (test for excess errors)
PASS: gcc.dg/asan/pr63845.c   -Os  (test for excess errors)
PASS: gcc.dg/asan/pr63845.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
PASS: gcc.dg/asan/pr63845.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)

But!

$ cat gcc/testsuite/gcc/dbg.log

expect: does "fPIC170653.c:3:13: internal compiler error: Segmentation
fault\r\n" (spawn_id exp7) match regular expression ".+"? (No Gate, RE only)
gate=yes re=yes

compiler exited with status 1

So the problem manifests itself during the test run, but the runner fails to
recognize it for some reason.

[Bug c/113252] New: No -Wtype-limits on comparaisons against type max values

[mailhol.vincent at wanadoo dot fr via Gcc-bugs]

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

Bug ID: 113252
   Summary: No -Wtype-limits on comparaisons against type max
values
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mailhol.vincent at wanadoo dot fr
  Target Milestone: ---

Let ui be an unsigned int, then expression

  ui > UINT_MAX

is a tautology (always false).

However gcc's -Wtype-limits does not catch the above. However, it will emit a
warning for:

  ui > (unsigned long)UINT_MAX

Both expression get optimized out at compilation time, so it is surprising not
to get a warning for both.

This affects all GCC versions.

Follow this link for above example in actions:

  https://godbolt.org/z/MWaMao5Tr


Yours sincerely,
Vincent Mailhol

[Bug target/113140] [SPARC] [13 Regression] Segmentation fault during RTL pass: dbr

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
Investigating.

[Bug lto/113204] lto1: error: qsort comparator non-negative on sorted output: 64

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[14 Regression] lto1:   |lto1: error: qsort
   |error: qsort comparator |comparator non-negative on
   |non-negative on sorted  |sorted output: 64
   |output: 64  |
   Target Milestone|14.0|---

[Bug lto/113204] [14 Regression] lto1: error: qsort comparator non-negative on sorted output: 64

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

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

--- Comment #3 from Sam James  ---
13 is affected too at least, I'm pretty sure, but I can't check right now. Just
needs checking.

[Bug lto/113204] [14 Regression] lto1: error: qsort comparator non-negative on sorted output: 64

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
   See Also||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=912152
   Keywords||ice-checking

--- Comment #2 from Sam James  ---
I hit this a little while ago (https://bugs.gentoo.org/912152) but I gave up
after I couldn't get Go to preserve the files I needed.

[Bug target/105525] some targets don't define __INTPTR_TYPE__ breaking libgcov-driver.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
  Known to work||14.0

--- Comment #5 from Mikael Pettersson  ---
Fixed for gcc-14, no plans to backport.

[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-06
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
Yes, I think you're right about the typo

[Bug sanitizer/113251] [14 Regression] ICE on gcc.dg/asan/pr63845.c on i686-linux since r14-6946

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Priority|P3  |P1
 CC||iii at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

[Bug sanitizer/113251] New: [14 Regression] ICE on gcc.dg/asan/pr63845.c on i686-linux since r14-6946

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

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

Bug ID: 113251
   Summary: [14 Regression] ICE on gcc.dg/asan/pr63845.c on
i686-linux since r14-6946
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub 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, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Since r14-6946-ge66dc37b299cac4171b1c5b90cf6b54388bd5bc5
I'm seeing on i686-linux:
+FAIL: gcc.dg/asan/pr63845.c   -O0  (internal compiler error: Segmentation
fault)
+FAIL: gcc.dg/asan/pr63845.c   -O0  (test for excess errors)
+FAIL: gcc.dg/asan/pr63845.c   -O1  (internal compiler error: Segmentation
fault)
+FAIL: gcc.dg/asan/pr63845.c   -O1  (test for excess errors)
+FAIL: gcc.dg/asan/pr63845.c   -O2  (internal compiler error: Segmentation
fault)
+FAIL: gcc.dg/asan/pr63845.c   -O2  (test for excess errors)
+FAIL: gcc.dg/asan/pr63845.c   -O2 -flto  (internal compiler error:
Segmentation fault)
+FAIL: gcc.dg/asan/pr63845.c   -O2 -flto  (test for excess errors)
+FAIL: gcc.dg/asan/pr63845.c   -O2 -flto -flto-partition=none  (internal
compiler error: Segmentation fault)
+FAIL: gcc.dg/asan/pr63845.c   -O2 -flto -flto-partition=none  (test for excess
errors)
+FAIL: gcc.dg/asan/pr63845.c   -O3 -g  (internal compiler error: Segmentation
fault)
+FAIL: gcc.dg/asan/pr63845.c   -O3 -g  (test for excess errors)
+FAIL: gcc.dg/asan/pr63845.c   -Os  (internal compiler error: Segmentation
fault)
+FAIL: gcc.dg/asan/pr63845.c   -Os  (test for excess errors)
(reproduceable also with -fPIC -fsanitize=address -m32 on x86_64-linux).
The ICE is:
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/asan/pr63845.c:16:1: internal compiler
error: Segmentation fault
0x90680da crash_signal
../../gcc/toplev.cc:316
0x90813b8 asan_function_start()
../../gcc/asan.cc:1484
0x944b657 ix86_code_end
../../gcc/config/i386/i386.cc:6334
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.
compiler exited with status 1
The problem is when ix86_code_end does
6334  ASM_DECLARE_FUNCTION_NAME (asm_out_file, name, decl);
cfun is still NULL and so when asan_function_start is called,
current_function_funcdef_no access ICEs.
Either varasm.cc could avoid calling asan_function_start if cfun is NULL, or
e.g. ix86_code_end could work it around by temporarily clearing flag_sanitize
around this,
after all, there is no asan support in PIC landing pad.