https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #18 from Khem Raj ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Khem Raj from comment #15)
> > My problem was that I made the version to be 15.1.0
>
> How?
in yocto, we copy the tools/symlinks into locations manua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #17 from Sam James ---
(In reply to Khem Raj from comment #15)
I don't think this is really the same problem. It can easily happen if you e.g.
build gcc 15 with newer binutils then downgrade (with any sort of gymnastics
in-between).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #16 from Andrew Pinski ---
(In reply to Khem Raj from comment #15)
> My problem was that I made the version to be 15.1.0
How?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
Khem Raj changed:
What|Removed |Added
CC||raj.khem at gmail dot com
--- Comment #15 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
Sam James changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #13 from David Binderman ---
(In reply to Sam James from comment #12)
> Please include the .s file referenced, config.log for the corresponding GCC,
> and `as --version`.
Problem seems to have gone away:
~ $ vi cq.cc
~ $ for i in /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #11 from David Binderman ---
(In reply to Andreas Schwab from comment #10)
> Can you provide an example of the evidence?
Sure. For this C++ source code:
void s61() { static char extra_special_characters[] = "\n\t\b\r\f\\\'"; }
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #10 from Andreas Schwab ---
Can you provide an example of the evidence?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #7 from David Binderman ---
Created attachment 59485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59485&action=edit
log file from config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #8 from David Binderman ---
gcc $ grep BASE auto-host.h
#define HAVE_DECL_BASENAME 1
/* #undef HAVE_GAS_BASE64 */
/* #undef HAVE_LD_PE_DISABLE_DYNAMICBASE */
gcc $
So either I get a different gas when I compile gcc with clang,
or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #4 from Andrew Pinski ---
We need the config.log from the gcc subdirectory not the one from the toplevel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #6 from Andreas Schwab ---
c) you have downgraded binutils after building gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #5 from Jakub Jelinek ---
Combined build is when you build gcc together with binutils (and often other
modules like gmp, mpfr, libmpc, etc.) by unpacking those into the same tree.
The toplevel configure indeed doesn't check for .base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #3 from David Binderman ---
No mention of base64 in the config.log:
working.2 $ grep base64 config.log
working.2 $
What's a combined build ?
My usual configure line is:
CC="clang" CXX="clang++" \
../trunk/configure --prefix=$HO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #2 from Andrew Pinski ---
For me it has:
```
configure:25857: checking assembler for .base64
configure:25867: /usr/bin/as --64 -o conftest.o conftest.s >&5
conftest.s: Assembler messages:
conftest.s:2: Error: unknown pseudo-op: `.ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
18 matches
Mail list logo
