Doubt : Help
Hi! In .md file, while writing Function-unit specifications, we have to define an attribute called "simultaneity". I am still confused to get the correct meaning it. Can anyone plz elaborate on it? I have found the following definition from GCC manual. "simultaneity specifies the maximum number of insns that can be executing in each instance of the function unit simultaneously or zero if the unit is pipelined and has no limit." -- Regards, --- |Sachin Vijaykumar Sonawane|Hostel-12, R.No.-A107, |[EMAIL PROTECTED] | |M.Tech.-CSE-IITB, |Mobile-9819506594, |[EMAIL PROTECTED] | |Roll.No.-03305039,|www.cse.iitb.ac.in/sachinvs|[EMAIL PROTECTED]| --- ___. ___ __ ____ __ .__ __. / |/ \ / || | | | | | | \ | | | (` / ^ \ | ,'| |__| | | | | \| | \ \ / /_\ \ | | | __ | | | | . ` | .) |/ _ \ | `.| | | | | | | |\ | |___//__/ \__\ \__||__| |__| |__| |__| \__|
Templates and C++ embedded subsets
Praxis is certainly of the opinion that a limited form of generics can be accomodated, but I do not think that anyone would suggest that unlimited use of C++ templates could be easily accomodated by some of these tools. I think that is beside the point of what I was trying to get from your previous connection. Well I was just speculating on possible reasons for excluding templates from a C++ subset intended for embedded use. By comparison, SPARK has excluded generics from the Ada subset used for SC applications in the praxis context.
Re: 2 suggestions
On Thu, 14 Apr 2005, Gerald Pfeifer wrote: > This patch accomplishes the goal to get rid of asterisks in @anchor > names by > > - replacing components of a target triplet which read "*" by "x", > - and omiting trailing asterisks from all other components. > > Tested by running doc/install.texi2html and selecting every single > link in the directory of specific.html. Applied now to mainline and the 4.0-branch with the following ChangeLog. 2005-04-16 Gerald Pfeifer <[EMAIL PROTECTED]> * doc/install.texi (Specific): Avoid using asterisks in @anchor names related to target triplets. Remove i?86-*-esix from platform directory. Remove powerpc-*-eabiaix from platform directory. Gerald
Re: internal compiler error at dwarf2out.c:8362
On Thu, Apr 14, 2005 at 03:02:36PM -0700, James E Wilson wrote:
> 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.
No, the first statement in the attribut handler is return NULL_TREE, so it
can not create a type.
I added to the i386 version the following code (using a unmodified gcc for the
rest):
[EMAIL PROTECTED]:/tmp/gcc/gcc]$cvs diff -u config/i386/i386.c
Index: config/i386/i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.808
diff -u -r1.808 i386.c
--- config/i386/i386.c 12 Apr 2005 01:46:28 - 1.808
+++ config/i386/i386.c 16 Apr 2005 12:37:52 -
@@ -1608,9 +1608,19 @@
#endif
}
+
+static tree
+m68hc05_handle_eeprom_attribute (tree * node, tree name,
+tree args ATTRIBUTE_UNUSED,
+int flags ATTRIBUTE_UNUSED,
+bool * no_add_attrs)
+{
+ return NULL_TREE;
+}
/* Table of valid machine attributes. */
const struct attribute_spec ix86_attribute_table[] =
{
+ {"eeprom", 0, 0, false, true, false, m68hc05_handle_eeprom_attribute},
/* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler } */
/* Stdcall attribute says callee is responsible for popping arguments
if they are not variable. */
This creates a usedless attribute named eeprom, and I think, that this code
should not contain any error.
Then it fails for at the line (the latest CVS version as well as 20050412):
$cat x.c
typedef unsigned char GROUP9_T[3];
typedef GROUP9_T EGROUP9_T __attribute ((eeprom));
$./cc1 --version
GNU C version 4.1.0 20050416 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050302 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
$./cc1 -g x.c
x.c:2: internal compiler error: in modified_type_die, at dwarf2out.c:8362
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
So the problem is in the core or I have defined the attribute in i386.c in a
wrong way. Correct me, if my modification is not allowed or does an other
forbidden thing.
> You mentioned that this works for all types except array types. Instead
> of trying to figure out why array types don't work, perhaps you should
> figure out why other types do work, and then maybe you can understand
> why array types don't work.
>
> Looking at this, I see that you have two array types, both with the same
> typename which points at the same type decl. It doesn't seem right for
> two different types to both claim to be the same typedef. That doesn't
> seem to be an issue though.
I tried to compare the differences on the modified i386 with the file:
typedef unsigned char uchar;
typedef uchar euchar __attribute ((eeprom));
typedef unsigned char GROUP9_T[3];
typedef GROUP9_T EGROUP9_T __attribute ((eeprom));
The only difference I have noticed, is that GROUP9_T has no TYPE_NAME, but
uchar has.
type->type.type_main_variant equals type in any case.
typedef usigned char uchar;
(gdb) call debug_tree(type)
constant invariant 8>
unit size constant invariant 1>
align 8 symtab 0 alias set -1 precision 8 min
max >
(gdb) call debug_tree(type->type.name)
unit size
align 8 symtab 0 alias set -1 precision 8 min max >
VOID file line 0
align 1>
(gdb) call debug_tree(type->type.name->decl.result)
(gdb) call debug_tree(type->type.main_variant)
constant invariant 8>
unit size constant invariant 1>
align 8 symtab 0 alias set -1 precision 8 min
max >
typedef uchar euchar __attribute((eeprom));
(gdb) call debug_tree(type)
constant invariant 8>
unit size constant invariant 1>
align 8 symtab 0 alias set -1
attributes > precision 8 min
max >
(gdb) call debug_tree(type->type.name)
unit size
align 8 symtab -1208520444 alias set -1 precision 8 min max >
asm_written VOID file x1.c line 1
align 1
result unit size
align 8 symtab -1208520392 alias set -1 precision 8 min max >>
(gdb) call debug_tree(type->type.name->decl.result)
constant invariant 8>
unit size constant invariant 1>
align 8 symtab -1208520392 alias set -1 precision 8 min max >
(gdb) call debug_tree(type->type.main_variant)
constant invariant 8>
unit size constant invariant 1>
align 8 symtab 0 alias set -1
attributes > precision 8 min
max >
typedef unsigned char GROUP9_T[3];
(gdb) call debug_tree(t
Re: implicit type cast problem of reference of ponter to const type
On Sat, Apr 16, 2005 at 01:13:46PM +0800, Steve Yee wrote:
> the following code can not compile. is it due to the standard?
Yes, this is not valid C++. int* -> const int* creates a temporary and
you can't bind a non-const reference to a temporary.
You might mean
void testfun(int * const & pr)
or just
void testfun(int * pr)
GCC is correct to reject this code so if you want more information you
should try somewhere like comp.lang.c++
> void testfun(const int *&pr)
> {
> }
>
> main()
Should be "int main()"
> {
> int *p;
> testfun(p);
> }
hope that helps,
jon
--
"Democracy is the theory that the common people know what they want, and
deserve to get it good and hard."
- H.L. Mencken
Re: Template and dynamic dispatching
On 04/15/2005 08:36 PM, Robert Dewar wrote: [snip] As I said, templates and Ada generics cause trouble with certification requirements in two respects. First, they have the potential to intefere with required traceability from source to object. Second, there are a number of formal techniques that are used in certification for which support of generics/templates is an issue. Visit the praxis site (www.praxis-his.com) for more insight into this issue. Robert, I briefly looked at several papers from: http://www.praxis-his.com/publications/ but found no mention of generic or templates any of: c_by_c_better_cheaper.pdf principled_design_oo.pdf systems_not_just_sw.pdf could you provide a specific link to something on www.praxis-his.com to help us out? TIA. -Larry
Re: Doubt : Help
Sachin Vijay Sonawane <[EMAIL PROTECTED]> writes: > In .md file, while writing Function-unit specifications, we have to > define an attribute called "simultaneity". I am still confused to get > the correct meaning it. Can anyone plz elaborate on it? I have found > the following definition from GCC manual. > > "simultaneity specifies the maximum number of insns that can be > executing in each instance of the function unit simultaneously or zero > if the unit is pipelined and has no limit." First I'll note that all that define_function_unit is gone in the current compiler, along with its documentation. The new approved approach is to use define_cpu_unit and define_insn_reservation. That said, simultaneity is attempting to describe a feature of processor functional units. Consider a multiplier. Let's say that the multiplier takes several cycles to complete the operation. What happens if a second multiply instruction comes along while the multiplier is working? One option is that the second multiply instruction stalls until the first one is complete (for example, the XScale works this way). In this case, the multiply unit has a "simultaneity" of 1: one instruction may occupy the functional unit at one time. Another option is that the multiplier is fully pipelined, and the second multiply instruction simply begins executing in the pipeline (e.g., Pentium II, many other high end processors). In this case, the multiply unit has a "simultaneity" of 0, meaning that there is no limit on the number of instructions which may occupy the functional unit at one time. It is of course possible to have two non-pipelined multiplier units, in which case a second multiply instruction would begin executing immediately, while a third one would be stalled until one of them completed. For example, I believe that the Athlon has three floating point multiplication units, and therefore has a "simultaneity" of 3. Hope this helps. Ian
Re: Template and dynamic dispatching
On 04/16/2005 10:19 AM, Larry Evans wrote: [snip] I briefly looked at several papers from: http://www.praxis-his.com/publications/ [snip] principled_design_oo.pdf [snip] I should mention that this paper does mention dynamic dispatching but nothing about templates or generic types.
My opinions on tree-level and RTL-level optimization
I seem to have inadvertantly annoyed Steven Bosscher on IRC, so by way of an apology and explanation I thought I'd post my current opinion and thinking on the optimizations performed by GCC's middle-end both at the tree-level in the tree-ssa optimizers and at the RTL-level in the exisiting RTL-optimizers. The intention is to (i) explain my current position, understanding and misunderstandings and (ii) for people to disagree and/or convince me otherwise. My current opinion is that for the medium-term, let's arbitrarily say prior to GCC 5.x, GCC will continue to need to perform optimizations at both the tree-level and the RTL-level. The tree-level, I see as fundamentally responsible for high-level and machine independent transformations, and the RTL optimizers for the lower-level machine-dependent transformations. It's unlikely that RTL, or an instruction-based, representation of a program will ever go away. And the RTL passes corresponding to instruction selection (combine), register allocation (reload) and scheduling will almost certainly be RTL-level tasks/passes. But the advent of the tree-ssa infrastructure, the other RTL "optimization" passes, notably CSE, GCSE, loop, if-conversion, and jump bypassing may not be long for this world. And certainly not preserved in their current incarnations. The difficulty here is that by expressing a program as low-level insns, we expose optimization opportunities not visible as trees. The RTL expanders and backend's pattern expanders inadvertantly introduce redundancies and inefficiencies, or more commonly by providing machine-specific idioms open up code transformations, for example with SUBREGs, that just didn't occur previously. For example, expand_mult may produce a sequence of shifts and additions for an integer multiplication. If there are two integer multiplications by a constant in a basic block, CSE will be able to identify shared terms between their shift/add sequences that aren't visible to the tree-level multiplications. One might argue that the shifts/adds should be exposed at the tree-level. But not only does this require detailed knowledge of the instructions available on a machine, but it would also obfuscate the multiplication from the tree-ssa optimizers, such as iv-opts, etc... Instead, representing the multiplication at the tree-level as a MULT_EXPR, propagating constants into it, and letting expand do it's thing gets the best of both worlds. This doesn't constrain us to keep all of GCC's original RTL optimizers though. Unlike gcc 3.x and earlier, we now expect tree-ssa to do most of the heavy lifting. One goal is to have the initial RTL that we generate to be pretty close to it's final form. Perhaps only requiring minor clean-ups. I forsee a world in which RTL transformations become far more local. Perhaps the RTL-level loop optimizers will disappear completely. Although, RTL expansion may introduce new loops, these tend to be rare, and the expanders have all the information they need to hoist/sink invariant expressions and unroll/peel themselves. Certainly there should be no need for RTL-level loop optimizations to do loop unrolling or other large scale reorganization. Simiarly, CSE shouldn't need to process more than a single basic blocks, and GCSE shouldn't need to move anything other than simple expressions. The quality of alias analysis at the RTL-level shouldn't be an issue. This brave new world also has a profound impact on how backends are written. Previously, because with the exception of "fold" and "expand", all optimization was performed on the RTL-level, backend's played tricks to virtualize their hardware to the middle-end in an attempt to allow the RTL optimizers to understand what was going on. Virtual high-level patterns would be introduced for the benefit of the RTL optimizers, only to be split later. The problem with this is that by splitting/lowering after the RTL optimizers any inefficiencies that are introduced are too late to be cleaned up. Perhaps one of the most notorious examples of this is the handling of DImode on IA-32. The i386.c backend pretends that it has native DImode support prior to reload. Whilst in gcc 3.x, this is essential, constant propagation and constant folding wouldn't work with highparts and lowparts, and for example, the loop analysis would be unable to do anything with a loop using a "long long" counter once the loop exit test has been decomposed into highpart and lowpart subtests. Unfortunately, the late splitting leads to terrible register allocation, and numerous dead loads/stores to/from memory. SPECint's crafty suffers. With tree-ssa, however, these design decisions can and need to be re-evaluated. Now that a "long long" for-loop will be reversed at tree-level, the x86 backend is far better of decomposing DImode early, and getting the benefit of RTL optimizers to eliminate the dead/load stores etc... One side-effect of such a move is that although we genera
How to -Werror in a fortran testcase?
Hi! gfortran does not support -Werror it seems. What do I need to put in dg-options to make a testcase fail, if there is any warning? Thanks, Richard.
Re: Heads-up: volatile and C++
Jason Merrill wrote: On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote: Could you clarify whether 'other writes' means 'other _volatile_ writes', or '_any_ other writes'? Since non-volatile writes are not visible outside of the abstract machine, how can they be ordered wrt volatiles? Any others. I was basing that on the requirement that the side-effects of those writes are required to be complete, though I suppose you could argue that they aren't required to be visible outside the current thread. Can you clarify whether threads are being considered as a) parts of a single abstract machine (which will therefore need extending in the std) b) separate abstract machines. It's not clear to me which is the best approach. (b) allows threads to be supported via copious uses of volatile (but probably introduces pessimizations), whereas (a) forces the thread interactions to be compiler visible (but shows more promise for optimizations). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
compile error for gcc-4.0.0-20050410
hello, list I am not sure if someone has reported this before, 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/libiberty' make: *** [all-build-libiberty] Error 2 I did not subscribe the list so please cc to the reply to me thanks -Guochun
C++ ABI mismatch crashes
Hi, I have a copy of Inkscape compiled with GCC 3.3, running on a GCC 3.4 based system. All of the C++ libraries it links directly against, like GTKmm, are statically linked. In other words, it dynamically links against no C++ libraries. Inkscape dlopens libgtkspell, which in turn dlopens libaspell (to add a spelling checker). libgtkspell is written in C, but libaspell is written in C++ and exposes a C interface. This causes a crash, even though the GCC documentation explicitly says this should work because the C++ standard library has symbol versioning applied so the usual ELF cross-wiring mess is (theoretically) avoided. But this isn't what happens. Here is an LD_DEBUG=binding trace at the point of the crash: 17179: binding file /usr/lib/libaspell.so.15 to /usr/lib/libstdc++.so.6: normal symbol `_ZNKSs5rfindEcj' [GLIBCXX_3.4] 17179: binding file /usr/lib/libaspell.so.15 to /usr/lib/libaspell.so.15: normal symbol `_ZN8aspeller9find_fileERN7acommon6StringERKS1_S4_S4_PKc' 17179: binding file /usr/lib/libaspell.so.15 to /usr/lib/libstdc++.so.5: normal symbol `_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_' 17179: binding file /usr/lib/libstdc++.so.5 to /usr/lib/libstdc++.so.5: normal symbol `_ZNSsC1ERKSs' [GLIBCPP_3.2] 17179: binding file /usr/lib/libstdc++.so.5 to /usr/lib/libstdc++.so.5: normal symbol `_ZNSs6appendERKSs' [GLIBCPP_3.2] 17179: binding file /usr/lib/libaspell.so.15 to /usr/lib/libstdc++.so.6: normal symbol `_ZNSsC1ERKSs' [GLIBCXX_3.4] 17179: binding file ./inkscape.stripped to /lib/tls/libc.so.6: normal symbol `fprintf' [GLIBC_2.0] Emergency save activated! Just before the last line, the std::string destructor calls free on an invalid pointer, which glibc detects and triggers an abort (which in turn triggers an emergency save). Note that on the first line libaspell is being bound to libstdc++.so.6, which is what I'd expect as libaspell is compiled using gcc 3.4 - and indeed up until this point it's been linked only against libstdc++.so.6. Then for some reason it's linked against libstdc++.so.5, for the following symbol: _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_ or std::basic_string, std::allocator > std::operator+, std::allocator >(std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&) This symbol does exist in v6 of the library: 2471: 009ac084 145 FUNCWEAK DEFAULT 11 _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_@@GLIBCXX_3.4 but it's also defined in v5: 2492: 0311d2a098 FUNCWEAK DEFAULT 11 _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_@@GLIBCPP_3.2.1 and for some reason (first in the link order I guess) it takes precedence. I don't know exactly what revisions of the C++ ABI spec gcc 3.3 and 3.4 implement (does anybody know? It'd be nice to be able to see exactly what changed) but I guess these two symbols aren't compatible. I'm not sure why the symbol versioning is being ignored. Can anybody help me? thanks -mike
Re: [m68k]: More trouble with byte moves into Address registers
>> 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 {*addsi3_5200} (insn_list
>> 5558 (nil))
>
>You might want to look at CANNOT_CHANGE_MODE_CLASS, which can be used to
>change how reload handles (subreg:SI (reg:QI)). That might help avoid
>generating QImode ADDR_REG reloads in the first place.
>
>But if they are generated, then you need second reloads to resolve them
>as Ian mentioned. There is probably no way to avoid implementing this.
>
>You should also look at MODES_TIEABLE_P, which may also help prevent
>getting QImode ADDR_REG reloads.
>
>Even if you fix both of these, you will probably still need the
>secondary reload support for this case.
I added:
/* Try to suppress (subreg:SI (reg:QI)) from ending up in ADDR_REGS */
#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
(((FROM) == QImode || (TO) == QImode) \
? reg_classes_intersect_p (ADDR_REGS, (CLASS)) : 0)
to my gcc-3.4.3 for ColdFire v4e, and that allows perl-5.9.2 to build.
I'm in the midst of rebuilding the entire linux kernel and user
environment to make sure it didn't cause anything else to go wrong,
but so far, so good. I have my fingers crossed that this is both
correct and is enough(Should I try (GET_MODE_SIZE (FROM) == 1 ||
GET_MODE_SIZE (TO) == 1) )?
I'm really leary of twisting any more knobs without a *clear*
understanding of what impact the knobs actaully have, and the doco
just isn't giving me that.
I've got a "Using and Porting GNU CC" manual for rev 2.95, and am
looking around for a newer one and can't find it anywhere. Does
anyone know if a newer printed manual is available(and if so, where I
can find it)?
Eventually I'll have to try my changes on gcc-4.0 to see what that does.
--
Peter Barada
[EMAIL PROTECTED]
gcc-4.0-20050416 is now available
Snapshot gcc-4.0-20050416 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050416/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050416 You'll find: gcc-4.0-20050416.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050416.tar.bz2 C front end and core compiler gcc-ada-4.0-20050416.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050416.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050416.tar.bz2 C++ front end and runtime gcc-java-4.0-20050416.tar.bz2 Java front end and runtime gcc-objc-4.0-20050416.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050416.tar.bz2The GCC testsuite Diffs from 4.0-20050409 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [m68k]: More trouble with byte moves into Address registers
Peter Barada <[EMAIL PROTECTED]> writes: > I've got a "Using and Porting GNU CC" manual for rev 2.95, and am > looking around for a newer one and can't find it anywhere. Does > anyone know if a newer printed manual is available(and if so, where I > can find it)? At the risk of stating the dreadfully obvious, the manual is online at http://gcc.gnu.org/onlinedocs/gccint/ and you can print your own copy by running "make dvi" and using your favorite DVI printing program, or running dvipdf to produce a PDF. If you mean a printed and bound book published by somebody else, I don't think there is a newer one available. Ian
Re: [m68k]: More trouble with byte moves into Address registers
Ian Lance Taylor writes: > Peter Barada <[EMAIL PROTECTED]> writes: >> I've got a "Using and Porting GNU CC" manual for rev 2.95, and am >> looking around for a newer one and can't find it anywhere. Does >> anyone know if a newer printed manual is available(and if so, where I >> can find it)? > > If you mean a printed and bound book published by somebody else, I > don't think there is a newer one available. FSF Press did a new edition in the 3.4 timeframe, if memory serves. It's not listed as available on their page, though. [http://www.gnu.org/doc/gnupresspub.html] zw
Re: My opinions on tree-level and RTL-level optimization
Although, RTL expansion may introduce new loops, these tend to be rare, and the expanders have all the information they need to hoist/sink invariant expressions and unroll/peel themselves. I disagree. In order to make the proper decisions about merging givs and chosing which giv should represent a biv, you have to know a lot about the valid addressing modes on the machine and this isn't something the tree level optimizers should have to deal with. And there is still the issue of addressing calculations, which I don't think have been completely exposed yet. Certainly there should be no need for RTL-level loop optimizations to do loop unrolling or other large scale reorganization. Agreed there. Simiarly, CSE shouldn't need to process more than a single basic blocks, Again, not clear. Certainly the costly stuff I put in ages ago to walk through comparisons and around loops needs to go, but there's no reason to tie CSE to a basic block: it can operate until the next label, like it does now. Admittedly, the number of CSE opportunities won't be great, but why restrict them to a basic block? and GCSE shouldn't need to move anything other than simple expressions. Why would we need a GCSE at the RTL level at all? I'd guess the number of wins it would produce would be very small. The quality of alias analysis at the RTL-level shouldn't be an issue. Here I disagree the strongest! Instruction scheduling is rapidly becoming one of the most critical optimizations and must be done at the RTL level. The quality of instruction scheduling depends quite heavily on the quality of the aliasing information.
Re: GCC 4.0 Freeze
Zack Weinberg wrote: "This compiler does not support all of Fortran 77 yet. We recommend distributors continue to provide packages of g77 from GCC 3.4 for the time being. When gfortran is considered a complete replacement for g77 we will announce it." "We recommend distributors continue..." Oh I say, is it really so hard? -- Brane
Re: GCC 4.0 Freeze
Branko Äibej <[EMAIL PROTECTED]> writes: > Zack Weinberg wrote: > >> "This compiler does not support all of Fortran 77 yet. We recommend >> distributors continue to provide packages of g77 from GCC 3.4 for >> the time being. When gfortran is considered a complete replacement >> for g77 we will announce it." >> >> > "We recommend distributors continue..." > > Oh I say, is it really so hard? Are you objecting to the absence of "that" after "recommend"? I don't personally find that infelicitous (and find the version with a "that" excessively verbose) but I wouldn't be surprised if other dialects of English held the opposite perspective. z "prescriptivism considered mandatory or harmful on a case-by-case basis" w
Re: GCC 4.0 Freeze
Zack Weinberg wrote: Branko Äibej <[EMAIL PROTECTED]> writes: Zack Weinberg wrote: "This compiler does not support all of Fortran 77 yet. We recommend distributors continue to provide packages of g77 from GCC 3.4 for the time being. When gfortran is considered a complete replacement for g77 we will announce it." "We recommend distributors continue..." Oh I say, is it really so hard? Are you objecting to the absence of "that" after "recommend"? Indeed. I don't personally find that infelicitous (and find the version with a "that" excessively verbose) but I wouldn't be surprised if other dialects of English held the opposite perspective. Well, the sentence seems lopsided to me without the "that". But then, I prefer "it's not as weird as all that" to "it's not that weird", at least in formal communication. Maybe I'm just weird myself. z "prescriptivism considered mandatory or harmful on a case-by-case basis" w Heh. :) -- Brane
Re: GCC 4.0 Freeze
Even if there were complete g77 compatibility in g95, folks may want to stick with the g77 version from gcc 3.4 for awhile purely for performance reasons. In doing some test runs of the APBS Adaptive Poisson-Boltzmann Solver program, I discovered that the g95 built binary runs 60% slower than the g77 built version. This was on MacOS X 10.3.8 using the version from Feb 24, 2005. Jack
Re: C++ ABI mismatch crashes
On Sat, Apr 16, 2005 at 11:47:05PM +0100, Mike Hearn wrote: > I have a copy of Inkscape compiled with GCC 3.3, running on a GCC 3.4 > based system. All of the C++ libraries it links directly against, like > GTKmm, are statically linked. In other words, it dynamically links > against no C++ libraries. > > Inkscape dlopens libgtkspell, which in turn dlopens libaspell (to add > a spelling checker). libgtkspell is written in C, but libaspell is written > in C++ and exposes a C interface. > > This causes a crash, even though the GCC documentation explicitly says > this should work because the C++ standard library has symbol versioning > applied so the usual ELF cross-wiring mess is (theoretically) avoided. Do we really promise somewhere that this will work? I know that we warn in other places that it probably will not. Yes, symbol versioning is present, and will avoid many problems, but there were also a couple of layout bugs in gcc 3.3 that were fixed in 3.4. These could cause code compiled by 3.3 to assume that fields of classes are at different positions than code compiled by 3.4. Such cases are not common, but it is another way to get a crash. > But this isn't what happens. Here is an LD_DEBUG=binding trace at the > point of the crash: > [ trace deleted ] I'm not enough of a linker expert to help you track this one down. I
Problem with weak_alias and strong_alias in gcc-4.1.0 with MIPS...
Greetings. I have a working MIPS cross toolchain with: binutils-2.15 gcc-3.4.2 glibc-2.3.4 linux-2.6.12 and then decided to work with gcc-4.1.0 out of the cvs head. I am now getting build problems with glibc-2.3.4 with the first major snafu being: ../sysdeps/ieee754/dbl-64/s_isinf.c:29: error: 'isinf' aliased to undefined symbol '__isinf' ../sysdeps/ieee754/dbl-64/s_isinf.c:31: error: '__isinfl' aliased to undefined symbol '__isinf' ../sysdeps/ieee754/dbl-64/s_isinf.c:32: error: 'isinfl' aliased to undefined symbol '__isinf' I am attempting to try and figure out what changed so drastically to cause this. I also looked in GCC and glibc Bugzilla databases, but did not find anything addressing this problem. Has anyone seen this behavior? Thanks. -Steve
Re: GCC 4.0 Freeze
[EMAIL PROTECTED] (Jack Howarth) writes: >Even if there were complete g77 compatibility in g95, folks may want > to stick with the g77 version from gcc 3.4 for awhile purely for > performance reasons. In doing some test runs of the APBS > Adaptive Poisson-Boltzmann Solver program, I discovered that the g95 > built binary runs 60% slower than the g77 built version. This was > on MacOS X 10.3.8 using the version from Feb 24, 2005. > Jack > Have you checked to see if there are any bugs filed about similar performance problems? If not, then have you filed any bugs about the slow down? -- Thanks, Jim http://www.csclub.uwaterloo.ca/~ja2morri/ http://phython.blogspot.com http://open.nit.ca/wiki/?page=jim
Re: GCC 4.0 Freeze
Jack Howarth wrote: >Even if there were complete g77 compatibility in g95, folks may want > to stick with the g77 version from gcc 3.4 for awhile purely for > performance reasons. In doing some test runs of the APBS > Adaptive Poisson-Boltzmann Solver program, I discovered that the g95 > built binary runs 60% slower than the g77 built version. This was > on MacOS X 10.3.8 using the version from Feb 24, 2005. Can you try to isolate the problem and file a bug report? I.e. if it is a problem with gfortran also. - Tobi
Re: [m68k]: More trouble with byte moves into Address registers
Zack Weinberg <[EMAIL PROTECTED]> writes: > Ian Lance Taylor writes: > > Peter Barada <[EMAIL PROTECTED]> writes: > >> I've got a "Using and Porting GNU CC" manual for rev 2.95, and am > >> looking around for a newer one and can't find it anywhere. Does > >> anyone know if a newer printed manual is available(and if so, where I > >> can find it)? > > > > If you mean a printed and bound book published by somebody else, I > > don't think there is a newer one available. > > FSF Press did a new edition in the 3.4 timeframe, if memory serves. > It's not listed as available on their page, though. > [http://www.gnu.org/doc/gnupresspub.html] > > zw > I remember a heavily altered users manual for GCC 3.3 being published by gnupress. I can't seem to find a way to order it though. -- Thanks, Jim http://www.csclub.uwaterloo.ca/~ja2morri/ http://phython.blogspot.com http://open.nit.ca/wiki/?page=jim
Re: [m68k]: More trouble with byte moves into Address registers
>> I've got a "Using and Porting GNU CC" manual for rev 2.95, and am >> looking around for a newer one and can't find it anywhere. Does >> anyone know if a newer printed manual is available(and if so, where I >> can find it)? > >At the risk of stating the dreadfully obvious, the manual is online at >http://gcc.gnu.org/onlinedocs/gccint/ >and you can print your own copy by running "make dvi" and using your >favorite DVI printing program, or running dvipdf to produce a PDF. Yes, I've done that before where I had punched paper and a duplex laser printer. Here at home I have neither. >If you mean a printed and bound book published by somebody else, I >don't think there is a newer one available. I like the printed book since I can dog-ear pages and scribble notes in it. As it is, my 2.95 version's binding is nearly fallying apart :) -- Peter Barada [EMAIL PROTECTED]
Re: GCC 4.0 Freeze
On 4/17/05, Jack Howarth <[EMAIL PROTECTED]> wrote: > Even if there were complete g77 compatibility in g95, folks may want > to stick with the g77 version from gcc 3.4 for awhile purely for > performance reasons. In doing some test runs of the APBS > Adaptive Poisson-Boltzmann Solver program, I discovered that the g95 > built binary runs 60% slower than the g77 built version. This was > on MacOS X 10.3.8 using the version from Feb 24, 2005. There's no checking performance hits lurking around here, are there? -- Cheers, /ChJ
GCC 4.0 RC2 Status
I plan to create RC2 bits tomorrow. The only PR which I currently think might merit holding up the final release is: 20973 [4.0/4.1 Regression] kdelibs (khtml) miscompiled by reload Michael Matz has attached a possible reload patch to the PR. Any comments? I'm not going to wait very long even for this bug, though. Instead, I'm going to get 4.0.0 out the door, and move on to 4.0.1, sticking as close to the announced schedule as possible. So, there will be a 4.0.0 release within the next week. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
