Jonathan Wakely wrote:
Sorry for the late reply. It does indeed fix the problem I saw with 4.0
on FreeBSD, but I'm now seeing this with 3.4.4 20050228 too, so I think
it's a regression introduced in the last 6 weeks or so.
Is the same fix safe to apply to 3.4?
Yes, it should also be safe for gcc-3.
On Fri, 2005-03-04 at 21:32, Vivek Takalkar wrote:
> Could some one help me in building GCC as NATIVE GCC on platform other
> than INTEL PC, say ARM, SPARC, etc.
The procedure for building a native gcc is generally the same regardless
of target. If you know how to build it on one machine, then yo
Gary Funck wrote:
Question: If we assume that a TImode would've been a more efficient mode
to represent the record type above, would it not have been acceptable for
the compiler to promote the alignment of this type to 128, given there
are no apparent restrictions otherwise, or are there other C co
Gary Funck wrote:
When compiled with GCC 3.4.3, at -O2, the ident string above will _not_
appear in the executable. This is apparently expected behavior.
See the docs for __attribute__ ((used)). Contrary to the docs, it works
for more than functions.
However, interestingly,
gcc -fkeep-static-
Giovanni Bajo wrote:
I would like to still get hold of the information that used to be present at
that page because they were in fact very useful.
This is what web search engines are for. Going to yahoo, typing gcc
visibility, and then clicking on the "cached" link for the first search
result, I
feng qiu wrote:
> When I compile with "gcc" ,the output is 6.But the output is 5 when
> using "-fpack-struct" to build,and the "#pragma pack(2)" seems to be
> invalid.What is the reason?
-fpack-struct and #pragma pack(2) are contraditctory instructions, and
-fpack-struct wins. It was never the
Andrew Muraco wrote:
After the compiler is installed im going to recompile glibc using gcc
4.0 and recompile other major parts of the system
This is probably more trouble than it is worth. gcc-4 won't be fully
ABI compatible with gcc-3.4, and you are likely to find bugs in gcc and
various other
Steve Kargl wrote:
I'm looking to the broken behavior of gfortran with its
-r8, -i8, and -d8 options. gfortran/lang.opt contains
You can't choose any name for front-end options. There are complicated
rules for determining whether an option is for the gcc driver or
preprocessor or front-end or b
Balaji S wrote:
But, i'm not able to access target specific attribute from second level
of indirection onwards.
For example,
int **gpi ;
Note that in this case finding the target means indirecting through a
memory address, and hence we would have to track the attributes of all
memory locations w
Paul Schlie wrote:
Does anyone have any further insight with respect to this potential problem?
I don't believe there is any problem here if attributes are used
correctly. If you need attributes to work differently than they already
do, then you will have to extend gcc yourself.
I also think th
Rajkishore Barik wrote:
Does anyone know how to obtain the overall spill cost for the old reg
alloc of GCC (global.c)?
We don't have existing hooks for this, but it shouldn't be hard for you
to add them yourself. Try looking at the code, see in particular
dump_global_regs in global.c and the u
Denis Zaitsev wrote:
a) Formally, the code is correct. As p->what can never be < 0
according to its type.
I am assuming this is C code. C and C++ have different rules for enums.
This isn't strictly true. The C standard does not say that enums are
unsigned. It only says that they are equivalent
Sachin Sonawane wrote:
But I want to see the Assembly code with no-ops. How do I go for it?
Which construct in .md file or any other file do I need to set for it?
We have no support for emitting padding nops. You would have to modify
the x86 backend to emit them, and this would be a non-trivial
Paul Schlie wrote:
- might forcing sjlj exceptions help? With what consequences?
Perhaps, try it and see. Less efficient C++ EH support. We also have C
extensions for EH support, but they are not widely used.
- or might it be best for me to attempt to refine the baseline exception
data struct
Shaun Jackman wrote:
Why does the above specs snippet cause gcc to forget it's linking
against thumb libraries?
The -mthumb support works by passing extra -L options to the linker.
Try using -v and looking at the linker options.
You didn't include your linker script, but a possibility here is tha
Shaun Jackman wrote:
Is it possible by hacking the specs file to change the target for
arm-elf-gcc from -marm to -mthumb? I tried a few obvious things like
changing marm in *multilib_defaults to mthumb, but this did not have
the desired effect.
You have to do more than that. multilib_defaults only
Fredrik Hugosson wrote:
My proposal is the following new options:
-fglobalize-symbol=SYMBOLNAME
-fglobalize-symbols=FILENAME
-fglobalize-all-symbols
It is unlikely someone will volunteer to implement a feature that only
you need.
Globalizing a symbol in a shared library is potentially unsafe, and
On Thu, 2005-03-10 at 15:27, Joe Buck wrote:
> On Thu, Mar 10, 2005 at 12:39:28PM -0800, James E Wilson wrote:
> > Also, it is probably a little early to worry about this, as the gcc-4
> > release is probably still 2 months away.
> While I usually hesitate to disagree with J
On Thu, 2005-03-10 at 16:55, Hans-Peter Nilsson wrote:
> But that requires source-level instrumentation.
Isn't a compiler option -fglobalize-symbol also a form of source-level
instrumentation? Either way, you need the source, and you get different
code emitted.
If you are interested in implement
Ranjit Mathew wrote:
IMHO "gnattools" should be added to "ADA_DIRS" in "gcc_release"
to generate snapshots properly. Otherwise, people who do not
download and install "gcc-ada" tarballs will get a bootstrap
error.
I verified that if I download the gcc-core snapshot and try a bootstrap,
I get a f
On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> This isn't a source-level modification, by definition.
And I could argue that my suggestion isn't a source-level modification
either, or I could argue that your suggestion really is a source-level
modification, but it seems pointless to argu
On Thu, 2005-03-10 at 20:14, Hans-Peter Nilsson wrote:
> That question isn't applicable or maybe I should say "by
> identity mapping". To wit, SYMNAME refers to whatever has
> "static" in front of it *in the source code*, but for which you
> want it removed, i.e. globalized (speaking in C terms).
Toon Moene wrote:
Ditto. Jim, are you reading from some documentation about this option
processing that I couldn't find ? I've spend hours and hours to try to
deduce the option processing rules from debugging various parts of the
gcc driver, with no success.
I doubt that this stuff is well doc
Toon Moene wrote:
Again I got a reaction of accepting write after approval (this time for
Feng Wang) as "processed by: None".
System adminstration work is performed by [EMAIL PROTECTED]
You should ask them. Checking the overseers mailing list archive, I
see that the last message is an automate
On Fri, 2005-03-11 at 16:01, Joe Buck wrote:
> [EMAIL PROTECTED] works just as well, since it's the same machine by
> a different name. On this list we should be advertising the gcc.gnu.org
> name, I think.
True. But if you want to look at the mailing list archive, you have to
use the non GNU na
On Fri, 2005-03-11 at 08:12, Hans-Peter Nilsson wrote:
> I don't really understand what you mean: if a thing is called
> "foo" in the source, then -fglobalize-symbol=foo would work.
My main concern is that we have a long history of adding flawed features
that have to be later removed. So I want y
On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote:
> All true, but I want to note that the preferred non-GNU name is
> sourceware.org.
What about the trademark status? Last I heard, the trademark holder had
asked us to stop using the name. That is when and why the machine got
renamed away from
Michael Cieslinski wrote:
/usr/bin/ld: Warning: size of symbol
`ACE_At_Thread_Exit::~ACE_At_Thread_Exit()' changed from 46 in
.shobj/POSIX_Proactor.o to 48 in .shobj/Proactor.o
This looks like a destructor function name, which means two different
versions of gcc generated different code for the sa
Balaji S wrote:
_On 11-Mar-2005 02:48, James E Wilson san wrote_:
Is expression evaluation (expr.c, expand_expr_real) converting tree into
RTL, the right place to extend GCC as required?
Basically, yes. However, variables declarations are typically handled
separately from the expression, so if
Richard Stallman wrote:
Currently, I believe, GCC combines various calls to abort in a single
function, because it knows that none of them returns.
To give this request a little context, consider the attached example.
If I compile this with -O2 -g, and run it under the debugger, it tells
me that
James E Wilson wrote:
To give this request a little context, consider the attached example.
This time actually attached.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
int
sub (int i, int j)
{
if (i == 0)
abort ();
else if (j == 0)
abort ();
else
return i * j
On Sat, 2005-03-12 at 21:00, feng qiu wrote:
> Is it difficult to modify the gcc sources if I want to use the both?
The tricky part might be defining what it means. There are at least 4
interacting features here, #pragma pack, attribute ((packed)), attribute
((aligned(X)), and -fpack-struct. Cur
Sam Lauber wrote:
The gccinstall info says that `make uninstall' would open
a can of worms. I don't get it. Why?
The same paragraph gives one explanation. Gcc includes shared
libraries. If you uninstall a copy of gcc, then everything compiled
with that gcc will suddenly stop working (ignoring
Rajesh Babu wrote:
I am working with gcc-3.3.3, and I want to insert my module after
construction of AST and before RTL generation.
gcc-3.3 is not interesting for work like this. This stuff has already
been obsoleted in current gcc sources. But if you insist on using out
dated sources, look at
Rajesh Babu wrote:
I found that PRE is not done in gcc-3.3.3, though the code for doing
PRE exists in source code.
gcc-3.3 is not interesting for work like this. The PRE support in
gcc-3.3 has already been effectively obsoleted by other work in current
gcc sources, though it is still there.
邹琼 wrote:
> ../../../source/gcc-4.0-20050109/gcc/config/rs6000/darwin.md:243:
> unknown mode `V4SI'
That is a snapshot that is over two months old. Snapshots are
unsupported, and have a lifetime of less than a week, so this has been
obsolete for almost 2 months now. If there is a problem here, i
Thomas Koenig wrote:
any reason why the message
http://gcc.gnu.org/ml/fortran/2005-03/msg00282.html
was rejected as spam from gcc-patches, yet accepted on the fortran
list?
See
http://www.sourceware.org/lists.html#rbl-sucks
which has a discussion of how the spam filters work, and how to get
ar
Nitin Gupta wrote:
following lines were added in config.gcc in order to recognise
--with-cpu=default32. But I dont understand , how it was actually made
to default to 32-bit.
The trick is to look at the default64 code, and note what default32
doesn't do that default64 does do.
The code you quoted
Mostafa Hagog wrote:
The question is: what is the correct fix for the longer term ?
is it enough to mark the SMSed block dirty? or do we need
also to keep the REG_DEAD correct in each basic-block
separately?
You either have to keep all REG_NOTES up to date, or call code that will
recompute them.
하태준 wrote:
> where i get the impormation about code, log_links, reg_notes
See the internals documentation, in the file gcc/doc/rtl.texi, or on the
web at
http://gcc.gnu.org/onlinedocs/gccint/Insns.html#Insns
See also the sources for more info, as the docs may not be fully up to
date, in partic
Rajesh Babu wrote:
The target I used is i686-linux. For the same example gcc-3.4.1
eliminated the redundant expression, where as gcc-3.3.3 didn't do it. I
observed it by dumping RTL with -dG switch. I didnt get abt the flaw
you were talking about. The optimization is done on the pseudo
regi
Denis Chertykov wrote:
I think that sequence of compare + cond-jump will exists in any
compiler pass.
Combine can optimize away compares, if you have other instructions that
set the condition code register to useful values. This optimization
will only work correctly if instructions that set or c
Kazu Hirata wrote:
ip2k
This is an Ubicom cpu, and they maintain a GNU port in house. There are
references to it on their web site, though I didn't see a convenient
link to download it. Probably not much worth to the FSF version of this
port if they aren't contributing patches to it.
ns32k
Ev
Mostafa Hagog wrote:
Thanks for the information, what we were doing was to call
update_life_info_in_dirty_blocks, but for some reason this wasn't
sufficient to
mark a register dead (REG_DEAD note) when the register was defined in a
predecessor block and dies in the dirty block; we had to call
updat
Paul Schlie wrote:
Steven Bosscher wrote:
IIRC these notes are for CCO, and you have to move the CC setter
and user together.
- unless it can be guaranteed that the particular setter's cc, will be
preserved (i.e. not corrupted by successive operations) prior to it's
ultimate use; ...
Steven was
Dale Johannesen wrote:
I'm interested in fixing this, but could use some help from somebody
knowledgeable about how x86 EH is supposed to work. In particular,
what's the expected relationship between SP at the point of a throwing
call, and when it gets back to the landing pad?
There is no direct r
Stefan Strasser wrote:
movl %ebx, -200(%ebp)
movl %ebx, -196(%ebp)
movl %eax, 4(%esp)
movl -200(%ebp), %edx
movl -196(%ebp), %ecx
It is hard to say without a testcase, but my first guess would be reload
inheritance and/or the post-reload cse pass.
Reload may need to load/store something from
Steve Ellcey wrote:
Any optimization experts care to take a look at this test case and help
me understand what is going on and if this change from 3.4 to 4.0 is
intentional or not?
Use the -da -fdump-tree-all options, and start looking at the dumps.
The first thing I notice is that in the RTL .loop
Richard Henderson wrote:
19255 EH bug on IA32 when using heavy optimization
Typo in pr number?
I think that is supposed to be 19225, for which I have already suggested
a solution though not a patch (disable deferred argument popping when a
call can throw). It isn't marked critical though, so I d
Michael LeBlanc wrote:
Does that option do anything except supply -maltivec implicitly?
As explained in the install docs, it does two things, enables -maltivec
by default, and enables -mabi=altivec by default.
This option has been deprecated and removed in the upcoming gcc-4.0
release. The pref
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
> I'd suggest trying -fmove-loop-invariants, and report a bug about
> that instead if it does not move those loop invariants. We really
> should move away from loop.c anyway.
In general, yes, but we will probably always need some RTL loop
optimi
On Thu, 2005-03-24 at 16:39, Andrew Pinski wrote:
> Jim you know that -fmove-loop-invariants enables the "new" RTL BB based
> loop optimizer? This option was added back in 3.4.0.
No, I don't, and I stupidly didn't bother to check. I thought he was
talking about some tree-ssa option.
I tried it,
zouq wrote:
> i build a crosscompiler for gcc, abi=n32 gcc-4.1-20050327/configure
> -target=mips64el-linux -prefix=/opt/gcc-4.1-20050327/
> -enable-languages=c --disable-shared make it will error with
> config/mips/mips.c
We need more info than what you have provided. In particular, we need
to kn
Steven Bosscher wrote:
As far as I can tell, there is no architecture requirement that p1 and
p2 must be a register pair (ie. p6,p7 or p2,p3, etc.), but that seems
to be the only form that GCC can produce.
Perhaps this was done this way to avoid insn patterns with two sets?
It was done this way bec
Steven Bosscher wrote:
OK, so I know this is not a popular subject, but can we *please* stop
working on loop.c and focus on getting the new RTL and tree loop passes
to do what we want?
I don't think anyone is objecting to this. My answers in an earlier
thread were a little confused because I didn
zouq wrote:
> /home/cpu/source/gcc-4.1-20050327/gcc/config/mips/mips.c:3976: error:
> structure has no member named `truthvalue_conversion'
This is the info we needed. Looking at the ChangeLog file, I see that
this was accidentally broken by Joseph Myers last week. I posted a
followup to the pa
Steve Kargl wrote:
In trying to do "gmake dvi" in the build directory, the
gfortran.texi eventually dies with
I noticed something similar, though the error messages I get are quite
different. I tried taking a look. There is a gfortran.log file that
lists the errors. I had to type ^Z while texi
or desirable
here, but one problem at a time...
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
2005-03-29 James E Wilson <[EMAIL PROTECTED]>
* dwarf2out.c (tree_add_const_value_attribute): Call expand_expr
and add_const_val
Peter Barada wrote:
I'd like to make the reload look like:
(set (reg:SI y) (plus:SI (reg_SI 16) (const_int 32832)))
(set (reg:DF x) (mem:DF (reg:SI y)))
Reload already knows how to make this transformation, so it should not
be necessary to resort to LEGITIMIZE_RELOAD_ADDRESS. This is only
needed
Clemens Koller wrote:
/[..]/qt-x11-free-3.3.4/bin/uic -L /[..]/qt-x11-free-3.3.4/plugins
-embed designercore [lots of images/*.png's]
-o qmake_image_collection.cpp
make: *** [qmake_image_collection.cpp] Aborted
make: *** Deleting file `qmake_image_collection.cpp'
uic is dumping core. We can't real
Dan Kegel wrote:
Moving an installed gcc/glibc crosstoolchain
to a different directory was not allowed
for gcc-2.96 and below, I seem to recall,
but became permissible around gcc-3.0.
Moving trees around has worked for a long time, but it required manually
setting the GCC_EXEC_PREFIX environment v
Sanjiv Kumar Gupta wrote:
But I don't want to
allow expressions like (const:SI (plus:SI
symbol_ref:SI) (const_int)) in the insn.
How should I do that, do I need to implement
LEGITIMATE_CONST_P () accordingly?
Try making CONSTANT_ADDRESS_P reject the value.
Though it still isn't clear why you are ge
Zagorodnev, Grigory wrote:
IA64 bootstrap failed at abi_check stage reporting undefined references
from libstdc++ (see log at the bottom).
This seems indirectly related to bug 20964. Mark's proposed fix to stop
building abi-check at bootstrap time means the IA-64 bootstrap should
now succeed.
Levent Erbuke wrote:
Is there a tool that retrieve which version of gcc was used to compile a
lib or anything else ?
It depends on the target, but use of strings in the .comment section is
fairly common. Try
objdump --section=.comment --full-contents
There will be one string for every object f
Nathan Sidwell wrote:
Being conservative I'd go for my patch on 4.0 and yours (if verified) on
mainline.
I'm fine with that. Have you actually written a patch yet? I don't see
one in the bug report or in gcc-patches.
I found a complication with my patch (string constants) when
bootstrapping, a
Vinayak Ghate wrote:
Do we have GNU toolchain for blackfin processor?? Can anybody help me out in
this regard??
There is no blackfin port in the FSF GCC sources. However, Analog
Devices does maintain some gcc ports for their targets, and may
contribute them to us in the future. See
http://www.
Steven Bosscher wrote:
../../reload-branch/gcc/unwind.inc:313: error: Attempt to delete
prologue/epilogue insn:
(insn/f 137 136 138 0 ../../reload-branch/gcc/unwind.inc:285 (set (reg:DI 33
r35)
(reg:DI 320 b0)) -1 (nil)
(nil))
Reload is using registers without setting regs_ever_live.
Steven Bosscher wrote:
Bootstrap with the reload-branch dies on ia64 in stage0 while
building unwind-ia64.c:
I needed one more minor patch to quiet a warning in reload.c, and I
couldn't help but notice that reload1.c is being compiled with -Wno-error.
Thhis got me all the way to a bootstrap compa
On Fri, 2005-04-01 at 00:38, Nathan Sidwell wrote:
> Here it is, ok?
The patch is OK. The ChangeLog entry should refer to INTEGER_CST
instead of INT_CST.
You are missing a ChangeLog entry for the testcase.
The testcase is not portable, as I pointed out in the PR. Trying this
on an x86_64-linux
Vinayak Ghate wrote:
Do we have GNU toolchain for blackfin processor?? Can anybody help me out in
this regard??
I was mistaken. The Blackfin port has already been submitted, but not
yet added to our source code repository. There is a chance that it may
end up in the upcoming release, gcc-4.0.
-
Zagorodnev, Grigory wrote:
How it is possible that recent cgraph changes affect ia64 compiler
behavior? I see reclaimed callgraph differs on ia64 but not on ia32;
therefore ia32/x86_64 compiler remains stable.
This is presumably the same problem that is now PR 20717.
--
Jim Wilson, GNU Tools Suppor
Grzegorz B. Prokopski wrote:
If I do that I run into an infinite loop in fixup_reorder_chain()
in its first for loop at:
while (NEXT_INSN (insn)) << HERE
insn = NEXT_INSN (insn);
It looks like there is an undocumented assumption about insn-chains and
the rbi->header and
René Rebe wrote:
../../gcc/tree-cfg.c: In function `remove_bb':
../../gcc/tree-cfg.c:2062: error: invalid type argument of `unary *'
This was fixed on mainline on March 7.
Is --enable-mapped-location considered to be a functional in 4.0 ?
Apparently no. The fixes have not been backported to the gc
tbp wrote:
Question: why do i get an unaligned array as soon as g++ (4.1.0
20050327, cygwin) finds out that it's static (i mean even if i try to
fool it around a bit)?
I would guess a limitation of cygwin binutils support, or perhaps of
Windows itself.
This seems to work fine on linux. If I comp
feng qiu wrote:
> I want to modify the gcc source code,what should I do?
Look at the c-pragma.c file, search for pack. Also see -fpack-struct in
common.opt and fpack_struct in opts.c. Then expand your search from there.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
On Tue, 2005-04-05 at 21:20, feng qiu wrote:
> In c-pragma.c file, #pragma pack(n) set the value of
> "maximum_field_alignment".
> And in opts.c file,-fpack-struct set "flag_pack_struct = 1" .
> But I don't known the relation between them.
Try using grep, as in "grep flag_pack_struct *.c" and "gr
Steven Bosscher wrote:
We have a bootstrap time regression since March 30. Bootstrap times
on Diego Novillo's SPEC box went up from (an already high) 5500s to
almost 8000s
I tried looking at this, but I haven't been able to find any bootstrap
time regressions. I've got a mainline tree checked o
On Thu, 2005-04-07 at 04:35, Bernd Schmidt wrote:
> Try the patch below - does it fix the problem?
OK, I will try it. This may take about 2 days. My lone IA-64 machine
is busy doing other stuff at the moment.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
H. J. Lu wrote:
Gcc 4,0 generates
.section .gnu.linkonce.t._ZN3FooC1Ev,"axG",@progbits,_ZN3FooC1Ev,comdat
for comdat group. Can gcc use
.section .text._ZN3FooC1Ev,"axG",@progbits,_ZN3FooC1Ev,comdat
instead? At least, there will be less characters for linker to process.
I know of no reason why we mu
zouq wrote:
> i wonder whether there exists or not alias analysis for scalar variable,
> array variable, even pointers.
> thank you.
Yes. See alias.c for alias analysis on RTL. See also tree-ssa-alias.c
for alias analysis on trees. The latter is much more sophisticated.
The latter hasn't been
On Thu, 2005-04-07 at 17:34, Diego Novillo wrote:
> Another thing, has our library code base (libjava, libstdc++)
> grown significantly lately?
I was doing full builds, except for Ada. I should have mentioned that.
Ada doesn't get configured by default, and I haven't bothered to check
why. I pr
On Fri, 2005-04-08 at 16:36, Daniel Berlin wrote:
> Jim works on a machine:
Athlon64 3400+, with 1GB main memory, running SuSE 9.1 x86_64-linux.
Charles J Gillan wrote:
Is the GOT not sufficient to do this though ? I can’t see why
it is necessary to define two new sections ? What goes into those
sections ?
The GOT is sufficient if you have a shared library loader that knows how
to read ELF files and apply the relocations embedded within
Andrew Haley wrote:
Oh, right. I wonder why this happens only with Java?
Because Java defaults to -fnon-call-exceptions. Add
-fno-non-call-exceptions and it will work. It looks to me like the
REG_EH_REGION check in postreload-gcse.c is bogus. We can have these
notes here with -fnon-call-exce
Rajkishore Barik wrote:
Can someone tell me if there is a way to generate RTL code which does not
include use and def of the same pseudo in the same insn?
That depends on how you are generating RTL, but it should be pretty
obvious that you can use gen_reg_rtx to generate a temp reg for use as a
d
Dave Korn wrote:
[EMAIL PROTECTED] /gnu/testing/obj-HEAD> make check 2>&1 | tee check.log
Always use "make -k check". Some testsuites exit with an error if one
or more tests failed, and because this is the normal situation for
almost all testsuites, this means the only way to get meaningful resu
Martin Koegler wrote:
tree type = TREE_TYPE (*node);
tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type));
tree newtype = build_type_attribute_variant (type, attr);
TYPE_MAIN_VARIANT (newtype) = TYPE_MAIN_VARIANT (type);
TREE_TYPE (*node) = ne
Chris Miller wrote:
Hi. I'm hoping you can help me with the questions in this e-mail and the
one that follows.
Bugs should be reported into bugzilla. Period. The old info is
obsolete and should be ignored. See
http://gcc.gnu.org/bugs.html
Mailing list info can be found here:
http://g
Martin Koegler wrote:
I changed the attribute handler to only return NULL_TREE in any case, but
the result is still the same (using the same gcc core).
But you are still creating the types in the attribute function right?
If so, that is probably why you still have a problem.
You mentioned that th
Peter Barada wrote:
pp_pack.c:2220: error: unable to find a register to spill in class `ADDR_REGS'
pp_pack.c:2220: error: this is the insn:
(insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 8 %a0 [1421])
(plus:SI (subreg:SI (reg:QI 1420) 0)
(const_int -32 [0xffe0]))) 121
Björn Haase wrote:
In case that one should not use machine specific atttributes, *is* there a
standard way for GCC how to implement different address spaces?
Use section attributes to force functions/variables into different
sections, and then use linker scripts to place different sections into
James Tabor wrote:
fp-bit.c:744: error: unrecognizable insn:
(call_insn:HI 53 49 59 0 fp-bit.c:743 (parallel [
(set (reg:SF 33 1)
(call (mem:SI (symbol_ref:SI ("__pack_f") [flags 0x41]
) [0 S4 A32])
(const_int 0 [0x0])))
(use (const_int 0
Clemens Koller wrote:
/usr/local/lib/nof/libstdc++.so.6: undefined reference to
[EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to
[EMAIL PROTECTED]'
These functions should come from libgcc_s.so or libgcc_eh.a, depending
on whether this is a shared or static link.
Try
Petar Penchev wrote:
I tried to use force_reg or PUT_MODE
but it does nothing and PUSH AL, inc S remain.
If nothing is happening, then that means the peephole isn't matching.
The matching happens in peephole2_insns. You could try putting a
breakpoint there and stepping through the code to see wh
Guochun Shi wrote:
make[1]: Entering directory
`/home/gshi/gcc/gcc-4.0.0-20050410/build-i686-pc-linux-gnu/libiberty'
make[1]: *** No rule to make target `../include/ansidecl.h', needed by
`regex.o'. Stop.
make[1]: Leaving directory
`/home/gshi/gcc/gcc-4.0.0-20050410/build-i686-pc-linux-gnu/libi
Ling-hua Tseng wrote:
> It's obvious that `movil' and `movim' are only access the partial
> 16-bit of the 32-bit register. How can I use RTL expression to
> represent the operations?
As you noticed, within a register, subreg can only be used for low
parts. You can't ask for the high part of a s
Devang Patel wrote:
warning: initialization discards qualifiers from pointer target type
This warning can not be disabled using -Wno-cast-qual
(or any other warning flags). Is it intentional ?
It looks like we have been doing it this way since at least gcc-1.42.
The same code is there, with n
Martin Koegler wrote:
I added to the i386 version the following code (using a unmodified gcc for the rest):
With this change, I can reproduce the problem.
I noticed that I get a failure for all types, not just array types.
This is different than what you described earlier, but perhaps the
differe
commented onMark Mitchell wrote:
The changes that I anticipate between now and the final release are
(a) documentation changes, (b) a patch for 20991, and (c) a possible
patch for 20973. Other than that, I will only consider patches that
fix egregious problems, like a fail to bootstrap on a primar
Ling-hua Tseng wrote:
James E Wilson wrote:
I read the descriptions of (high:m exp) and (lo_sum:m x y) in the gcc
internal manuls (Section 10.7 and 10.9).
The last line of their descriptions confused me because they wrote "m
should be Pmode".
A doc bug. You only need Pmode if you are
1 - 100 of 262 matches
Mail list logo
