deconstructs a global object of class A. This caused an error in my program.
> Could you tell me how can I avoid this problem?Upgrade compiler
> version?Modify my code?
>
> my code like this:
> class A{
> static int var;
> ~A(); //A Destructor depe
I compile my program using g++ 4.8.5, I find that when my program exits, it
first deconstructs the static member variables of class A, and then
deconstructs a global object of class A. This caused an error in my program.
Could you tell me how can I avoid this problem?Upgrade compiler
version
on devices that
have the AVGPR register file (they use it as spill space and therefore
don't need the memory loads) and I actually don't need XNACK on the
older devices at this time, but probably this is just pushing the
problem further down the road so if there's a better solution then I'd
like to find it.
Thanks in advance
Andrew
Hi
I have foujnd the reason for the weird behavior of gcc when reading 64 bits
data.
I found out how to avoid this. The performance of the generated code doubled.
I thank everyone in this forum for their silence to my repeated help requests.
They remind me that:
THE ENTIRE RISK AS TO THE QUAL
Trying to build default target in 13.1.0 source, and am hitting a
Pthreads are required error.
I have the .h and lib on my system, so not sure why hitting this error.
I goog'd the error and see nothing recent about why I'd get the error.
Any suggestions?
Please include me in response, as I'm n
On Thu, 16 Mar 2023 at 17:45, oszibarack korte via Gcc wrote:
>
> *An unsolved problem for more than a decade!*
> *Dear GNU Compiler Collection development team!*
>
> *There is a problem with the gcc and g++ compilers for Linux operating
> systems!*
> *Here are 3 pieces o
On Thu, Mar 16, 2023 at 10:46 AM oszibarack korte via Gcc
wrote:
>
> *An unsolved problem for more than a decade!*
> *Dear GNU Compiler Collection development team!*
>
> *There is a problem with the gcc and g++ compilers for Linux operating
> systems!*
> *Here are 3 pieces o
*An unsolved problem for more than a decade!*
*Dear GNU Compiler Collection development team!*
*There is a problem with the gcc and g++ compilers for Linux operating
systems!*
*Here are 3 pieces of C and 3 pieces of C++ source code.*
*- Please compile them on any LINUX!- Run it!- Compare the
On Fri, Dec 9, 2022 at 7:17 PM 刘畅 via Gcc wrote:
>
> Hi all,
>
> I met a problem when I was testing the weak attribute and the weakref
> attribute of GCC. I've read the documentation and in the 6.33.1 Common
> Function Attributes - weakref part I found:
>
>
Hi all,
I met a problem when I was testing the weak attribute and the weakref
attribute of GCC. I've read the documentation and in the 6.33.1 Common
Function Attributes - weakref part I found:
Without a target given as an argument to weakref or to alias,
weakref is equivalent to wea
> Re GCC 9.1, however beware of <https://gcc.gnu.org/PR104749>
> "stage1 d21 fails to link with GDC 9.1".
Thanks for all who replied. Thanks especially for mentioning this problem, as
my build did indeed fail with this error on GCC 9.3. I applied the fix and
that'
The problem is fixed now.
Thanks.
Should i push again with the first change log
في الجمعة، ٢٠ مايو، ٢٠٢٢ ٩:٢٠ م Mohamed Atef
كتب:
> I cloned he repo again but there is a problem here.
> This line is not in the previous repo.
>
> https://github.com/gcc-mirror/gcc/blob/master/li
I cloned he repo again but there is a problem here.
This line is not in the previous repo.
https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef
كتب:
> I am really sorry.
>
> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed At
I am really sorry.
في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef
كتب:
> In fact that's why i downloaded the repo again i forget to modify the
> copyright and when i tried to repush but i got an error As my branch is not
> updated i wanted delete the branch and create new one and push again.
> If
In fact that's why i downloaded the repo again i forget to modify the
copyright and when i tried to repush but i got an error As my branch is not
updated i wanted delete the branch and create new one and push again.
If you have the authority to remove the last batch please do.
في الجمعة، ٢٠ مايو،
On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
> I use 1.15.1.
> This is the link to the line I mentioned.
> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
You shouldn't be running autoreconf, just automake to regenerate
Makefile.in, and when I run it,
I use 1.15.1.
This is the link to the line I mentioned.
https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
On Fri, May 20, 2022 at 11:40 AM Jakub Jelinek wrote:
> On Fri, May 20, 2022 at 11:25:59AM +0200, Mohamed Atef wrote:
> >I downloaded the last version of the
On Fri, May 20, 2022 at 11:25:59AM +0200, Mohamed Atef wrote:
>I downloaded the last version of the repo, but when I try to
> autoreconf
> in libgomp/
> i get this error "plugin/Makefrag.am:29: error: libgomp_la_LIBADD must be
> set with '=' before using '+='"
> line 29 in libgomp/plugin/Makefr
Hello,
I downloaded the last version of the repo, but when I try to
autoreconf
in libgomp/
i get this error "plugin/Makefrag.am:29: error: libgomp_la_LIBADD must be
set with '=' before using '+='"
line 29 in libgomp/plugin/Makefrag.am has
"libgomp_la_LIBADD += $(DL_LIBS)"
I removed this line and
Hi Jonathan,
Thank you very much for your response.
Since the previous email I have had more correspondence with Marc at
the OpenBSD misc mailing list.
He clarified that the reason the -L/usr/lib prefix was added, was
"because of ld.ldd, the linker from clang. see, that one does not link
with /u
ion that it turns
> out not to be needed.
>
> I describe my problem here:
> https://marc.info/?l=openbsd-misc&m=161472828522043&w=2
>
> In summary my problem is that on OpenBSD, GCC will prepend to LD's
> arguments "-L/usr/lib", which means that "-lz&qu
Hi GCC users mailing list,
I am currently figuring out a GCC usecase on OpenBSD. This situation
involves some non-superficial understanding of GCC's code, and
therefore I wish to query you here even in the situation that it turns
out not to be needed.
I describe my problem here:
eliminates it. The reason it happens is that the DCE
code (run_fast_df_dce) is run as a side-effect of a live-register problem and
is considered a recursive call. This causes DCE to ignore the register uses in
the CALL_INSN_FUNCTION_USAGE list and, thus the prior set becomes dead.
I believe this
day, December 30, 2020 11:00 PM
> To: gcc@gcc.gnu.org
> Subject: A problem with field decl offsets in newly minted types
>
> I'm having some grief with creating/using some modified types.
>
> I problem occurs in tree-ssa-sccvn.c when some code tries
> to take a DECL_FIEL
ation optimization, this is occurring
with the Mcf sources from SPEC17.
From: Gary Oblock
Sent: Wednesday, December 30, 2020 11:00 PM
To: gcc@gcc.gnu.org
Subject: A problem with field decl offsets in newly minted types
I'm having some grief with creating/using som
I'm having some grief with creating/using some modified types.
I problem occurs in tree-ssa-sccvn.c when some code tries
to take a DECL_FIELD_OFFSET and unfortuenately gets a null
that causes a crash.
So, I traced this back the to types I created. Note, the method I used
has seemed to be f
On Mon, Sep 14, 2020 at 08:35:44PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> >> Although this looks/sounds complicated, the advantage is that everything
> >> remains up-to-date. If we instead added a second attribute and only
> >> defined it for instructions like *add__, othe
Segher Boessenkool writes:
>> Although this looks/sounds complicated, the advantage is that everything
>> remains up-to-date. If we instead added a second attribute and only
>> defined it for instructions like *add__, other instructions
>> (including config/arm instructions) would still have type
to add new attribute to resolve this problem, why
> > not use the Case1 directly?
>
> It's a trade-off. At the moment the rule for arm and aarch64 is simple:
> the "type" attribute specifies the complete scheduling type. If we
> instead change policy and divide t
Erick,
I assume that this needs to be done on all the functions since
you mention "cfun".
Gary
From: Erick Ochoa
Sent: Monday, September 14, 2020 12:10 AM
To: Gary Oblock ; gcc@gcc.gnu.org
Subject: Re: Dominance information problem
[EXTERNAL EMAIL NO
" "=r")
> (plus:GPI (ASHIFT:GPI (match_operand:GPI 1 "register_operand" "r")
> (match_operand:QI 2
> "aarch64_shift_imm_" "n"))
> (match_operand:GPI 3 "register_oper
On 14/09/2020 03:53, Qian, Jianhua wrote:
>> -Original Message-
>> From: Richard Earnshaw
>> Sent: Friday, September 11, 2020 9:30 PM
>> To: Qian, Jianhua/钱 建华 ; gcc@gcc.gnu.org
>> Subject: Re: A problem with one instruction multiple latencies and pipelines
&
Hi Gary,
I'm not 100% sure this will fix the problem, but in the past I have had
to call the following function:
/* If dominator info is not available, we need to calculate it. */
if (!dom_info_available_p (CDI_DOMINATORS))
calculate_dominance_info (CDI_DOMINATORS);
Basi
uot; "r")))]
""
"add\\t%0, %3, %1, %2"
[(set_attr "type" "alu_shift_imm,alu_shift_imm1to4")]
)
It means that one "type" value should be matched by one operand constraint
pattern. So this will raise two problems.
> -Original Message-
> From: Richard Earnshaw
> Sent: Friday, September 11, 2020 9:30 PM
> To: Qian, Jianhua/钱 建华 ; gcc@gcc.gnu.org
> Subject: Re: A problem with one instruction multiple latencies and pipelines
>
> On 07/09/2020 07:08, Qian, Jianhua wrote:
> >
I'm trying to do performance qualification for my structure
reorganization optimization.
I'm doing pretty straightforward stuff and I haven't at this point in
time (qualifying the optimization,) modified the program. So I'm a
little surprised this is failing. Here is the code that's failing on
th
Hi!
On Fri, Sep 11, 2020 at 08:44:54AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > Consider cores that do not care about the "subtype" at all: when using
> > just "type", all cores have to test for "foo,foo_subtype", while with
> > a separate attribute they can just test for
On 07/09/2020 07:08, Qian, Jianhua wrote:
> Hi
>
> I'm adding a new machine model. I have a problem when writing the
> "define_insn_reservation" for instruction scheduling.
> How to write the "define_insn_reservation" for one instruction that there
Segher Boessenkool writes:
> On Thu, Sep 10, 2020 at 11:04:26AM +0100, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > You can also use some other attributes to classify instructions, you
>> > don't have to put it all in one "type" attribute. This can of course be
>> > done later, at
On Thu, Sep 10, 2020 at 11:04:26AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > You can also use some other attributes to classify instructions, you
> > don't have to put it all in one "type" attribute. This can of course be
> > done later, at a time when it is clearer what a
Segher Boessenkool writes:
> Hi!
>
> On Mon, Sep 07, 2020 at 09:20:59PM +0100, Richard Sandiford wrote:
>> This is just personal opinion, but in general (from the point of view
>> of a new port, or a new subport like SVE), I think the best approach
>> to handling the "type" attribute is to start w
senkool
> Sent: Thursday, September 10, 2020 5:23 AM
> To: Qian, Jianhua/钱 建华 ; gcc@gcc.gnu.org;
> richard.sandif...@arm.com
> Subject: Re: A problem with one instruction multiple latencies and pipelines
>
> Hi!
>
> On Mon, Sep 07, 2020 at 09:20:59PM +0100, Richard San
Hi!
On Mon, Sep 07, 2020 at 09:20:59PM +0100, Richard Sandiford wrote:
> This is just personal opinion, but in general (from the point of view
> of a new port, or a new subport like SVE), I think the best approach
> to handling the "type" attribute is to start with the coarsest
> classification th
n, Jianhua/钱 建华
> Cc: gcc@gcc.gnu.org
> Subject: Re: A problem with one instruction multiple latencies and pipelines
>
> "Qian, Jianhua" writes:
> > Hi
> >
> > I'm adding a new machine model. I have a problem when writing the
> "define_i
"Qian, Jianhua" writes:
> Hi
>
> I'm adding a new machine model. I have a problem when writing the
> "define_insn_reservation" for instruction scheduling.
> How to write the "define_insn_reservation" for one instruction that there are
> dif
On Mon, Sep 7, 2020 at 10:46 AM Qian, Jianhua wrote:
>
> Hi Richard
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, September 7, 2020 3:41 PM
> > To: Qian, Jianhua/钱 建华
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: A proble
Hi Richard
> -Original Message-
> From: Richard Biener
> Sent: Monday, September 7, 2020 3:41 PM
> To: Qian, Jianhua/钱 建华
> Cc: gcc@gcc.gnu.org
> Subject: Re: A problem with one instruction multiple latencies and pipelines
>
> On Mon, Sep 7, 2020 at 8:10
On Mon, Sep 7, 2020 at 8:10 AM Qian, Jianhua wrote:
>
> Hi
>
> I'm adding a new machine model. I have a problem when writing the
> "define_insn_reservation" for instruction scheduling.
> How to write the "define_insn_reservation" for one instructio
Hi
I'm adding a new machine model. I have a problem when writing the
"define_insn_reservation" for instruction scheduling.
How to write the "define_insn_reservation" for one instruction that there are
different latencies and pipelines according to parameter.
For
On Tue, Aug 11, 2020 at 6:15 AM Gary Oblock via Gcc wrote:
>
> I'm trying to debug a problem cropping up in value range propagation.
> Ironically I probably own an original copy 1995 copy of the paper it's
> based on but that's not going to be much help since I&#
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
On Wed, 2020-08-12 at 16:53 +0100, Jonathan Wakely wrote:
> On Wed, 12 Aug 2020 at 14:33, Paul Smith
> wrote:
>
> > I'm not talking about PREFIX/lib, though. As can be seen from my
> > question I'm talking about PREFIX///lib. This is
> > where GCC keeps its own internal libraries,
>
> Not by d
On Wed, 12 Aug 2020 at 14:33, Paul Smith wrote:
>
> I'm not talking about PREFIX/lib, though.
>
> As can be seen from my question I'm talking about
> PREFIX///lib. This is where GCC keeps its own
> internal libraries,
Not by default, it isn't. I'm not sure what directory that is, but
none of my
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 should still w
On Wed, Aug 12, 2020 at 09:33:05AM -0400, Paul Smith wrote:
> As someone who takes a lot of advantage of the flexibility that tools
> like GCC provide I'm wary of reducing that flexibility. On the other
> hand I'm not sure that breaking up the internal structure of GCC's
> installation via symlink
On Wed, 2020-08-12 at 15:08 +0200, Jakub Jelinek wrote:
> > I think it's worth adding this to bugzilla. Depending on the
> > existence of empty directories seems less than ideal.
>
> But canonicalizing the paths without taking the filesystem state into
> account will significantly change the behav
On Wed, Aug 12, 2020 at 01:08:53PM +0100, Jonathan Wakely via Gcc wrote:
> > Oddly, I looked through the gnulib library and didn't find any
> > appropriate module for this. It seems like there should be one.
>
> C++17 provides std::filesystem::weakly_canonical for that. It doesn't
> help GCC or g
On Wed, 12 Aug 2020 at 01:02, 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 of
>
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 of
operating system, etc.
After being checked into Git, the compiler started fa
I'm trying to debug a problem cropping up in value range propagation.
Ironically I probably own an original copy 1995 copy of the paper it's
based on but that's not going to be much help since I'm lost in the
weeds. It's running on some optimization (my structure reor
This problem is from my structure reorganization optimization
optimization code (simplified and cleaned to illustrate
the problem.
Here's what happening below at the high level
>From the user program:
typedef struct type type_t;
struct type {
double x;
double y;
}:
I'l
On Mon, 2020-07-13 at 08:39 +0200, Hans-Peter Nilsson via Gcc wrote:
> Again, Debian 9. Doing "git gcc-backport a4aca1edaf37d43" on
> releases/gcc-10 gave me:
>
> [releases/gcc-10 83cf5a7c6a5] PR94600: fix volatile access to the
> whole of a compound object.
> Date: Sun Jul 5 20:50:52 2020 +0200
Again, Debian 9. Doing "git gcc-backport a4aca1edaf37d43" on
releases/gcc-10 gave me:
[releases/gcc-10 83cf5a7c6a5] PR94600: fix volatile access to the whole of a
compound object.
Date: Sun Jul 5 20:50:52 2020 +0200
9 files changed, 276 insertions(+), 1 deletion(-)
create mode 100644 gcc/test
On Wed, Jun 24, 2020 at 9:05 PM Gary Oblock via Gcc wrote:
>
> Richard,
>
> First off I did suspect INDIRECT_REF wasn't supported, thanks for
> confirming that.
>
> I tried what you said in the original code before I posted
> but I suspect how I went at it is the
Richard,
First off I did suspect INDIRECT_REF wasn't supported, thanks for
confirming that.
I tried what you said in the original code before I posted
but I suspect how I went at it is the problem. I'm probably
doing something(s) in a glaringly stupid way.
Can you spot it, because
On Wed, Jun 24, 2020 at 1:36 AM Gary Oblock via Gcc wrote:
>
> I'm somehow misusing GIMPLE (probably in multiple ways) and I need
> some help in straightening out this little mess I've made.
>
> I'm trying to do the following:
>
> In an attempt at structure reorganization (instance interleaving) a
I'm somehow misusing GIMPLE (probably in multiple ways) and I need
some help in straightening out this little mess I've made.
I'm trying to do the following:
In an attempt at structure reorganization (instance interleaving) an
array of structures is being transformed into a structure of arrays.
On Mon, 6 Jan 2020 at 06:57, Yu <17671260...@163.com> wrote:
>
> Hello,
>
> I have some questions about developing my own compiler plugin. I tried to
> develop it using
> riscv-gnu-toolchain(https://github.com/riscv/riscv-gnu-toolchain), but it
> couldn't find following header files.
Which head
/* If plugin support is enabled, we could use libdl. */
#include
#endif
/* Do not introduce a gmp.h dependency on the build system. */
#ifndef GENERATOR_FILE
#include
#endif
#ifdef HAVE_SYS_MMAN_H
# include
#endif
How to resolve this problem? I would be very grateful indeed for any he
On Mon, Jul 22, 2019 at 4:05 AM Maxim Blinov wrote:
> Is it possible, in the arch.opt file, to have GCC generate a bitmask
> relative to a user-defined variable without an associated name? To
> illustrate my problem, consider the following option file snippet:
> ...
> But, I don&
Hi all,
Is it possible, in the arch.opt file, to have GCC generate a bitmask
relative to a user-defined variable without an associated name? To
illustrate my problem, consider the following option file snippet:
...
Variable
HOST_WIDE_INT riscv_bitmanip_flags = 0
...
mbmi-zbb
Target Mask
On Sun, Jun 23, 2019 at 3:27 AM Jonathan Wakely
wrote:
> On Sat, 22 Jun 2019 at 12:25, Akshat Garg wrote:
> >
> > On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab
> > wrote:
> >
> > > On Jun 22 2019, Akshat Garg wrote:
> > >
> > > > I believe I should be getting a warning like:
> > > > warning:
On Sat, 22 Jun 2019 at 12:25, Akshat Garg wrote:
>
> On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab
> wrote:
>
> > On Jun 22 2019, Akshat Garg wrote:
> >
> > > I believe I should be getting a warning like:
> > > warning: initialization from incompatible pointer type
> > > [-Wincompatible-pointer
On Sat, Jun 22, 2019 at 1:10 PM Andreas Schwab
wrote:
> On Jun 22 2019, Akshat Garg wrote:
>
> > I believe I should be getting a warning like:
> > warning: initialization from incompatible pointer type
> > [-Wincompatible-pointer-types]
> > but in the gcc.log file, I found this:
> > error: initi
On Jun 22 2019, Akshat Garg wrote:
> I believe I should be getting a warning like:
> warning: initialization from incompatible pointer type
> [-Wincompatible-pointer-types]
> but in the gcc.log file, I found this:
> error: initialization of '_Atomic struct rcutest *' from incompatible
> pointer t
Hello all,
I have been trying to run a test which assigns a value from non-atomic to
an atomic pointer type. The code is as follows:
/* File: xyz.c */
/* { dg-do compile } */
/* { dg-options "-std=c11 -pedantic-errors" } */
#include
typedef __SIZE_TYPE__ size_t;
extern void abort (void);
exte
On Sat, 8 Jun 2019, Jonathan Wakely wrote:
You can see which tests failed by looking in the .log files in the
testsuite directories,
There are .sum files for a quick summary.
or by running the contrib/test_summary script.
There is also contrib/compare_tests, although running it globally ha
On Sat, 8 Jun 2019 at 21:51, Akshat Garg wrote:
>
>
> On Sun, Jun 9, 2019 at 1:57 AM Jonathan Wakely wrote:
>>
>> On Sat, 8 Jun 2019 at 19:03, Akshat Garg wrote:
>> >
>> > On Sat, Jun 8, 2019 at 9:20 PM Eric Botcazou wrote:
>> >
>> > > > Makefile:2323: recipe for target 'do-check' failed
>> > >
On Sun, Jun 9, 2019 at 1:57 AM Jonathan Wakely
wrote:
> On Sat, 8 Jun 2019 at 19:03, Akshat Garg wrote:
> >
> > On Sat, Jun 8, 2019 at 9:20 PM Eric Botcazou
> wrote:
> >
> > > > Makefile:2323: recipe for target 'do-check' failed
> > > > make: *** [do-check] Error 2
> > > > make: Target 'check'
On Sat, 8 Jun 2019 at 19:03, Akshat Garg wrote:
>
> On Sat, Jun 8, 2019 at 9:20 PM Eric Botcazou wrote:
>
> > > Makefile:2323: recipe for target 'do-check' failed
> > > make: *** [do-check] Error 2
> > > make: Target 'check' not remade because of errors.
> > >
> > > Please, can anyone let me know
> https://gcc.gnu.org/ml/gcc-testresults/2019-06/msg00810.html
> results have been produced or there is something I am not aware of.
You need to issue a third command:
make mail-report.log
--
Eric Botcazou
On Sat, Jun 8, 2019 at 9:20 PM Eric Botcazou wrote:
> > Makefile:2323: recipe for target 'do-check' failed
> > make: *** [do-check] Error 2
> > make: Target 'check' not remade because of errors.
> >
> > Please, can anyone let me know what am I doing wrong?
>
> Nothing, this just means that there
> Makefile:2323: recipe for target 'do-check' failed
> make: *** [do-check] Error 2
> make: Target 'check' not remade because of errors.
>
> Please, can anyone let me know what am I doing wrong?
Nothing, this just means that there are some failures in the testsuite.
> Also, when running an input
Hello all,
GCC build details:
Using built-in specs.
COLLECT_GCC=../build/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++
Thread model: posix
gcc version 10.0.0 20190607 (experimental) (GCC)
I have been trying to run the testsuite using the gcc trun
Hi !
While porting a GCC 4.9 private port to GCC 7, I've encountered an issue with
named address space support.
I have defined the following target macros:
#define K1_ADDR_SPACE_UNCACHED 1
#define K1_ADDR_SPACE_CONVERT 2
TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P (returns false for CONVERT, regul
On 17/01/2019 15:25, Sebastian Huber wrote:
On 17/01/2019 12:40, Eric Botcazou wrote:
I can build the trunk with a native
gnat --version
GNAT 8.2.1 20190103 [gcc-8-branch revision 267549]
Copyright (C) 1996-2018, Free Software Foundation, Inc.
This is free software; see the source for copying c
On 17/01/2019 12:40, Eric Botcazou wrote:
I can build the trunk with a native
gnat --version
GNAT 8.2.1 20190103 [gcc-8-branch revision 267549]
Copyright (C) 1996-2018, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for
> I can build the trunk with a native
>
> gnat --version
> GNAT 8.2.1 20190103 [gcc-8-branch revision 267549]
> Copyright (C) 1996-2018, Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FO
On 17/01/2019 09:56, Sebastian Huber wrote:
Hello,
I tried to build the arm-rtems target with Ada support on the trunk
yesterday. It fails with:
/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-
Hello,
I tried to build the arm-rtems target with Ada support on the trunk
yesterday. It fails with:
/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86
_64-linux-gnu-1/build/./gcc/xgcc
-B/home
ing. Maybe it was
> > something in
> > glibc that changed.
>
> Most likely it only worked by accident so far. Last week the first
> GLIBC_2.29 symbol has been added to libm.
>
> Andreas.
Yup, I backed off those glibc changes and I could build, so that seems
to be the
On Nov 26 2018, Steve Ellcey wrote:
> I looked through the patches for the last couple of weeks to see if I could
> identify
> what changed here but I haven't found anything. Maybe it was something in
> glibc that changed.
Most likely it only worked by accident so far. Last week the first
GLI
I am trying to do a bootstrap build of GCC using a newly built glibc in
a non standard location on my aarch64 platform (thunderx). This was working
up until a week or so ago but now I am running into a problem I haven't seen
before:
build/genautomata /home/sellcey/test-tot/src/gcc/gcc/comm
On 12 June 2018 at 06:49, 刘超杰 wrote:
> Hi:
> When I was using g++, I found a problem, maybe which is a bug or not.
This is the wrong mailing list for your question. Please use the
gcc-h...@gcc.gnu.org list for help and questions about GCC.
> It is about the order of object files neede
Hi:
When I was using g++, I found a problem, maybe which is a bug or not. It is
about the order of object files needed to link, if you change the order of
files, the result is different. I can duplicate the problem, and I have write
an example, whose git address is:
https://github.com/Erician
On Tue, May 29, 2018 at 11:43 AM, Sebastian Huber
wrote:
> would you mind trying this with -Ttext=0x9000?
This gives me for the weak call
9014: 7097 auipc ra,0x7
9018: fec080e7 jalr -20(ra) # 0 <__global_pointer$+0x6fffe7d4>
> Please have a look at:
> https
Hello Jim,
- Am 29. Mai 2018 um 20:27 schrieb Jim Wilson j...@sifive.com:
> On 05/28/2018 06:32 AM, Sebastian Huber wrote:
>> I guess, that the resolution of the weak reference to the undefined
>> symbol __deregister_frame_info somehow sets __deregister_frame_info to
>> the absolute address 0
=medany -O tmp.c
-Ttext=0x8000 -nostdlib -nostartfiles.
I need enough info to reproduce your problem in order to look at it.
One thing you can try is adding -Wl,--noinhibit-exec, which will produce
an executable even though there was a linker error, and then you can
disassemble the binary to
1 - 100 of 1545 matches
Mail list logo
