Hi Jonathan,
Thanks for the suggestion, it seems promising. I switched out the
error attribute for the warning attribute at first, since they should
be equivalent except warning just warns instead of erroring. This
results in the link step failing if LTO is enabled for some reason
though. I then c
On Mon, 14 Apr 2025 at 14:47, Julian Waters wrote:
>
> Hi Jonathan,
>
> Thanks for the suggestion, it seems promising. I switched out the
> error attribute for the warning attribute at first, since they should
> be equivalent except warning just warns instead of erroring. This
> results in the lin
On Mon, 14 Apr 2025 at 11:53, Julian Waters wrote:
>
> Hi Jonathan,
>
> Yep, unfortunately #pragma GCC poison is far too restrictive, it
> doesn't check if it is a function call to that particular banned
> function, it restricts any and all use of that identifier in the code
> altogether. Not only
On Mon, 14 Apr 2025 at 12:57, Jonathan Wakely wrote:
>
> On Mon, 14 Apr 2025 at 11:53, Julian Waters wrote:
> >
> > Hi Jonathan,
> >
> > Yep, unfortunately #pragma GCC poison is far too restrictive, it
> > doesn't check if it is a function call to that particular banned
> > function, it restricts
ng the whole process.
>
> It would be nice to have compiler support to help with this.
I would recommend writing your GCC plugin which would add some problem specific
pragmas.
Some code from https://github.com/bstarynk/bismon might be improved (by you or
your colleagues/interns) to fit into lat
nctions. The crucial thing is that this mechanism must have a
> > disable switch for when a callsite must actually call a forbidden
> > function, complicating the whole process.
> >
> > It would be nice to have compiler support to help with this. Something like:
> >
>
callsite must actually call a forbidden
> function, complicating the whole process.
>
> It would be nice to have compiler support to help with this. Something like:
>
> #pragma GCC forbidden void *malloc(size_t) // Forbids malloc from
> being called anywhere
Have you looked at
ement that.
The problem is there's really no way at all to forbid standard library
functions. The crucial thing is that this mechanism must have a
disable switch for when a callsite must actually call a forbidden
function, complicating the whole process.
It would be nice to have compiler
o test the Arm
cross compiler? Are there any documents?
These days I'd be QEMU is the best approach if you don't have hardware.
Not sure if there's any reasonable documentation on it. The embecosm
folks might have suitable docs on their web page along with the dejagnu
configurat
To my surprise, I have just found out that Arm simulator has been
deprecated:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aec7815b4b78d4dcd2261f1dab1092dbf4a9e0be.
Taking that into account what is the "official" way to test the Arm
cross compiler? Are there any documents?
/J.D.
Hello,
we are delighted you found contributing to GCC interesting.
On Tue, Nov 19 2024, Vaibhav Arora via Gcc wrote:
> Dear GNU Compiler Collection Team,
>
> I hope this email finds you well. My name is Vaibhav Arora, and I am an
> enthusiastic software developer with a strong
Dear GNU Compiler Collection Team,
I hope this email finds you well. My name is Vaibhav Arora, and I am an
enthusiastic software developer with a strong interest in contributing to
open-source projects. I am writing to express my keen interest in GNU
Compiler Collection, and to seek your
I am currently studying assembly language by kip Irvine and have ordered
Sam R teah yourself C++ in 24 hours..
My route will include the most updated Java edition afterwards.
I also need to update my computer, whoh is no longer supported, which
computer should I get to accommodate your compiler
2024 um 17:11 schrieb Matthias Kretz via Gcc :
> > > >
> > > > Hi,
> > > >
> > > > the unit tests are my long-standing pain point of
> > > > excessive compiler memory usage and compile times. I've always worked
> > > > around
> >
2024 um 17:11 schrieb Matthias Kretz via Gcc :
> > > >
> > > > Hi,
> > > >
> > > > the unit tests are my long-standing pain point of
> > > > excessive compiler memory usage and compile times. I've always worked
> > > > around
> >
On Wed, Oct 2, 2024 at 9:13 AM Richard Biener
wrote:
>
> On Tue, Oct 1, 2024 at 6:06 PM Richard Biener
> wrote:
> >
> >
> >
> > > Am 01.10.2024 um 17:11 schrieb Matthias Kretz via Gcc :
> > >
> > > Hi,
> > >
> > > the
Ben Boeckel via Gcc writes:
> On Tue, Oct 01, 2024 at 18:06:35 +0200, Richard Biener via Gcc wrote:
>> Analyze where the compile time is spent and where memory is spent.
>> Identify unfitting data structures and algorithms causing the issue.
>> Replace with better ones. That’s what I do for thes
On Tue, Oct 1, 2024 at 6:06 PM Richard Biener
wrote:
>
>
>
> > Am 01.10.2024 um 17:11 schrieb Matthias Kretz via Gcc :
> >
> > Hi,
> >
> > the unit tests are my long-standing pain point of
> > excessive compiler memory usage and compile times. I
On Tue, Oct 01, 2024 at 18:06:35 +0200, Richard Biener via Gcc wrote:
> Analyze where the compile time is spent and where memory is spent.
> Identify unfitting data structures and algorithms causing the issue.
> Replace with better ones. That’s what I do for these kind of issues
> in the middle en
> Am 01.10.2024 um 17:11 schrieb Matthias Kretz via Gcc :
>
> Hi,
>
> the unit tests are my long-standing pain point of
> excessive compiler memory usage and compile times. I've always worked around
> the memory usage problem by splitting the test matrix into mul
Hi,
the unit tests are my long-standing pain point of
excessive compiler memory usage and compile times. I've always worked around
the memory usage problem by splitting the test matrix into multiple
translations (with different -D flags) of the same source file. I.e. pay with
a huge n
Am 27.09.2024 um 13:00 schrieb Richard Earnshaw (lists):
> It was very common at that time for suppliers to use slightly modified gcc
sources for microcontrollers (especially ARM, but also for other targets).
Typically manufacturers and some major third-party gcc builders were ahead of
mainli
Am 27.09.2024 um 11:03 schrieb David Brown:
So there is a very real chance that the sources you have are not original.
You could download the archived release from the gcc website and compare
the sources to get some idea if they have changed.
i do not have original source - only binaries, i ho
> but that usage should be visible by using -v on the original build, or?
>>> >
>>>
>>> I think so yes, but I'm not sure. If you said arm-elf in the mail Subject
>>> you might get the attention of somebody who knows the details.
>>
>> so jus
t; but that usage should be visible by using -v on the original build, or?
>
I think so yes, but I'm not sure. If you said arm-elf in the mail Subject
you might get the attention of somebody who knows the details.
so just repost with a changed subject?
Have you tried to obtain the so
gcc-help@ list where questions like this belong.
ARM maintainers will probably see it anyway.
I've CC'd one of the ARM maintainers now too.
Richard, can you answer the question from the first mail in the
thread, regarding arm multilibs? (This is for gcc 3.4.0!)
Can the original m
ginal build, or?
>
I think so yes, but I'm not sure. If you said arm-elf in the mail Subject
you might get the attention of somebody who knows the details.
so just repost with a changed subject?
Have you tried to obtain the sources from whoever provided the original
compiler that you
7;m not sure. If you said arm-elf in the mail Subject
you might get the attention of somebody who knows the details.
Have you tried to obtain the sources from whoever provided the original
compiler that you're trying to replicate?
content of my gcc-3.4.0\gcc\config\arm\t-arm-elf
https://pastebin.com/CivYHhRa
Am 27.09.2024 um 09:23 schrieb Dennis Luehring via Gcc:
im currently trying to replicate a gcc-3.4.0 arm-elf build from an very
old cross toolchain
building with my script (https://pastebin.com/kAEK0S24) works
but my
On Fri, 27 Sept 2024, 08:24 Dennis Luehring via Gcc,
wrote:
> im currently trying to replicate a gcc-3.4.0 arm-elf build from an very
> old cross toolchain
> building with my script (https://pastebin.com/kAEK0S24) works
> but my -print-multi-lib returns only
>
> ---
> .;
> thumb;@mthumb
> ---
>
>
Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
They might not have
been using the original gcc-3.4.0 sources.
seems to be very possible
There should be no need to edit those files, but that doesn't mean that the
people who built your old toolchain didn't edit them.
the other way would
im currently trying to replicate a gcc-3.4.0 arm-elf build from an very
old cross toolchain
building with my script (https://pastebin.com/kAEK0S24) works
but my -print-multi-lib returns only
---
.;
thumb;@mthumb
---
the original builds -print-multi-lib returns
---
.;
thumb;@mthumb
be;@mbig-endi
Yea, am just wanna make a compiler for my programming language (because it
is VERY NEW and the good reason is that IT IS COMPILED) and because it is
compiled i need a compiler for my programming language,
There are not many features in it BUT i will be adding stuff to it.
The programming
On Mon, Aug 7, 2023 at 8:52 AM Şahin Duran via Gcc wrote:
>
> Dear GCC Developers,
>
> I think I've just discovered a bug/ undefined situation in the compiler.
> When I try to call a weakly defined function, compiler successfully
> generates the code of calling procedure
On 07/08/2023 16:51, Şahin Duran via Gcc wrote:
Dear GCC Developers,
I think I've just discovered a bug/ undefined situation in the compiler.
When I try to call a weakly defined function, compiler successfully
generates the code of calling procedure. However, this calling procedure is
no
Dear GCC Developers,
I think I've just discovered a bug/ undefined situation in the compiler.
When I try to call a weakly defined function, compiler successfully
generates the code of calling procedure. However, this calling procedure is
nothing but branching to address 0 which resul
gi?id=110926 .
Thanks,
Andrew
> > > >
> > > > To quote:
> > > >
> > > > during RTL pass: split1
> > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function
> > > > 'matmul_i1_avx512f&
> 'matmul_i1_avx512f':
> > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1:
> > > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> > > 'w' (rtx const_int) in vpternlog_redundant_operand_m
I guess
--enable-checking=yes,rtl,extra is key to reproduce the issue?
> >
> > To quote:
> >
> > during RTL pass: split1
> > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function
> > 'matmul_i1_avx512f':
> > /home/toon/compil
ed/matmul_i1.c: In function
> 'matmul_i1_avx512f':
> /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1:
> internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
/generated/matmul_i1.c:1781:1:
internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
config/i386/i386.cc:19460
1781 | }
| ^
during RTL pass: split1
/home/toon/compilers/gcc/libgfo
Hi,
I'm not sure who on this mailing list reads comp.compilers, but there is
an interesting article about built-in regression search in the go
compiler at https://compilers.iecc.com/comparch/article/23-05-003 .
Using a similar approach could also be interesting for gcc,
complementing tools
Currently I have a libtool that looks something like this:
# The library search path used internally by the compiler when linking # a
shared library.
compiler_lib_search_path="-LD:/Eclipse/Workspace/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/x86_64-w64-mingw32/libstdc++-v3/src
-LD:/Ec
I am curious why spill_failure() in gcc/reload1.cc aborts the compiler.
static void
spill_failure (rtx_insn *insn, enum reg_class rclass)
{
if (asm_noperands (PATTERN (insn)) >= 0)
error_for_asm (insn, "cannot find a register in class %qs while "
"reloading %",
gt;
>> > On Mon, Mar 20 2023, Anastasia3412 via Gcc wrote:
>> >
>> > > Hello Everyone I'm Anastasia.
>> > >
>> > > I am a prospective GSOC Student. I wish to know if the project C++:
>> > > Implement compiler built-in traits for the
Hi,
I am Ken, an undergraduate student majoring in Computer Science and
minoring in Linguistics (because of my interest in syntax from both
natural and programming languages prospectives) at University of
Washington, Seattle. I am interested in the GSoC project: C++:
Implement compiler built-in
ery happy that you are considering contributing to GCC.
> >
> > On Mon, Mar 20 2023, Anastasia3412 via Gcc wrote:
> >
> > > Hello Everyone I'm Anastasia.
> > >
> > > I am a prospective GSOC Student. I wish to know if the project C++:
> > > Implem
OC Student. I wish to know if the project C++:
> >Implement compiler built-in traits for the standard library traits is
> >still available. I have already build and got my hand dirty on
> >debugging GCC.
>
> Various prospective contributors have shown interest in it but we h
Hello Anastasia,
we are very happy that you are considering contributing to GCC.
On Mon, Mar 20 2023, Anastasia3412 via Gcc wrote:
> Hello Everyone I'm Anastasia.
>
>I am a prospective GSOC Student. I wish to know if the project C++:
>Implement compiler built-in traits for the
Hello Everyone I'm Anastasia. I am a prospective GSOC Student. I wish to know
if the project C++: Implement compiler built-in traits for the standard library
traits is still available. I have already build and got my hand dirty on
debugging GCC. How should I proceed to make a proposal. A
Hi Ken,
On Mon, Feb 27, 2023 at 5:02 PM Ken Matsui via Gcc wrote:
>
> Hi,
>
> My name is Ken Matsui. I am highly interested in contributing to the
> project idea, "C++: Implement compiler built-in traits for the
> standard library traits." To understand how to impleme
On Tue, 28 Feb 2023 at 10:58, Berke Yavas via Gcc wrote:
>
> Hi,
>
> I am Berke. I am interested in the project C++: Implement compiler built-in
> traits for the standard library traits for the upcoming GSoC. I am a
> Software Engineer with a year of experience. I am very
Hi,
I am Berke. I am interested in the project C++: Implement compiler built-in
traits for the standard library traits for the upcoming GSoC. I am a
Software Engineer with a year of experience. I am very excited to have a
chance to work on gcc.
So far, I have built gcc from source, runned tests
Hi,
My name is Ken Matsui. I am highly interested in contributing to the
project idea, "C++: Implement compiler built-in traits for the
standard library traits." To understand how to implement those traits,
could you please give me some example implementations of the compiler
built-in
Hi,
My name is Ken Matsui. I am highly interested in contributing to the
project idea, "C++: Implement compiler built-in traits for the
standard library traits." To understand how to implement those traits,
could you please give me some example implementations of the compiler
built-in
On Tue, 8 Nov 2022 at 12:37, Jonathan Wakely wrote:
>
> On Tue, 8 Nov 2022 at 11:22, Florian Weimer via Libstdc++
> wrote:
> >
> > I'm trying to validate a change to gcc/config/msp430/msp430.cc.
> > The cross-compiler builds as far as I can tell, but I hit a sn
On Tue, 8 Nov 2022 at 11:22, Florian Weimer via Libstdc++
wrote:
>
> I'm trying to validate a change to gcc/config/msp430/msp430.cc.
> The cross-compiler builds as far as I can tell, but I hit a snag while
> configuring libstdc++:
>
> checking for shl_load... configure: er
I'm trying to validate a change to gcc/config/msp430/msp430.cc.
The cross-compiler builds as far as I can tell, but I hit a snag while
configuring libstdc++:
checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:12334: conf
On 15/6/22 7:56 pm, Richard Biener wrote:
> On Wed, Jun 15, 2022 at 11:27 AM Chris Johns
> wrote:
>>
>> Hi,
>>
>> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
>> chip vendor is using it when building controller software tha
On Wed, Jun 15, 2022 at 11:27 AM Chris Johns wrote:
>
> Hi,
>
> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
> chip vendor is using it when building controller software that is part of a
> system.
>
> The build I am using symlinks gmp, mp
Hi,
I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
chip vendor is using it when building controller software that is part of a
system.
The build I am using symlinks gmp, mpfr etc as source so they are built as part
of the gcc build.
The mpfr package is reporting
after inlining")
... and all my local tests look good with that applied.
Compiler explorer's trunk build now has that fix, so the examples from before
now look good:
aarch64: https://godbolt.org/z/vMczqjYvs
x86_64: https://godbolt.org/z/cveff9hq5
Jeremy, now that the real issue has
mmary after inlining")
... and all my local tests look good with that applied.
Compiler explorer's trunk build now has that fix, so the examples from before
now look good:
aarch64: https://godbolt.org/z/vMczqjYvs
x86_64: https://godbolt.org/z/cveff9hq5
Jeremy, now that the real issu
ng investigated.
> >
> > Jemery originally reported this as an issue with {readl,writel}_relaxed(),
> > but
> > the underlying problem doesn't have anything to do with those specifically.
> >
> > I'm dumping a bunch of info here largely for posterit
7;t have anything to do with those specifically.
>
> I'm dumping a bunch of info here largely for posterity / archival, and to find
> out who (from the kernel side) is willing and able to test proposed compiler
> fixes, once those are available.
>
> I'm happy to do so for aarch64; Peter, I assume you'd be happy to look at the
> x86 side?
Sure..
On 05/04/2022 14:04, Mark Rutland wrote:
> On Tue, Apr 05, 2022 at 01:51:30PM +0100, Mark Rutland wrote:
> My x86_64 test case is:
>
> Per compiler explorer (https://godbolt.org/z/cveff9hq5) GCC trunk currently
> compiles this as:
>
> | msr_rmw_set_bits:
> |
et_bits(unsigned long reg, unsigned long bits)
> | {
> | unsigned long val;
> |
> | val = rdmsr(reg);
> | val |= bits;
> | wrmsr(reg, val);
> | }
> |
> | void func_with_msr_side_effects(unsigned long reg)
> | {
> | msr_rmw_set_bits(reg, 1UL << 0);
> | ms
who (from the kernel side) is willing and able to test proposed compiler
fixes, once those are available.
I'm happy to do so for aarch64; Peter, I assume you'd be happy to look at the
x86 side?
This is a generic issue, and
I wrote test cases for aarch64 and x86_64. Those are inlin
hat you are writing to that location of memory.
> > > volatile asm does not do what you think it does.
> > > You didn't read further down about memory clobbers:
> > > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers
> > > Specif
forces the compiler to generate the
instruction in the code path as intended. The only problem
is that it doesn't also tell the compiler that there may
be memory side effects. Meaning that if a function is comprised
entirely of relaxed io operations, the compiler may think that
it only has reg
g this.
> > >
> > > On Fri, Apr 01, 2022 at 11:44:06AM -0500, Jeremy Linton wrote:
> > > > The relaxed variants of read/write macros are only declared
> > > > as `asm volatile()` which forces the compiler to generate the
> > > > instruction in the c
The relaxed variants of read/write macros are only declared
> > > as `asm volatile()` which forces the compiler to generate the
> > > instruction in the code path as intended. The only problem
> > > is that it doesn't also tell the compiler that there may
> > &g
On Fri, Apr 1, 2022 at 10:24 AM Mark Rutland via Gcc wrote:
>
> Hi Jeremy,
>
> Thanks for raising this.
>
> On Fri, Apr 01, 2022 at 11:44:06AM -0500, Jeremy Linton wrote:
> > The relaxed variants of read/write macros are only declared
> > as `asm volatile()` which f
Hi Jeremy,
Thanks for raising this.
On Fri, Apr 01, 2022 at 11:44:06AM -0500, Jeremy Linton wrote:
> The relaxed variants of read/write macros are only declared
> as `asm volatile()` which forces the compiler to generate the
> instruction in the code path as intended. The only problem
The relaxed variants of read/write macros are only declared
as `asm volatile()` which forces the compiler to generate the
instruction in the code path as intended. The only problem
is that it doesn't also tell the compiler that there may
be memory side effects. Meaning that if a functi
-with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
>
> Apple clang version 13.0.0 (clang-1300.0.29.30)
This means you even aren't using gcc at all but a different compiler.
Jakub
I goofed and failed to put a space after the "case" word:
switch(nu){
case1: v1 =val;break;
case2: v2 =val;break;
case3: v3 =val;break;
case4: v4 =val;break;
}
gcc compiler showed NO errors or warnings. Execution of the code produced
incorrect results.
After I added a space(no oth
Dear compiler developers or maintainers，
We are writing to see if you would like to participate in a new research study
being conducted at Nanjing University. This research plays an important role in
advancing our understanding of C programmers' knowledge and views of certain
security i
rtіcle Τіtle: "Evaluation of compiler-induced vulnerabilities"
2. Аrtіcle Keywords: Codes (symbols); Open source software; Program
compilers; Security of data; Assembly language; Compilation process; Confidence
levels; Machine codes; Persistent state; Security vulnerabilities; Softw
On 14/07/2021 09:33, Richard Biener wrote:
I tried to add a TREE_USED (var) = 1, but this seems to have no effect.
Could someone give me a hint what needs to be added so that this object
is created? The object is placed in a linker set.
You can call mark_decl_referenced (var), TREE_USED is only
On Wed, Jul 14, 2021 at 7:50 AM Sebastian Huber
wrote:
>
> Hello,
>
> I noticed that the following static read-only object gets optimized away
> if optimization is enabled:
>
> /* Generate the pointer to the gcov_info_var in a dedicated section. */
>
> static void
> build_gcov_info_var_registrati
Hello,
I noticed that the following static read-only object gets optimized away
if optimization is enabled:
/* Generate the pointer to the gcov_info_var in a dedicated section. */
static void
build_gcov_info_var_registration (tree gcov_info_type)
{
tree var = build_decl (BUILTINS_LOCATION,
Miller J.A., Dacumos K...,
Hope that you are having a good day.
Your рареr entіtlҽd "Evaluation of compiler-induced vulnerabilities" ρᴜblisһed
in Jοᴜrnаl of Aerospace Information Systems has impressed us profoundly. *Here,
we strongly іnνіtҽ you to сontriƄսte other unρᴜblisһed рареr
On 6/2/21 10:10 AM, sotrdg sotrdg via Gcc wrote:
The document said yes. However, what does bootstrap actually do that can make
compiler faster?
Hello.
In case of openSUSE, we leverage both bootstrap-lto config with 'make
profiledbootstrap'. That utilizes
profile-guided op
Hi,
On Wed, Jun 02 2021, sotrdg sotrdg via Gcc wrote:
> The document said yes. However, what does bootstrap actually do that can make
> compiler faster?
Assuming the gcc you are bootstrapping is newer than your system
compiler, it is quite likely to be better able to optimize itself th
The document said yes. However, what does bootstrap actually do that can make
compiler faster?
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
On Sat, May 01, 2021 at 09:51:00PM -0700, Jaime Guzman Gaytan via Gcc wrote:
> How can I get the compiler if I don't have internet in my apartment?
Depending on what platform you're on, there should be a package (deb, rpm, etc)
which you can download at i.e. work or a local library
Thanks.
An internal compiler error is always a problem with the compiler itself.
I submitted this to our bug tracker (Bugzilla) as Problem Report 96712
on your behalf.
Follow it by looking at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96712
Kind regards,
Toon.
On 8/19/20 4:22 PM, Bernd
On Wed, Aug 19, 2020 at 10:34 AM Bernd Eggen via Gcc wrote:
>
> Hello,
>
> I realised when I created the small code snippet I accidentally put the
> variable "m" in the default integer declaration, I checked it and moving it
> (to kind=16) does not make a difference either.
>
> I also checked on U
the same error message / behaviour. I re-attach the corrected f90 file,
which also as a slightly improved loop exit condition.
Best wishes, Bernd
On Wed, 19 Aug 2020 at 15:22, Bernd Eggen wrote:
> Hello,
>
> I've come across an internal compiler error (in GFortran), concern
On Wed, 19 Aug 2020 at 15:24, Bernd Eggen via Gcc wrote:
>
> Hello,
>
> I've come across an internal compiler error (in GFortran), concerning the
> function NINT(),
Then you should be reporting it to Bugzilla, not to this mailing list.
> Please submit a full bug repo
Hello,
I've come across an internal compiler error (in GFortran), concerning the
function NINT(), I attach a very simple source code that illustrates the
error. Essentially I am working with 16-byte integers, and there seems no
way to ensure that NINT() returns the correct precision intege
On Wed, 2020-08-12 at 15:05 -0500, Segher Boessenkool wrote:
> > As usual I've built my own version of GCC, and then I check it into
> > Git so that all builds can use this one canonical compiler
> > regardless of operating system, etc.
>
> There's your problem.
On Tue, Aug 11, 2020 at 08:01:55PM -0400, Paul Smith wrote:
> This is a kind of esoteric problem, but all the more annoying for that.
:-)
> As usual I've built my own version of GCC, and then I check it into Git
> so that all builds can use this one canonical compiler regardless
On Wed, 12 Aug 2020 at 17:43, Paul Smith wrote:
> However, the lib directory is empty in my build. What lives in your
> version of lib?
All the runtime libs, but I think that's because mingw doesn't use the
lib/lib64 split.
$ ls -1 ~/gcc/mingw/x86_64-w64-mingw32/lib/
libatomic-1.dll
libatomic.a
s own internal libraries,
>
> Not by default, it isn't. I'm not sure what directory that is, but
> none of my builds have it.
>
> Is this a cross-compiler? Mine have PREFIX//lib instead, and
> it's not empty (for a 64-bit --disable-multlib build)
Sorry, you'r
what directory that is, but
none of my builds have it.
Is this a cross-compiler? Mine have PREFIX//lib instead, and
it's not empty (for a 64-bit --disable-multlib build)
On Wed, 2020-08-12 at 15:37 +0200, Jakub Jelinek wrote:
> The important thing is that GCC wants to be relocatable, so most
> paths are not hardcoded into the compiler, but depend on where the
> gcc driver actually is. One can then just move the whole gcc tree
> somewhere else and it
x27;s
> installation via symlinks in random ways is something that needs to be
> supported. Anyway, the user can always replace the "lib64" directory
> with a symlink as well.
The important thing is that GCC wants to be relocatable, so most paths are
not hardcoded into the compiler,
1 - 100 of 1579 matches
Mail list logo
