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 of C and 3 pieces of C++ so
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 of C and 3 pieces of C++
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/libgomp/plugin/Makefr
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 Atef
> كتب:
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
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'm lost in the
> weeds. It's running
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. Git is not an archiver. Git does
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 of
> operating sy
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
> operating system, etc.
>
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
On 02/21/2018 02:33 PM, Alexander Fichtinger wrote:
> When you look at line 23 it is called 1 time. Line 24 is called 2 times (the
> bold one).
> We already looked in the disassembly but did not see a reason why the line
> should be executed 2 times.
>
> Can anyone help here, please?
>
> Kind r
T-Bird snafu resend:
On 06/05/17 14:52, Bruce Korb wrote:
> On 06/01/17 07:24, Douglas B Rupp wrote:
>>
>> This is a reproducer for a problem we have with fixincludes on
>> vxworks6.6. The desired output is
>> FOO= 1
>>
>> The problem is the rules for handling headers enclosed in quotes can
>> ca
On 06/01/17 07:24, Douglas B Rupp wrote:
>
> This is a reproducer for a problem we have with fixincludes on
> vxworks6.6. The desired output is
> FOO= 1
>
> The problem is the rules for handling headers enclosed in quotes can
> cause gcc to #include the original header not the patched header.
>
On 10/04/16 10:38, Andrew Pinski wrote:
On Tue, Oct 4, 2016 at 8:33 AM, Bill Seurer wrote:
parameter_handler.cc: In member function 'double
ParameterHandler::get_double(const string&) const':
parameter_handler.cc:777:28: error: ISO C++ forbids comparison between
pointer and integer [-fpermissiv
I'd +1 vote to send them a patch. I've had to do this for other
compilers. If you need a hand, I can give you some tips on how to do
that and also where to check if this has already been fixed.
Thanks
On Tue, Oct 4, 2016 at 11:43 PM, Jeff Law wrote:
> On 10/04/2016 09:41 AM, Marek Polacek wrote:
On Tue, Oct 4, 2016 at 8:33 AM, Bill Seurer wrote:
> parameter_handler.cc: In member function 'double
> ParameterHandler::get_double(const string&) const':
> parameter_handler.cc:777:28: error: ISO C++ forbids comparison between
> pointer and integer [-fpermissive]
>AssertThrow ((s.c_str()!='\
On 10/04/2016 09:41 AM, Marek Polacek wrote:
On Tue, Oct 04, 2016 at 08:38:00AM -0700, Andrew Pinski wrote:
On Tue, Oct 4, 2016 at 8:33 AM, Bill Seurer wrote:
parameter_handler.cc: In member function 'double
ParameterHandler::get_double(const string&) const':
parameter_handler.cc:777:28: error
On Tue, Oct 04, 2016 at 08:38:00AM -0700, Andrew Pinski wrote:
> On Tue, Oct 4, 2016 at 8:33 AM, Bill Seurer wrote:
> > parameter_handler.cc: In member function 'double
> > ParameterHandler::get_double(const string&) const':
> > parameter_handler.cc:777:28: error: ISO C++ forbids comparison betwee
On 31-Aug-15 02:19 PM, Richard Biener wrote:
On Mon, Aug 31, 2015 at 6:51 AM, shmeel gutl
wrote:
When dealing with an array with known values, pre will evaluate the first
iteration of a loop over the elements. The code generator with then jump
into the loop. This is at best increasing the size
On Mon, Aug 31, 2015 at 6:51 AM, shmeel gutl
wrote:
> When dealing with an array with known values, pre will evaluate the first
> iteration of a loop over the elements. The code generator with then jump
> into the loop. This is at best increasing the size of the code. It also
> creates inferior co
On Mon, Feb 9, 2015 at 11:11 AM, Ricardo Telichevesky wrote:
> Hello Renato, thanks for your reply, sorry about the confusion with
> compilers - since there is a "clang" in the mac, I thought gcc was gcc..
> After your suggestion, I modified the code, and installed a bona fide gcc
> compiler in th
Hello Renato, thanks for your reply, sorry about the confusion with compilers - since there is a "clang" in the mac, I thought gcc was gcc.. After your suggestion, I modified the code, and installed a bona fide gcc compiler in the Mac I got more data that is kind of interesting, wanted to share
On 23 January 2015 at 16:07, Ricardo Telichevesky wrote:
> gcc: Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) - don't
> know what that means expected a number like 4.2.1 or something like that,
> 2.53 GHz Intel Core 2 Duo
Hi Ricardo,
This is not gcc at all, it's Clang+LLVM. :/
Thanks Richard for your input, much appreciated.
I followed up on your suggestions; unfortunately the -Wdisabled-optimization option you suggested did not cause any warnings. Still trying one by one the --params options without success. I got a new hint, though, running the same examples on a
On Tue, Jan 20, 2015 at 4:57 AM, Ricardo Telichevesky wrote:
> Hi,
>
> I have a strange problem with extremely large procedures when generating
> 64-bit code
> I am using gcc 4.9.2 on RHEL6.3 on a 64-thread 4-socket Xeon E7 4820 with
> 256GB of memory. No avx extensions, using sse option whe
On Fri, 26 Sep 2014, Jakub Jelinek wrote:
> > One related question: the __builtin_signbit is not type generic, is there
> > any reason for it not to be? Is there any reason for it not to be? I ask
>
> I guess history, builtins that were added earlier when we didn't have any
> typegeneric builti
On Fri, Sep 26, 2014 at 11:07:28AM +0200, FX wrote:
> > Thus, the middle-end assumes that if you have __builtin_{isfinite,isnormal},
> > you also have __builtin_is{less,greater}equal builtins too.
>
> Many thanks to both of you! I wasn’t looking into the right place at all. I
> defined them, and
> Thus, the middle-end assumes that if you have __builtin_{isfinite,isnormal},
> you also have __builtin_is{less,greater}equal builtins too.
Many thanks to both of you! I wasn’t looking into the right place at all. I
defined them, and now it works.
One related question: the __builtin_signbit is
On Fri, Sep 26, 2014 at 10:29:57AM +0200, FX wrote:
> Hi,
>
> I’m trying to make the Fortran front-end emit calls to some builtins we don’t
> currently use (isfinite, isnormal). However, trying to use the same code as
> isnan doesn’t work at all. Our gfc_define_builtin does three things:
>
>
On Fri, Sep 26, 2014 at 10:29 AM, FX wrote:
> Hi,
>
> I’m trying to make the Fortran front-end emit calls to some builtins we don’t
> currently use (isfinite, isnormal). However, trying to use the same code as
> isnan doesn’t work at all. Our gfc_define_builtin does three things:
>
> decl = ad
On Thu, May 15, 2014 at 08:01:13AM +0200, Siegmar Gross wrote:
> I'm using gcc-4.9.0 and have a problem with the following program.
> I have reported the problem allready on gcc-help some days ago,
> but didn't get any replies. Perhaps somebody in this list knows,
> if the behaviour is intended.
Y
On 15.05.2014 08:01, Siegmar Gross wrote:
#include
#include
#include
int main (void)
{
#pragma omp parallel default (none)
fprintf (stderr, "Hello!\n");
return EXIT_SUCCESS;
}
I get the following error, when I try to compile the program
on "Solaris 10 Sparc".
tyr OpenMP 116 \gcc -
On Wed, Mar 27, 2013 at 3:13 AM, Nikhil Patil wrote:
> Hello everyone,
>
> I am trying to understand the points-to analysis ("pta") ipa pass, but
> I am not able to match the information generated by the pass and that
> in structure "SSA_NAME_PTR_INFO".
>
> For the code segment,
>
> --
Hi Martin
/> It seems to me however that PLUGIN_ALL_IPA_PASSES_END runs prior to
trnsformation phase of IPA passes (the name is rather unclear in this
regard)...//
/
If i am not wrong the PLUGIN_ALL_IPA_PASSES_START ( execution ) is hooked in
the begging of
all_smole_ipa_passes , before ALL_SI
Hi,
On Tue, Jan 29, 2013 at 12:44:07AM -0500, Chassin wrote:
> Hi again , this time i am trying to clone a function then insert it
> with new name
>
If you want to create a clone of a function including its body, you
probably want to use cgraph_function_versioning. See how it is used
in ipa-spl
On Tue, Jan 29, 2013 at 6:44 AM, Chassin wrote:
> Hi again , this time i am trying to clone a function then insert it with new
> name
>
> sample code
>
> struct cgraph_node *old_node = util_get_cgnode_by_name((char *)user_data);
> struct cgraph_node *new_node ;
>
> tree old_decl = old_node->d
> I'm currently trying to retarget the gcc backend to a VLIW architecture
> developed in my workgroup.
> This architecture has a branch delay slot, so i tried the following
> (according to http://gcc.gnu.org/onlinedocs/gccint/Delay-Slots.html):
>
> (define_attr "type" "branch,other" (const_string
On Thu, 23 Aug 2012, jojelino wrote:
> On 2012-08-20 AM 6:44, Ji?í Pale?ek wrote:
> > Hello,
> >
> > I tried to run "make check-c++" from the top directory of the source
> > code. During the run, all of the libgomp tests run by it failed. From
> > the log file, you can see that the gcc from the sys
On 2012-08-20 AM 6:44, Jiří Paleček wrote:
Hello,
I tried to run "make check-c++" from the top directory of the source
code. During the run, all of the libgomp tests run by it failed. From
the log file, you can see that the gcc from the system (rather than the
gcc currently built) was run:
Exec
Hello Jiří,
I think this question should be directed at gcc-h...@gcc.gnu.org.
Please send any response to this email there.
Jiří Paleček a écrit:
> I tried to run "make check-c++" from the top directory of the source
> code.
Quoted from http://gcc.gnu.org/install/configure.html:
we highly
On Wed, 2012-06-06 at 23:19 +0200, Eric Botcazou wrote:
> > This is a followup mail to http://gcc.gnu.org/ml/gcc/2012-05/msg00400.html
> > now that I understand my problem better and can change the subject line to
> > reflect that.
>
> I'm not sure whether digging into the behavior of the driver i
> This is a followup mail to http://gcc.gnu.org/ml/gcc/2012-05/msg00400.html
> now that I understand my problem better and can change the subject line to
> reflect that.
I'm not sure whether digging into the behavior of the driver is the best way to
solve this kind of testsuite problems. I think
PERRONNET Alain wrote:
My program and subroutines are mainly written in fortran 77 with blanck
common of different sizes.
If the program and subroutines are compiled with the option -g the
load-module is OK.
if the program and subroutines are compiled with the option -O the
execution
of the lo
This mailing list is for discussing development *of* gcc, not help
using it. Your question would be appropriate on the
gcc-h...@gcc.gnu.org list, please take any follow-up there, thanks.
On 7 February 2012 13:57, Alexandre Almeida wrote:
>
> It seems to be impossible to define an inline member fun
On Tue, Aug 2, 2011 at 11:24 AM, Toon Moene wrote:
> What am I doing wrong:
>
> configure:3247: checking for suffix of object files
> configure:3269: /home/toon/compilers/obj-t/./gcc/xgcc
> -B/home/toon/compilers/obj-t/./gcc/ -B/tmp/lto/x86_64-unknown-linux-gnu/bin/
> -B/tmp/lto/x86_64-unknown-lin
On 21 June 2011 10:39, Aneesh V wrote:
> Not sue if this is the right place to report this problem.
It's not, as explained on the website.
As stated at http://gcc.gnu.org/lists.html for help using GCC you
should use the gcc-help list, or to report bugs see the "How to
report" link on the GCC home
Try strtold() perhaps. It happily reads all the formats (15892938475,
1.5892938475E10 etc) you asked for.
If the significand part of the float is as large or larger than the
int type, then you can convert the result to an int type with no loss
of precision. 80 bit long double (common on x86) has
Sean Robert McGuffee writes:
> Regarding all the scanf functions reading long values
> (sscanf,fscanf,scanf,... etc...).
I'm sorry, this is the wrong mailing list. gcc is just the compiler.
Functions like sscanf, fscanf, scanf are part of the C library. gcc
does not provide a C library.
In an
Camo Johnson writes:
> So NOW it is a direct store operation. And the compiler crashes with the
> following error message:
>
> ../uart2sim/uart2i_3.c: In Funktion »main«:
> ../uart2sim/uart2i_3.c:307: Fehler: Befehl erfüllt nicht seine Bedingungen:
> (insn 44 41 45 4 ../uart2sim/uart2i_3.c:272 (
Alex Chen writes:
> The srtange thing is that those missing libraries are in
> /usr/local/lib and only some libraries are flagged as 'not found'
> while some libraries are fine.
This question is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for gcc developers. It would be appro
On Fri, Apr 15, 2011 at 12:33 AM, Camo Johnson wrote:
>
> Hello,
>
> I'm currently writing a gcc 4.4.5 backend for an 18 bit architecture.
> I have a c-project with some thousand lines of code. Without optimizations it
> compiles. But with -O1 and -O2 I encounter a problem in the induction
> vari
Hello Ian,
On 28.12.10 06:37, Ian Lance Taylor wrote:
Seems like you don't have a cbranchMODE4 insn in the required mode.
Double check that. You should only get to that assert if there is no
cbranch pattern. To assert is indicating that if there is no cbranch
pattern there has to be a cmp patt
Christian Grössler writes:
> Sorry, the line numbers in the ICE are wrong, since I added some debug
> messages.
> The abort happens here in prepare_cmp_insn():
>
> /* Handle a libcall just for the mode we are using. */
> libfunc = optab_libfunc (cmp_optab, mode);
> gcc_assert
On 28.12.10 00:22, Ian Lance Taylor wrote:
Christian Grössler writes:
Looking at the history of optabs.c, the MODE_CC test was introduced when
merging the cond-optab branch
to main. I didn't find a description of the cond-optab branch and what it was
supposed to do.
This is the description
Christian Grössler writes:
> Looking at the history of optabs.c, the MODE_CC test was introduced when
> merging the cond-optab branch
> to main. I didn't find a description of the cond-optab branch and what it was
> supposed to do.
This is the description of the now-merged cond-optab branch, f
Hi Ian
Thanks for the response.
All of those flags are set correctly, though it is still emitting
loads and stores 4 byte aligned and not 8. I'm trying to get the
compiler to combine two 4 byte loads in to a single 8 byte load as it
is more efficient on this architecture, so I'm guessing because
Neil Hickey writes:
> I'm porting gcc to a new architecture and I'm allowing use of movdi
> instructions as the processor allows 8 byte loads. The processor
> however requires 8 byte loads and stores to be naturally aligned, yet
> gcc seems to be emitting loads and stores that are 4 byte aligned.
Jeff Law writes:
>> If
>> there is any register pressure, B is going to go onto the stack or is
>> going to force something else onto the stack.
> Not today, which is the problem.
Well, I was implicitly anding in the clause "if the compiler were
correct."
Ian
On 10/19/10 14:42, Ian Lance Taylor wrote:
Jeff Law writes:
Reload has the ability to replace a pseudo with its equivalent memory
location. This is fine and good.
Imagine:
1. We have a pseudo (call is pseudo A) with a read-only memory
equivalent. Pseudo A does not get a hard reg
2.
Jeff Law writes:
> Reload has the ability to replace a pseudo with its equivalent memory
> location. This is fine and good.
>
> Imagine:
>
> 1. We have a pseudo (call is pseudo A) with a read-only memory
> equivalent. Pseudo A does not get a hard reg
>
> 2. Pseudo A crosses a call (because
Hello,
* FX wrote on Sun, Oct 03, 2010 at 11:22:50AM CEST:
> > This is a known issue and related to timestamps of those generated
> > .texi files. By touching generated .texi it can be solved.
Hacked around, I would say, not solved.
I guess to solve it, genhooks should produce output in binary m
On Sun, Oct 3, 2010 at 6:05 AM, FX wrote:
>> This is a known issue and related to timestamps of those generated
>> .texi files. By touching generated .texi it can be solved. This test
>> in make is here a bit broken IMHO, as a content check would satisfy
>> needs for validity-check alone.
>
> Actu
> This is a known issue and related to timestamps of those generated
> .texi files. By touching generated .texi it can be solved. This test
> in make is here a bit broken IMHO, as a content check would satisfy
> needs for validity-check alone.
Actually, it doesn't solve it. If "cpmd -s" returns fa
> This is a known issue and related to timestamps of those generated
> .texi files. By touching generated .texi it can be solved. This test
> in make is here a bit broken IMHO, as a content check would satisfy
> needs for validity-check alone.
I'm wondering about this part of the Makefile:
2010/10/3 FX :
> Hi all,
>
> I'm trying to bootstrap trunk on i686-pc-mingw32. I configure with
> --disable-werror --enable-threads --disable-nls --build=i686-pc-mingw32
> --enable-libgomp --with-dwarf2 --disable-sjlj-exceptions
>
> During stage 1, bootstrap fails when comparing trunk tm.texi and
On 7/9/2010 4:44 PM, Anthony Green wrote:
Building and testing the moxie-uclinux toolchain with the HEAD of GCC
is very simple:
$ git clone git://github.com/atgreen/moxiedev
$ cd moxiedev/gcc
$ ../scripts/fix-svn.sh
$ ./contrib/gcc_update
$ cd ..
$ PATH=`pwd`/root/usr/bin:$PATH
$ ant build
Of
On 7/9/2010 11:59 AM, Maxim Kuvyrkov wrote:
On 7/9/10 3:22 PM, Anthony Green wrote:
Hi Maxim,
Recent changes to config.gcc are preventing me from building a
moxie-uclinux toolchain.
Anthony,
What is the error the build process is failing on?
Here are the details:
Without OPTION_ANDROID=0:
On 7/9/10 3:22 PM, Anthony Green wrote:
Hi Maxim,
Recent changes to config.gcc are preventing me from building a
moxie-uclinux toolchain.
Anthony,
What is the error the build process is failing on?
Thanks,
--
Maxim Kuvyrkov
CodeSourcery
ma...@codesourcery.com
(650) 331-3385 x724
Thank you everyone!!!
I found out a solution...
I had to add a line to my pass (the 2nd if):
for (node = cgraph_nodes; node; node = node->next) {
if (node->analyzed && cgraph_is_master_clone (node)) {
if (!gimple_in_ssa_p (DECL_STRUCT_FUNCTION (node->decl))) return 0; // I
added this line
On Fri, Apr 30, 2010 at 10:48, Michael Matz wrote:
>> For default SSA names, the defining statement will be NULL.
>
> Nope, it will be non-NULL but gimple_nop_p().
Bah! yes, of course. Sorry about that.
Diego.
Hi,
On Fri, 30 Apr 2010, Diego Novillo wrote:
> On 4/30/10 09:35 , Massimo Nazaria wrote:
>
> > fprintf (dump_file, "gimple_code: %d\n",
> > gimple_code (def_stmt)); // Here I get segmentation fault...
>
> For default SSA names, the defining statement will be
On Fri, Apr 30, 2010 at 3:35 PM, Massimo Nazaria wrote:
>> You'll have to post your work so people can see. Now the
>> best the
>> experts here can do is guess what you're holding behind
>> your back :-)
>>
>> Ciao!
>> Steven
>>
>
> I completely agree with you. This is my pass:
>
> static unsigned
On 4/30/10 09:35 , Massimo Nazaria wrote:
> fprintf (dump_file, "gimple_code: %d\n",
> gimple_code (def_stmt)); // Here I get segmentation fault...
For default SSA names, the defining statement will be NULL. A default
SSA name will be created when a symbol is n
> The place where you insert the patch is as important as
> the
> implementation of your patch. What do your changes to
> passes.c look
> like?
Here is the "passes.c":
NEXT_PASS (pass_early_warn_uninitialized);
NEXT_PASS (pass_all_early_optimizations);
NEXT_PASS (pass_mypass); //
On Fri, Apr 30, 2010 at 3:35 PM, Massimo Nazaria wrote:
>> You'll have to post your work so people can see. Now the
>> best the
>> experts here can do is guess what you're holding behind
>> your back :-)
>>
>> Ciao!
>> Steven
>>
>
> I completely agree with you. This is my pass:
The place where yo
> You'll have to post your work so people can see. Now the
> best the
> experts here can do is guess what you're holding behind
> your back :-)
>
> Ciao!
> Steven
>
I completely agree with you. This is my pass:
static unsigned int
execute_mypass (void)
{
basic_block bb;
gimple stmt, def_stm
On Fri, Apr 30, 2010 at 1:42 PM, Massimo Nazaria wrote:
>> You have to schedule your IPA pass at a point where the
>> whole
>> program is in SSA form, which is during the regular IPA
>> passes
>> at earlierst.
>>
>> Richard.
>>
>
> It does not work :(
> I put my pass after all the ipa-passes and r
On Fri, Apr 30, 2010 at 1:42 PM, Massimo Nazaria wrote:
>> You have to schedule your IPA pass at a point where the
>> whole
>> program is in SSA form, which is during the regular IPA
>> passes
>> at earlierst.
>>
>> Richard.
>>
>
> It does not work :(
> I put my pass after all the ipa-passes and r
> You have to schedule your IPA pass at a point where the
> whole
> program is in SSA form, which is during the regular IPA
> passes
> at earlierst.
>
> Richard.
>
It does not work :(
I put my pass after all the ipa-passes and right before the optimization-passes.
My problem occurs when I try t
On Thu, Apr 29, 2010 at 7:28 PM, Massimo Nazaria wrote:
> Hi everybody!
> I am working on a gcc-pass which processes every statement using this code:
>
> for (node = cgraph_nodes; node; node = node->next)
> {
> if (node->analyzed && cgraph_is_master_clone (node))
> {
> pus
Thank you very much!!! :D
--- Mer 24/3/10, Ian Lance Taylor ha scritto:
> Da: Ian Lance Taylor
> Oggetto: Re: Problem with ADDR_EXPR array offset
> A: "Massimo Nazaria"
> Cc: gcc@gcc.gnu.org
> Data: Mercoledì 24 marzo 2010, 23:59
> Massimo Nazaria
> writes:
>
Massimo Nazaria writes:
> I'm working on a pass and I need to handle some pointer expressions.
> For example, I have this C-code:
> int v[1000];
> int *p;
> p = &v[10];
>
> The problem is that, when I'm trying to parse "p = &v[10];", I'm not able to
> get the array offset (10 in this cas
On 18/02/2010 10:11, Naveen H. S wrote:
> Issue
> -
> Float variables are prefixed by some garbage value in printf function.
> However, the values are generated correctly when seen through GDB.
> Ex:- If the expected result is 0.456
> RUN OUTPUT - 0.00456 (INCORRECT)
> GDB OUTPUT - 0.456
Richard Guenther wrote:
On Sat, Feb 6, 2010 at 3:44 AM, Martin Chaney wrote:
This problem showed up in a PDP10 C version of GCC I'm responsible for and
took a good while to track down. The fix is in generic gcc code so even
though my PDP10 compiler is not an official gcc version and I haven
Hi,
On Sat, 6 Feb 2010, Richard Guenther wrote:
> > CSE detects that the same subexpression is used in two places and
> > substitutes a reaching register for the reference to u32.word without
> > noticing that the memory has been modified by the bit field reference.
> > Adding a call to invalida
On Sat, Feb 6, 2010 at 3:44 AM, Martin Chaney wrote:
> This problem showed up in a PDP10 C version of GCC I'm responsible for and
> took a good while to track down. The fix is in generic gcc code so even
> though my PDP10 compiler is not an official gcc version and I haven't been
> successful at
1 - 100 of 454 matches
Mail list logo
