[Bug rtl-optimization/7061] Access of bytes in struct parameters

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

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

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

https://gcc.gnu.org/g:64d4f27a0ce47e97867512bda7fa5683acf8a134

commit r13-1282-g64d4f27a0ce47e97867512bda7fa5683acf8a134
Author: Roger Sayle 
Date:   Mon Jun 27 07:47:40 2022 +0100

Implement __imag__ of float _Complex using shufps on x86_64.

This patch is a follow-up improvement to my recent patch for
PR rtl-optimization/7061.  That patch added the test case
gcc.target/i386/pr7061-2.c:

float im(float _Complex a) { return __imag__ a; }

For which GCC on x86_64 currently generates:

movq%xmm0, %rax
shrq$32, %rax
movd%eax, %xmm0
ret

but with this patch we now generate (the same as LLVM):

shufps  $85, %xmm0, %xmm0
ret

This is achieved by providing a define_insn_and_split that allows
truncated lshiftrt:DI by 32 to be performed on either SSE or general
regs, where if the register allocator prefers to use SSE, we split
to a shufps_v4si, or if not, we use a regular shrq.

2022-06-27  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/7061
* config/i386/i386.md (*highpartdisi2): New define_insn_and_split.

gcc/testsuite/ChangeLog
PR rtl-optimization/7061
* gcc.target/i386/pr7061-2.c: Update to look for shufps.

[Bug tree-optimization/94026] combine missed opportunity to simplify comparisons with zero

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

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

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

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

commit r13-1281-gf3f73e86ec8613f176db3e52bbfbfbb9636cb714
Author: Roger Sayle 
Date:   Mon Jun 27 07:44:49 2022 +0100

[PATCH] PR tree-optimization/94026: Simplify (X>>8)&6 != 0 as X&1536 != 0.

This patch implements the missed optimization described in PR 94026,
where a the shift can be eliminated from the sequence of a shift,
followed by a bit-wise AND followed by an equality/inequality test.
Specifically, ((X << C1) & C2) cmp C3 into (X & (C2 >> C1)) cmp (C3 >> C1)
and likewise ((X >> C1) & C2) cmp C3 into (X & (C2 << C1)) cmp (C3 << C1)
where cmp is == or !=, and C1, C2 and C3 are integer constants.
The example in the subject line is taken from the hot function
self_atari from the Go program Leela (in SPEC CPU 2017).

2022-06-27  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/94026
* match.pd (((X << C1) & C2) eq/ne C3): New simplification.
(((X >> C1) & C2) eq/ne C3): Likewise.

gcc/testsuite/ChangeLog
PR tree-optimization/94026
* gcc.dg/pr94026.c: New test case.

[Bug tree-optimization/106099] New: ICE in execute_todo, at passes.cc:2134

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 106099
   Summary: ICE in execute_todo, at passes.cc:2134
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran 13.0.0 20220626 snapshot (g:ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd)
ICEs when compiling libgomp/testsuite/libgomp.oacc-fortran/routine-1.f90:

% gfortran-13.0.0 -O1 -fopenacc -funreachable-traps -fno-tree-ccp -c
libgomp/testsuite/libgomp.oacc-fortran/routine-1.f90
during GIMPLE pass: ivcanon
libgomp/testsuite/libgomp.oacc-fortran/routine-1.f90:21:16:

   21 |   !$acc parallel
  |^
internal compiler error: in execute_todo, at passes.cc:2134
0x71c660 execute_todo
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220626/work/gcc-13-20220626/gcc/passes.cc:2134

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #4 from Xi Ruoyao  ---
BTW I found this issue trying to triage PR106096, but I think it's not related
to this one.

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #5 from Xi Ruoyao  ---
And it actually does not need a reproducer: "x << 32 >> 32" for sign-extension
is undefined by C++ standard if x is negative:

> The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are 
> zero-filled. If E1 has an unsigned type, the value of the result is
> E1 × 2^{E2}, reduced modulo one more than the maximum value representable in
> the result type. Otherwise, if E1 has a signed type and non-negative value,
> and E1 × 2^{E2} is representable in the corresponding unsigned type of the
> result type, then that value, converted to the result type, is the resulting
> value; otherwise, the behavior is undefined.

And the result of right shifting negative numbers is implementation-defined
(zext or sext), though GCC always uses sext.

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #3 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #2)
> by using the --with-build-config=bootstrap-ubsan option at configure time or
> BUILD_CONFIG variable to build time.
> 
> See https://gcc.gnu.org/install/build.html

The problem is -fsanitize=undefined does not work on LoongArch for now.  But it
can be reproduced by building a cross compile on x86_64:

/path/to/gcc/configure --target=loongarch64-linux-gnu
make {C,CXX}FLAGS="-O2 -g -fsanitize=undefined" all-gcc

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

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

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

--- Comment #2 from Andrew Pinski  ---
by using the --with-build-config=bootstrap-ubsan option at configure time or
BUILD_CONFIG variable to build time.

See https://gcc.gnu.org/install/build.html

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #1 from chenglulu  ---

How can I reproduce the problem?
Thanks!
Lulu Cheng

[Bug c++/106098] error message that uses ANSI codes that can cause characters to disappear

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> What terminal are you using?

Basically some terminals implement this differently and maybe even incorrectly.
See the other (still open) bug report for more details on this and even on the
some of the terminals emulations and such.

[Bug other/90411] Colored diagnostics can omit characters

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jonathan.poelen at gmail dot 
com

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

[Bug c++/106098] error message that uses ANSI codes that can cause characters to disappear

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 90411.

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

[Bug c++/106098] error message that uses ANSI codes that can cause characters to disappear

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

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

--- Comment #1 from Andrew Pinski  ---
What terminal are you using?

[Bug c++/106098] New: error message that uses ANSI codes that can cause characters to disappear

[jonathan.poelen at gmail dot com via Gcc-bugs]

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

Bug ID: 106098
   Summary: error message that uses ANSI codes that can cause
characters to disappear
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonathan.poelen at gmail dot com
  Target Milestone: ---

Created attachment 53204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53204&action=edit
comparison between a 106 and 127 column terminal

int main() {
  char const* b = "" + "";
}

$ g++ -fdiagnostics-color=always test.cpp
test.cpp: In function ‘int main()’:
test.cpp:2:22: error: invalid operands of types ‘const char [1]’ and ‘const
char [1]’ to binary ‘operator ’
[...]

On a terminal of 106 characters per line, the `+` sign disappeared. This is due
to the use of the ANSI code \x1b[K which normally removes the characters to the
right of the cursor. However, many terminals make the last character of the
line disappear when this code is used at the end of the line. This is the case
here with a 106 column terminal ($COLUMNS=106).

I don't know why \x1b[K is used, but as far as I can see, it is useless.

[Bug target/106097] New: undefined behaviors regarding integer shifts in loongarch_build_integer

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Bug ID: 106097
   Summary: undefined behaviors regarding integer shifts in
loongarch_build_integer
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at mengyan1223 dot wang
  Target Milestone: ---

UBSan reports these undefined behaviors building a cross compiler for
loongarch64-linux-gnu on x86_64-linux-gnu:

/home/xry111/git-repos/gcc-la-build/./gcc/xgcc
-B/home/xry111/git-repos/gcc-la-build/./gcc/ -xc -nostdinc /dev/null -S -o
/dev/null -fself-test=../../gcc/gcc/testsuite/selftests
../../gcc/gcc/config/loongarch/loongarch.cc:1471:49: runtime error: left shift
of 4294967296 by 32 places cannot be represented in type 'long int'
../../gcc/gcc/config/loongarch/loongarch.cc:1520:49: runtime error: left shift
of negative value -524288
../../gcc/gcc/config/loongarch/loongarch.cc:1515:38: runtime error: left shift
of negative value -2048

/home/xry111/git-repos/gcc-la-build/./gcc/xgcc
-B/home/xry111/git-repos/gcc-la-build/./gcc/ -xc++ -nostdinc /dev/null -S -o
/dev/null -fself-test=../../gcc/gcc/testsuite/selftests
../../gcc/gcc/config/loongarch/loongarch.cc:1471:49: runtime error: left shift
of 4294967296 by 32 places cannot be represented in type 'long int'
../../gcc/gcc/config/loongarch/loongarch.cc:1520:49: runtime error: left shift
of negative value -524288
../../gcc/gcc/config/loongarch/loongarch.cc:1515:38: runtime error: left shift
of negative value -2048

[Bug target/106096] New: [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu since r13-911

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Bug ID: 106096
   Summary: [13 regression] ICE building stage 2 libgcc on
loongarch64-linux-gnu since r13-911
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at mengyan1223 dot wang
  Target Milestone: ---

Since r13-911, bootstrapping on loongarch64-linux-gnu is broken because of an
ICE building stage 2 libgcc.

This issue is particularly diffcult to diagnose, due to the reasons:

1. r13-910 and r13-909 does not build, so it's hard to tell which change
"really" triggers the issue.
2. r13-{909,910,911} consist a very large change.
3. GCC even fails to produce a stacktrace on the ICE.
4. It's not reproducible with a cross compiler on x86_64 host, even with ASan
and UBSan.

A backtrace gathered using GDB:

#0  0x2000 in ?? ()
#1  0x000120b2157c in path_range_query::range_defined_in_block (
this=this@entry=0x121b3bb20, r=..., name=name@entry=0x755a17a0, 
bb=bb@entry=0x75598750) at ../../gcc/gcc/gimple-range-path.cc:354
#2  0x000120b21880 in path_range_query::compute_ranges_in_phis (
this=this@entry=0x121b3bb20, bb=bb@entry=0x75598750)
at ../../gcc/gcc/gimple-range-path.cc:400
#3  0x000120b21b70 in path_range_query::compute_ranges_in_block (
this=this@entry=0x121b3bb20, bb=bb@entry=0x75598750)
at ../../gcc/gcc/gimple-range-path.cc:448
#4  0x000120b225b8 in path_range_query::compute_ranges (this=0x121b3bb20, 
path=..., imports=)
at ../../gcc/gcc/gimple-range-path.cc:665
#5  0x000120bb1ba0 in back_threader::find_taken_edge_cond (
this=0x7fff6d18, path=..., cond=0x75775f40)
at ../../gcc/gcc/tree-ssa-threadbackward.cc:319
#6  0x000120bb1d9c in back_threader::find_taken_edge (
this=this@entry=0x7fff6d18, path=...)
at ../../gcc/gcc/tree-ssa-threadbackward.cc:276
#7  0x000120bb2768 in back_threader::maybe_register_path (
this=this@entry=0x7fff6d18)
at ../../gcc/gcc/tree-ssa-threadbackward.cc:232
#8  0x000120bb2f34 in back_threader::find_paths_to_names (
this=this@entry=0x7fff6d18, bb=, 
interesting=interesting@entry=0x7fff6c90)
at ../../gcc/gcc/tree-ssa-threadbackward.cc:419
#9  0x000120bb317c in back_threader::resolve_phi (
interesting=, phi=, this=)
at ../../gcc/gcc/tree-ssa-threadbackward.cc:396
#10 back_threader::resolve_phi (this=0x7fff6d18, phi=0x757a0d00, 
interesting=0x7fff6c90) at ../../gcc/gcc/tree-ssa-threadbackward.cc:356
#11 0x000120bb2cf0 in back_threader::find_paths_to_names (
this=this@entry=0x7fff6d18, bb=, 
interesting=interesting@entry=0x7fff6c90)
at ../../gcc/gcc/tree-ssa-threadbackward.cc:444
#12 0x000120bb2ddc in back_threader::find_paths_to_names (
this=this@entry=0x7fff6d18, bb=, 
bb@entry=0x755986e8, interesting=interesting@entry=0x7fff6c90)
at ../../gcc/gcc/tree-ssa-threadbackward.cc:459
#13 0x000120bb3408 in back_threader::find_paths (this=0x7fff6d18, 
bb=0x755986e8, name=0x755a1050) at ../../gcc/gcc/bitmap.h:955
#14 0x000120bb3620 in back_threader::thread_blocks (
this=this@entry=0x7fff6d18)
at ../../gcc/gcc/tree-ssa-threadbackward.cc:901
#15 0x000120bb3694 in (anonymous namespace)::pass_thread_jumps::execute (
this=, fun=)
at ../../gcc/gcc/tree-ssa-threadbackward.cc:1003
#16 0x00012082a10c in execute_one_pass (pass=pass@entry=0x1219d0550)
at ../../gcc/gcc/passes.cc:2638
#17 0x00012082aa68 in execute_pass_list_1 (pass=0x1219d0550)
at ../../gcc/gcc/passes.cc:2738
#18 0x00012082aa78 in execute_pass_list_1 (pass=0x1219cded0)
at ../../gcc/gcc/passes.cc:2739
#19 0x00012082aad8 in execute_pass_list (fn=, 
pass=) at ../../gcc/gcc/passes.cc:2749
#20 0x0001203e1a1c in cgraph_node::expand (this=0x75609980)
at ../../gcc/gcc/context.h:48
#21 cgraph_node::expand (this=0x75609980)
at ../../gcc/gcc/cgraphunit.cc:1788
#22 0x0001203e3540 in expand_all_functions ()
at ../../gcc/gcc/cgraphunit.cc:1999
#23 symbol_table::compile (this=this@entry=0x7548c000)
at ../../gcc/gcc/cgraphunit.cc:2349
#24 0x0001203e6be0 in symbol_table::compile (this=0x7548c000)
at ../../gcc/gcc/cgraphunit.cc:2262
#25 symbol_table::finalize_compilation_unit (this=0x7548c000)
at ../../gcc/gcc/cgraphunit.cc:2530
#26 0x00012092d148 in compile_file () at ../../gcc/gcc/toplev.cc:479
#27 0x0001201ca3d4 in do_compile (no_backend=false)
at ../../gcc/gcc/toplev.cc:2144
#28 toplev::main (this=this@entry=0x7fff7148, argc=, 
argc@entry=3, argv=, argv@entry=0x7fff72d8)
at ../../gcc/gcc/toplev.cc:2296
#29 0x0001201cba28 in main (argc=, argv=0x7fff72d8)
at ../../gcc/gcc/main.

[Bug target/106095] New: Some AVX builtins produce invalid asm with -masm=intel

[bouanto at zoho dot com via Gcc-bugs]

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

Bug ID: 106095
   Summary: Some AVX builtins produce invalid asm with -masm=intel
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Some builtins don't produce valid asm when using the flag `-masm=intel`:

 * __builtin_ia32_pmovdw128mem_mask
 * __builtin_ia32_cvtss2sd_mask_round
 * __builtin_ia32_cvtsd2ss_mask_round
 * __builtin_ia32_pmovqw256mem_mask
 * __builtin_ia32_pmovqw128mem_mask

I'll soon post a patch fixing this issue.

[Bug tree-optimization/106063] [12/13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

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

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

--- Comment #4 from Tamar Christina  ---
Ah, there's optimize_vectors_before_lowering_p,

would you prefer I check the operation or just gate the pattern on the above
Richi?

[Bug c++/106094] Lifetime extension of temporary do not obey some rules of [class.temporary]

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||53288

--- Comment #4 from Andrew Pinski  ---
PR 53288 is for the pointer to a member case I think.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288
[Bug 53288] [C++11] Lifetime of temporary object backing pointer-to-member
expression not extended

[Bug c++/106094] Lifetime extension of temporary do not obey some rules of [class.temporary]

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

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

--- Comment #3 from Andrew Pinski  ---
Also please attach the testcase next time rather than just a link to godbolt. I
attached it this time.

[Bug c++/106094] Lifetime extension of temporary do not obey some rules of [class.temporary]

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 53203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53203&action=edit
testcase

[Bug c++/106094] Lifetime extension of temporary do not obey some rules of [class.temporary]

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101572

--- Comment #1 from Andrew Pinski  ---
dynamic cast is filed as PR 101572 (though I don't see a test here).

[Bug c++/106094] New: Lifetime extension of temporary do not obey some rules of [class.temporary]

[kirshamir at gmail dot com via Gcc-bugs]

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

Bug ID: 106094
   Summary: Lifetime extension of temporary do not obey some rules
of [class.temporary]
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kirshamir at gmail dot com
  Target Milestone: ---

The simple cases of lifetime extension are working.

But all below do not obey the rules.
Lifetime should have been extended and it is not.

// casting (non user-defined) + member access
const auto& a1 = static_cast(A("a1")).ptr;

// casting (non user-defined) + member access
const auto& a2 = ((const A&&)A("a2")).arr;

// casting (non user-defined) + member access
const auto& a3 = const_cast(A("a3")).str;

// a pointer to a member + extending lifetime access
const auto& arr_member = &A::arr;
const auto& a4 = (A("a4").*arr_member)[0];

const auto& str_member = &A::str;
const auto& a5 = A("a5").*str_member;

const auto& ptr_member = &A::ptr;
const auto& a6 = A("a6").*ptr_member;

Code:
https://godbolt.org/z/jeeoefhPr

Rules:
https://timsong-cpp.github.io/cppwp/n4868/class.temporary#6

[Bug c++/106093] New: [Regression] False positive -Wstringop-overflow with -O3 when resizing std::vector

[aclopte at gmail dot com via Gcc-bugs]

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

Bug ID: 106093
   Summary: [Regression] False positive -Wstringop-overflow with
-O3 when resizing std::vector
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aclopte at gmail dot com
  Target Milestone: ---

Created attachment 53202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53202&action=edit
preprocessed reproducer

Very similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239 and others.
This one reproduces on 12.1.0 but not on 11.2.0.

cat > repro.cpp << EOF
#include 

template  struct Allocator {
  using value_type = T;

  Allocator() = default;

  T *allocate(unsigned long n) {
return reinterpret_cast(::operator new(sizeof(T) * n));
  }

  void deallocate(T *ptr, unsigned long n) { ::operator delete(ptr); }
};

static std::vector> m_stream{};
void read_available() {
m_stream.resize(1);
}
EOF

attached the preprocessed output

$ g++ -std=c++2a repro.cpp -S -O3

In function ‘constexpr decltype (::new(void*(0)) _Tp) std::construct_at(_Tp*,
_Args&& ...) [with _Tp = char; _Args = {char}]’,
inlined from ‘static constexpr
std::_Require >::__construct_helper<_Tp, _Args>::type>,
std::is_constructible<_Tp, _Args ...> > > std::allocator_traits<
 >::_S_construct(_Alloc&, _Tp*, _Args&& ...) [with _Tp
= char; _Args = {char}; _Alloc = Allocator]’ at
/usr/include/c++/12.1.0/bits/alloc_traits.h:263:21,
inlined from ‘static constexpr decltype (std::allocator_traits<
 >::_S_construct(__a, __p,
(forward<_Args>)(std::allocator_traits< 
>::construct::__args)...)) std::allocator_traits< 
>::construct(_Alloc&, _Tp*, _Args&& ...) [with _Tp = char; _Args = {char};
_Alloc = Allocator]’ at
/usr/include/c++/12.1.0/bits/alloc_traits.h:364:16,
inlined from ‘constexpr void std::__relocate_object_a(_Tp*, _Up*,
_Allocator&) [with _Tp = char; _Up = char; _Allocator = Allocator]’ at
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:1064:26,
inlined from ‘constexpr _ForwardIterator
std::__relocate_a_1(_InputIterator, _InputIterator, _ForwardIterator,
_Allocator&) [with _InputIterator = char*; _ForwardIterator = char*; _Allocator
= Allocator]’ at
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:1092:26,
inlined from ‘constexpr _ForwardIterator std::__relocate_a(_InputIterator,
_InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = char*;
_ForwardIterator = char*; _Allocator = Allocator]’ at
/usr/include/c++/12.1.0/bits/stl_uninitialized.h:1133:33,
inlined from ‘static constexpr std::vector<_Tp, _Alloc>::pointer
std::vector<_Tp, _Alloc>::_S_relocate(pointer, pointer, pointer,
_Tp_alloc_type&) [with _Tp = char; _Alloc = Allocator]’ at
/usr/include/c++/12.1.0/bits/stl_vector.h:504:26,
inlined from ‘constexpr void std::vector<_Tp,
_Alloc>::_M_default_append(size_type) [with _Tp = char; _Alloc =
Allocator]’ at /usr/include/c++/12.1.0/bits/vector.tcc:663:16,
inlined from ‘constexpr void std::vector<_Tp, _Alloc>::resize(size_type)
[with _Tp = char; _Alloc = Allocator]’ at
/usr/include/c++/12.1.0/bits/stl_vector.h:1011:21,
inlined from ‘void read_available()’ at t/repro/repro.cc:17:20:
/usr/include/c++/12.1.0/bits/stl_construct.h:97:14: warning: writing 8 bytes
into a region of size 1 [-Wstringop-overflow=]
   97 | { return ::new((void*)__location)
_Tp(std::forward<_Args>(__args)...); }
  | 
^~~~

[Bug fortran/103707] Stray "Array operands are incommensurate"

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-06-26
 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #5)
> Thanks for the quick reduction, Gerhard.
> 
> This originally came from something like
> 
> program p
>real, parameter :: fmin(1) = 0.
>real, parameter :: fmax(1) = 1.
>real :: x(1)
>where (fmin <= 0)
>   x = fmin + (fmax-fmin)
>elsewhere
>   x = (fmax/fmin)**2
>end where
>print *,x
> end
> 
> so there is no division by zero at runtime.

Some data points from other compiler that reject the code:

NAG prints

NAG Fortran Compiler Release 7.0(Yurakucho) Build 7009
Error: pr103707.f90, line 8: Floating-point divide by zero


Cray versions 10 thru 14 print:

  x = (fmax/fmin)**2
   ^ 
ftn-1184 crayftn: WARNING P, File = pr103707.f90, Line = 8, Column = 16 
  Evaluation of this constant expression produced a NaN or other abnormal
value.
 ^   
ftn-1184 crayftn: WARNING P, File = pr103707.f90, Line = 8, Column = 22 
  Evaluation of this constant expression produced a NaN or other abnormal
value.

Cray Fortran : Version 14.0.0
(20220420160222_c98838affc7b58fed2a72f164d77c35e1bc8772f)


Intel and Nvidia are silent.

While gfortran's error message is misleading, what is our plan?
Avoid simplification in the frontend?

[Bug middle-end/106092] Bogus -Wfree-nonheap-object

[lavr at ncbi dot nlm.nih.gov via Gcc-bugs]

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

--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
Created attachment 53201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53201&action=edit
preprocessed source

Attached!  It's rather big

[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Should have taken it...

[Bug middle-end/106092] Bogus -Wfree-nonheap-object

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c++ |middle-end

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source?

[Bug c++/106092] New: Bogus -Wfree-nonheap-object

[lavr at ncbi dot nlm.nih.gov via Gcc-bugs]

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

Bug ID: 106092
   Summary: Bogus -Wfree-nonheap-object
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lavr at ncbi dot nlm.nih.gov
  Target Milestone: ---

I got the following report from the compilation:

In file included from /home/ANTON/cxx/src/util/qparse/parser.cpp:352:
query_parser_bison.tab.c: In function ‘int ncbi_q_parse(void*)’:
query_parser_bison.tab.c:2354:18: warning: ‘void free(void*)’ called on
unallocated object ‘yyssa’ [-Wfree-nonheap-object]
In file included from /home/ANTON/cxx/src/util/qparse/parser.cpp:352:
query_parser_bison.tab.c:1351:18: note: declared here

The thing is, the code which is "blamed", looks like this (line numbers on):

   2353   if (yyss != yyssa)
   2354 YYSTACK_FREE (yyss);

which obviously tells NOT to free if the "yyss" is the same as "yyssa"...
So it's unclear from which context GCC "figured" that yyssa is going to be
freed.

The declarations look like this:

   1350 /* The state stack.  */
   1351 yytype_int16 yyssa[YYINITDEPTH];
   1352 yytype_int16 *yyss;
   1353 yytype_int16 *yyssp;

   1384   yyss = yyssa;

so at some point, yyss gets assigned with yyssa.  But then again, the code
instructs exactly NOT to free, in this case.  There's nothing to warn about.

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on mainline so far.

[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed.

Thanks for the report!

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r13-1277-gff35dbc02092fbcd3d814fcd9fe8e871c3f741fd
Author: Harald Anlauf 
Date:   Tue Jun 21 23:20:18 2022 +0200

Fortran: fix simplification of INDEX(str1,str2) [PR105691]

gcc/fortran/ChangeLog:

PR fortran/105691
* simplify.cc (gfc_simplify_index): Replace old simplification
code by the equivalent of the runtime library implementation.  Use
HOST_WIDE_INT instead of int for string index, length variables.

gcc/testsuite/ChangeLog:

PR fortran/105691
* gfortran.dg/index_6.f90: New test.

[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r13-1276-ga312407bd715647f7c11b67e0a52effc94d0f15d
Author: Harald Anlauf 
Date:   Mon Jun 20 20:59:55 2022 +0200

Fortran: handle explicit-shape specs with constant bounds [PR105954]

gcc/fortran/ChangeLog:

PR fortran/105954
* decl.cc (variable_decl): Adjust upper bounds for explicit-shape
specs with constant bound expressions to ensure non-negative
extents.

gcc/testsuite/ChangeLog:

PR fortran/105954
* gfortran.dg/pr105954.f90: New test.

[Bug target/106091] [11/12/13 Regression] during RTL pass: swaps ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 69 with -fnon-call-exceptions

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #1 from Andrew Pinski  ---
Swaps is a target specific pass.

[Bug rtl-optimization/106091] New: [11/12/13 Regression] during RTL pass: swaps ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 69 with -fnon-call-exceptions

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106091
   Summary: [11/12/13 Regression] during RTL pass: swaps ICE:
verify_flow_info failed: missing REG_EH_REGION note at
the end of bb 69 with -fnon-call-exceptions
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu

Created attachment 53200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53200&action=edit
reduced testcase

Compiler output:
$ powerpc64le-unknown-linux-gnu-gcc -O -fnon-call-exceptions -fno-tree-dce
-fno-tree-forwprop testcase.c -Wno-psabi
testcase.c: In function 'foo':
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 69
   11 | }
  | ^
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 52
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 35
testcase.c:11:1: error: missing REG_EH_REGION note at the end of bb 18
during RTL pass: swaps
testcase.c:11:1: internal compiler error: verify_flow_info failed
0xab57d3 verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:284
0xec32da execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2097
0xec385b execute_todo
/repo/gcc-trunk/gcc/passes.cc:2139
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.

$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1269-20220626001633-g87509781849-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/13.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1269-20220626001633-g87509781849-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220626 (experimental) (GCC)

[Bug fortran/106071] single where run error

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/106071] single where run error

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

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to han.wu from comment #0)
> two layer where work ok, why single where work error? 
> 
> example one:
> 
> program test
>   real :: x(3) = 1, y(3) = 2
>   logical :: m(3) = .true., m2(3) = .false.
>   where (m)
> x = f1()
>   end where
>   if (any(x/=3)) then
> print *, 'FAIL', x
>   else
> print *,'ok'
>   end if
> contains
>   function f1()
> m = .false.
> !m2 = .true.
> f1 = 3
>   end function
> end
> 
> gfortran-12:
> ASM generation compiler returned: 0
> Execution build compiler returned: 0
> Program returned: 0
>  FAIL   3.   1.   1.   
> 

Well, this is simple to understand.  The WHERE is eventually translated by
gfc_trans_where_3() from trans-stmt.cc.  What is essentially happening is
that (in pseudo-code) the WHERE is converted to


do i = 1, size(m)
   if (m(i)) then
  m = .false.   ! This resets all elements of m!
  x(i) = 3
   end if
end do

where I have in-lined the function f1.  Looking in gfc_trans_where_3() we see
that gfortran should create a temporary when scalarizing the mask.  I don't
know how to do that.  When you come up with a patch, can you submit it?

[Bug target/106088] ld cannot find dependent libraries when cross compiling

[galaxyking0419 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from William Tang  ---
Okay, the '=' before search dir denotes sysroot replacement
(https://sourceware.org/binutils/docs/ld/Options.html), so the configuration of
ld should be correct.  Anyway, it should be a binutils issue.

[Bug gcov-profile/106090] New: [GCOV] Wrong coverage for loop statements

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 106090
   Summary: [GCOV] Wrong coverage for loop statements
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:volatile int cnt = 0;
-:2:
-:3:__attribute__((noinline, noclone)) static int
5:4:last (void)
-:5:{
5:6:  return ++cnt % 5 == 0;
-:7:}
-:8:
-:9:__attribute__((noinline, noclone)) static void
6:   10:do_it (void)
-:   11:{
6:   12:  asm volatile ("" : : "r" (&cnt) : "memory");
6:   13:}
-:   14:
1:   15:static void f1 (void)
-:   16:{
1:   17:  do_it();
4:   18:  for (;; do_it())
-:   19:{
5:   20:  if (last ())
1:   21:break;
-:   22:}
1:   23:  do_it ();
1:   24:}
-:   25:
-:   26:int
1:   27:main ()
-:   28:{
1:   29:  f1 ();
-:   30:}
Should the coverage of line 18 be 5?

[Bug target/106088] ld cannot find dependent libraries when cross compiling

[galaxyking0419 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from William Tang  ---
Thanks, you are right, somehow, the ld of binutils has the wrong default
SEARCH_DIR:

[william@NoteBook ~]$ arm-linux-gnueabihf-ld --verbose | grep SEARCH
SEARCH_DIR("/usr/lib/binutils/arm-linux-gnueabihf");
SEARCH_DIR("=/usr/arm-linux-gnueabihf/lib");

Created a bug for binutils:
https://sourceware.org/bugzilla/show_bug.cgi?id=29288

[Bug fortran/106089] false positives with -Wuninitialized for allocation on assignment

[beliavsky at aol dot com via Gcc-bugs]

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

--- Comment #1 from beliavsky at aol dot com ---
I see that the report is a duplicate of some reports listed at
https://fortran-lang.discourse.group/t/gfortran-uninitialized-warnings/3838/4

56670 – Allocatable-length character var causes bogus warning with
-Wuninitialized 1
91442 – Wrong "may be used uninitialized" warning with allocation on assignment
77504 – [10/11/12/13 Regression] "is used uninitialized" with allocatable
string and array constructors

[Bug fortran/106089] New: false positives with -Wuninitialized for allocation on assignment

[beliavsky at aol dot com via Gcc-bugs]

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

Bug ID: 106089
   Summary: false positives with -Wuninitialized for allocation on
assignment
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beliavsky at aol dot com
  Target Milestone: ---

For the code 

implicit none
integer, allocatable :: v(:)
character(len=1), allocatable :: a(:)
a = ["a"]
print*, a
v = [10,20]
print*,v
end

gfortran -Wall -Wextra xgfortran_warn.f90

gives many incorrect warnings:

xgfortran_warn.f90:4:9:

4 | a = ["a"]
  | ^
Warning: 'a.offset' is used uninitialized [-Wuninitialized]
xgfortran_warn.f90:3:37:

3 | character(len=1), allocatable :: a(:)
  | ^
note: 'a' declared here
xgfortran_warn.f90:4:9:

4 | a = ["a"]
  | ^
Warning: 'a.dim[0].lbound' is used uninitialized [-Wuninitialized]
xgfortran_warn.f90:3:37:

3 | character(len=1), allocatable :: a(:)
  | ^
note: 'a' declared here
xgfortran_warn.f90:4:9:

4 | a = ["a"]
  | ^
Warning: 'a.dim[0].ubound' is used uninitialized [-Wuninitialized]
xgfortran_warn.f90:3:37:

3 | character(len=1), allocatable :: a(:)
  | ^
note: 'a' declared here
xgfortran_warn.f90:4:9:

4 | a = ["a"]
  | ^
Warning: 'a.dim[0].lbound' may be used uninitialized [-Wmaybe-uninitialized]
xgfortran_warn.f90:3:37:

3 | character(len=1), allocatable :: a(:)
  | ^
note: 'a' declared here
xgfortran_warn.f90:4:9:

4 | a = ["a"]
  | ^
Warning: 'a.dim[0].ubound' may be used uninitialized [-Wmaybe-uninitialized]
xgfortran_warn.f90:3:37:

3 | character(len=1), allocatable :: a(:)
  | ^
note: 'a' declared here
xgfortran_warn.f90:4:9:

4 | a = ["a"]
  | ^
Warning: 'a.dim[0].ubound' may be used uninitialized [-Wmaybe-uninitialized]
xgfortran_warn.f90:3:37:

3 | character(len=1), allocatable :: a(:)
  | ^
note: 'a' declared here
xgfortran_warn.f90:4:9:

4 | a = ["a"]
  | ^
Warning: 'a.dim[0].lbound' may be used uninitialized [-Wmaybe-uninitialized]
xgfortran_warn.f90:3:37:

3 | character(len=1), allocatable :: a(:)
  | ^
note: 'a' declared here


The output is the same for gfortran 12.0.1 20220213 on Windows from
equation.com
and gfortran-11 on WSL2. The code combines two codes from a Fortran Discourse
discussion
https://fortran-lang.discourse.group/t/gfortran-uninitialized-warnings/3838 .

[Bug target/106088] ld cannot find dependent libraries when cross compiling

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at mengyan1223 dot wang

--- Comment #2 from Xi Ruoyao  ---
It means you've misconfigured ld.  GCC has nothing to do with tracking
DT_NEEDED entries in ELF shared objects.

[Bug target/106088] ld cannot find dependent libraries when cross compiling

[galaxyking0419 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from William Tang  ---
The mentioned libraries did exist in the cross compile environment.  Compiling
with command "arm-linux-gnueabihf-gcc main.c
-Wl,-rpath-link,/usr/arm-linux-gnueabihf/usr/lib -larchive" works just fine.

[Bug target/106088] New: ld cannot find dependent libraries when cross compiling

[galaxyking0419 at gmail dot com via Gcc-bugs]

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

Bug ID: 106088
   Summary: ld cannot find dependent libraries when cross
compiling
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: galaxyking0419 at gmail dot com
  Target Milestone: ---

Cross compiling the following program using command "arm-linux-gnueabihf-gcc
main.c -lz" works without any issues:

#include 
#include 

int main(int argc, char const *argv[])
{
z_stream s;
inflateSync(&s);
return 0;
}

However, if the linked library has dependencies, the ld program seems not be
able to find them.  e.g. compiling the following program using command
"arm-linux-gnueabihf-gcc main.c -larchive":

#include 
#include 

int main(int argc, char const *argv[])
{
puts(archive_zlib_version());
return 0;
}

gives error:

/usr/bin/arm-linux-gnueabihf-ld: warning: libcrypto.so.1.1, needed by
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so,
not found (try using -rpath or -rpath-link)
/usr/bin/arm-linux-gnueabihf-ld: warning: libacl.so.1, needed by
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so,
not found (try using -rpath or -rpath-link)
/usr/bin/arm-linux-gnueabihf-ld: warning: libexpat.so.1, needed by
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so,
not found (try using -rpath or -rpath-link)
/usr/bin/arm-linux-gnueabihf-ld: warning: liblzma.so.5, needed by
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so,
not found (try using -rpath or -rpath-link)
/usr/bin/arm-linux-gnueabihf-ld: warning: libzstd.so.1, needed by
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so,
not found (try using -rpath or -rpath-link)
/usr/bin/arm-linux-gnueabihf-ld: warning: liblz4.so.1, needed by
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so,
not found (try using -rpath or -rpath-link)
/usr/bin/arm-linux-gnueabihf-ld: warning: libbz2.so.1.0, needed by
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so,
not found (try using -rpath or -rpath-link)
/usr/bin/arm-linux-gnueabihf-ld: warning: libz.so.1, needed by
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so,
not found (try using -rpath or -rpath-link)
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `lzma_stream_encoder_mt@XZ_5.2'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `inflateReset'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `lzma_code@XZ_5.0'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `lzma_raw_encoder@XZ_5.0'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `lzma_stream_decoder@XZ_5.0'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `LZ4_decompress_safe_usingDict'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `acl_get_qualifier@ACL_1.0'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `LZ4_freeStream'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `acl_clear_perms@ACL_1.0'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `XML_ParserCreate'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `LZ4_compress_HC'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `inflateEnd'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to `acl_get_entry@ACL_1.0'
/usr/bin/arm-linux-gnueabihf-ld:
/usr/lib/gcc/arm-linux-gnueabihf/10.2.0/../../../../arm-linux-gnueabihf/lib/libarchive.so:
undefined reference to

[Bug tree-optimization/106087] Segmentation fault in GIMPLE pass: ccp

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|9.1.1   |12.1.0
  Component|c   |tree-optimization

--- Comment #2 from Andrew Pinski  ---
Hmmm,
See  for instructions.

[Bug c/106087] Segmentation fault in GIMPLE pass: ccp

[nyh at math dot technion.ac.il via Gcc-bugs]

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

--- Comment #1 from Nadav Har'El  ---
Created attachment 53199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53199&action=edit
preprocessed source file which gcc saved for reporting the crash (compressed
because of bugzilla's attachment length limit)

[Bug c/106087] New: Segmentation fault in GIMPLE pass: ccp

[nyh at math dot technion.ac.il via Gcc-bugs]

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

Bug ID: 106087
   Summary: Segmentation fault in GIMPLE pass: ccp
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nyh at math dot technion.ac.il
  Target Milestone: ---

When building the attached file, part of the open-source OSv project, in gcc
12.1.1 (on Fedora 36), I get:


during GIMPLE pass: ccp
bsd/sys/dev/hyperv/vmbus/hyperv.cc: In function ‘bool hyperv_identify()’:
bsd/sys/dev/hyperv/vmbus/hyperv.cc:117:1: internal compiler error: Segmentation
fault
  117 | hyperv_identify()
  | ^~~
Please submit a full bug report, with preprocessed source.
See  for instructions.
Preprocessed source stored into /tmp/ccCg8LNL.out file, please attach this to
your bugreport.

The preprocessed source file is attached.

I discovered that removing the two static variables hyperv_pm_features and
hyperv_features3 makes the compilation succeed. These two variables are static,
and are only set by the function which failed compilation and never read
anywhere else in the source file, so these variables are not needed. So I would
have accepted a warning about them being unused - but not a compiler crash.

[Bug middle-end/106081] missed vectorization

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #2 from Hongtao.liu  ---
Looks quite similar to PR103999