[PATCH V2] [RFC]Support vectorization for Complex type.

[liuhongt via Gcc-patches]

V2 update:
   Handle VMAT_ELEMENTWISE, VMAT_CONTIGUOUS_PERMUTE, VMAT_STRIDED_SLP,
   VMAT_CONTIGUOUS_REVERSE, VMAT_CONTIGUOUS_DOWN for complex type.

I've run SPECspeed@2017 627.cam4_s, there's some vectorization cases,
but no big performance impact(since this patch only handle load/store).

Any comments?

gcc/ChangeLog:

PR tree-optimization/106010
* tree-vect-data-refs.cc (vect_get_data_access_cost):
Pass complex_p to vect_get_num_copies to avoid ICE.
(vect_analyze_data_refs): Support vectorization for Complex
type with vector scalar types.
(vect_permute_load_chain): Handle Complex type.
* tree-vect-loop.cc (vect_determine_vf_for_stmt_1): VF should
be half of TYPE_VECTOR_SUBPARTS when complex_p.
* tree-vect-slp.cc (vect_record_max_nunits): nunits should be
half of TYPE_VECTOR_SUBPARTS when complex_p.
(vect_optimize_slp): Support permutation for complex type.
(vect_slp_analyze_node_operations_1): Double nunits in
vect_get_num_vectors to get right SLP_TREE_NUMBER_OF_VEC_STMTS
when complex_p.
(vect_slp_analyze_node_operations): Ditto.
(vect_create_constant_vectors): Support CTOR for complex type.
(vect_transform_slp_perm_load): Support permutation for
complex type.
* tree-vect-stmts.cc (vect_init_vector): Support complex type.
(vect_get_vec_defs_for_operand): Get vector type for
complex type.
(vectorizable_store): Get right ncopies/nunits and
elem_type for complex type vector, also return false when
complex_p and !TYPE_VECTOR_SUBPARTS.is_constant ().
(vect_truncate_gather_scatter_offset): Return false for
complex type.
(vectorizable_load): Ditto.
(vect_get_vector_types_for_stmt): Get vector type for
complex type.
(get_group_load_store_type): Hanlde complex type for
nunits.
(perm_mask_for_reverse): New overload.
(get_negative_load_store_type): Handle complex type,
p_offset should be N - 2 beofre addres of DR.
(vect_check_scalar_mask): Return false for complex type.
* tree-vectorizer.h (STMT_VINFO_COMPLEX_P): New macro.
(vect_get_num_copies): New overload.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr106010-1a.c: New test.
* gcc.target/i386/pr106010-1b.c: New test.
* gcc.target/i386/pr106010-1c.c: New test.
* gcc.target/i386/pr106010-2a.c: New test.
* gcc.target/i386/pr106010-2b.c: New test.
* gcc.target/i386/pr106010-2c.c: New test.
* gcc.target/i386/pr106010-3a.c: New test.
* gcc.target/i386/pr106010-3b.c: New test.
* gcc.target/i386/pr106010-3c.c: New test.
* gcc.target/i386/pr106010-4a.c: New test.
* gcc.target/i386/pr106010-4b.c: New test.
* gcc.target/i386/pr106010-4c.c: New test.
* gcc.target/i386/pr106010-5a.c: New test.
* gcc.target/i386/pr106010-5b.c: New test.
* gcc.target/i386/pr106010-5c.c: New test.
* gcc.target/i386/pr106010-6a.c: New test.
* gcc.target/i386/pr106010-6b.c: New test.
* gcc.target/i386/pr106010-6c.c: New test.
* gcc.target/i386/pr106010-7a.c: New test.
* gcc.target/i386/pr106010-7b.c: New test.
* gcc.target/i386/pr106010-7c.c: New test.
* gcc.target/i386/pr106010-8a.c: New test.
* gcc.target/i386/pr106010-8b.c: New test.
* gcc.target/i386/pr106010-8c.c: New test.
* gcc.target/i386/pr106010-9a.c: New test.
* gcc.target/i386/pr106010-9b.c: New test.
* gcc.target/i386/pr106010-9c.c: New test.
* gcc.target/i386/pr106010-9d.c: New test.
---
 gcc/testsuite/gcc.target/i386/pr106010-1a.c |  58 +
 gcc/testsuite/gcc.target/i386/pr106010-1b.c |  63 ++
 gcc/testsuite/gcc.target/i386/pr106010-1c.c |  41 
 gcc/testsuite/gcc.target/i386/pr106010-2a.c |  82 +++
 gcc/testsuite/gcc.target/i386/pr106010-2b.c |  62 ++
 gcc/testsuite/gcc.target/i386/pr106010-2c.c |  47 
 gcc/testsuite/gcc.target/i386/pr106010-3a.c |  80 +++
 gcc/testsuite/gcc.target/i386/pr106010-3b.c | 126 +++
 gcc/testsuite/gcc.target/i386/pr106010-3c.c |  69 ++
 gcc/testsuite/gcc.target/i386/pr106010-4a.c | 101 +
 gcc/testsuite/gcc.target/i386/pr106010-4b.c |  67 ++
 gcc/testsuite/gcc.target/i386/pr106010-4c.c |  54 +
 gcc/testsuite/gcc.target/i386/pr106010-5a.c | 117 ++
 gcc/testsuite/gcc.target/i386/pr106010-5b.c |  80 +++
 gcc/testsuite/gcc.target/i386/pr106010-5c.c |  62 ++
 gcc/testsuite/gcc.target/i386/pr106010-6a.c | 115 ++
 gcc/testsuite/gcc.target/i386/pr106010-6b.c | 157 +
 gcc/testsuite/gcc.target/i386/pr106010-6c.c |  80 +++
 gcc/testsuite/gcc.target/i386/pr106010-7a.c |  58 +
 gcc/testsuite/gcc.target/i386/pr106010-7b.c |  63 ++
 gcc/testsuite/gcc.target/i386/pr106010-7c.c |  41 
 

[PATCH] Extend 16/32-bit vector bit_op patterns with (m, 0, i)(vertical) alternative.

[liuhongt via Gcc-patches]

And split it after reload.

>IMO, the only case it is worth adding is a direct immediate store to
>memory, which HJ recently added.

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?

gcc/ChangeLog:

PR target/106038
* config/i386/mmx.md (3): Extend to AND mem,imm,
and adjust below define_split.
(mmxinsnmode): New mode attribute.
(*mov_imm): Refactor with mmxinsnmode.
* config/i386/predicates.md
(register_or_x86_64_const_vector_operand): New predicate.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr106038-1.c: New test.
---
 gcc/config/i386/mmx.md | 58 +++---
 gcc/config/i386/predicates.md  |  4 ++
 gcc/testsuite/gcc.target/i386/pr106038-1.c | 27 ++
 3 files changed, 60 insertions(+), 29 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr106038-1.c

diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 3294c1e6274..fbcb34d4395 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -86,6 +86,14 @@ (define_mode_attr mmxvecsize
   [(V8QI "b") (V4QI "b") (V2QI "b")
(V4HI "w") (V2HI "w") (V2SI "d") (V1DI "q")])
 
+;; Mapping to same size integral mode.
+(define_mode_attr mmxinsnmode
+  [(V8QI "DI") (V4QI "SI") (V2QI "HI")
+   (V4HI "DI") (V2HI "SI")
+   (V2SI "DI")
+   (V4HF "DI") (V2HF "SI")
+   (V2SF "DI")])
+
 (define_mode_attr mmxdoublemode
   [(V8QI "V8HI") (V4HI "V4SI")])
 
@@ -350,22 +358,7 @@ (define_insn_and_split "*mov_imm"
   HOST_WIDE_INT val = ix86_convert_const_vector_to_integer (operands[1],
mode);
   operands[1] = GEN_INT (val);
-  machine_mode mode;
-  switch (GET_MODE_SIZE (mode))
-{
-case 2:
-  mode = HImode;
-  break;
-case 4:
-  mode = SImode;
-  break;
-case 8:
-  mode = DImode;
-  break;
-default:
-  gcc_unreachable ();
-}
-  operands[0] = lowpart_subreg (mode, operands[0], mode);
+  operands[0] = lowpart_subreg (mode, operands[0], mode);
 })
 
 ;; For TARGET_64BIT we always round up to 8 bytes.
@@ -2975,32 +2968,39 @@ (define_insn "*mmx_3"
(set_attr "mode" "DI,TI,TI,TI")])
 
 (define_insn "3"
-  [(set (match_operand:VI_16_32 0 "register_operand" "=?r,x,x,v")
+  [(set (match_operand:VI_16_32 0 "nonimmediate_operand" "=?r,m,x,x,v")
 (any_logic:VI_16_32
- (match_operand:VI_16_32 1 "register_operand" "%0,0,x,v")
- (match_operand:VI_16_32 2 "register_operand" "r,x,x,v")))
+ (match_operand:VI_16_32 1 "nonimmediate_operand" "%0,0,0,x,v")
+ (match_operand:VI_16_32 2 "register_or_x86_64_const_vector_operand" 
"r,i,x,x,v")))
(clobber (reg:CC FLAGS_REG))]
   ""
   "#"
-  [(set_attr "isa" "*,sse2_noavx,avx,avx512vl")
-   (set_attr "type" "alu,sselog,sselog,sselog")
-   (set_attr "mode" "SI,TI,TI,TI")])
+  [(set_attr "isa" "*,*,sse2_noavx,avx,avx512vl")
+   (set_attr "type" "alu,alu,sselog,sselog,sselog")
+   (set_attr "mode" "SI,SI,TI,TI,TI")])
 
 (define_split
-  [(set (match_operand:VI_16_32 0 "general_reg_operand")
+  [(set (match_operand:VI_16_32 0 "nonimmediate_gr_operand")
 (any_logic:VI_16_32
- (match_operand:VI_16_32 1 "general_reg_operand")
- (match_operand:VI_16_32 2 "general_reg_operand")))
+ (match_operand:VI_16_32 1 "nonimmediate_gr_operand")
+ (match_operand:VI_16_32 2 "register_or_x86_64_const_vector_operand")))
(clobber (reg:CC FLAGS_REG))]
   "reload_completed"
   [(parallel
  [(set (match_dup 0)
-  (any_logic:SI (match_dup 1) (match_dup 2)))
+  (any_logic: (match_dup 1) (match_dup 2)))
   (clobber (reg:CC FLAGS_REG))])]
 {
-  operands[2] = lowpart_subreg (SImode, operands[2], mode);
-  operands[1] = lowpart_subreg (SImode, operands[1], mode);
-  operands[0] = lowpart_subreg (SImode, operands[0], mode);
+  if (GET_CODE (operands[2]) == CONST_VECTOR)
+{
+  HOST_WIDE_INT val = ix86_convert_const_vector_to_integer (operands[2],
+   mode);
+  operands[2] = GEN_INT (val);
+}
+  else
+operands[2] = lowpart_subreg (mode, operands[2], mode);
+  operands[1] = lowpart_subreg (mode, operands[1], mode);
+  operands[0] = lowpart_subreg (mode, operands[0], mode);
 })
 
 (define_split
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index c71c453cceb..5f63a7d52f5 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -1205,6 +1205,10 @@ (define_predicate "x86_64_const_vector_operand"
   return trunc_int_for_mode (val, SImode) == val;
 })
 
+(define_predicate "register_or_x86_64_const_vector_operand"
+  (ior (match_operand 0 "register_operand")
+   (match_operand 0 "x86_64_const_vector_operand")))
+
 ;; Return true when OP is nonimmediate or standard SSE constant.
 (define_predicate "nonimmediate_or_sse_const_operand"
   (ior (match_operand 0 

[Bug fortran/106336] New: BLOCK construct and host association are not handled correctlyThis

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

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

Bug ID: 106336
   Summary: BLOCK construct and host association are not handled
correctlyThis
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

This program

   program foo
   x = 1
   print  *, x
   block
 x = x + 1
 print *, x
 data x/41/
   end block
   print *, x
   end program foo

should print

   1.
   42.000
   1.


F2018: C876  (R839) A variable whose designator appears as a data-stmt-object
   ... shall not be ... accessed by ... host association, in a named common
   block unless the DATA statement is in a block data program unit, in blank
   common, a function name, a function result name, an automatic data  object,
   or an allocatable variable.

The DATA statement causes explicit initialization at the start of
execution, and if I understand C876 it blocks host association.  That
is, the 'x' in the block construct has local scope.

Re: [AVX512 PATCH] Add UNSPEC_MASKOP to kupck instructions in sse.md.

[Hongtao Liu via Gcc-patches]

On Sat, Jul 16, 2022 at 10:08 PM Roger Sayle  wrote:
>
>
> This AVX512 specific patch to sse.md is split out from an earlier patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596199.html
>
> The new splitters proposed in that patch interfere with AVX512's
> kunpckdq instruction which is defined as identical RTL,
> DW:DI = (HI:SI<<32)|zero_extend(LO:SI).  To distinguish these,
> and avoid AVX512 mask registers accidentally being (ab)used by reload
> to perform SImode scalar shifts, this patch adds the explicit
> (unspec UNSPEC_MASKOP) to the unpack mask operations, which matches
> what sse.md does for the other mask specific (logic) operations.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32}
> with no new failures.  Ok for mainline?
Ok, thanks for handling this.
>
> 2022-07-16  Roger Sayle  
>
> gcc/ChangeLog
> * config/i386/sse.md (kunpckhi): Add UNSPEC_MASKOP unspec.
> (kunpcksi): Likewise, add UNSPEC_MASKOP unspec.
> (kunpckdi): Likewise, add UNSPEC_MASKOP unspec.
> (vec_pack_trunc_qi): Update to specify required UNSPEC_MASKOP
> unspec.
> (vec_pack_trunc_): Likewise.
>
>
> Thanks in advance,
> Roger
> --
>


-- 
BR,
Hongtao

Re: rust non-free-compatible trademark

[Richard Kenner via Gcc]

> Normal use of a word isn't something that Trademarks prevent.

In general, no, but what it prevents is using the word in a way that
would produce confusion with an "official" use of that mark.  If the
word that constitutes the mark is too general, then the trademark
shouldn't have been granted.  But let's assume that somebody has
trademarked a common adjective, which we'll call "adjective", when
applied to noun "noun".

If I write "I have an adjective noun", that's supposed to refer to the
trademarked it.  If it instead refers to some other item (e.g., in our
case a compiler with patches), that's a trademark violatio.

Re: rust non-free-compatible trademark

[lkcl via Gcc]

sorry, Mark, you're still misunderstanding, on multiple levels
and in so many ways i am having a hard time tracking them
all.

i don't feel that i've been heard, and consequently do not
feel comfortable continuing the conversation, especially
given that i have other priorities.

if you had asked questions "so let me make sure that
i understand you correctly" i would feel much more
comfortable to continue the conversation.

i have raised the topic: it is your responsibility and duty to
consider.

l.

Re: rust non-free-compatible trademark

[Mark Wielaard]

Hi Luke,

On Sun, Jul 17, 2022 at 07:29:22PM +0100, lkcl wrote:
> whilst you *as developers* have been in contact with the Rust Foundation
> and presumably have private assurances that your use of the Trademarked
> word "rust" is Authorised under License (through either implication or by
> actual explicit approval) absolutely nobody else does.

As far as I know all discussions have been in public. The Rust
Foundation is aware of the gccrs frontend and other "unofficial"
implementations.

Using the word "rust" in the implementation of the gccrs frontend
doesn't need any "Authorization under License". Normal use of a word
isn't something that Trademarks prevent.

> i appreciate that this is a bloody nuisance.  i do however expect the
> Rust Foundation to get their act together and act Reasonably and
> Fairly to sort out the mess they've accidentally created.

I believe the Rust Foundation is reasonable. We aren't using the word
mark "Rust" in a way that needs any trademark license. And even if we
did the Rust Foundation allows all usage of the word mark as long as
you don't deliberately try to confuse about (commercially) shipping a
product called "Rust" that is officially endorsed by the Rust
Foundation.

If the Rust Foundation really believed that some of the marketing we
do around the gccrs frontend is confusing they would contact us and if
they are reasonable we can adjust the messaging (we can be reasonable
too).

The best advice I can give you is to listen to what the Rust
Foundation itself says about their trademark:

  Please do not approach users of the trademarks with a
  complaint. That should be left to the Rust Foundation and its
  representatives. Thanks!

  If you have a specific question or concern about promoting Rust or
  using its trademarks, please contact the Rust Foundation:
  cont...@rustfoundation.org.

Cheers,

Mark

gcc-13-20220717 is now available

[GCC Administrator via Gcc]

Snapshot gcc-13-20220717 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/13-20220717/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 7bcd7f47359b903bf7a193b95d4450d9d69c60ba

You'll find:

 gcc-13-20220717.tar.xz   Complete GCC

  SHA256=685bc20e4af2a1667ac1579a3bf36d9f48b395e998303879cee790b79d344fd4
  SHA1=a5ad926398b7d5d2c795fecd98a52cabb6eb4c83

Diffs from 13-20220710 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #4 from Zhendong Su  ---
Here is another repro that ICEs at -O2 (without -fno-inline-small-functions).

[570] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220717 (experimental) [master r13-1722-g7bcd7f47359] (GCC)
[571] %
[571] % gcctk -O2 small.c
small.c: In function ‘n’:
small.c:18:1: error: unrecognizable insn:
   18 | }
  | ^
(insn 41 25 32 8 (set (reg:TI 85 [ D.2008 ])
(reg:V1TI 90 [ D.2008 ])) "small.c":16:12 -1
 (expr_list:REG_DEAD (reg:V1TI 90 [ D.2008 ])
(expr_list:REG_EQUAL (mem/c:TI (symbol_ref:DI ("k") [flags 0x2]
) [2 k+0 S16 A128])  
(nil
during RTL pass: subreg3
small.c:18:1: internal compiler error: in extract_insn, at recog.cc:2791
0x722ccc _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-trunk/gcc/rtl-error.cc:108
0x722ce8 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-trunk/gcc/rtl-error.cc:116
0x72121b extract_insn(rtx_insn*)
../../gcc-trunk/gcc/recog.cc:2791
0x1d4e697 decompose_multiword_subregs
../../gcc-trunk/gcc/lower-subreg.cc:1555
0x1d4f51d execute
../../gcc-trunk/gcc/lower-subreg.cc:1820
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[572] %
[572] % cat small.c
struct a {
  int b;
  int c;
  int d;
  int e;
} i, j, k, l;
int f, g, h;
static struct a n() {
  if (f)
while (1)
  i = k;
  j = k;
  for (; g; g++)
;
  if (h)
return k;
  return j;
}
void o() { l = n(); }
int main() {
  o();
  return 0;
}

Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

[Stephan Bergmann via Gcc-patches]

On 7/15/22 22:25, Marek Polacek via Gcc-patches wrote:

Yeah, I guess so.  But I've already pushed the patch.


This commit obviously breaks using libstdc++ with Clang (in -std=c++2b 
mode), which doesn't implement those new builtins.  Something like the 
below would fix that,



diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index b1a1deecf66..a6e028b42ec 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -3505,6 +3505,7 @@ template
   template
 inline constexpr bool is_scoped_enum_v = is_scoped_enum<_Tp>::value;
 
+#if __has_builtin(__reference_constructs_from_temporary) && __has_builtin(__reference_converts_from_temporary)

 #define __cpp_lib_reference_from_temporary 202202L
 
   /// True if _Tp is a reference type, a _Up value can be bound to _Tp in

@@ -3544,6 +3545,7 @@ template
   template
 inline constexpr bool reference_converts_from_temporary_v
   = reference_converts_from_temporary<_Tp, _Up>::value;
+#endif
 #endif // C++23
 
 #if _GLIBCXX_HAVE_IS_CONSTANT_EVALUATED

diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 5edca2f3007..7c4b7f7cc6d 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -304,7 +304,9 @@
 #define __cpp_lib_byteswap 202110L
 #define __cpp_lib_constexpr_typeinfo 202106L
 #define __cpp_lib_is_scoped_enum 202011L
+#if __has_builtin(__reference_constructs_from_temporary) && 
__has_builtin(__reference_converts_from_temporary)
 #define __cpp_lib_reference_from_temporary 202202L
+#endif
 
 #if _GLIBCXX_HOSTED

 #define __cpp_lib_adaptor_iterator_pair_constructor 202106L

[Bug c/47409] volatile struct member bug

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

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

[Bug c/106335] struct copies with volatile fields are done using memcpy

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 47409.

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

[Bug c/106335] New: struct copies with volatile fields are done using memcpy

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

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

Bug ID: 106335
   Summary: struct copies with volatile fields are done using
memcpy
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

struct s { volatile int x[42]; } a;
void f(struct s b) { a = b; }

results in machine code calling memcpy(), which is not valid.

☺ Buildbot (GNU Toolchain): gccrust - build successful (master)

[builder--- via Gcc-rust]

A restored build has been detected on builder gccrust-rawhide-x86_64 while 
building gccrust.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/132/builds/39

Build state: build successful
Revision: 9c7a580aa13707a18c53bc772c3d9301dd9bfb2c
Worker: bb2
Build Reason: (unknown)
Blamelist: Philip Herron , bors[bot] 
<26634292+bors[bot]@users.noreply.github.com>

Steps:

- 0: worker_preparation ( success )

- 1: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/1/logs/stdio

- 2: rm -rf gccrs-build ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/2/logs/stdio

- 3: configure ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/3/logs/stdio

- 4: make ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/4/logs/stdio
- warnings (28): 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/4/logs/warnings__28_

- 5: make check ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/5/logs/stdio
- rust.sum: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/5/logs/rust_sum
- rust.log: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/5/logs/rust_log
- warnings (7): 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/5/logs/warnings__7_

- 6: grep unexpected rust.sum ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/6/logs/stdio

- 7: prep ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/7/logs/stdio

- 8: build bunsen.cpio ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/8/logs/stdio

- 9: fetch bunsen.cpio ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/9/logs/stdio

- 10: unpack bunsen.cpio ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/10/logs/stdio

- 11: pass .bunsen.source.gitname ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/11/logs/stdio

- 12: pass .bunsen.source.gitbranch ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/12/logs/stdio

- 13: pass .bunsen.source.gitrepo ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/13/logs/stdio

- 14: upload to bunsen ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/14/logs/stdio

- 15: clean up ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/132/builds/39/steps/15/logs/stdio

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[Bug middle-end/106323] [Suboptimal] memcmp(s1, s2, n) == 0 expansion on AArch64 compare to llvm

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||104611

--- Comment #2 from Andrew Pinski  ---
Note this could be even better as using cmp/ccmp on aarch64 than using eor/or
really.
See bug 104611 comment #1 for that.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611
[Bug 104611] memcmp/strcmp/strncmp can be optimized when the result is tested
for [in]equality with 0 on aarch64

[Bug fortran/103590] ICE: find_array_spec(): Missing spec

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Error recovery issue.  Can be mitigated by e.g.:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ebf076f730..be024d50c2e 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -4976,7 +4976,7 @@ gfc_resolve_dim_arg (gfc_expr *dim)
 static void
 resolve_assoc_var (gfc_symbol* sym, bool resolve_target);

-static void
+static bool
 find_array_spec (gfc_expr *e)
 {
   gfc_array_spec *as;
@@ -5004,7 +5004,11 @@ find_array_spec (gfc_expr *e)
   {
   case REF_ARRAY:
if (as == NULL)
- gfc_internal_error ("find_array_spec(): Missing spec");
+ {
+   gfc_error ("Symbol %qs at %L has not been declared as an array",
+  e->symtree->n.sym->name, >where);
+   return false;
+ }

ref->u.ar.as = as;
as = NULL;
@@ -5028,6 +5032,8 @@ find_array_spec (gfc_expr *e)

   if (as != NULL)
 gfc_internal_error ("find_array_spec(): unused as(2)");
+
+  return true;
 }


@@ -5346,7 +5352,8 @@ gfc_resolve_ref (gfc_expr *expr)
   for (ref = expr->ref; ref; ref = ref->next)
 if (ref->type == REF_ARRAY && ref->u.ar.as == NULL)
   {
-   find_array_spec (expr);
+   if (!find_array_spec (expr))
+ return false;
break;
   }

[Bug middle-end/106323] [Suboptimal] memcmp(s1, s2, n) == 0 expansion on AArch64 compare to llvm

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

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

--- Comment #1 from Andrew Pinski  ---
GCC might be better if the first bytes are in cache but the next bytes are not
and then branch is predictable (which it might be).

So this is much more complex than just changing this really.

[Bug target/106322] i386: Wrong code at O2 level (O0 / O1 are working)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||i386-linux-gnu
  Component|c++ |target

--- Comment #8 from Andrew Pinski  ---
Does -fwrapv fix the issue?

Re: Inquiry: Country of Origin for gfortran

[Richard Kenner via Gcc]

> If these bureaucratic parasites (but I repeat myself) don't want to
> use GCC, or Clang, then they can write their own compiler suite from
> scratch. Doubt that's going to happen, so this "investigation" is
> simply yet another frivilous waste of taxpayer dollars.

I won't blame this on bureaucrats.  Congress is who passed the law (in
1933).  These folks are just checking the boxes.

[Bug lto/106328] Build doesn't respect -j N flag

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm:
https://gcc.gnu.org/onlinedocs/gcc-10.4.0/gcc/Optimize-Options.html#index-flto

Maybe the automation detection of job server is not working on freebsd
correctly.

[Bug fortran/106331] [12/13 Regression] Whole array assignment of empty string segfaults with -Og

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|Whole array assignment of   |[12/13 Regression] Whole
   |empty string segfaults with |array assignment of empty
   |-Og |string segfaults with -Og
   Last reconfirmed||2022-07-17
 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |12.2
  Known to work||11.3.1
  Known to fail||12.1.1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed on x86_64-pc-linux-gnu with -m64 for character length 17 to 31.
For -m32 the issue does not show up, at least for the character length values
I tried.

Note however that replacing the array assignment

  a = ''

by an explicit loop

  do i = 1,2
 a(i) = ''
  end do

does not change the behavior of the reproducer.

valgrind a.out says:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x5b0fd6f in ???
#1  0x4005e7 in ???
#2  0x40061f in ???
#3  0x5afa2bc in ???
#4  0x400519 in ???
#5  0x in ???
==14463== 
==14463== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==14463==at 0x5B0FCB9: raise (in /lib64/libc-2.31.so)
==14463==by 0x5B0FD6F: ??? (in /lib64/libc-2.31.so)
==14463==by 0x4005E6: MAIN__ (in /home/anlauf/gcc-bugs/a.out)
==14463==by 0x40061F: main (in /home/anlauf/gcc-bugs/a.out)

I have no idea what is going on here...

Re: Inquiry: Country of Origin for gfortran

[Dave Blanchard]

On Sun, 17 Jul 2022 14:18:40 EDT
Richard Kenner via Gcc  wrote:

> > Should this question be posed to the Linux distribution that NASA is using?
> 
> Yes, most likely.  But exactly how Free Software fits into the
> Buy America Act (what she's talking about) is less than clear.

If these bureaucratic parasites (but I repeat myself) don't want to use GCC, or 
Clang, then they can write their own compiler suite from scratch. Doubt that's 
going to happen, so this "investigation" is simply yet another frivilous waste 
of taxpayer dollars.

-- 
Dave Blanchard 

Re: rust non-free-compatible trademark

[Alexandre Oliva via Gcc]

On Jul 17, 2022, Richard Biener via Gcc  wrote:

> We’ll call it gust.

How about "giust"?  (GNU Implementation of...)

so that it sounds like https://just-lang.org/

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: rust non-free-compatible trademark

[Alexandre Oliva via Gcc]

On Jul 17, 2022, Mark Wielaard  wrote:

> None of that required a trademark license because the usage of the
> word java was just for compatibility with the java programming
> language.

"just for compatibility" is an defense that applies to copyrights, but
AFAIK it doesn't apply to trademarks.

indeed, one can probably still find records suggesting that gcj got its
name, "GNU Compiler for Java", that way rather than the more natural
phrasing "Java Compiler", because the Java trademark was liberally
licensed for use in the form "for Java", whereas other uses were not.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||ice-on-valid-code

Re: rust non-free-compatible trademark

[lkcl via Gcc]

ah. right. sorry Mark i missed something.

whilst you *as developers* have been in contact with the Rust Foundation
and presumably have private assurances that your use of the Trademarked
word "rust" is Authorised under License (through either implication or by
actual explicit approval) absolutely nobody else does.

all *new* gcc developers for example who have *not* been party to
those private conversations may not safely assume that they are part
of any such explicit or implicit consent.

and given that literally anyone in the world may pick up the gcc source
code and consider themselves to become a developer (as permitted
by the GPL) that's a serious concern.

in addition to that, even if you as developers have indeed been
explicitly or implicitly granted a Trademark License that does *not*
extend to *Distributors* of gcc and i again refer you to the wording that i
copied here, and to the debian bugreport.

i appreciate that this is a bloody nuisance.  i do however expect the
Rust Foundation to get their act together and act Reasonably and
Fairly to sort out the mess they've accidentally created.

after all, Trademarks do have value in FOSS Projects, to protect
them from harm in ways that Copyright Licenses cannot touch.
it's just rather unfortunate that they're really not well-understood,
not even by Lawyers!

l.

Re: rust non-free-compatible trademark

[Richard Kenner via Gcc]

> I think you are misinterpreting when you need a trademark license for
> usage a word mark in an implementation of a compiler for a programming
> language. Note that gcc used to come with a full implementation of the
> Java programming language, compiler, runtime and core library
> implementation (for which I was the GNU maintainer). None of that
> required a trademark license because the usage of the word java was
> just for compatibility with the java programming language. 

Was "Java" a trademark for both the language and compiler or just the
language?  What about "rust"?  That would seem to make a difference.

If the trademark is just for the language, then when you say you have
a "compiler for the XYZ language", you're refering to the trademarked
entity (the language) and you can always use a trademark to refer to
the trademark owner's product.

But if the trademark is also for the compiler and you have a different
compiler (even if it differs just by patches), you need the permission
of the trademark owner to call you compiler by the trademarked name.

[Bug c/106333] Required condition omitted from generated code

[eran.kornblau at kaltura dot com via Gcc-bugs]

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

--- Comment #6 from Eran Kornblau  ---
Indeed!
/tmp/x.c:18:44: runtime error: signed integer overflow: 9223372036854775807 -
-1 cannot be represented in type 'long long int'

Thanks!

Eran

Re: rust non-free-compatible trademark

[Richard Kenner via Gcc]

> just as with the Java Trademark, you as developers can say "gust is
> compatible with the rust language" but you *cannot* say "gust is
> compatible with rust".

Note that trademarks are adjectives, not nouns (and only apply to specific
nouns, so I'm not sure what you mean here.

Re: Inquiry: Country of Origin for gfortran

[Richard Kenner via Gcc]

> Should this question be posed to the Linux distribution that NASA is using?

Yes, most likely.  But exactly how Free Software fits into the
Buy America Act (what she's talking about) is less than clear.

[Bug c/106333] Required condition omitted from generated code

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

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

--- Comment #5 from Andrew Pinski  ---
There was -Wstrict-overflow but many of those warnings are gone in recent
versions of the compiler and it was way too noisy. -fsanitize=undefined should
be able to detect the problem at runtime instead.

Re: rust non-free-compatible trademark

[lkcl via Gcc]

On Sun, Jul 17, 2022 at 6:41 PM Mark Wielaard  wrote:

> I think you are misinterpreting when you need a trademark license for
> usage a word mark in an implementation of a compiler for a programming
> language.

i'm aware of the difference.  i mentioned this in my first reply to Richard
(and covered it briefly in my reply to you as well)

> Note that gcc used to come with a full implementation of the
> Java programming language, compiler, runtime and core library
> implementation (for which I was the GNU maintainer). None of that
> required a trademark license because the usage of the word java was
> just for compatibility with the java programming language.

yes. i mentioned that example in my reply to you and in my separate
reply to Richard: you may have missed it.

that would likely be down to the difference in the Java Trademark License
and the Rust Trademark License.

with the wording the Rust Trademark License has attempted to create a poor-man's
Certification Mark.

Certification Mark Law is an advanced variant of Trademark Law covering
Standards Compliance.

> And since
> there was no claim of being or distributing Java(tm). The same is true
> for Rust(tm) and the gccrs frontend.

this would be perfectly fine if the Rust Foundation had not explicitly
worded the Trademark License in terms of a poor-man's Certification
Mark.

i gave the relevant section that you can pass over to appropriate Legal
Counsel.

i leave it with you as i am just a "reasonably well-informed
non-lawyer messenger"
here.

> Also note that the Rust Foundation is aware of the work and has
> already integraeted parts of gcc through another alternative
> implementation (based on libgccjit). As far as we know thy have no
> problem with either alternative implementation of the Rust programming
> language.

then that needs to be put into writing and made public.  only the Trademark
Holder may do that - not you. otherwise if you claim something and it turns
out not to be true, you can be sued for misrepresentation.

did i say Trademarks are a pig already?

l.

Re: rust non-free-compatible trademark

[Mark Wielaard]

Hi Luke,

On Sun, Jul 17, 2022 at 06:06:45PM +0100, lkcl via Gcc wrote:
> given that gcc is *entirely implementing* the rust programming
> language (from scratch) and given that that implementation is not in
> fact implemented by the Rust Foundation (the Trademark Holders
> themselves) but by the gcc developers, then by definition *every*
> single line of source code constitutes "a patch", and according to
> the Trademark License they (the Rust Foundation) require that you
> seek explicit approval for its distribution.

I think you are misinterpreting when you need a trademark license for
usage a word mark in an implementation of a compiler for a programming
language. Note that gcc used to come with a full implementation of the
Java programming language, compiler, runtime and core library
implementation (for which I was the GNU maintainer). None of that
required a trademark license because the usage of the word java was
just for compatibility with the java programming language. And since
there was no claim of being or distributing Java(tm). The same is true
for Rust(tm) and the gccrs frontend.

Also note that the Rust Foundation is aware of the work and has
already integraeted parts of gcc through another alternative
implementation (based on libgccjit). As far as we know thy have no
problem with either alternative implementation of the Rust programming
language.

Cheers,

Mark

[Bug lto/106334] New: [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072

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

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

Bug ID: 106334
   Summary: [13 Regression] lto -g ICE in
dwarf2out_register_external_die at dwarf2out.cc:6072
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Noticed ICE on nix-2.10.3 project. It started using LTO recently.

I extracted something that looks like a reproducer, needs 3 files:

// $ cat eval.hh
void listElems();

namespace nix {
struct Value {

  auto listItems() {
struct ListIterable {
  typedef int* iterator;
  iterator begin() __attribute__((noipa)) { return 0; }
  iterator end() __attribute__((noipa)) { return 0; }
};
listElems();
return ListIterable{};
  }
};
}

// $ cat eval-cache.cc
#include "eval.hh"

void getListOfStrings(nix::Value & v) {
  for (auto elem : v.listItems())
;
}

// $ cat eval.cc
#include "eval.hh"

struct iterator {
  bool operator!=(iterator);
  void operator++();
  int operator*() { return 0; }
};
template  auto enumerate(T) {
  struct iterable_wrapper {
auto begin() { return iterator{}; }
auto end() { return iterator{}; }
  };
  return iterable_wrapper{};
}
void EvalStatecoerceToString(nix::Value & v) {
  for (auto v : enumerate(v.listItems()))
;
}

Triggering the crash:

$ g++ -Werror=return-type -O1 -flto -fPIC -g -I. -o eval-cache.o -c
eval-cache.cc
$ g++ -Werror=return-type -O1 -flto -fPIC -g -I. -o eval.o -c eval.cc
$ g++ -Werror=return-type -O1 -flto -fPIC -g -I. -o libnixexpr.so -shared
eval-cache.o eval.o
lto1: internal compiler error: in dwarf2out_register_external_die, at
dwarf2out.cc:6072
0xa059db dwarf2out_register_external_die
../../gcc-13-20220710/gcc/dwarf2out.cc:6072
0x903d0d lto_read_decls
../../gcc-13-20220710/gcc/lto/lto-common.cc:1952
0x904a7a lto_file_finalize
../../gcc-13-20220710/gcc/lto/lto-common.cc:2271
0x904a7a lto_create_files_from_ids
../../gcc-13-20220710/gcc/lto/lto-common.cc:2281
0x904a7a lto_file_read
../../gcc-13-20220710/gcc/lto/lto-common.cc:2336
0x904a7a read_cgraph_and_symbols(unsigned int, char const**)
../../gcc-13-20220710/gcc/lto/lto-common.cc:2784
0x8eca42 lto_main()
../../gcc-13-20220710/gcc/lto/lto.cc:626

Using '-g0' makes the file compile.

Compiler is this week's gcc-13 snapshot:

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

[Bug c/106333] Required condition omitted from generated code

[eran.kornblau at kaltura dot com via Gcc-bugs]

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

--- Comment #4 from Eran Kornblau  ---
Ok, thank you both.

One last point - maybe it makes sense to at least output a warning in this
case?
I added '-Wall -pedantic -Wextra' to the command, and didn't get any warning
about this.

The end result here was that some condition that I wrote didn't make it to the
binary, would have been good to know about it, before it happened to us on
production... something like the 'condition is always true/false' warnings.

Thanks,

Eran

[Bug c/106333] Required condition omitted from generated code

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Eran Kornblau from comment #2)
> Thanks Andreas, I understand there's an overflow here, but isn't it a bug
> that it affects the second part of the condition?


No.


> I mean, any value is legit for the first part of the condition, if the
> behavior is undefined... but the second part of the condition is well
> defined. 


That's not how undefined behaviour works. If the program has undefined
behaviour, the entire program has undefined behaviour. The unexpected outcome
is not limited to a single expression.

> I personally find it a bit troubling that -
> 1. The result of the condition depends on the order of the operands (while
> they don't have any side-effects...), and -

They don't have side effects, but evaluating one condition might have undefined
behaviour, so it's up to you to avoid that.


> 2. The optimizations change the behavior of the code in this case

No, the behaviour is always undefined. Optimization changes the observed
outcomes of that undefined behaviour, but that's allowed. Undefined behaviour
means anything can happen.

"This undefined behaviour surprises me" is not a bug.

Re: rust non-free-compatible trademark

[lkcl via Gcc]

On Sun, Jul 17, 2022 at 5:31 PM Mark Wielaard  wrote:
>
> Hi Luke,
>
> On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote:
> > with the recent announcement that rust is supported by gcc
>
> There is just a discussion about whether and how to integrate
> (portions) of the gccrs frontend into the main gcc repository. Nobody
> claims that means the rust programming language is supported by gcc
> yet. There is a lot of work to be done to be able to claim that.

as i just replied to Richard, my understanding is that your careful usage
of wording there is Lawful ("the rust programming language is supported by gcc"
rather than "*rust* is supported by gcc").

> > has it been taken into consideration that the draconian 
> > (non-free-compatible)
> > requirements of the rust Trademark make the distribution of the gcc
> > compiler Unlawful?
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920
>
> That looks to me as an overreaching interpretation of how to interpret
> a trademark.

Trademarks are a bitch.   if no explicit License is given, then "default"
Trademark Law applies, where you must seek permission for all and
any distribution.  if the License *does* exist and does not explicitly
grant a Permission, then, exactly like Copyright Law, you must explicitly
seek it.

you have to be *really* careful here, particularly given that the Mozilla
Foundation is attempting a poor-man's "Certification Mark".

they have defined the Trademark as requiring "language compatibility".
which is perfectly reasonable given that they don't want end-users to
be complaining "i can't compile my program" or worse, "my program
broke, rust is supposed to be secure, whom do i sue".

Uses that require explicit approval #

Distributing a modified version of the Rust programming language
[or the Cargo package manager] with modifications other than those
permitted above and calling it Rust or Cargo requires explicit,
written permission from the Rust Foundation.

given that gcc is *entirely implementing* the rust programming language
(from scratch) and given that that implementation is not in fact implemented
by the Rust Foundation (the Trademark Holders themselves) but by the
gcc developers, then by definition *every* single line of source code
constitutes
"a patch", and according to the Trademark License they (the Rust Foundation)
require that you seek explicit approval for its distribution.

(i.e. the *entire* gccrs source code is "a modified version of the rust
 programming language")

distribution in this particular case would be:

* all tarballs under the gcc.org domain name
* all git repositories under the same
* all git repositories created by all gcc developers

so, yes, you've enacted distribution, and enabled and empowered
others to engage in distribution - sorry to have to inform you of this
(i trust you won't engage in "Shooting-Messenger-Syndrome") but,
how can i put this... if you check with a good - and i do mean good -
Trademark Lawyer, you'll likely be advised that you're legally liable,
here.  checking that is of course your responsibility, not mine.

> If you are afraid your usage of gcc with the gccrs frontend integrated
> does cause confusion around the Rust word mark then I would suggest
> contacting the Rust Foundation to discuss how you can remove such
> confusion.

that would not be my responsibility, but yours [i'm assuming you're
a gcc developer?]

only if *i* were to engage in *distribution* of gcc with gccrs frontend
integration would *i* become concerned, and i appreciate the reminder/prompting
from you that, at some point in the near future, this will actually occur.
sigh.

to that end i would strongly recommend and advocate that the
gccrs frontend be a dynamic-loadable plugin into gcc, so that it
can be optionally excluded.

or, as Richard suggested, begin calling it "gust".  gccgust frontend.
(but don't for goodness sake put anywhere "we ARE renaming
all uses of rust to gust in gcc".)

l.

Re: rust non-free-compatible trademark

[lkcl via Gcc]

On Sun, Jul 17, 2022 at 5:25 PM Richard Biener
 wrote:

> > if the word "rust" is entirely removed from the gcc source code then
> > there is no problem whatsoever (recall: "iceweasel").
>
> We’ll call it gust.

love it! the puns i would have recommended would have been based
on "iron oxide".

please bear in mind: under Trademark Law, as developers, you *must* not make
"announcements" saying "we *are* changing the name from rust to gust".
this creates "Confusion" for which you become directly and legally liable
and responsible.

*users* are permitted to go, "oh look, errr there's this thing called gust
and the source code compiles for rust".

just as with the Java Trademark, you as developers can say "gust is
compatible with
the rust language" but you *cannot* say "gust is compatible with rust".

Trademarks are a bitch.  get legal advice.

l.

Re: rust non-free-compatible trademark

[Mark Wielaard]

Hi Luke,

On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote:
> with the recent announcement that rust is supported by gcc

There is just a discussion about whether and how to integrate
(portions) of the gccrs frontend into the main gcc repository. Nobody
claims that means the rust programming language is supported by gcc
yet. There is a lot of work to be done to be able to claim that.

> has it been taken into consideration that the draconian (non-free-compatible)
> requirements of the rust Trademark make the distribution of the gcc
> compiler Unlawful?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920

That looks to me as an overreaching interpretation of how to interpret
a trademark. I notice you are the bug reporter. It would only apply if
a product based on gcc with the gccrs frontend integrated would claim
to be endorsed by the Rust Foundation by using the Rust wordmark. Just
using the word rust doesn't trigger confusion about that. And
trademarks don't apply when using common words to implement an
interface or command line tool for compatibility with a programming
language.

If you are afraid your usage of gcc with the gccrs frontend integrated
does cause confusion around the Rust word mark then I would suggest
contacting the Rust Foundation to discuss how you can remove such
confusion. Probably adding a README explicitly saying "this product
isn't endorsed by and doesn't claim to be endoresed by the Rust
Foundation" will be enough.

Good luck,

Mark

Re: rust non-free-compatible trademark

[Richard Biener via Gcc]

> Am 17.07.2022 um 17:29 schrieb lkcl via Gcc :
> 
> with the recent announcement that rust is supported by gcc
> has it been taken into consideration that the draconian (non-free-compatible)
> requirements of the rust Trademark make the distribution of the gcc
> compiler Unlawful?
> 
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920
> 
> if the word "rust" is entirely removed from the gcc source code then
> there is no problem whatsoever (recall: "iceweasel").

We’ll call it gust.

Richard 
> 
> l.

[Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Johel Ernesto Guerrero Peña  ---
> The workaround of Comment 5 stopped working for my actual use-case some time 
> ago.

The `using` declaration works if I move it earlier in the TU.

[Bug c/106333] Required condition omitted from generated code

[eran.kornblau at kaltura dot com via Gcc-bugs]

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

--- Comment #2 from Eran Kornblau  ---
Thanks Andreas, I understand there's an overflow here, but isn't it a bug that
it affects the second part of the condition?
I mean, any value is legit for the first part of the condition, if the behavior
is undefined... but the second part of the condition is well defined. 

I personally find it a bit troubling that -
1. The result of the condition depends on the order of the operands (while they
don't have any side-effects...), and -
2. The optimizations change the behavior of the code in this case

Btw, the reason I chose this order is that the first part of the condition is
false in 99% of the time, while the second part is true 99% of the time. So, in
my case there is a tiny optimization in keeping the order as is.

Thank you,

Eran

Re: Inquiry: Country of Origin for gfortran

[David Edelsohn via Gcc]

Should this question be posed to the Linux distribution that NASA is using?

Thanks, David

On Sun, Jul 17, 2022 at 4:56 AM Thomas Koenig via Gcc  wrote:
>
> Hi Cynthia,
>
>  > Hello, my name is Cynthia and I am a Supply Chain Risk Management
>  > Analyst at NASA. NASA is currently conducting a supply chain
>  > assessment of gfortran. As stated in Sections 208 and 514 of the
>  > Consolidated Appropriations Act, 2022, Public Law 117-103,
>  > enacted March 15, 2022, a required step of our process is to
>  > verify the Country of Origin (CoO) information for the
>  > product (i.e., the country where the products were developed,
>  > manufactured, and assembled.)
>
>  > As gfortran is open source, we understand that this inquiry is
>  > not directly applicable, as contributions may be made from
>  > individuals from around the world. In this case, NASA is
>  > interested in confirming the following information:
>
>  > 1.  Is there an organization which sponsors/publishes the project, or
>  > a primary developer who audits the code for potential
> vulnerabilities, > errors, or malicious code? Y/N
>
> gfortran is not an independent project, it is part of the Gnu Compiler
> Collection, https://gcc.gnu.org/ .  As such, any evaluation you
> may already have made of gcc also should also apply to gfortran,
> and I am also addressing this mail to the gcc mailing list, where
> it is more appropriate, especially since I personally am unclear
> about the current relationship with the Free Software Foundation.
>
> Regarding gfortran specifically:  Code changes are reviewed by
> the individuals listed in the file
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=MAINTAINERS;hb=HEAD
>
> (where you can search for Fortran).
>
>  > 2.  Does gfortran have an overseeing organization or individual
>  >   along these lines? Y/N
>
> See my previous reply.
>
>  > 1.  If so, please provide the name of the organization and country
>  > they are established in
>
>  > If the information above is unknown or cannot be provided, we
>  > request that you provide the country or list of countries where
>  > the majority of contributions originate from to satisfy Sections
>  > 208 and 514 of the Consolidated Appropriations Act, 2022, Public
>  > Law 117-103, enacted March 15, 2022.
>
> Main contributions to gfortran, i.e. the Fortran front end to gcc and
> its supporting library, came (in no particular order) from the UK, the
> US, France, Finland, Germany, the Netherlands and the Czech Republic.
> Up to 2006, there were also some contributors from China.
>
> Best regards
>
> Thomas
>

Re: [PATCH] libphobos: Fix instability in the parallelized testsuite

[Lewis Hyatt via Gcc-patches]

> Hi Lewis,
> 
> Thanks! Good spot. I think it should be calling dg-runtest however,
> same as what libphobos.cycles/cycles.exp is doing. Could also fix the
> test name so each one is unique, just to hit two birds in one -
> something like the following would suffice (haven't had time to check).
> 
> Kind Regards,
> Iain.
> 
> ---
> 
> --- a/libphobos/testsuite/libphobos.unittest/unittest.exp
> +++ b/libphobos/testsuite/libphobos.unittest/unittest.exp
> @@ -42,8 +42,10 @@ foreach unit_test $unit_test_list {
>  set expected_fail [lindex $unit_test 1]
>  
>  foreach test $tests {
> -set shouldfail $expected_fail
> -dg-test $test "" $test_flags
> + set libphobos_test_name "[dg-trim-dirname $srcdir $test] $test_flags"
> + set shouldfail $expected_fail
> + dg-runtest $test "" $test_flags
> + set libphobos_test_name ""
>  }
>  
>  set shouldfail 0
> 

Thanks for the followup. I tested and can confirm your version works fine:

PASS: libphobos.unittest/customhandler.d -fversion=FailNoPrintout (test for 
excess errors)
PASS: libphobos.unittest/customhandler.d -fversion=FailNoPrintout execution test
PASS: libphobos.unittest/customhandler.d -fversion=FailedTests (test for excess 
errors)
PASS: libphobos.unittest/customhandler.d -fversion=FailedTests execution test
PASS: libphobos.unittest/customhandler.d -fversion=GoodTests (test for excess 
errors)
PASS: libphobos.unittest/customhandler.d -fversion=GoodTests execution test
PASS: libphobos.unittest/customhandler.d -fversion=NoTests (test for excess 
errors)
PASS: libphobos.unittest/customhandler.d -fversion=NoTests execution test
PASS: libphobos.unittest/customhandler.d -fversion=PassNoPrintout (test for 
excess errors)
PASS: libphobos.unittest/customhandler.d -fversion=PassNoPrintout execution test

Let me know if you want me to do anything from there please?  By the way, there
are a few other tests that cause some minor glitches with comparing results:

libphobos.sum:PASS: libphobos.shared/link.d 
-I/home/lewis/gccdev/base/src/libphobos/testsuite/libphobos.shared lib.so 
-shared-libphobos (test for excess errors)
libphobos.sum:PASS: libphobos.shared/link.d 
-I/home/lewis/gccdev/base/src/libphobos/testsuite/libphobos.shared lib.so 
-shared-libphobos execution test
libphobos.sum:PASS: libphobos.shared/link_linkdep.d 
-I/home/lewis/gccdev/base/src/libphobos/testsuite/libphobos.shared 
liblinkdep.so lib.so -shared-libphobos (test for excess errors)
libphobos.sum:PASS: libphobos.shared/link_linkdep.d 
-I/home/lewis/gccdev/base/src/libphobos/testsuite/libphobos.shared 
liblinkdep.so lib.so -shared-libphobos execution test
libphobos.sum:PASS: libphobos.shared/link_loaddep.d 
-I/home/lewis/gccdev/base/src/libphobos/testsuite/libphobos.shared 
libloaddep.so -shared-libphobos (test for excess errors)
libphobos.sum:PASS: libphobos.shared/link_loaddep.d 
-I/home/lewis/gccdev/base/src/libphobos/testsuite/libphobos.shared 
libloaddep.so -shared-libphobos execution test

The problem here is that the absolute path to the test dir ends up in
the results summary, since it appears in the options string that is
part of the test name. It's not so hard to work around when doing the
comparisons, but it seems to be the only case where this happens in
the whole testsuite, other than one other similar case from libgo. Is
there a standard way to handle it I take it? Thanks...

-Lewis

[Bug c/106333] Required condition omitted from generated code

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
If frame->pts_delay < 0 then NGX_LIVE_INVALID_PTS - frame->pts_delay overflows,
thus this assumed to not happen.  You need to check frame->pts_delay >= 0 first
to get defined behaviour.

rust non-free-compatible trademark

[lkcl via Gcc]

with the recent announcement that rust is supported by gcc
has it been taken into consideration that the draconian (non-free-compatible)
requirements of the rust Trademark make the distribution of the gcc
compiler Unlawful?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920

if the word "rust" is entirely removed from the gcc source code then
there is no problem whatsoever (recall: "iceweasel").

l.

Re: [PATCH] c: Fix location for _Pragma tokens [PR97498]

[Lewis Hyatt via Gcc-patches]

On Sat, Jul 9, 2022 at 11:59 PM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote:
> > Hello-
> >
> > PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
> > related to the fact that imprecise locations for _Pragma result in
> > counterintuitive behavior for GCC diagnostic pragmas, which inhibit the
> > ability to make convenient wrapper macros for enabling and disabling
> > diagnostics in specific scopes.
> >
> > It looks like David did a lot of work a few years ago improving this
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 and
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558), and in particular
> > r233637 added a lot of new test coverage for cases that had regressed in the
> > past.
> >
> > I think the main source of problems for all remaining issues is that we use
> > the global input_location for deciding when/if a diagnostic should apply. I
> > think it should be eventually doable to eliminate this, and rather properly
> > resolve the token locations to the place they need to be
> I've long wanted to see our dependency on input_location be diminished
> with the goal of making it go away completely.
> > so that _Pragma
> > type wrapper macros just work the way people expect.
> Certainly desirable since many projects have built wrapper macros which
> use Pragmas to control warnings.  One of the biggest QOI implementation
> details we've had with the warnings has been problems with location data
> leading to an inability to turn them off in specific locations.
>
> So I'm all for improvements, in terms of getting our location data more
> correct.
>
>
>
> >
> > That said, PR97498 can be solved easily with a 2-line fix without removing
> > input_location, and I think the resulting change to input_location's value
> > is an improvement that will benefit other areas, so I thought I'd see what
> > you think about this patch please?
> >
> > Here is a typical testcase. Note the line continuations so it's all one
> > logical line.
> >
> > ===
> > _Pragma("GCC diagnostic push") \
> > _Pragma("GCC diagnostic ignored \"-Wunused-function\"") \
> > static void f() {} \
> > _Pragma("GCC diagnostic pop")
> > ===
> >
> > What happens is that in C++ mode, input_location is always updated to the
> > most recently-lexed token, so the above case works fine and does not warn
> > when compiled with "g++ -Wunused-functions". However, in C mode, it does
> > warn because input_location in C is almost always set to the start of the
> > line, and is in this case. So the pop is deemed to take place prior to the
> > definition of f().
> >
> > Initially, I thought it best to change input_location for C mode to behave
> > like C++, and always update to the most recently lexed token. Maybe that's
> > still the right way to go, but there was a fair amount of testsuite fallout
> > from that. Most of it, was just that we would need to change the tests to 
> > look
> > for the new locations, and in many cases, the new locations seemed
> > preferable to the old ones, but it seemed a bit much for now, so I took a
> > more measured approach and just changed input_location in the specific case
> > of processing a pragma, to be the location of the CPP_PRAGMA token.
> >
> > Unfortunately, it turns out that the CPP_PRAGMA token that libcpp provides
> > to represent the _Pragma() expression doesn't have a valid location with
> > which input_location could be overridden. Looking into that, in r232893
> > David added logic which sets the location of all tokens inside the
> > _Pragma(...) to a reasonable place (namely it points to "_Pragma" at the
> > expansion point). However, that patch didn't change the location of the
> > CPP_PRAGMA token itself to similarly point there, so the 2nd line of this
> > patch does that.
> >
> > The rest of it is just tweaking a couple tests which were sensitive to the
> > location being output. In all these cases, the new locations seem more
> > informative to me than the old ones. With those tweaks, bootstrap + regtest
> > all languages looks good with no regressions.
> >
> > Please let me know what you think? Thanks!
> > gcc/c/ChangeLog:
> >
> >   PR preprocessor/97498
> >   * c-parser.cc (c_parser_pragma): Set input_location to the
> >   location of the pragma, rather than the start of the line.
> >
> > libcpp/ChangeLog:
> >
> >   PR preprocessor/97498
> >   * directives.cc (destringize_and_run): Override the location of
> >   the CPP_PRAGMA token from a _Pragma directive to the location of
> >   the expansion point, as is done for the tokens lexed from it.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   PR preprocessor/97498
> >   * c-c++-common/pr97498.c: New test.
> >   * c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
> >   * c-c++-common/gomp/pragma-5.c: Likewise.
> >   * gcc.dg/pragma-message.c: Likewise.
> >
> > libgomp/ChangeLog:
> >
> >   * 

[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent

[lhyatt at gmail dot com via Gcc-bugs]

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gmail dot com

--- Comment #8 from Lewis Hyatt  ---
(In reply to Martin Liška from comment #7)

> We actually speak about 2 modified lines, so can we backport it, please?

It will work fine for any of 10, 11, 12. I'll ask for approval for that on
gcc-patches then.

[Bug middle-end/106332] Possible out of bound buffer access in opts-common.c

[liftdat at protonmail dot com via Gcc-bugs]

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

--- Comment #3 from liftdat at protonmail dot com ---
(In reply to Andrew Pinski from comment #1)
> The one inside check_offload_target_name (in gcc.cc) will always have at
> least one entry in candidates.
> 
> The one inside cmdline_handle_error (in opts-common.cc) could in theory be
> called with no elements for candidates but if there was none, the option
> itself would have been disabled before hand.
> 
> The two in config/aarch64.cc:
> aarch64_print_hint_for_core_or_arch: there will always be at least one
> candidate since there is always more than one core/arch defined.
> aarch64_print_hint_for_extensions: there is always at least one candidate as
> extensions will always be more than one
> 
> 
> 
> The few in config/i386.cc:
> ix86_parse_stringop_strategy_string: at least one stringop_strategy
> ix86_option_override_internal (both of them): at least one processor defined
> 
> 
> 
> So the question is how did you find this?

This is found by a static analysis tool. I think putting an assertion can help
to clarify the requirements for any future clients of this function.

[Bug c/106333] New: Required condition omitted from generated code

[eran.kornblau at kaltura dot com via Gcc-bugs]

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

Bug ID: 106333
   Summary: Required condition omitted from generated code
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eran.kornblau at kaltura dot com
  Target Milestone: ---

Hi,

We bumped into a case where a required condition gets omitted from our code, we
validated the issue on versions 11.1.0, 11.2.0, 11.3.0, 12.1.0. 
Version 10.3.0 is working as expected.

The issue happens only when compiling with optimizations (I tested -O2), when
running without any -Oxxx flag, it works as expected.

The issue can be reproduced with these commands -
$ docker run -it gcc:12.1.0 /bin/sh

# cat > /tmp/x.c
#include 
#include 
#include 
#include 

#define NGX_LIVE_INVALID_PTS (LLONG_MAX)

typedef struct {
int64_t created;
int64_t dts;
uint32_tflags;
int32_t pts_delay;
} kmp_frame_t;

static int test(kmp_frame_t *frame)
{
if (frame->dts >= NGX_LIVE_INVALID_PTS - frame->pts_delay &&
frame->pts_delay >= 0) {
printf("bad!\n");

} else {
printf("good!\n");
}
}

int main()
{
kmp_frame_t  frame;

memset(, 0xff, sizeof(frame));
frame.dts = 149201707622903;

test();

return 0;
}
^C
# gcc -O2 /tmp/x.c -o /tmp/x ; /tmp/x
bad!
# gcc /tmp/x.c -o /tmp/x ; /tmp/x
good!
#

Following the memset with 0xff, the value of frame.pts_delay is -1. Therefore,
the second part of the if condition (frame->pts_delay >= 0) is expected to be
false (the field is a signed int32_t), so we should get the string 'good!'
printed.
However, it seems the second part of the condition (following the &&) gets
optimized out, and we get 'bad!' printed out.

Thank you!

Eran

Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

[Andreas K. Huettel via Gcc-patches]

> I'm kind of torn on this one: this has been around for a while and 
> dropping it would be an ABI break, but the feedback from distro folks is 
> pretty consistently that multlib is broken on RISC-V.  If it's really 
> unusably broken then I could buy the argument that there's no binaries 
> (and thus no ABI to break), but there's at some base multilib 
> functionality working -- I build multilib cross toolchains regularly, 
> for example, and they can build simple stuff.

So as the one who initially bootstrapped rv64 for Gentoo in full multilib 
mode...

1) Multilib works in principle.

2) The main problem with the lib64/lp64d etc paths is that software authors
out there assume that the "libdir" is a single-depth directory. 
In Gentoo specifically, "normally" $(get_libdir) echos "lib64" and people
assume that "$(get_libdir)/../" ends up at a specific location. Now if 
$(get_libdir) echos "lib64/lp64" ...
That is not limited to the Gentoo side though.

3) The second problem is that binary-distributed software, built for
non-multilib lp64d (hey, rust, I'm talking of you), of course use
"lib64" and not "lib64/lp64d".

4) The third problem (more of an oddity) is that for rv32 the non-multilib
fallback for the "lib32/ilp32d" directories is not "lib32" but "lib".

With incompatible changes some time ago (the 17.0 to 20.0 profile change), 
2) and 3) was "fixed" in Gentoo (where we officially only do rv64 so far
because usermode qemu-riscv32 is b0rk b0rk b0rk). What I did:

* The main ABI (normally lp64d) was moved to lib64
  https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/multilib.eclass#n419
* Compat symlinks, e.g. /usr/lib64/lp64d -> . were installed.

This 
* *mostly* solves 2) because only a small subset of libraries is
  installed for the non-default ABI, 
* and solves 3) because the default ABI is in the fallback non-multilib
  location (but also accessible via the symlink if something insists).

https://gentoo.osuosl.org/releases/riscv/autobuilds/

Given these hacks, our multilib stages are not linked on the website, 
but they are built just fine and should work just fine. Feel free to
try in a chroot / with qemu / ...


> I always find making that "nobody's used it" argument really hard, 
> there's just too many users to try and track everyone down.  We're in 
> kind of a weird spot with RISC-V in general when it comes to ABI stuff: 
> we were probably a bit overly optimistic about how fast any of this was 
> going to get used when we committed to the ABI freeze, but any ABi break 
> has such a huge potential for user headaches that I'm not sure it's 
> going to be possible.  It means we're stuck with some baggage, and while 
> it's a headache to keep around stuff that's probably not all that useful 
> I think it's just what we've got to live with.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: Inquiry: Country of Origin for gfortran

[Thomas Koenig via Gcc]

Hi Cynthia,

> Hello, my name is Cynthia and I am a Supply Chain Risk Management
> Analyst at NASA. NASA is currently conducting a supply chain
> assessment of gfortran. As stated in Sections 208 and 514 of the
> Consolidated Appropriations Act, 2022, Public Law 117-103,
> enacted March 15, 2022, a required step of our process is to
> verify the Country of Origin (CoO) information for the
> product (i.e., the country where the products were developed,
> manufactured, and assembled.)

> As gfortran is open source, we understand that this inquiry is
> not directly applicable, as contributions may be made from
> individuals from around the world. In this case, NASA is
> interested in confirming the following information:

> 1.  Is there an organization which sponsors/publishes the project, or 
> a primary developer who audits the code for potential 
vulnerabilities, > errors, or malicious code? Y/N


gfortran is not an independent project, it is part of the Gnu Compiler
Collection, https://gcc.gnu.org/ .  As such, any evaluation you
may already have made of gcc also should also apply to gfortran,
and I am also addressing this mail to the gcc mailing list, where
it is more appropriate, especially since I personally am unclear
about the current relationship with the Free Software Foundation.

Regarding gfortran specifically:  Code changes are reviewed by
the individuals listed in the file

https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=MAINTAINERS;hb=HEAD

(where you can search for Fortran).

> 2.  Does gfortran have an overseeing organization or individual
>   along these lines? Y/N

See my previous reply.

> 1.  If so, please provide the name of the organization and country
> they are established in

> If the information above is unknown or cannot be provided, we
> request that you provide the country or list of countries where
> the majority of contributions originate from to satisfy Sections
> 208 and 514 of the Consolidated Appropriations Act, 2022, Public
> Law 117-103, enacted March 15, 2022.

Main contributions to gfortran, i.e. the Fortran front end to gcc and
its supporting library, came (in no particular order) from the UK, the
US, France, Finland, Germany, the Netherlands and the Czech Republic.
Up to 2006, there were also some contributors from China.

Best regards

Thomas

[Bug middle-end/106332] Possible out of bound buffer access in opts-common.c

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

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

--- Comment #2 from Jonathan Wakely  ---
I suppose we could just put a gcc_assert in there to make that assumption
explicit and give an ICE in checked builds.

[Bug target/106273] [13 Regression] wrong code with -Og -march=cascadelake (due to ANDN?) since r13-1379-ge8a46e5cdab500ea

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

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

--- Comment #4 from Roger Sayle  ---
This should now be fixed.

[Bug target/106278] [13 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: in ix86_output_ssemov, at config/i386/i386.cc:5555 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

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

--- Comment #4 from Roger Sayle  ---
This shoud now be fixed.

[Bug middle-end/106332] Possible out of bound buffer access in opts-common.c

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

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

--- Comment #1 from Andrew Pinski  ---
The one inside check_offload_target_name (in gcc.cc) will always have at least
one entry in candidates.

The one inside cmdline_handle_error (in opts-common.cc) could in theory be
called with no elements for candidates but if there was none, the option itself
would have been disabled before hand.

The two in config/aarch64.cc:
aarch64_print_hint_for_core_or_arch: there will always be at least one
candidate since there is always more than one core/arch defined.
aarch64_print_hint_for_extensions: there is always at least one candidate as
extensions will always be more than one



The few in config/i386.cc:
ix86_parse_stringop_strategy_string: at least one stringop_strategy
ix86_option_override_internal (both of them): at least one processor defined



So the question is how did you find this?

[Bug c/106332] New: Possible out of bound buffer access in opts-common.c

[liftdat at protonmail dot com via Gcc-bugs]

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

Bug ID: 106332
   Summary: Possible out of bound buffer access in opts-common.c
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liftdat at protonmail dot com
  Target Milestone: ---

In the file gcc/opts-common.cc, the function candidates_list_and_hint has the
following code (link:
https://github.com/gcc-mirror/gcc/blob/9715f10c0651c9549b479b69d67be50ac4bd98a6/gcc/opts-common.cc#L1342):

const char *
candidates_list_and_hint (const char *arg, char *,
  const auto_vec  )
{
  size_t len = 0;
  int i;
  const char *candidate;
  char *p;

  FOR_EACH_VEC_ELT (candidates, i, candidate)
len += strlen (candidate) + 1;

  str = p = XNEWVEC (char, len);
  FOR_EACH_VEC_ELT (candidates, i, candidate)
{
  len = strlen (candidate);
  memcpy (p, candidate, len);
  p[len] = ' ';
  p += len + 1;
}
  p[-1] = '\0';
  return find_closest_string (arg, );
}

When candidates is an empty vector, the buffer access p[-1] is out of bound.