p, but could not find a hint on
the web that VLA arguments are forbidden to alias.
Am I overlooking something here? Why is "restrict" not useful in that
context (but -fargument-noalias is)? And why does it work for VLAs
without any of both?
Regards,
Markus
parallelize the loop. (Tree level
if-conversion for vectorizer)
Are there also some other optimisation passes working on the GIMPLE/SSA
representation which make use of any machine-dependent features?
Thanks for help,
Markus Franke
PAREN"
"ASM_GLOBALIZE_LABEL"
"FUNCTION_ARG_PARTIAL_NREGS"
--snap---
I read something about poisened macros and that they shouldn't be used
anymore. But in fact I was not able to find any documentation about
these macros. When were they declared as poisened and especially why?
What should be done instead of using this macros? Just uncommenting
everything can't be a solution. I was also looking in GCC-Internals
manual without any success.
Thanks for your help,
Markus Franke
me kind of standard set of Header-Files
exists which is needed by every backend? Can somebody give me a list or
something like that. I had already a look at the Internals Manual but
without finding something about it.
Thanks in advance,
Markus Franke
standardised code in order to contribute my
development. I would appreciate any help. By the way, I already had a
look in the GCC Internals manual but I am still a bit confused.
Thanks in advance and regards,
Markus Franke
Thank you for your response. I understood everything you said but I am
still confused about the file -protos.h. Which prototypes have
to be defined there?
Thanks in advance,
Markus Franke
pranav bhandarkar wrote:
>> I am wondering where to define the prototypes for functions in
>>
Thank you very much. That was exactly the information I was looking for.
I will think about a contribution to the GCC Internals.
Thanks again,
Markus Franke
Rask Ingemann Lambertsen wrote:
> On Tue, Jan 16, 2007 at 11:24:56AM +0100, Markus Franke wrote:
>
>
>>I am wondering wher
rect what can I do to change it to the other way
around. Which macro variable do I have to change?
Thanks in advance,
Markus Franke
(4.1.1). I just wanted to know whether I can correct this, but
if not its also OK.
Thanks,
Markus
Robert Dewar wrote:
> Markus Franke wrote:
>
>> Please let me know whether I missunderstood something completely. If
>> this behaviour is correct what can I do to change it to the o
al\\t%S0%("
[(set_attr "type" "jump")
(set_attr "mode" "none")])
---snap---
I think the warning is caused by the second parameter of the set
instruction, right? But I don't know where to specify the source mode. I
had already a look into the GCC Internals Manual without success.
Any suggestions how to fix this problem?
Regards,
Markus Franke
Hello,
thank you for your answer. Having changed the code in the way you
suggested I get still the same warning message.
Any further suggestions?
Regards,
Markus
Ian Lance Taylor wrote:
> Markus Franke <[EMAIL PROTECTED]> writes:
>
>
>>---snip---
>>;;
>&
Ian Lance Taylor wrote:
> Oh, yeah, you probably want to say call:SI too.
Yes I can do this and the warning message disappears. But now I get an
internal error message about a non matching rtl expression when
compiling a test program. Without "call:SI" I get warnings during
compilation but the com
uot;jump")
(set_attr "mode" "none")])
---snap---
> Actually, most targets don't use a mode with call, since a call can
> often return multiple modes. But then they don't use a mode for the
> result of the call, either. Look at what other targets do.
Till, now I haven't found a similar template where the return value
which is set is a "reg:SI". I will keep on searching :-)
Regards,
Markus Franke
--snap---
This pattern matches for function calls but unfortunately now I get a
segmentation fault during compilation of the following program:
---snip---
int odd(int i)
{
return i & 0x1;
}
int
foo(int i, int j)
{
int a;
a=odd(i+j);
return a;
}
---snap---
The segmentation fault occurs in th
sage.
---snip---
int odd(int i)
{
return i & 0x1;
}
int foo(int i, int j)
{
int a;
a=odd(i+j);
return a;
}
---snap---
If simply omit the "a=odd(i+j)"-line everything works fine so it has
something to do with this call.
What am I doing wrong? It seems so simple but I can't figure out what's
wrong with my pattern.
Regards,
Markus Franke
HARD_REGNO_MODE_OK (regno, rl->mode))
---snap---
This causes in the end the error message because no suitable registers
could be found.
Does anybody have an idea what could be wrong in the machine description
or to where start finding the error?
Any suggestions are welcome.
Regards,
Markus Franke
--
Nichts ist so praktisch wie eine gute Theorie!
ger reg, then 8 insns would need reloads.
Ok that's clear. Thanks for explaining. Nevertheless I can't figure out
from the above files what's wrong and maybe I am just lacking of the
right interpretation of these intermediate files.
Can you figure out any abnormal behaviour from the above file excerpts?
Thanks in advance,
Markus Franke
Again with attachment and CC to the Mailing List. Sorry for missing this.
Regards,
Markus
---
Hello,
thanks for your instructions. Indeed you were right. I mixed up some files.
Again an excerpt of the output-files:
---snip--- // expand
(insn 45 47 46 1 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4
On Tue, Nov 08, 2005 at 09:17:10AM -0700, Mark Cuss wrote:
> Hi Eric
>
> sparc-sun-solaris2.9-objdump -f returns the following:
> libc.so:
> start address 0x
> ...
Congratulations, this must be the longest top-post ever.
--
Markus
> work. If you still get a failure, this is a pre-existing bug.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 for a small
testcase.
It looks like this is not a pre-existing issue, because with your
sanity check there is not failure.
--
Markus
y frustrating thing for me is "git bisect" doesn't always
> work. I think cherry-pick is OK, but probably not rebase nor merge.
>
> Can we enforce that "git bisect" must work on official branches?
The Linux kernel uses merges all the time, yet "git bisect" works
without any issues. So this not a reason to forbid merges.
BTW while I have your attention: Why are you constantly creating
(rebasing) and deleting branches? Why not simply use a local git tree
for this purpose?
--
Markus
correlate with ChangeLogs,
> etc.) Won't that work better than the ML archives?
Another possibility would be to simply use the @gcc.gnu.org addresses.
That should make the mapping pretty straightforward.
--
Markus
sue still persists, please post the exact errors that you
encounter.
--
Markus
t; case would need to compile correctly to an object file -- so "delta"
> is reducing it very slowly. So far I'm down from 11MB preprocessed
> source to 1.1MB preprocessed source after running delta a few times.
These undefined references are normally user errors. For exampl
On 2015.11.23 at 11:11 -0800, Steven Noonan wrote:
> On Tue, Nov 17, 2015 at 1:09 AM, Markus Trippelsdorf
> wrote:
> > On 2015.11.16 at 14:18 -0800, Steven Noonan wrote:
> >> Hi folks,
> >>
> >> (I'm not subscribed to the list, so please CC me on all re
filed. couldn't seem to find docs for how
> to request this, so spamming this list.
Just log in with your gcc email address...
--
Markus
nd
crash for this reason. -fno-delete-null-pointer-checks is a workaround.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68853 for an analysis
of the Chromium crash.
--
Markus
e googletest in their testsuite may be affected.
I've opened: https://github.com/google/googletest/issues/705
--
Markus
t page just
> points to the mailing list archive. There is no option to subscribe
> it.
https://sourceware.org/lists.html#ml-requestor
--
Markus
delete-null-pointer-checks.
So the kernel obviously is already using its own C dialect, that is
pretty far from standard C.
All these options also have a negative impact on the performance of the
generated code.
--
Markus
... The side effect of updating the stored value of the left operand
> shall occur between the previous and the next sequence point."
No. We discussed this on IRC today and Richard Biener pointed out that
bar cannot make c point to &c - 8, because computing that pointer would
be invalid. So c->f1_ cannot clobber c itself.
--
Markus
an either use -fno-diagnostics-color in your CFLAGS or configure
gcc with: --with-diagnostics-color=never.
--
Markus
e read the
comments in gcc/diagnostic-color.c.
--
Markus
GCC bug?
I don't think so. All compilers (clang, icc, visual C++) behave the
same.
Also these kinds of questions regarding the C++ standard should be asked
on a more appropriate forum like stackoverflow.com or the ISO C++ group:
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-discussion
--
Markus
> behavior I'm unknowingly invoking in the code, or it may be a code
> generation bug in gcc. I tried to isolate the exact gcc commit that
> caused the change, but I got stuck...
You should check this first by compiling with -fsanitize=undefined and
fixing all issues that may pop up.
--
Markus
The git server seems to be stuck for over a day.
Latest revision on it is r243504.
Latest svn revision is r243523.
--
Markus
On 2016.12.11 at 09:59 -0500, Jason Merrill wrote:
> On Dec 11, 2016 2:41 AM, "Markus Trippelsdorf"
> wrote:
> > The git server seems to be stuck for over a day.
> > Latest revision on it is r243504.
> > Latest svn revision is r243523.
> Yes, someone branched
gt; find a way to accelerate the compilation in a single file. Can we
> change some serial process into
>
> Parallel? Could you give me some advices? Thank you very much.
Compiling with -flto= and gcc-4.9 should help.
--
Markus
r, the next release should be 10.0, not 5.0.
>
> 10.0 would be even better from a marketing perspective.
Since gcc is released annually why not tie the version to the year of
the release, instead of choosing an arbitrary number?
15.o
--
Markus
to narrow down the issue is to use git (or svn) bisect to
find out which gcc revision causes the miscompile. Then you can md5sum
the kernel object files for the bad revision and for the first good
revision and compare the results. After that you can look at the
disassembly of the object files, for which md5sum differs, and try to
figure out the reason why.
--
Markus
g=bootstrap-lto
>
> then did a profiledbootstrap make
When using profiledbootstrap you should add --disable-werror to the
configuration flags.
--
Markus
On 2014.09.19 at 14:55 +0200, Markus Trippelsdorf wrote:
> On 2014.09.19 at 13:15 +0100, Rogelio Serrano wrote:
> > /home/rogelio/gcc-build/./prev-gcc/g++
> > -B/home/rogelio/gcc-build/./prev-gcc/ -B/x86_64-unknown-linux-gnu/bin/
> > -nostdinc++
> > -B/home/rogelio/gc
> a.c:6:11: error: overriding final function ‘virtual Base::~Base()’
> virtual ~Base() final {}
What about:
class Derived final: public Base {};
--
Markus
defines like
__ARM_LPC1114__, __ARM_STM32F405__, etc.
- How would we proceed in general?
- Many flavours at once, or better start with one or two, adding more when
these work?
- Did AVR support make things we should not repeat?
Thanks for discussing,
Markus
P.S.: arm-libc discussion so f
Am 13.11.2014 um 14:08 schrieb Fabien Chêne:
> Perhaps that would make sense to mention the existence of the compile
> farm, and add link to it.
Good idea. Bonus points for adding a script which executes all the required
steps.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. In
On 2014.11.21 at 16:16 +0100, Toon Moene wrote:
> See: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02259.html
>
> What's not in the log file sent to gcc-results:
See: http://thread.gmane.org/gmane.comp.gcc.patches/327449
--
Markus
gcc-help is more appropriate for this kind of question.
If you compile with gcc-5 and -fsanitize=undefined you'll get:
mystring.cpp:104:26: runtime error: null pointer passed as argument 2, which is
declared to never be null
So you should guard the memcpy() call.
--
Markus
if it is 5.1, then after branching for release of
> 5.0, trunk will become 6.0, no?
http://gcc.gnu.org/develop.html#num_scheme
--
Markus
On 2015.03.21 at 12:11 -0400, Jack Howarth wrote:
> On Sat, Mar 21, 2015 at 1:45 AM, Markus Trippelsdorf
> wrote:
> > On 2015.03.20 at 20:08 -0400, Jack Howarth wrote:
> >> What was the final decision concerning future versioning of FSF
> >> gcc post-5.0? In p
On 2015.05.07 at 13:46 -0500, Jason Merrill wrote:
> I think it's time to switch to C++11 as the default C++ dialect for GCC
> 6. Any thoughts?
Why not C++14?
--
Markus
disabled: 57m12s (99.33%)
Measuring the impact on bigger projects that use pch like QT or Boost
would be more informative perhaps.
And until C++ modules are implemented (unfortunately nobody is working
on this AFAIK) pch is still the only option left. So deprecating them
now seem premature.
--
Markus
If yes, can we have
documentation upgraded to clearly state that this use case is valid?
Thank you.
Markus
um 16:08 Uhr
> Von: "Alexander Monakov"
> An: "Richard Earnshaw (lists)"
> Cc: "Paul Koning" , "Markus Fröschle"
> , gcc@gcc.gnu.org
> Betreff: Re: asking for __attribute__((aligned()) clarification
>
> On Mon, 19 Aug 2019, Richard Earnshaw (l
e's preferred markup of
> adding a comment to explicitly note a fall through. Candidate
> individual to complain to
>
> If he added a new option affecting libgfortran, then he should
> fix up libgfortran.
He didn't add the warning to specifically annoy fortran developers.
It is trivial to add seven gcc_fallthrough() or breaks for someone who
knows the code and the person who added the warning obviously doesn't.
--
Markus
On 2017.03.27 at 06:26 -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 08:58:43AM +0200, Markus Trippelsdorf wrote:
> > On 2017.03.26 at 19:30 -0700, Steve Kargl wrote:
> > > On Sun, Mar 26, 2017 at 06:45:07PM -0700, Jerry DeLisle wrote:
> > > > On 03/26/20
On 2017.03.27 at 07:44 -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 03:39:37PM +0200, Markus Trippelsdorf wrote:
> >
> > Well, a missing break is a bug. No?
>
> Every 'case' statement without exception must be accompanied by
> a 'break' state
to build a whole
>distro. On my Gentoo test box anything but level 1 is simply
>unacceptable, because you will miss important other warnings
>in the -Wimplicit-fallthrough noise otherwise.
The quotation doesn't have anything to do with the current discussion,
which is the general usefulness of the warning.
It only talks about one of the (admittedly over-engineered) six
different levels of the warning.
--
Markus
NULL;
>gimplify_stmt (&DECL_SAVED_TREE (fndecl), &seq);
Haha, your option also has dramatic binary size saving effects.
I would suggest to enable it unconditionally on every April Fools' Day.
--
Markus
istic (void)
phys_kbytes = MIN (phys_kbytes, limit_kbytes);
phys_kbytes = MAX (phys_kbytes, 4 * 1024);
- phys_kbytes = MIN (phys_kbytes, 128 * 1024);
+ phys_kbytes = MIN (phys_kbytes, 1000 * 1024);
return phys_kbytes;
}
--
Markus
On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote:
> On Sun, 9 Apr 2017, Markus Trippelsdorf wrote:
>
> > The minimum size heuristic for the garbage collector's heap, before it
> > starts collecting, was last updated over ten years ago.
> > It currently ha
On 2017.04.09 at 20:23 +0200, Richard Biener wrote:
> On Sun, Apr 9, 2017 at 4:41 PM, Markus Trippelsdorf
> wrote:
> > The minimum size heuristic for the garbage collector's heap, before it
> > starts collecting, was last updated over ten years ago.
> > It curren
On 2017.04.09 at 21:10 +0200, Markus Trippelsdorf wrote:
> On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote:
> > On Sun, 9 Apr 2017, Markus Trippelsdorf wrote:
> >
> > > The minimum size heuristic for the garbage collector's heap, before it
> > > starts
On 2017.04.10 at 10:56 +0100, Richard Earnshaw (lists) wrote:
> On 09/04/17 21:06, Markus Trippelsdorf wrote:
> > On 2017.04.09 at 21:10 +0200, Markus Trippelsdorf wrote:
> >> On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote:
> >>> On Sun, 9 Apr 2
On 2017.04.10 at 12:15 +0200, Markus Trippelsdorf wrote:
> On 2017.04.10 at 10:56 +0100, Richard Earnshaw (lists) wrote:
> >
> > What are the numbers with 256M?
>
> Here are the numbers from a 4core/8thread 16GB RAM Skylake machine.
> They look less stellar than the ppc6
On 2017.04.10 at 13:14 +0100, Richard Earnshaw (lists) wrote:
> On 10/04/17 12:06, Segher Boessenkool wrote:
> > On Mon, Apr 10, 2017 at 12:52:15PM +0200, Markus Trippelsdorf wrote:
> >>> --param ggc-min-heapsize=131072
> >>> 11264.89user 311.88system 24:18.69e
e if this email goes through the machines that are having problems
> it may not get anywhere
Yes, looks like the sourceware server is having problems:
https://check-host.net/check-ping?host=gcc.gnu.org
--
Markus
n gcc-7_1_0-release
I've added the tag.
--
Markus
least 10), so clearing these things up takes
> time. Some (I'd say most) of the errors I've seen out of
> Git-svn are also not completely intuitive so it's not always
> clear what or where the problem is.
>
> So I'd like to see if there's something that can be done to
> move the migration forward.
The same issue also happen with git when several people push at the same
time.
--
Markus
On 2017.05.18 at 13:42 -0600, Martin Sebor wrote:
> On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote:
> > On 2017.05.18 at 12:41 -0600, Martin Sebor wrote:
> > > On 05/18/2017 11:59 AM, Jeff Law wrote:
> > > > On 05/18/2017 11:41 AM, Martin Sebor wrote:
> > >
On 2017.05.23 at 05:26 -0400, Aldy Hernandez wrote:
> Jason Merrill writes:
>
> > Yes, the git mirror can lag the SVN repo by a few minutes, that's why
> > you need to 'git svn rebase' to pull directly from SVN before a
> > commit.
> >
> > Jason
her than
> just an ICE.
"internal compiler error: Killed" is almost always an out of memory
error. dmesg will show that the OOM killer kicked in and killed the
cc1plus process.
> The system has 858Mb of RAM without the swap file.
>
> Building a single source file seems to use up to 97% of the available memory
> (for a 2522 line C++ source file).
>
> make -j2 is enough to cause the failure.
Well, you should really use a cross compiler for this setup.
--
Markus
fic size.
For many applications using -flto does reduce code size more than just
going from -O2 to -Os.
--
Markus
On 2017.08.26 at 12:40 +0200, Allan Sandfeld Jensen wrote:
> On Samstag, 26. August 2017 10:56:16 CEST Markus Trippelsdorf wrote:
> > On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote:
> > > First let me put into some perspective on -Os usage and some history:
> > > 1
phase (too strong
> optim?)
>
> I haven't seen something relevant to this in the gcc release notes.
>
> More information here:
> https://bugs.llvm.org/show_bug.cgi?id=34140
>
> Does it ring a bell for anyone?
Try building without -gsplit-dwarf?
--
Markus
On 2017.08.26 at 17:18 +0200, Sylvestre Ledru wrote:
>
>
> On 26/08/2017 13:10, Markus Trippelsdorf wrote:
> > On 2017.08.26 at 13:04 +0200, Sylvestre Ledru wrote:
> >> Hello,
> >>
> >> I have been trying to build the llvm toolchain with gcc 7.2 using
has been:
> memcpy(&d_point,
> p,
> sizeof(d_point));
>
> Does this make any sense to anybody?
No. Please open a bug and attach the full program that causes the crash.
Otherwise the issue is impossible to debug.
--
Markus
On 2017.08.29 at 12:35 +0200, Markus Trippelsdorf wrote:
> On 2017.08.29 at 12:31 +0200, Marco Varlese wrote:
> > Hi,
> >
> > I got a SEGFAULT in my program when compiling it with gcc-7 but it
> > is/was all good when using gcc-6.
> >
> > The SEGFAULT hap
; futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
> unavailable)
To me the whole issue looks related to PR81931.
Are you using a clean build directory? Make sure you have the r251328
fix.
--
Markus
On 2017.08.29 at 12:53 +0200, Martin Liška wrote:
> On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote:
> > On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
> >> On 08/29/2017 12:39 PM, Martin Liška wrote:
> >>> (gdb) bt
> >>> #0 0x3fff950e58e4 in
cc1 is on the futex. as is waiting to read. Could that hang be
> related to what's being discussed here?
No. Ryzen is buggy. If you have a chip that was produced before June
this year, your only option is to RMA it.
--
Markus
internal compiler errors
> we hit. The other issue is that there's no benefit of turning those on for
> SPEC CPU benchmarking as far as I remember but quite a bit of extra
> compile-time cost.
Not to mention the numerous wrong-code bugs. IMHO graphite should
deprecated as soon as possible.
--
Markus
M, Martin Liška wrote:
> >>>> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
> >>>>> On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
> >>>>>> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras
> >>>>>> wrote:
> &
g would work. But running the testsuite takes much to long to
make this approach feasible.
--
Markus
ason for staying with the old 2.2.7a libtool ?
> If not, then does anyone object to my upgrading the gcc, gdb and
> binutils mainline sources ?
Last time I've looked in 2011, libtool's "with_sysroot" was not
compatible with gcc's. So a naive copy doesn't work. But reverting
commit 3334f7ed5851ef1 in libtool before copying should work.
--
Markus
causes random gcc crashes. Not the
best setup for a regression tester...
--
Markus
On 2017.10.11 at 08:22 +0200, Paulo Matos wrote:
>
>
> On 11/10/17 06:17, Markus Trippelsdorf wrote:
> > On 2017.10.10 at 21:45 +0200, Paulo Matos wrote:
> >> Hi all,
> >>
> >> It's almost 3 weeks since I last posted on GCC Buildbot. Here's an
r, etc.) of the bot. As a result variance
goes to the roof and all measurements drown in noise.
So it would be good if there was a strict separation of machines used
for bots and machines used by humans. In other words bots should only
run on dedicated machines.
--
Markus
On 2017.12.15 at 10:21 +0100, Paulo Matos wrote:
>
>
> On 15/12/17 08:42, Markus Trippelsdorf wrote:
> >
> > I don't think this is good news at all.
> >
>
> As I pointed out in a reply to Chris, I haven't seeked permission but I
> am pretty sure
0.0/
Unfortunately it is incompatible with mpc-1.0.3.
Once a new mpc version gets released contrib/download_prerequisites
could be updated.
--
Markus
xit
--enable-clocale=gnu --with-build-config=bootstrap-lto
And built with:
make -j4 BOOT_CFLAGS="-march=native -O2 -pipe"
STAGE1_CFLAGS="-march=native -O2 -pipe" CFLAGS_FOR_TARGET="-march=native
-O2 -pipe" profiledbootstrap
--
Markus
On 2011.07.17 at 18:54 +0200, Markus Trippelsdorf wrote:
> On 2011.07.17 at 18:30 +0200, Richard Guenther wrote:
> > On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou
> > wrote:
> > >> I have measured it at some point and IIRC it was about 10% slower
> > >> (
Revisions 176335 removed the traditional "#include " from
gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
etc.) that implicitly rely on it.
I'm not sure that the gain is worth the pain in this case.
--
Markus
e sync with upstream would be the best option IMO.
--
Markus
gt;
> 2012-01-23 08:26:38.652665266 +0100
> @@ -8375,7 +8375,7 @@
> {
> &ipa_escaped_pt.vars,
> 1,
> -sizeof (ipa_escaped_pt.vars),
> +sizeof (ipa_escaped_pt),
> >_ggc_mx_bitmap_head_def,
> >_pch_nx_bitmap_head_def
> },
> ...
>
>
> Any ideas about the cause?
I've opened a bug for this issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51969
It only happens if you try to build gcc-4.6 with gcc-4.7 on my machine.
--
Markus
expects. I'm not really an expert in this area so I wanted to report it
> here so that more knowledgeable people can decide how to solve the issue...
FYI, the gcc bug can be found here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
--
Markus
e one that will be updated for a
given instruction directly depends on the destination register chosen
for that instruction.
My question is; would it be possible for GCC take advantage of these
"extra" CC registers? And if that should be the case how would I go
about modelling it?
BR
/Markus
pass=0x8993ec0) at
../../trunk/gcc-4.4.1/gcc/passes.c:1280
#18 0x083e2ddc in execute_pass_list (pass=0x8993ec0) at
../../trunk/gcc-4.4.1/gcc/passes.c:1329
#19 0x08531811 in tree_rest_of_compilation (fndecl=0xb7d18400) at
../../trunk/gcc-4.4.1/gcc/tree-optimize.c:420
...
thanks and best regards
/Markus
Hi Adam,
Looks like you were right! My SIZE_TYPE was undefined so it defaulted
to "long unsigned int". Setting it to "unsigned int" solved my
problems.
Thank you very much!
/Markus
2009/8/13 Adam Nemet :
> Markus L writes:
>> I run into an assert in convert_memo
o do this. I have searched the available
ports but have not been able to find any which seem to use its
registers in a similar way. Any advice or pointers to code to look
into would be much appreciated.
Thanks in advance.
/Markus
look for or what I might be doing
wrong.
The GCC version that I am using is 4.4.1.
BR
/Markus
1 - 100 of 131 matches
Mail list logo
