[Bug fortran/111341] Elemental operator on zero-sized array seg-faults

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
gfcx -c a.f90
a.f90:3:7:

3 |   use iso_varying_string, only: varying_string, operator(//), put_line
  |   1
Fatal Error: Cannot open module file 'iso_varying_string.mod' for reading at
(1: No such file or directory


Unforturnately, it seems the issue cannot be reproduced.

[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80396
Summary|__integer_pack fails to |[11/12/13/14 Regression]
   |work with values of |__integer_pack fails to
   |dependent type convertible  |work with values of
   |to integers in noexcept |dependent type convertible
   |context |to integers in noexcept
   ||context
   Target Milestone|--- |11.5

--- Comment #3 from Andrew Pinski  ---
I think this is techincally a regression as the user code is now being
rejected;  even though the builtin was only added in GCC 8
(r8-871-gf0c1ade45a74 ).

[Bug c++/111357] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Reduced slightly:
```
#include 

using std::integer_sequence;
using std::make_integer_sequence;

template
void g(integer_sequence)
{}

template
struct c1
{
  static constexpr int value = 1;
  constexpr operator int() { return value; } 
};
template
struct R
{
using S = make_integer_sequence{}>;

R() noexcept(noexcept(g(S(
{}
};
int main()
{
R();
}
```

The obvious workaround in this case (and the tuple_size case) is to use
`::value` (or tuple_size_v ).

[Bug c++/111357] __integer_pack fails to work with values of dependent type convertible to integers

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

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

--- Comment #1 from Andrew Pinski  ---
The front-end does:
  hi = instantiate_non_dependent_expr (hi, complain);
  hi = cxx_constant_value (hi, complain);
  int len = valid_constant_size_p (hi) ? tree_to_shwi (hi) : -1;

[Bug libstdc++/111357] New: __integer_pack fails to work with values of dependent type convertible to integers

[frankhb1989 at gmail dot com via Gcc-bugs]

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

Bug ID: 111357
   Summary: __integer_pack fails to work with values of dependent
type convertible to integers
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com
  Target Milestone: ---

Case:

#include 
#include 
#include 

using std::size_t;
#if __cpp_lib_integer_sequence >= 201304L
using std::index_sequence;
using std::make_index_sequence;
#else
template
struct index_sequence
{};

template
struct succ;

template
struct succ>
{
using type = index_sequence;
};

template
struct iseq
{
using type = typename succ::type>::type;
};

template<>
struct iseq<0>
{
using type = index_sequence<>;
};

template
using make_index_sequence = typename iseq::type;
#endif


template
void g(index_sequence)
{}

template
struct R
{
using S = make_index_sequence>{}>;

R() noexcept(noexcept(g(S(
{}
};

int main()
{
R();
}


Output of x86-64 gcc 13.2 (Compiler #1)
: In instantiation of 'R::R() [with T = int]':
:55:9:   required from here
:49:33: error: argument to '__integer_pack' must be between 0 and
268435452
   49 | R() noexcept(noexcept(g(S(
  | ^~~

This should work as -std=c++11 which uses a naive implementation of
make_index_sequence here.

I mark it as a libstdc++ bug of conformance for the case. The root cause seems
a bug of the implementation in the frontend, but I'm not that sure, because the
document of __integer_pack does not mention such cases explicitly. (The error
message here is obviously confusing, though.)

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:0d50facd937bda26e3083046dc5dec8fca47e1e6

commit r14-3825-g0d50facd937bda26e3083046dc5dec8fca47e1e6
Author: Juzhe-Zhong 
Date:   Sun Sep 10 07:57:44 2023 +0800

RISC-V: Fix dump FILE of VSETVL PASS[PR111311]

To make the dump FILE not too big, add TDF_DETAILS.

This patch fix these following FAILs in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
comparison
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl,  -O3 -g  comparison

gcc/ChangeLog:

PR target/111311
* config/riscv/riscv-vsetvl.cc (pass_vsetvl::vsetvl_fusion): Add
TDF_DETAILS.
(pass_vsetvl::pre_vsetvl): Ditto.
(pass_vsetvl::init): Ditto.
(pass_vsetvl::lazy_vsetvl): Ditto.

[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C

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

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

--- Comment #5 from Hans-Peter Nilsson  ---
(In reply to Jonathan Wakely from comment #2)
> The FAIL should be gone after r14-3812-gb96b554592c5cb

Also: thanks!

[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C

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

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

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to Jonathan Wakely from comment #2)
> The FAIL should be gone after r14-3812-gb96b554592c5cb 

Confirmed

> but the underlying
> g++ problem is latent.

So, keeping this PR open is TRT?
Should the title then change to reflect a description of the latent error?
Suggestion: "Mangling error exposed by ", but I'm unsure.

[Bug target/110960] TestSatWidenMulPairwiseAdd in the Google Highway test suite fails when compiled with GCC 12 or later with the -mcpu=power9 option

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #11 from John Platts  ---
Created attachment 55869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55869=edit
Test program to reproduce GCC 12 compilation bug

Here is the expected output of the ppc9_test_sat_add_090923.cpp test program:
Test completed successfully

The ppc9_test_sat_add_090923.cpp test program results in the following output
when compiled with GCC 12 with -O2 -mcpu=power9 -std=c++14:
Expected vector not equal to actual
Aborted (core dumped)

The ppc9_test_sat_add_090923.cpp test program does generate the expected
results when compiled with GCC 11 with the -O2 -mcpu=power9 -std=c++14 options.

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

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

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

--- Comment #7 from Jonathan Wakely  ---
And there are a number of proposals related to increasing how much of the
standard library is available for freestanding, which might eventually meet
your needs. But it would help if you stop publicly insulting the people doing
that work, complaining about their work, and generally acting like a child.

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

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

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

--- Comment #6 from Jonathan Wakely  ---
Defect reports to WG21 do not go to GCC's bugzilla though.

And it's not a defect, it's the intended design, working as intended and
approved by the committee. Just because you don't like it, doesn't make it a
defect. Changing it requires a proposal submission, not a DR.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #8 from John Soo  ---
> Also, it is typically Windows that suffers from this limitation of command 
> line length.

Ok that may be true but I am effected by this on linux as are quite a few
others in this issue https://github.com/NixOS/nixpkgs/issues/41340

[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C

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

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

--- Comment #3 from Jonathan Wakely  ---
Possibly relevant, compiling anything including  with
-Wsystem-headers -Wabi gives these warnings:

/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace: At global scope:
/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace:201:24: warning: the mangled
name of 'constexpr std::stacktrace_entry::_M_get_info(std::string*,
std::string*, int*) constoperator void (*)(void*,
std::stacktrace_entry::uintptr_t, const char*,
std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)() const'
changed between '-fabi-version=10'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE0_cvPFvS8_mSA_mmEEv')
and '-fabi-version=18'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_cvPFvS8_mSA_mmEEv')
[-Wabi]
  201 |   auto __cb2 = [](void* __data, uintptr_t, const char*
__symname,
  |^
/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace:201:24: warning: the mangled
name of 'static constexpr void std::stacktrace_entry::_M_get_info(std::string*,
std::string*, int*) const_FUN(void*,
std::stacktrace_entry::uintptr_t, const char*,
std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)' changed
between '-fabi-version=10'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENUlPvmPKcmmE0_4_FUNES8_mSA_mm')
and '-fabi-version=18'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENUlPvmPKcmmE_4_FUNES8_mSA_mm')
[-Wabi]
/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace:201:24: warning: the mangled
name of 'std::stacktrace_entry::_M_get_info(std::string*, std::string*, int*)
const::' changed
between '-fabi-version=10'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE0_clES8_mSA_mm')
and '-fabi-version=18'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_clES8_mSA_mm')
[-Wabi]

e.g. g++ -x c++ /dev/null -include stacktrace -Wsystem-headers -std=c++23
-Wabi=10
(either using GCC 13 built with --enable-libstdcxx-backtrace or using GCC trunk
before r14-3812-gb96b554592c5cb which moved the lambda out of the header into
libstdc++exp.a)

Those -Wabi warnings might be related to the "previous mangle" errors in the
modules test.

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
It's evident that there's a flaw in the standard, making it impossible to
allocate uninitialized memory for freestanding environments. That's precisely
why I reported it as a potential issue for future proposals. Unfortunately,
some individuals, including yourself, mistook my intent for trolling. The truth
is, we can't have features that rely on compiler magic to be implemented by
users; this necessitates reporting it as a Defect Report (DR) to WG21.

While std::addressof still had a workaround via __builtin_addressof, you're
currently left without such an alternative.

Perhaps it would be beneficial for the standard to introduce specialized
functions like constexpr_allocate_at and constexpr_deallocate_at, similar to
construct_at. These functions could offer a constexpr-compatible means of
allocating memory without involving allocators or operator new.


see this issue:

https://github.com/microsoft/STL/issues/4002

[Bug c++/111356] Segmentation fault when compiling large static data structure

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

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

--- Comment #2 from Andrew Pinski  ---
Works for me on the trunk.

[Bug target/110960] TestSatWidenMulPairwiseAdd in the Google Highway test suite fails when compiled with GCC 12 or later with the -mcpu=power9 option

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from John Platts  ---
Created attachment 55868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55868=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug

The ppc9_test_sat_widen_pairwise_add_090923_2b.cpp compiles successfully with
GCC 12, even if compiled with the -O2 -mcpu=power9 options.

[Bug target/110960] TestSatWidenMulPairwiseAdd in the Google Highway test suite fails when compiled with GCC 12 or later with the -mcpu=power9 option

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from John Platts  ---
Created attachment 55867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55867=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug

The attached ppc9_test_sat_widen_pairwise_add_090923_2.cpp test program
generates the following error if compiled with the -O2 -mcpu=power9 options:
Mismatch in lane 0 (ppc9_test_sat_widen_pairwise_add_090923_2.cpp:341):
Expected: -5376, -5632, -5888, -6144, -6400, -6656, -6912, -7168
Actual: -32768, -32768, -32768, -32768, -32768, -32768, -32768, -32768
Aborted (core dumped)

Here is the expected output of the
ppc9_test_sat_widen_pairwise_add_090923_2.cpp test program:
Test completed successfully

[Bug c++/111356] Segmentation fault when compiling large static data structure

[comer352l at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from comer352l at googlemail dot com ---
Created attachment 55866
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55866=edit
cpp file

[Bug c++/111356] New: Segmentation fault when compiling large static data structure

[comer352l at googlemail dot com via Gcc-bugs]

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

Bug ID: 111356
   Summary: Segmentation fault when compiling large static data
structure
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: comer352l at googlemail dot com
  Target Milestone: ---

Created attachment 55865
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55865=edit
header file

Source files attached.

gcc-Version:
13.2.1 20230803 [revision cc279d6c64562f05019e1d12d0d825f9391b5553] (SUSE
Linux)

System type:
x86-64 (openSUSE Tumbleweed)

Command line that triggers the bug:
LC_ALL=en_GB.UTF-8 g++-13 -c Definitions.cpp

Output:
"g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions."

Additional notes:
- gcc 12.3.0 works fine, so this seems to be a regression.
- bug doesn't occur when compiling with -fwrapv

[Bug driver/86030] specs file processing does not create response files for input directories

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Costas Argyris  ---
(In reply to John Soo from comment #6)
> This is not a Windows-only bug, so I don't think it is fixed.

Althought it is not mentioned explicitly in the title of this PR, the original
reporter did describe it as Windows-specific problem:

"GCC does not use response files for %D and %I handling (see do_spec_1), so if
you have a project which contrains a lot of Includes or library directories cc1
or collect2 respectively will overflow the commandline limit on Windows and
error out."

Also, it is typically Windows that suffers from this limitation of command line
length.

[Bug analyzer/96395] Generalize gcc.dg/analyzer tests to be run with both C and C++

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

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

--- Comment #7 from CVS Commits  ---
The trunk branch has been updated by Benjamin Priour :

https://gcc.gnu.org/g:50b5199cff690891726877e1c00ac53dfb7cc1c8

commit r14-3823-g50b5199cff690891726877e1c00ac53dfb7cc1c8
Author: benjamin priour 
Date:   Sat Sep 9 18:03:56 2023 +0200

analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]

Second batch of moving tests from under gcc.dg/analyzer into
c-c++-common/analyzer.

Prior to this patch the analyzer was not unwrapping ordering
binop_svalue, such as LT_EXPR, when evaluating conditions.

Therefore when an ordering conditional was stored, the analyzer
was missing out on some constraints, which led to false positives.

gcc/analyzer/ChangeLog:

PR analyzer/96395
* region-model.cc
(region_model::add_constraints_from_binop): binop_svalues around
LT_EXPR, LE_EXPR, GT_EXPR, GE_EXPR are now unwrapped.

gcc/testsuite/ChangeLog:

PR analyzer/96395
* gcc.dg/analyzer/allocation-size-1.c: Moved to...
* c-c++-common/analyzer/allocation-size-1.c: ...here.
* gcc.dg/analyzer/allocation-size-2.c: Moved to...
* c-c++-common/analyzer/allocation-size-2.c: ...here.
* gcc.dg/analyzer/allocation-size-3.c: Moved to...
* c-c++-common/analyzer/allocation-size-3.c: ...here.
* gcc.dg/analyzer/allocation-size-4.c: Moved to...
* c-c++-common/analyzer/allocation-size-4.c: ...here.
* gcc.dg/analyzer/analyzer-verbosity-0.c: Moved to...
* c-c++-common/analyzer/analyzer-verbosity-0.c: ...here.
* gcc.dg/analyzer/analyzer-verbosity-1.c: Moved to...
* c-c++-common/analyzer/analyzer-verbosity-1.c: ...here.
* gcc.dg/analyzer/analyzer-verbosity-2.c: Moved to...
* c-c++-common/analyzer/analyzer-verbosity-2.c: ...here.
* gcc.dg/analyzer/analyzer-verbosity-3.c: Moved to...
* c-c++-common/analyzer/analyzer-verbosity-3.c: ...here.
* gcc.dg/analyzer/attr-alloc_size-1.c: Moved to...
* c-c++-common/analyzer/attr-alloc_size-1.c: ...here.
* gcc.dg/analyzer/attr-alloc_size-2.c: Moved to...
* c-c++-common/analyzer/attr-alloc_size-2.c: ...here.
* gcc.dg/analyzer/call-summaries-malloc.c: Moved to...
* c-c++-common/analyzer/call-summaries-malloc.c: ...here.
* gcc.dg/analyzer/call-summaries-pr107158-2.c: Moved to...
* c-c++-common/analyzer/call-summaries-pr107158-2.c: ...here.
* gcc.dg/analyzer/capacity-1.c: Moved to...
* c-c++-common/analyzer/capacity-1.c: ...here.
* gcc.dg/analyzer/dot-output.c: Moved to...
* c-c++-common/analyzer/dot-output.c: ...here.
* gcc.dg/analyzer/escaping-1.c: Moved to...
* c-c++-common/analyzer/escaping-1.c: ...here.
* gcc.dg/analyzer/expect-1.c: Moved to...
* c-c++-common/analyzer/expect-1.c: ...here.
* gcc.dg/analyzer/fgets-1.c: Moved to...
* c-c++-common/analyzer/fgets-1.c: ...here.
* gcc.dg/analyzer/file-uninit-1.c: Moved to...
* c-c++-common/analyzer/file-uninit-1.c: ...here.
* gcc.dg/analyzer/fileno-1.c: Moved to...
* c-c++-common/analyzer/fileno-1.c: ...here.
* gcc.dg/analyzer/first-field-1.c: Moved to...
* c-c++-common/analyzer/first-field-1.c: ...here.
* gcc.dg/analyzer/first-field-2.c: Moved to...
* c-c++-common/analyzer/first-field-2.c: ...here.
* gcc.dg/analyzer/flex-with-call-summaries.c: Moved to...
* c-c++-common/analyzer/flex-with-call-summaries.c: ...here.
* gcc.dg/analyzer/flex-without-call-summaries.c: Moved to...
* c-c++-common/analyzer/flex-without-call-summaries.c: ...here.
* gcc.dg/analyzer/flexible-array-member-1.c: Moved to...
* c-c++-common/analyzer/flexible-array-member-1.c: ...here.
* gcc.dg/analyzer/fold-string-to-char.c: Moved to...
* c-c++-common/analyzer/fold-string-to-char.c: ...here.
* gcc.dg/analyzer/fread-1.c: Moved to...
* c-c++-common/analyzer/fread-1.c: ...here.
* gcc.dg/analyzer/fread-2.c: Moved to...
* c-c++-common/analyzer/fread-2.c: ...here.
* gcc.dg/analyzer/fread-pr108661.c: Moved to...
* c-c++-common/analyzer/fread-pr108661.c: ...here.
* gcc.dg/analyzer/function-ptr-1.c: Moved to...
* c-c++-common/analyzer/function-ptr-1.c: ...here.
* gcc.dg/analyzer/function-ptr-2.c: Moved to...
* c-c++-common/analyzer/function-ptr-2.c: ...here.
* gcc.dg/analyzer/function-ptr-3.c: Moved to...
* c-c++-common/analyzer/function-ptr-3.c: ...here.
* 

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

John Soo  changed:

   What|Removed |Added

 CC||john.soo+gcc-bugzilla@arist
   ||a.com

--- Comment #6 from John Soo  ---
This is not a Windows-only bug, so I don't think it is fixed.

[Bug tree-optimization/111355] [14 Regression] ICE on valid code at -O1 and above: in lower_bound, at value-range.h:1078

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Same issue as PR 111303 .

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

[Bug tree-optimization/111303] [14 Regression] ICE: in type, at value-range.h:869

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

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

[Bug tree-optimization/111303] [14 Regression] ICE: in type, at value-range.h:869

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/111355] [14 Regression] ICE on valid code at -O1 and above: in lower_bound, at value-range.h:1078

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C

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

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

--- Comment #2 from Jonathan Wakely  ---
The FAIL should be gone after r14-3812-gb96b554592c5cb but the underlying g++
problem is latent.

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #4 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #3)
> what i am talking about is uninitialized memory for later initialization
> like implementing containers for example

So then say that, don't show an expected error message about a file that is
intentionally not present in freestanding.

Not a bug, this is by design, it's how the current versions of C++ are supposed
to work, whether you like it or not.

There is already bug reports suggesting that __builtin_operator_new would be
useful (although I'm unconvinced it should be usable in freestanding, since
::operator new(size_t) isn't usable in freestanding). This PR adds nothing
useful.


> 
> From: redi at gcc dot gnu.org 

Do you really need to quote the full history when you reply?

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
what i am talking about is uninitialized memory for later initialization like
implementing containers for example


From: redi at gcc dot gnu.org 
Sent: Saturday, September 9, 2023 9:08
To: unlv...@live.com 
Subject: [Bug libstdc++/111353] bits/new_allocator.h: No such file or directory
in freestanding C++ toolchain

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

--- Comment #2 from Jonathan Wakely  ---
This is not a proper bug report. What are you reporting, that you get an error
for some code (what code? where is the testcase? where is the `gcc -v` output?)
or that you want a new feature to support something that isn't currently
supported?

Just pasting a compiler error with no context IS USELESS. Try harder, or just
stop bothering us with your terrible attempts at bug reports.

You can allocate memory in freestanding anyway, so what are you talking about?


#include 
constexpr bool f()
{
  delete new int(0);
  return true;
}
static_assert( f() );

This compiles fine with -std=c++20 -ffreestanding


Maybe you mean you can't use operator new(size_t), but you didn't say that,
because as usual your bug reports are terrible and force people to guess what
the problem is.

Try harder, or go away.

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

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

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

--- Comment #2 from Jonathan Wakely  ---
This is not a proper bug report. What are you reporting, that you get an error
for some code (what code? where is the testcase? where is the `gcc -v` output?)
or that you want a new feature to support something that isn't currently
supported?

Just pasting a compiler error with no context IS USELESS. Try harder, or just
stop bothering us with your terrible attempts at bug reports.

You can allocate memory in freestanding anyway, so what are you talking about?


#include 
constexpr bool f()
{
  delete new int(0);
  return true;
}
static_assert( f() );

This compiles fine with -std=c++20 -ffreestanding


Maybe you mean you can't use operator new(size_t), but you didn't say that,
because as usual your bug reports are terrible and force people to guess what
the problem is.

Try harder, or go away.

[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo

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

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

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

Here is a proposed interim patch.  In the meantime I'll hunt down the missing
case clause (and fix the error location for the original bug).

(Although a caveat that I'm currently still bootstrapping on:
 Linux fedora 6.2.14-300.fc38.x86_64)

[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-09-09
 Ever confirmed|0   |1

--- Comment #5 from Gaius Mulley  ---
Ah yes I think the culprit is the largest case statement inside M2SymInit.mod
(at line 1272).

[Bug libstdc++/111353] bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Jonathan Wakely  ---
https://gcc.gnu.org/bugs/

[Bug tree-optimization/111355] New: ICE on valid code at -O1 and above: in lower_bound, at value-range.h:1078

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

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

Bug ID: 111355
   Summary: ICE on valid code at -O1 and above: in lower_bound, at
value-range.h:1078
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression.

Compiler Explorer: https://godbolt.org/z/rPvxdPsE4

[519] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230909 (experimental) (GCC) 
[520] % 
[520] % gcctk -O1 -w small.c
during GIMPLE pass: ccp
small.c: In function ‘main’:
small.c:4:1: internal compiler error: in lower_bound, at value-range.h:1078
4 | }
  | ^
0xd3617e irange::lower_bound(unsigned int) const
../../gcc-trunk/gcc/value-range.h:1078
0xd3617e irange::lower_bound(unsigned int) const
../../gcc-trunk/gcc/value-range.h:1076
0x161e375 gimple_simplify_TRUNC_DIV_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*)
/local/suz-local/software/gccbuild/objdir/gcc/gimple-match-7.cc:8473
0x173a4c6 gimple_resimplify2
../../gcc-trunk/gcc/gimple-match-exports.cc:1001
0x173af60 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
../../gcc-trunk/gcc/gimple-match-exports.cc:868
0xca44fc gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
../../gcc-trunk/gcc/gimple-fold.cc:7545
0x112da22 ccp_fold
../../gcc-trunk/gcc/tree-ssa-ccp.cc:1288
0x112da22 evaluate_stmt
../../gcc-trunk/gcc/tree-ssa-ccp.cc:2225
0x112f3f5 visit_assignment
../../gcc-trunk/gcc/tree-ssa-ccp.cc:2859
0x11e2f1a ssa_propagation_engine::simulate_stmt(gimple*)
../../gcc-trunk/gcc/tree-ssa-propagate.cc:221
0x11e322a ssa_propagation_engine::simulate_block(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-propagate.cc:328
0x11e3633 ssa_propagation_engine::ssa_propagate()
../../gcc-trunk/gcc/tree-ssa-propagate.cc:478
0x1125230 do_ssa_ccp
../../gcc-trunk/gcc/tree-ssa-ccp.cc:2978
0x1125230 execute
../../gcc-trunk/gcc/tree-ssa-ccp.cc:3024
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.
[521] % 
[521] % cat small.c
int main() {
  unsigned b;
  return b ? 1 << --b / 0 : 0;
}

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

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

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

--- Comment #13 from Paul Thomas  ---
(In reply to anlauf from comment #12)
> Fixed on mainline for gcc-14.
> 
> Shall we close it?  Or does it deserve backporting?

Hi Harald,

I was considering a backport of a composite finalization patch to bring
13-branch up to the same state as trunk. Since 13.2 has been released, this, or
fairly soon, seems like a good time to do it.

I am 200% tied up in daytime work for another two weeks and will return to this
and completion of the associate work then.

Cheers

Paul

[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization

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

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

--- Comment #19 from Xi Ruoyao  ---
(In reply to chenglulu from comment #18)

> This problem has been fixed on LA664．
> I don't quite understand why this operation is still needed in !TARGET_64BIT?

It's not needed with !TARGET_64BIT.  I just meant I didn't added TARGET_64BIT
because the diff was only for a quick discussion.

[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-09

--- Comment #7 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #6)
> (In reply to Iain Sandoe from comment #5)
> > (In reply to Iain Sandoe from comment #4)
> > > (In reply to Francois-Xavier Coudert from comment #3)
> > > > Clang: 14.0.0 build 1400
> > > > CLT: 14.2.0.0.1.1668646533

> maybe something like this (untested because 15b7 is only supported on
> macOS13 and my avx512 box has an earlier install)
> 
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index 0ea8bcb24e1..2d74f62e887 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -9776,6 +9776,7 @@ proc check_effective_target_avx512fp16 { } {
> void foo (void)
> {
>   asm volatile ("vmovw %edi, %xmm0");
> + asm volatile ("vfcmulcph %xmm1, %xmm2, %xmm3");
> }
>  } "-O2 -mavx512fp16" ]
>  }

hmm not enough it needs:
+ asm volatile ("vfcmulcph %xmm1, %xmm2, %xmm3{%k1}");
to fail on XC14 and pass on XC15

[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21

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

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > (In reply to Francois-Xavier Coudert from comment #3)
> > > Clang: 14.0.0 build 1400
> > > CLT: 14.2.0.0.1.1668646533
> > 
> > ah, it seems the vfcmulcph insn, at least, is not supported before XC14, and
> > it gives the error at 14.0b3 and 14.3.  It seems fixed at XC 15b7.
> 
> perhaps we can add something to the "avx512fp16" target test that requires
> assembly of one of those insns so that the tests will be automatically
> unsupported for broken assemblers.

maybe something like this (untested because 15b7 is only supported on macOS13
and my avx512 box has an earlier install)

diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 0ea8bcb24e1..2d74f62e887 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -9776,6 +9776,7 @@ proc check_effective_target_avx512fp16 { } {
void foo (void)
{
  asm volatile ("vmovw %edi, %xmm0");
+ asm volatile ("vfcmulcph %xmm1, %xmm2, %xmm3");
}
 } "-O2 -mavx512fp16" ]
 }

[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #18 from chenglulu  ---
(In reply to Xi Ruoyao from comment #17)
> I think the proper description should be:
> 
> diff --git a/gcc/config/loongarch/loongarch.md
> b/gcc/config/loongarch/loongarch.md
> index 75f641b38ee..000d17b0ba6 100644
> --- a/gcc/config/loongarch/loongarch.md
> +++ b/gcc/config/loongarch/loongarch.md
> @@ -64,6 +64,8 @@ (define_c_enum "unspec" [
>UNSPEC_CRC
>UNSPEC_CRCC
>  
> +  UNSPEC_DIV_W_OPERAND
> +
>UNSPEC_LOAD_FROM_GOT
>UNSPEC_PCALAU12I
>UNSPEC_ORI_L_LO12
> @@ -892,7 +894,7 @@ (define_expand "3"
>  emit_insn (gen_rtx_SET (reg1, operands[1]));
>  emit_insn (gen_rtx_SET (reg2, operands[2]));
>  
> -emit_insn (gen_di3_fake (rd, reg1, reg2));
> +emit_insn (gen_si3_extended (rd, reg1, reg2));
>  emit_insn (gen_rtx_SET (operands[0],
>   simplify_gen_subreg (SImode, rd, DImode, 0)));
>  DONE;
> @@ -915,11 +917,14 @@ (define_insn "*3"
>   (const_string "yes")
>   (const_string "no")))])
>  
> -(define_insn "di3_fake"
> +(define_insn "si3_extended"
>[(set (match_operand:DI 0 "register_operand" "=r,,")
>   (sign_extend:DI
> -   (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> -   (match_operand:DI 2 "register_operand" "r,r,r"]
> +   (any_div:SI
> + (unspec:SI [(match_operand:DI 1 "register_operand" "r,r,0")]
> +UNSPEC_DIV_W_OPERAND)
> + (unspec:SI [(match_operand:DI 2 "register_operand" "r,r,r")]
> +UNSPEC_DIV_W_OPERAND]
>""
>  {
>return loongarch_output_division (".w\t%0,%1,%2", operands);
> 
> i. e. we define "UNSPEC_DIV_W_OPERAND" as a "machine-specific operation": if
> the input is a sign-extended 32-bit value, the operation extracts the low
> 32-bit; otherwise, it produces random junks.
> 
> Note that the behavior actually depends on the values of operand[1] and
> operands[2], not the result of operand[1] / operand[2].  So we should put
> unspec inside any_div, not outside.
> 
> (I've not included the TARGET_64BIT change here, it should be done anyway.)
> 
> BTW is LA664 improved to handle non-properly-extended inputs with div.w?

This problem has been fixed on LA664．
I don't quite understand why this operation is still needed in !TARGET_64BIT?

[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization

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

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

--- Comment #17 from Xi Ruoyao  ---
I think the proper description should be:

diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..000d17b0ba6 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -64,6 +64,8 @@ (define_c_enum "unspec" [
   UNSPEC_CRC
   UNSPEC_CRCC

+  UNSPEC_DIV_W_OPERAND
+
   UNSPEC_LOAD_FROM_GOT
   UNSPEC_PCALAU12I
   UNSPEC_ORI_L_LO12
@@ -892,7 +894,7 @@ (define_expand "3"
 emit_insn (gen_rtx_SET (reg1, operands[1]));
 emit_insn (gen_rtx_SET (reg2, operands[2]));

-emit_insn (gen_di3_fake (rd, reg1, reg2));
+emit_insn (gen_si3_extended (rd, reg1, reg2));
 emit_insn (gen_rtx_SET (operands[0],
simplify_gen_subreg (SImode, rd, DImode, 0)));
 DONE;
@@ -915,11 +917,14 @@ (define_insn "*3"
(const_string "yes")
(const_string "no")))])

-(define_insn "di3_fake"
+(define_insn "si3_extended"
   [(set (match_operand:DI 0 "register_operand" "=r,,")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
+ (any_div:SI
+   (unspec:SI [(match_operand:DI 1 "register_operand" "r,r,0")]
+  UNSPEC_DIV_W_OPERAND)
+   (unspec:SI [(match_operand:DI 2 "register_operand" "r,r,r")]
+  UNSPEC_DIV_W_OPERAND]
   ""
 {
   return loongarch_output_division (".w\t%0,%1,%2", operands);

i. e. we define "UNSPEC_DIV_W_OPERAND" as a "machine-specific operation": if
the input is a sign-extended 32-bit value, the operation extracts the low
32-bit; otherwise, it produces random junks.

Note that the behavior actually depends on the values of operand[1] and
operands[2], not the result of operand[1] / operand[2].  So we should put
unspec inside any_div, not outside.

(I've not included the TARGET_64BIT change here, it should be done anyway.)

BTW is LA664 improved to handle non-properly-extended inputs with div.w?

[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #16 from chenglulu  ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to chenglulu from comment #13)
> > (In reply to Xi Ruoyao from comment #12)
> > > (In reply to chenglulu from comment #11)
> > > > (In reply to Xi Ruoyao from comment #10)
> > > > > (In reply to Xi Ruoyao from comment #9)
> > > > > 
> > > > > >  (define_insn "di3_fake"
> > > > > >[(set (match_operand:DI 0 "register_operand" "=r,,")
> > > > > > -   (sign_extend:DI
> > > > > > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > > - (match_operand:DI 2 "register_operand" 
> > > > > > "r,r,r"]
> > > > > > -  ""
> > > > > > +   (if_then_else
> > > > > > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > > +  (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > > > > +  (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > > > > +  (sign_extend:DI (subreg:SI (match_dup 2) 0
> > > > > > + (sign_extend:DI
> > > > > > +   (any_div:SI (subreg:SI (match_dup 1) 0)
> > > > > > +   (subreg:SI (match_dup 2) 0)))
> > > > > > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> > > > > 
> > > > > With this the compiler will still believe all bad {div,mod}.w{,u}
> > > > 
> > > > I think this is already defined as UNSPEC. Isn’t the simpler the logic, 
> > > > the
> > > > better?
> > > 
> > > Yes, I think we should just use 4 different UNSPEC_ values and the simple
> > > version.  But I've not find a way to use 4 different UNSPEC_ values in the
> > > RTL template except duplicating everything 4 times...
> > 
> > I still have a question that I don't quite understand, that is, why that the
> > four generated strings are equivalent when using an UNSPEC name? My template
> > names are different, and they will not be automatically matched during
> > optimization.???
> 
> Oh I get it, you mean
> 
>  (define_insn "di3_fake"
>[(set (match_operand:DI 0 "register_operand" "=r,,")
>   (sign_extend:DI
> -   (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> -   (match_operand:DI 2 "register_operand" "r,r,r"]
> +   (unspec:DI [(any_div:DI
> + (match_operand:DI 1 "register_operand" "r,r,0")
> + (match_operand:DI 2 "register_operand" "r,r,r"))]
> +  UNSPEC_ANY_DIV)))]
>""
>  {
>return loongarch_output_division (".w\t%0,%1,%2", operands);
> 
> Good idea! I think it's better than my stupid hacks :).
> 
> I'd been thinking about:
> 
>  (define_insn "di3_fake"
>[(set (match_operand:DI 0 "register_operand" "=r,,")
>   (sign_extend:DI
> -   (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> -   (match_operand:DI 2 "register_operand" "r,r,r"]
> +   (unspec:DI [(match_operand:DI 1 "register_operand" "r,r,0")
> +   (match_operand:DI 2 "register_operand" "r,r,r")]
> +  UNSPEC_ANY_DIV)))]
>""
>  {
>return loongarch_output_division (".w\t%0,%1,%2", operands);
> 
> and this is just wrong.

Is it better to modify it this way?

--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -60,6 +60,7 @@ (define_c_enum "unspec" [
   ;; Stack tie
   UNSPEC_TIE

+  UNSPEC_ANY_DIV
   ;; CRC
   UNSPEC_CRC
   UNSPEC_CRCC
@@ -900,7 +901,7 @@ (define_expand "3"
 (match_operand:GPR 2 "register_operand")))]
   ""
 {
- if (GET_MODE (operands[0]) == SImode)
+ if (GET_MODE (operands[0]) == SImode && TARGET_64BIT)
   {
 rtx reg1 = gen_reg_rtx (DImode);
 rtx reg2 = gen_reg_rtx (DImode);
@@ -938,9 +939,12 @@ (define_insn "*3"
 (define_insn "di3_fake"
   [(set (match_operand:DI 0 "register_operand" "=r,,")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
-  ""
+ (unspec:SI
+  [(subreg:SI
+(any_div:DI (match_operand:DI 1 "register_operand" "r,r,0")
+(match_operand:DI 2 "register_operand" "r,r,r")) 0)]
+ UNSPEC_ANY_DIV)))]
+  "TARGET_64BIT"
 {
   return loongarch_output_division (".w\t%0,%1,%2", operands);

[Bug target/111354] [7/10/12 regression] The instructions of the DPDK demo program are different and run time increases.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #3 from d_vampile  ---
(In reply to Andrew Pinski from comment #1)
> First off the performance is difference is die to micro-arch issues with
> unaligned stores of 256 bits. 
> 
> Also iirc rte_mov128blocks is tuned at copying blocks which are aligned at
> least to 32 bytes wide. But you are better asking the dpdk forum why they
> don't just use memcpy here.

The instruction 'movdqu' do not require the memory address to be aligned on a
natural vector-length byte boundary. Why does rte_mov128blocks need to be
aligened at 32 bytes wide? 

The test platform is Xeon.