Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: peshkoff at mail dot ru
Target Milestone: ---
Created attachment 50701
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50701&action=ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100317
Alex Peshkoff changed:
What|Removed |Added
Known to work||10.2.0
--- Comment #2 from Alex Peshkof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240
Peter Taraba changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
Peter Taraba changed:
What|Removed |Added
CC||taraba.peter at mail dot com
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at 3v1n0 dot net
Target Milestone: ---
Unfortunately I've not a minimal test case for this, but in gjs we can't use
pre-compiled headers with g++ (while they work fine with clang++).
In particular, we get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #1 from Marco Trevisan ---
Some verbose logging:
unstable /data/GNOME/gjs
❯ echo $PWD
/data/GNOME/gjs
unstable /data/GNOME/gjs
❯ ls _build/libgjs.so.0.0.0.p -lht
total 119M
-rw-rw-r-- 1 m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #3 from Marco Trevisan ---
Created attachment 50775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50775&action=edit
strace.log
This is crazy, as even according to strace the file isn't there...
But it is and it's valid.
❯ ls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #4 from Marco Trevisan ---
(In reply to Marco Trevisan from comment #3)
> Created attachment 50775 [details]
> strace.log
>
> This is crazy, as even according to strace the file isn't there...
>
> But it is and it's valid.
> ❯ ls -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #6 from Marco Trevisan ---
(In reply to Jakub Jelinek from comment #5)
> As documented - see
> https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html - PCH is only
> tried if no C token is seen before the #include directive (com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #7 from Marco Trevisan ---
(In reply to Marco Trevisan from comment #6)
> # Works
> g++ -I _build main.c -o main -include string -include gjs_pch.h
Ouch, I forgot to delete an include after pasting
# Works
g++ -I _build main.c -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #8 from Marco Trevisan ---
It's also relevant to say that just using
main.c:
#include "gjs_pch.h"
int main(int argc, char**argv)
{
std::string s = "Hi";
return 0;
}
fails with:
❯ g++ -I _build main.c -o main -include string
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following test case:
#include
#include
class Container
{
public:
typedef unsigned char value_type;
typedef value_type* pointer;
typedef std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Marco Trevisan changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #12 from Marco Trevisan ---
Well, I see...
At least the error should be a bit clearer though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
andysem at mail dot ru changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #3 from andysem at mail dot ru ---
To put it another way, the case of _size being large and n small is valid, and
memset (and resize in general) do behave correctly in this case. Which is why
the warning is bogus and the suggested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #5 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #4)
> The case of _size being very large and n very small may be handled correctly
> by the original code thanks to the check for _capacity but becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #7 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #6)
> In C/C++ the size of the largest object is PTRDIFF_MAX - 1 bytes. This is
> necessary so that the difference between the address of its first by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #9 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #8)
>
> Submitting a bug for the LTO problem is only helpful if it comes with a test
> case to reproduce it. I have heard about problems suppressing
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fsmoke at mail dot ru
Target Milestone: ---
I set -isystem /usr/local/include/qt5/ to suppress Qt library internal warnings
- all warnings are successfully suppressed except
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mail at milianw dot de
Target Milestone: ---
Hey there,
in a large code base I'm working on I stumbled over code in one area that
basically did the below, but in a more elaborate manner. It would have been
quite helpful to get a warning
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: egor_suvorov at mail dot ru
Target Milestone: ---
The following snippet, when compiled with `g++ -std=c++20`:
template
struct LiteralResolver {
constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100764
--- Comment #1 from Egor Suvorov ---
UPD: compiling with `g++ -v -std=c++20` on Godbolt's GCC 11.1 yields the
following information about versions:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-11.1.0/bin/g++
Target: x86_64-linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc d
: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamsupermouse at mail dot ru
Target Milestone: ---
This doesn't compile, but it should:
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following code:
#include
__m256i load_00FF()
{
__m256i mm = _mm256_setzero_si256();
return _mm256_srli_epi16(_mm256_cmpeq_epi64(mm, mm), 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
--- Comment #6 from andysem at mail dot ru ---
(In reply to Andrew Pinski from comment #1)
> >and gcc 12 generates a worse code:
>
> it is not worse really; depending on the how fast moving between the
> register sets is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
--- Comment #7 from andysem at mail dot ru ---
To be clear, I'm not asking the compiler to recognize the particular pattern of
alternating 0x00 and 0xFF bytes. Because hardcoding this particular pattern
won't improve generated cod
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: egor_suvorov at mail dot ru
Target Milestone: ---
May or may not be a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106119
Consider the following code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476
Maciej S. Szmigiero changed:
What|Removed |Added
CC||mail at maciej dot
szmigiero.name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476
--- Comment #11 from Maciej S. Szmigiero ---
(In reply to Andrew Pinski from comment #9)
> Does these two functions the same name then?
> ```
> namespace a {
>extern "C" void f(void);
> }
>
> namespace {
> extern "C" void f(void) {}
> }
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476
--- Comment #14 from Maciej S. Szmigiero ---
> This is not so useful in practice because most compilers don't make extern
> "C" and extern "C++" differentiate function types (implying calling
> conventions etc.).
The standard allows different
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: archicharmer at mail dot ru
Target Milestone: ---
I am currently using gcc-9.2.0 . At it's last building stage it was compiled
using the next configure additions:
--prefix=$PREFIX --enable-language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
Konstantin changed:
What|Removed |Added
CC||sks_f at mail dot ru
--- Comment #17 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871
Konstantin changed:
What|Removed |Added
CC||sks_f at mail dot ru
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104984
--- Comment #1 from Den ---
No one?.. Then, let's discourse.
These are inside the file t-hardfp-sfdf :
hardfp_float_modes := sf df
hardfp_int_modes := si
hardfp_extensions := sfdf
hardfp_truncations := dfsf
and these are inside the file t-soft
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104984
Den changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88165
--- Comment #13 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Fedor Chelnokov from comment #7)
> > This struct definition:
> > ```
> > struct A {
> > struc
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 364961 at mail dot ru
Target Milestone: ---
Created attachment 52884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52884&action=edit
the preprocessed bug's source fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105393
Laryushin Aleksandr <364961 at mail dot ru> changed:
What|Removed |Added
Resolution|INVALID |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105393
Laryushin Aleksandr <364961 at mail dot ru> changed:
What|Removed |Added
Resolution|INVALID |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105393
--- Comment #3 from Laryushin Aleksandr <364961 at mail dot ru> ---
Sorry, this is my first bug report.
>Среда, 27 апреля 2022, 9:54 +03:00 от jakub at gcc dot gnu.org
>:
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10539
: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamsupermouse at mail dot ru
Target Milestone: ---
Since C++20, `std::iterator_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676
--- Comment #1 from Egor ---
I was told this is a wording defect. The `cpp17-forward-iterator`
exposition-only concept in https://eel.is/c++draft/iterator.traits only permits
lvalue references.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 53528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53528&action=edit
Prepr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #3 from andysem at mail dot ru ---
I don't have the environment to build gcc locally, so I can't readily test
trunk. But I have been told the same issue reproduces with gcc-12
20220319-1ubuntu1 from Ubuntu 22.04:
https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #4 from andysem at mail dot ru ---
It fails the same way with 12.2 and trunk on godbolt:
https://gcc.godbolt.org/z/rT6TWhhvP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #6 from andysem at mail dot ru ---
So do you think this is a problem in Boost.Filesystem?
I would say this is a regression in string_view as the code is valid in
pre-C++23, and I would expect it to stay valid in C++23 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #8 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to andysem from comment #6)
> > So do you think this is a problem in Boost.Filesystem?
>
> I don't know yet, I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #10 from andysem at mail dot ru ---
(In reply to andysem from comment #8)
> (In reply to Jonathan Wakely from comment #7)
> >
> > Do you want ODR violations? Because that's how you get ODR violations.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
--- Comment #6 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to andysem from comment #3)
> > Is there no way to improve standard components implementation? I'd imagine
> > you c
: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamsupermouse at mail dot ru
Target Milestone: ---
GCC rejects this code:
template
struct A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107111
Egor changed:
What|Removed |Added
CC||iamsupermouse at mail dot ru
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107113
Egor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107111
--- Comment #4 from Egor ---
*** Bug 107113 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821
Marco Trevisan changed:
What|Removed |Added
CC||mail at 3v1n0 dot net
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821
--- Comment #10 from Marco Trevisan ---
I see the point, but then I also think that gcc-10 should not support
`--std=c++20` option but rather only the `--std=c++2a` one.
tatus: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamsupermouse at mail dot ru
Target Milestone: ---
Following code causes an ICE (segfault):
template struct A {};
int main()
NCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamsupermouse at mail dot ru
Target Milestone: ---
Following code compiles with -std=c++20 and earlier, but fails with -std=c++2b,
in both GCC
, not to function pointer
itself
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: safinaskar at mail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008
Aleksei Latyshev changed:
What|Removed |Added
CC||alex_700_95 at mail dot ru
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: armenchik at mail dot ru
Target Milestone: ---
template
constexpr bool has_char_static_param(int)
{ return true; }
template
constexpr bool has_char_static_param(...)
{ return
y: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
Target Milestone: ---
Starting with GCC 11, we don't see any warnings about extra semicolons anymore:
```
struct foo{};;
```
Compile:
```
g++ -Wall -Wpedantic -Wextra test.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103131
--- Comment #1 from Milian Wolff ---
correction: gcc version 10 and below used to complain
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: egor_suvorov at mail dot ru
Target Milestone: ---
Here is an issue that one of my students encountered today:
https://stackoverflow.com/questions/70069809/unrecognized-emulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103362
--- Comment #2 from Egor Suvorov ---
Thank you very much, sent a report there:
https://sourceware.org/bugzilla/show_bug.cgi?id=28619
Assignee: unassigned at gcc dot gnu.org
Reporter: zloten at mail dot ru
Target Milestone: ---
assert('Z' == 0x5A);
assert('Ы' == 0xD0AB);
assert('闩' == 0x00E997A9);
assert('𠂡' == 0xF0A082A1);
assert(U'Z' == 0x5A);
assert(U&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #1 from Zloten ---
56481 = 0xDCA1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #3 from Zloten ---
No. Just - O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #5 from Zloten ---
I use the latest MinGW, target-host are Windows, x86-64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #7 from Zloten ---
It's very very strange. I've tested GCC 11.2.0(x86-64) and MinGW(x86-64). Both
have the same problem.
Let's do not use L suffix (it's implementation-defined).
Let's use u suffix.
For both:
int test() {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #8 from Zloten ---
Sorry for my late reply
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: riad93 at mail dot ru
Target Milestone: ---
So, currently __stable_sort is implemented this way:
if (__buf.begin() == 0)
std::__inplace_stable_sort(__first
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Created attachment 51443
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51443&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #1 from andysem at mail dot ru ---
I forgot to mention that the same code compiles successfully with gcc 9.4.0.
And here is the output from gcc 11.1.0:
In file included from ./boost/assert.hpp:58,
from
./boost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #2 from andysem at mail dot ru ---
The code compiles if -std=c++03 is replaced with e.g. -std=c++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #4 from andysem at mail dot ru ---
(In reply to Martin Liška from comment #3)
> Dup.
>
> *** This bug has been marked as a duplicate of bug 100161 ***
This bug isn't about a warning but about an ICE. Are you posi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #6 from andysem at mail dot ru ---
Ok, thanks for confirming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98677
--- Comment #4 from Egor Suvorov ---
Note that the issue requires both UBSanitizer and Valgrind enabled
simultaneously. Running with just one of them does not result in an error.
The versions are ones installed in Ubuntu 20.04.3 Focal Fossa (amd
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102984
--- Comment #2 from Milian Wolff ---
Similarly:
std::vector locks(10); // works
std::vector locks(10, spinlock()); // doesn't work
This report here was motivated by stumbling over this report over at
https://github.com/efficient/libcuckoo/issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102984
Milian Wolff changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mhbalsmeier at mail dot de
Target Milestone: ---
Created attachment 53816
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53816&action=edit
source file
Hi
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nik_1357 at mail dot ru
Target Milestone: ---
Hello.
Test which causes the bug:
#include
#define ELEMS 0x4000
int a[ELEMS];
int b[ELEMS];
int main() {
memcpy(a, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554
--- Comment #1 from Nikita Voronov ---
I debugged a little and found out that this bug is caused when size of object
which has type of "long int" is being assigned to local variable of type "int".
Here's patch which fixed bug for me:
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554
--- Comment #2 from Nikita Voronov ---
Seems like I attached call stack from previous release version.
Here's from master:
0xf0ad0f crash_signal
../../../gcc/gcc-master/gcc/toplev.cc:314
0x7f6b9445d51f ???
./signal/../sysdeps/uni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64234
--- Comment #8 from lo1ol ---
https://www.youtube.com/watch?v=Ua3TiOSwVTI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Milian Wolff changed:
What|Removed |Added
CC||mail at milianw dot de
--- Comment #69
++
Assignee: unassigned at gcc dot gnu.org
Reporter: eiband at mail dot de
Target Milestone: ---
The following program exits with code 1.
test.cpp:
struct a
{
using get = void;
};
struct b : a
{
int get(int i) const;
};
template
concept c = requires { typename T::get
IRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: avo2000 at mail dot ru
Target Milestone: ---
Incorrect generation of the function's epilogue code when there is a
_builtin_alloca call. The stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841
--- Comment #2 from Alexander ---
Source code:
void qq(int a) {
char *s = alloca(128);
sprintf(s,"qq %d",3);
}
Generated code:
040c <_qq>:
40c: 1166mov r5, -(sp)
40e: 1185mov s
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: alexei1.84 at mail dot ru
Target Milestone: ---
Created attachment 54129
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54129&action=edit
configure and make l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186
--- Comment #3 from AlexK ---
(In reply to Andrew Pinski from comment #2)
> Does this comparison failure happen if you set LANG environment variable to
> C before doing a bootstrap?
> If it please let us know which your environment variables so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186
--- Comment #4 from AlexK ---
Created attachment 54140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54140&action=edit
--without-build-config: => zstd link error
zstd link error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186
--- Comment #5 from AlexK ---
(In reply to Richard Biener from comment #1)
> can you try configuring with --without-build-config please?
first small error - zstd link
I will change Makefile in gcc
see mylog.tar.gz attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186
--- Comment #6 from AlexK ---
(In reply to Richard Biener from comment #1)
> can you try configuring with --without-build-config please?
/mnt/Git/apt-build/build/gcc-12.2.0/build $
../configure --prefix=/tools/gcc-12.2.0 --without-build-conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186
--- Comment #7 from AlexK ---
(In reply to Richard Biener from comment #1)
> can you try configuring with --without-build-config please?
I changed gcc/Makefile by
sed -i 's/^ZSTD_LIB[ ]*=.*$/ZSTD_LIB = -lzstd/' gcc/Makefile
and continued
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186
--- Comment #8 from AlexK ---
(In reply to Richard Biener from comment #1)
> can you try configuring with --without-build-config please?
make[2]: вход в каталог «/mnt/Git/apt-build/build/gcc-12.2.0/build/c++tools»
/mnt/Git/apt-build/build/gcc-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186
--- Comment #9 from AlexK ---
(In reply to Richard Biener from comment #1)
> can you try configuring with --without-build-config please?
that was my influence - I have compiled binutils with shared intl
continue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186
--- Comment #10 from AlexK ---
(In reply to Richard Biener from comment #1)
> can you try configuring with --without-build-config please?
now there are 2 problems in libgo
links
1) no ../libbacktrace/libbacktrace.la
I had to change it to ../../
801 - 900 of 1049 matches
Mail list logo
