as apply a publicly posted patch.
Try a pragmatic approach, rather than a dogmatic approach.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
.
Let's tone down the high falootin' rhetoric about defending freedoms
and discuss the pragmatic issues of how to manage licenses in a
real world with real companies and real lawyers and real concerns.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
that this is a minor bug fix for a non-existent
minor release.
The version numbering scheme correlating to functional changes
is more valuable than any (IMO insubstantial) benefit of
identifying the change in license version.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325
into play.
Wrong. The original author can license his or her own code to
others using different licenses.
Under the license assignment, both FSF and the author can
license the code under different licenses.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650
who are unwilling to distribute code licensed under GPLv3.
And anyone using any past release.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
, like BITS_PER_WORD.
Comments?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Ian Lance Taylor wrote:
Michael Eager [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part
Ian Lance Taylor wrote:
Michael Eager [EMAIL PROTECTED] writes:
It seems to me that the same assembly code should be generated
independent of whether gcc is run on a 32-bit or 64-bit
host and all of these HOST_* tests should actually be
target domain parameters, like BITS_PER_WORD.
It is sad
Mike Stump wrote:
On Jul 12, 2007, at 9:23 AM, Michael Eager wrote:
I was looking through dwarf2out.c, tracking down the
cause for different assembly code being generated
when gcc was run on 32-bit and 64-bit hosts.
When QAing, it is very useful to be able to compare two .s files
targets?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
dictates the rules
is one of the least appealing aspects of this.
[I'll put away my soap box. For now.]
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Eric Botcazou wrote:
How does this work for 32-bit hosts and 64-bit targets?
Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
Meaning that I can't build gcc-ppc64 on an IA32 host?
Yuck! So much for cross-platform tools.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo
(experimental) Revision X
Perhaps it can also include branch name.
I have the following in my build script:
echo $VERSION $BLDDIR/gcc/gcc/DEV-PHASE
$VERSION shows up in place of experimental.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
which translates RTL to LocExpr not handling REG+offset,
I don't see a reason why REG+OFFSET is not valid, or why the comment says
that it is unnecessary. On Sparc, it's only unnecessary because Sparc
ignores the CIE.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650
handling in gcc. I'm not.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
. Debugging does.
My question was whether there was a good reason for ignoring
the offset in a RA expression.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
at the call instruction address, not the address where the
function will return. Either you never hit that breakpoint,
or you hit it on a different iteration.
In any case, for Sparc, on entry to a function the CIE doesn't
even say that %o7 is the return address.
--
Michael Eager[EMAIL PROTECTED
that the offset is necessary to unwind a frame
correctly (at least, if you use the CIE info). Is there any
reason to discard it?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
definition of available in May is May 1.
The marketer's definition of available in May is May 30.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
for embedded development with very poor
uControllers?
Try info gdb as a start.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
submit proposals by using
the form on the website. If you are interested in being an active
participant on the DWARF Standard Committee, please contact me
directly.
--
Michael Eager, Chair, DWARF Standard Committee
data types, use a union:
union {
long l;
char c[4];
} a;
a.l = 0x12345678;
a.c[0] = 0x01;
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
?
The PPC EABI says that arrays are aligned on the boundary
of the type, which suggests that this was a bug fix. But
unaligned char arrays make strcpy much slower.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Andrew Pinski wrote:
On Tue, 2007-01-16 at 20:04 -0800, Michael Eager wrote:
But unaligned char arrays make strcpy much slower.
Actually it depends on the processor unless you are messed up by using
-mstrict-align which is a huge hammer for most (if not all) PowerPC
processors even though
?hard=mhard-float
When I specify -mfp=hard, the correct lib (hard)is selected.
When I specify -mhard-float, the default is selected.
How should I write the MULTILIB_MATCHES spec to do this?
(The docs are less than clear about the MULTILIB_MATCHES
option and don't mention using '?'.)
--
Michael
Michael Eager wrote:
I'm having some trouble understanding how to write
a MULTILIB_MATCHES specification.
I need to treat a simple option like -mhard-float the
same as an option with a value -mfp=hard. Here's what
I came up with:
MULTILIB_OPTIONS = mfp=hard
MULTILIB_DIRNAMES = hard
be to contribute to the project.
You can feel sad all you want, but being patronizing is
not going to get much sympathy.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Ulf Magnusson wrote:
On 11/29/06, Michael Eager [EMAIL PROTECTED] wrote:
Ulf Magnusson wrote:
While searching for an answer, I noticed that lots of people seem
to have had problems with cross-compilation that to me look more
like problems in the documentation, which I find a bit sad
application, you will find that there
are an infinite number of configurations.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
(match_operand:DF 0 gpc_reg_operand =f)
(float:DF (match_operand:DI 1 gpc_reg_operand *f)))]
TARGET_POWERPC64 TARGET_HARD_FLOAT TARGET_FPRS
fcfid %0,%1
[(set_attr type fp)])
What keeps FP regs from being used to contain integer values?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo
) What is the correct way to set the reset vector?
Use a linker script to load a jump to the start routine in the reset vector.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
in parallel that is likely to be needed but possibly may
turn out to be unnecessary than wait until it's known for
sure that it is needed.
Ok maybe its just me.
Well, maybe. ;-)
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Olivier Galibert wrote:
On Sun, Nov 12, 2006 at 02:46:58PM -0800, Michael Eager wrote:
It would seem that the place to require the personality
routine would be in the routine which causes the stack
unwinding, not in every C++ object file, whether needed
or not.
Doesn't that otherwise very
Mark Mitchell wrote:
Michael Eager wrote:
GCC 4.1.1 for PowerPC generates a 162K executable for a
minimal program int main() { return 0; }. GCC 3.4.1
generated a 7.2K executable. Mark Mitchell mentioned the
same problem for ARM and proposed a patch to remove the
reference to malloc in atexit
++ percepts is that there
is no overhead for features which are not used.
Why should the personality routine be included in all C++ programs?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Mark Mitchell wrote:
Michael Eager wrote:
Why should the personality routine be included in all C++ programs?
Because all non-trivial, exceptions-enabled programs, may need to do
stack unwinding.
It would seem that the place to require the personality
routine would be in the routine which
unwinding
shouldn't have a superfluous reference to it.
There is a check in doing_eh() in except.c which checks that
-fexceptions is set if any exception-specific functions are
used. It seems that this would be the place to generate the
reference to __gxx_personality_v0.
--
Michael Eager[EMAIL
. Intel AMD
have announced that they are developing large multi-core symmetric processors.
The timelines I've seen say that the number of cores on each chip will
double every year or two. Moore's law hasn't stopped. The number of
gates per chip doubles every 18 months.
--
Michael Eager[EMAIL
is independent of each other.
Separate threads could process the tree/RTL for each function
independently, with the results merged on completion. This
may interact adversely with some global optimizations, such
as inlining.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650
system, the overhead is distributed across all processors, but
results in a net gain. For parallelizations pprograms, a
4-way processor might achieve 3X performance improvement.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
.
Possibly someone on the GCC mailing list can offer
some answer to your question.
One first suggestion I would have is that you compile
the source in question and take a look at the assembly
code which the compiler generates.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA
to solve some problem,
without telling us what the problem is. So every solution
is going to get the response thanks, but that is what
I need.
If you want help with a problem, describe the problem.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Michael Eager wrote:
Matteo Fioroni wrote:
Thanks for your help, I saw the gcc -E output: but it
don't match my needs.
I've to interface the Preprocessor to get the tokens
(keyword, preprocessor directives, grammar, ecc..) it
analyzes on which I've to permorm some operations.
The preprocessor
in the C code.
I think that I can use the preprocessore features to
scan the code I can obtain the informations I need
in a good way.
So, I ask you how can I get some docomuntation about C
preprocessor and how can I interface myself with it?
Have you looked at cpp? Or gcc -E?
--
Michael Eager
or --print-search-paths or whatever to
figure out why the compiler cannot create an executable.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
scripts
to ld, along with whatever libraries or support files
(like crti.o) are needed. The spec file insures that
the correct options are passed.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
the memory layout of a board or processor. There is
no compelling reason to prohibit this *correct* linker script from
being passed to the gcc driver and from there to ld.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
where the gcc driver is processing the
-T option.
Is the missing documentation an oversight or is the option
deprecated or something else?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Andrew Pinski wrote:
On Wed, 2006-09-06 at 15:00 -0700, Michael Eager wrote:
GCC passes a linker script to the linker for some
targets (e.g., powerpc-eabi with -mads). If you specify a
linker script using -Wl,-T,script.ld, you get both
passed to the linker and there may be conflicts
to the linker?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
down to that
poor practice works perfectly, in our case, under some restrictions,
while good practice just works perfectly.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Michael Eager wrote:
Miguel Angel Champin Catalan wrote:
Hello:
We are students of computer sciences in the Santa Maria University,
Chile. We just want to know if the function gets it's too dangerous
for a warning. The fact is that our teacher's assistant give us a
homework, and one
expect it will only make
them larger.
I invite your discussion, comments and general venting of personal
frustrations.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
depending on whether the
single-or double-precision FPU was available, as specified by a new
option -mfpu=. There would be some added instruction patterns
for the single-precision operations.
Does this sound like a reasonable approach or is there a better
way to do this?
--
Michael Eager[EMAIL
David Edelsohn wrote:
Michael Eager writes:
Michael I'm adding support to GCC for a different PPC floating point unit.
Michael It's similar to the standard PPC FPU in that it supports most of
Michael the same instructions and all operation are in FP registers.
Michael The FPU comes in a single
the
fneg instruction. What is the define_expand template doing?
Thanks!
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
://gcc.gnu.org/bugzilla/show_bug.cgi?id=28596
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
it
to the noconfigdirs list) or fix libssp/configure?
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
++ builds OK.
Following the discussion on that thread, it seems
like the suggestion is that one should build gcc
for some other similar target, such as powerpc-eabisim,
which sort of misses the goal of building powerpc-eabi.
So, what is the right way to build g++ for powerpc-eabi?
--
Michael Eager
within the gcc
source for stucture definitions.
These sections contain DWARF debugging information.
You can find documentation about DWARF at dwarf.freestandards.org.
--
Michael EagerChair, DWARF Workgroup [EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
to the Chair, Michael Eager,
at [EMAIL PROTECTED]
--
Michael Eager, DWARF Workgroup Chair
Eager Consulting
1960 Park Blvd., Palo Alto, CA 94306
650-325-8077
[EMAIL PROTECTED]
/listinfo/dwarf-discuss.
For additional information, please contact Michael Eager (mailto:[EMAIL
PROTECTED]).
--
Michael Eager, Chair, DWARF Workgroup[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
301 - 363 of 363 matches
Mail list logo
