Resume of Steve Snow : Database SQL Applications Programmer
Here is my full resume: http://www.sworde.com/resume2.doc Please forward this work experience & skills summary to your Database & software development, MIS/IT/Software Department for review. -- Resume of Steve Snow -- Database SQL Applications Programmer -- Phone: 970-300-4770 -- [EMAIL PROTECTED] -- Here is my full resume: http://www.sworde.com/resume2.doc Work Experience: * 20+ Years Database & Software Application developer * References available on request. * Create/Fix/Change/Convert Databases. * Display your data on your website, any number of pages in html/PHP/ASP. * Graphs, Maps, Charts, Diagrams, Pictures, Photos, and Graphics in Database and Reports. * Mail Merge of Databases/Information/Spreadsheets/Programs. * Create reports from Data such as PDF, Spreadsheet or HTML. * Sales leads for clients using Internet Resources. * Solving almost any job any data from any program source. * Fill out Website Forms automatically, or gather intelligence from them. * Exchange data from any number of programs, including websites. * Create inter office communication between cities/locations using Internet. * Inventory, Sales Lead, Accounting, Statistical Database Creation. * Meetings with employees to understand their needs/solution they wanted. * Training of personnel in all above systems. * Write software to perform the above jobs. * Problem solve any data question/problem you may have. * Transfer data between any number of unrelated programs, including websites. * Merge Data from unrelated programs and databases. * Test your entire website for errors by automatically filling in all your webforms on all your webpages. * Screenscrape, Webscraping, and Datamining from the internet straight to your custom databases. * Chief Developer and programmer for above with 30 years experience. Here is my full resume: http://www.sworde.com/resume2.doc -- Skills: * All VB/VBA,COM/ActiveX,DOM,SOAP, .NET * All SQL programming, Oracle (incl. PL/SQL),MS Access,SQL Server,Sybase * XML,HTML * All database access methods, ADO (ActiveX Data Objects),DAO (Data Access Objects),Microsoft Jet, ODBC * Operating systems, Windows NT 4.0 / 2000 / XP,Windows 95 / 98,ndows 3.1 / 3.11 -- Availability: * By the job or task/requirement (bid). * Contract or Independent Consultant * Full or part time Employee. * Can fly in and be available for "Live" meetings on short notice. * Remote desktop (anywhere in the world, using XP Pro and above). -- Bondable/References * SECRET Clearance (US Government) * Fully bondable * Non-disclosure/Confidentiality Agreements. -- Education * US Military, includes "SECRET" Clearance, University, Trade Schools & Certifications. -- Citizenship * Us Citizen. -- Vehicle/License * Class "A" License -- Special Mention * Can sign a waiver to not use your Company's Medical Insurance Policy (Already covered by US Veteran's Administration Medical Insurance) Here is my full resume: http://www.sworde.com/resume2.doc
Find the longest float type nodes
Hi all, I'm working on implementing a correct Fortran rounding (rounding to nearest-integer, with half integer values rounded to the integer of maximum absolute value) in the Fortran front-end, following ada/trans.c (convert_with_check) and http://gcc.gnu.org/ml/fortran/2005-04/msg00139.html The code Ada uses to do it has the following comments: /* The following calculations depend on proper rounding to even of each arithmetic operation. In order to prevent excess precision from spoiling this property, use the widest hardware floating-point type. FIXME: For maximum efficiency, this should only be done for machines and types where intermediates may have extra precision. */ calc_type = longest_float_type_node; /* FIXME: Should not have padding in the first place */ if (TREE_CODE (calc_type) == RECORD_TYPE && TYPE_IS_PADDING_P (calc_type)) calc_type = TREE_TYPE (TYPE_FIELDS (calc_type)); I have the three following questions, probably best directed to middle-end experts and Ada maintainers: * How can I know the longest float type? My first patch uses the long_double_type_node unconditionally, but it surely isn't a generic solution * How can I determine if a given type may have extra precision? * What is this padding code doing, and is it necessary? Thanks, FX
Has insn-attrtab.c been growing in size recently?
Hi all, A bootstrap attempt of GCC mainline on a i386-unknown-netbsdelf2.0.2 with: Memory: 378M Act, 264M Inact, 3520K Wired, 4664K Exec, 633M File, 151M Free Swap: 129M Total, 129M Free failed due to a compilation error in stage1: cc1: out of memory allocating 138677280 bytes after a total of 31484356 bytes make: *** [insn-attrtab.o] Error 1 The system compiler is gcc version 3.3.3 (NetBSD nb3 20040520). Last time I tried on this same computer was on 2006-12-03, and it passed stage1 OK. So I wonder what recent changes could have affected insn-attrtab.c on this target, and whether there could be a way to get it down in size. Thanks, FX
MiDataSets for MiBench to enable more realistic benchmarking and better tuning of the GCC optimization heuristic
Hi all, In case someone is interested, we are developing a set of inputs (MiDataSets) for the MiBench benchmark. Iterative optimization is now a popular technique to obtain performance or code size improvements over the default settings in a compiler. However, in most of the research projects, the best configuration is found for one arbitrary dataset and it is assumed that this configuration will work well with any other dataset that a program uses. We created 20 different datasets per program for free MiBench benchmark to evaluate this assumption and analyze the behavior of various programs with multiple datasets. We hope that this will enable more realistic benchmarking, practical iterative optimizations (iterative compilation), and can help to automatically improve GCC optimization heuristic. We just made a pre-release of the 1st version of MiDataSets and we made an effort to include only copyright free inputs from the Internet. However, mistakes are possible - in such cases, please contact me to resolve the issue or remove the input. More information can be found at the MiDataSets development website: http://midatasets.sourceforge.net or in the paper: Grigori Fursin, John Cavazos, Michael O'Boyle and Olivier Temam. MiDataSets: Creating The Conditions For A More Realistic Evaluation of Iterative Optimization. Proceedings of the International Conference on High Performance Embedded Architectures Compilers (HiPEAC 2007), Ghent, Belgium, January 2007 Any suggestions and comments are welcome! Yours, Grigori Fursin = Grigori Fursin, PhD INRIA Futurs, France http://fursin.net/research
Trouble understanding reload dump file format..
Morning all,
I'm not entirely familiar with the format and meaning of all the terms used
in the reload pass dump files, I was wondering if someone could comment on
whether this seems sane or not:
mul.c: In function `try_mulsi3':
mul.c:5: error: unable to find a register to spill in class `MPD_REG'
Reload 0: reload_in (SI) = (reg/v:SI 3 r3 [102])
MPD_REG, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v:SI 3 r3 [102])
Reload 1: GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 3), can't combine,
secondary_reload_p
Reload 2: MPD_REG, RELOAD_FOR_INPUT_ADDRESS (opnum = 3), can't combine,
secondary_reload_p
secondary_in_reload = 1
secondary_in_icode = reload_insi
Reload 3: reload_in (SI) = (scratch:SI)
MPR_REG, RELOAD_FOR_INPUT (opnum = 3)
reload_in_reg: (scratch:SI)
secondary_in_reload = 2
mul.c:5: error: this is the insn:
(insn 12 4 19 0 0x0 (parallel [
(set (reg:SI 67 s3_MPRL(r0) [104])
(mult:SI (reg/v:SI 2 r2 [103])
(reg/v:SI 3 r3 [102])))
(clobber (scratch:SI))
]) 51 {mulsi3} (insn_list 4 (insn_list 3 (nil)))
(expr_list:REG_DEAD (reg/v:SI 2 r2 [103])
(expr_list:REG_DEAD (reg/v:SI 3 r3 [102])
(expr_list:REG_UNUSED (scratch:SI)
(nil)
mul.c:5: confused by earlier errors, bailing out
In particular, I really don't understand what a RELOAD_FOR_INPUT_ADDRESS
means when all the operands are regs, or why there should be three reloads for
the same operand when it's just a clobber scratch. Is there something special
about how reload handles clobber and match_scratch?
The insn pattern looks like:
(define_insn "mulsi3"
[(set (match_operand:SI 0 "register_operand" "=d")
(mult:SI (match_operand:SI 2 "register_operand" "r")
(match_operand:SI 1 "register_operand" "a")))
(clobber (match_scratch:SI 3 "b"))]
"TARGET_MUL_BLOCK"
"sw \\t%3,%2; CAUSE MULTIPLY"
[(set_attr "type" "mul")
(set_attr "length" "4")]
)
where the constraint letters 'a', 'b' and 'd' mean MPD_REG, MPR_REG and
MPRL_REG respectively, classes that contain just a single special purpose hard
reg each.
If I replace the match_scratch with an explicit (reg:SI) using the hard reg
num of the MPR_REG, instead of trying to regclass preference gcc into picking
it as the scratch register, all those reloads disappear.
I currently use secondary reloads to specify that a GENERAL_REG is required
to reload the specialised regs from memory. I tried making the secondary
reload class functions return NO_REGS for a (scratch:MM) pattern, but that got
me a different kind of error:
mul.c: In function `try_mulsi3':
mul.c:5: error: unrecognizable insn:
(insn 28 4 12 0 0x0 (set (reg:SI 65 s1_MPR(r0))
(scratch:SI)) -1 (nil)
(nil))
mul.c:5: internal compiler error: in extract_insn, at recog.c:2175
...which is even more confusing.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Building without bootstrapping
Thanks for the information. So, if I want to debug a bug in the cc1 code that causes target library build to fail - should I just use the cc1 that is generated in /gcc/ ? Is there a better way of doing this, without going through a make that builds some components successfully (cc1) and fails for the others ( target libs ) ? On 3/18/07, Paul Brook <[EMAIL PROTECTED]> wrote: > How can I get the build scripts to use the precompiled gcc throughout > the build process ? Short answer is you can't. The newly build gcc is always used to build the target libraries[1]. Paul [1] Except when building a Canadian cross, in which case you're expected to have a build->target cross compiler available. Bad Things will probably happen if this doesn't match the compiler being built.
Re: Building without bootstrapping
On Mon, Mar 19, 2007 at 05:25:37AM -0700, Karthikeyan M wrote: > Thanks for the information. > So, if I want to debug a bug in the cc1 code that causes target > library build to fail - > should I just use the cc1 that is generated in /gcc/ ? Yes. -- Daniel Jacobowitz CodeSourcery
Re: Google SoC Project Proposal: Better Uninitialized Warnings
Jeffrey Law wrote: The one technical bit we never tacked was unoptimized compilation; I goof'd at one time and thought we went ahead and build the SSA graph even when not optimizing which is incorrect. I don't think fixing this should be a requirement for improving the current situation with -Wuninitialized, but if you've got the time, investigation would be a great bonus. I agree this would be helpful. One of the reasons that the GNAT front end has its own circuits to detect some cases of uninitialized variables is to get these warnings even with no optimization. Jeff
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On 19/03/07, Robert Dewar <[EMAIL PROTECTED]> wrote: Jeffrey Law wrote: > The one technical bit we never tacked was unoptimized compilation; I > goof'd at one time and thought we went ahead and build the SSA graph > even when not optimizing which is incorrect. I don't think fixing this > should be a requirement for improving the current situation with > -Wuninitialized, but if you've got the time, investigation would be > a great bonus. I agree this would be helpful. One of the reasons that the GNAT front end has its own circuits to detect some cases of uninitialized variables is to get these warnings even with no optimization. > You should really read what I wrote. That is a goal of the project. Was it too long/boring? I can try to shorten it or rewrite some parts. Cheers, Manuel.
Re: Google SoC Project Proposal: Better Uninitialized Warnings
Manuel López-Ibáñez wrote on 03/17/07 14:28: > This is the project proposal that I am planning to submit to Google > Summer of Code 2007. It is based on previous work of Jeffrey Laws, > Diego Novillo and others. I hope someone will find it interesting and Yes, I can act as a mentor. I'm particularly interested in what we are going to do at -O0. Ideally, I would try to build the SSA form and/or a predicated SSA form and try to phrase the problem in terms of propagation of the uninitialized attribute. I agree with your goal of consistency. The erratic behaviour of the current -Wuninitialized implementation is, to me, one of the most annoying traits of GCC. We can't even reorder the pass pipeline without running into this problem.
Re: We're out of tree codes; now what?
On 3/12/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> It's going to have a big performance impact. To extract a 9-bit value,
> the compiler will need to do a lot of masking every time it accesses
> the TREE_CODE.
"a lot masking" means at most two additional instructions, one if we
put it in the right place. I'd be shocked if we could even measure
this, let alone be a "big" performance impact.
I went ahead and implemented this, to see what the real impact would
be. The following patch frees up TREE_LANG_FLAG_5, and uses that extra
bit for the tree code.
On tramp3d, memory usage remains the same (obviously), and the
performance results are not as bad as I had imagined:
8-bit tree code, --enable-checking:
real1m56.776s
user1m54.995s
sys 0m0.541s
9-bit tree code, --enable-checking:
real2m16.095s
user2m12.132s
sys 0m0.562s
8-bit tree code, --disable-checking:
real0m55.693s
user0m43.734s
sys 0m0.414s
9-bit tree code, --disable-checking:
real0m58.821s
user0m46.122s
sys 0m0.443s
So, about 16% slower with --enable-checking, 5% slower with --disable-checking.
Subcodes might still be the way to go, but I'm feeling less bad about
the 9-bit tree code option.
Cheers,
Doug
2007-03-19 Douglas Gregor <[EMAIL PROTECTED]>
* java-tree.h (HAS_BEEN_ALREADY_PARSED_P): Move to TREE_PROTECTED.
2007-03-19 Douglas Gregor <[EMAIL PROTECTED]>
* tree.c (tree_contains_struct): Support 512 tree codes.
* tree.h (tree_contains_struct): Ditto.
(MAX_TREE_CODES): We now support 512 tree codes.
(struct tree_base): Make "code" 9 bits, remove lang_flag_5.
(TREE_LANG_FLAG_5): Remove.
(BINFO_FLAG_5): Remove.
* print-tree.c (print_node): Don't print TREE_LANG_FLAG_5.
2007-03-19 Douglas Gregor <[EMAIL PROTECTED]>
* cp-tree.h (C_IS_RESERVED_WORD): Move to TREE_PROTECTED.
(BINFO_PRIMARY_P): Move to BINFO_FLAG_6.
(DECL_VTABLE_OR_VTT_P): Move to nothrow_flag.
Index: java/java-tree.h
===
--- java/java-tree.h(revision 122993)
+++ java/java-tree.h(working copy)
@@ -48,7 +48,6 @@ struct JCF;
3: HAS_FINALIZER (in RECORD_TYPE)
4: IS_A_COMMAND_LINE_FILENAME_P (in IDENTIFIER_NODE)
IS_ARRAY_LENGTH_ACCESS (in INDIRECT_REF)
- 5: HAS_BEEN_ALREADY_PARSED_P (in IDENTIFIER_NODE)
6: CAN_COMPLETE_NORMALLY (in statement nodes)
Usage of TYPE_LANG_FLAG_?:
@@ -1521,7 +1520,7 @@ extern tree *type_map;
#define IS_A_COMMAND_LINE_FILENAME_P(ID) TREE_LANG_FLAG_4 (ID)
/* True if filename ID has already been parsed */
-#define HAS_BEEN_ALREADY_PARSED_P(ID) TREE_LANG_FLAG_5 (ID)
+#define HAS_BEEN_ALREADY_PARSED_P(ID) TREE_PROTECTED (ID)
/* True if TYPE (a TREE_TYPE denoting a class type) was found to
feature a finalizer method. */
Index: tree.c
===
--- tree.c (revision 122993)
+++ tree.c (working copy)
@@ -168,7 +168,7 @@ static unsigned int attribute_hash_list
tree global_trees[TI_MAX];
tree integer_types[itk_none];
-unsigned char tree_contains_struct[256][64];
+unsigned char tree_contains_struct[512][64];
/* Number of operands for each OpenMP clause. */
unsigned const char omp_clause_num_ops[] =
Index: tree.h
===
--- tree.h (revision 122993)
+++ tree.h (working copy)
@@ -41,7 +41,7 @@ enum tree_code {
#undef DEFTREECODE
-extern unsigned char tree_contains_struct[256][64];
+extern unsigned char tree_contains_struct[512][64];
#define CODE_CONTAINS_STRUCT(CODE, STRUCT)
(tree_contains_struct[(CODE)][(STRUCT)])
/* Number of language-independent tree codes. */
@@ -80,7 +80,7 @@ extern const char *const tree_code_class
#define TREE_CODE_CLASS_STRING(CLASS)\
tree_code_class_strings[(int) (CLASS)]
-#define MAX_TREE_CODES 256
+#define MAX_TREE_CODES 512
extern const enum tree_code_class tree_code_type[];
#define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
@@ -363,7 +363,7 @@ union tree_ann_d;
struct tree_base GTY(())
{
- ENUM_BITFIELD(tree_code) code : 8;
+ ENUM_BITFIELD(tree_code) code : 9;
unsigned side_effects_flag : 1;
unsigned constant_flag : 1;
@@ -388,7 +388,8 @@ struct tree_base GTY(())
unsigned lang_flag_2 : 1;
unsigned lang_flag_3 : 1;
unsigned lang_flag_4 : 1;
- unsigned lang_flag_5 : 1;
+ /* NOTE: lang_flag_5 is intentionally absent; it was been used for the 9th
+ bit of code. */
unsigned lang_flag_6 : 1;
unsigned visited : 1;
@@ -485,6 +486,12 @@ struct gimple_stmt GTY(())
CALL_FROM_THUNK_P in
CALL_EXPR
+ C_IS_RESERVED_WORD in
+ IDENTIFIER_NODE (C++ only)
+
+ HAS_BEEN_ALREADY_PARSED_P in
+ IDENTIFIER_NODE (Java only)
+
side_effects_flag:
TREE_SIDE_EFFECTS in
@@ -549,6 +556,9 @@ struct gimple_stmt GTY(())
TREE_THIS_NOTRAP in
(ALIGN/MISA
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On 19/03/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Manuel López-Ibáñez wrote on 03/17/07 14:28: > This is the project proposal that I am planning to submit to Google > Summer of Code 2007. It is based on previous work of Jeffrey Laws, > Diego Novillo and others. I hope someone will find it interesting and Yes, I can act as a mentor. I'm particularly interested in what we are going to do at -O0. Ideally, I would try to build the SSA form and/or a predicated SSA form and try to phrase the problem in terms of propagation of the uninitialized attribute. I agree with your goal of consistency. The erratic behaviour of the current -Wuninitialized implementation is, to me, one of the most annoying traits of GCC. We can't even reorder the pass pipeline without running into this problem. The idea is to have two options -Wuninitialized=precise and -Wuninitialized=verbose to please both groups of users, those that want precise warnings about the code that is being compiled in the current environment and those that want to get warnings even in the cases of dead-code or variables removed by optimisers. I think it is the latter group that is more interested in consistent warnings. Of course, the former group would welcome consistency as long as it doesn't imply more false positives. Nevertheless, I am sure that the final implementation will be very different from the original proposal but that's life. From the comments so far, I understand that the project is considered interesting, so I will formally submit it to Google. Thanks, Manuel.
Re: We're out of tree codes; now what?
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote: I went ahead and implemented this, to see what the real impact would be. The following patch frees up TREE_LANG_FLAG_5, and uses that extra bit for the tree code. On tramp3d, memory usage remains the same (obviously), and the performance results are not as bad as I had imagined: 8-bit tree code, --enable-checking: real1m56.776s user1m54.995s sys 0m0.541s 9-bit tree code, --enable-checking: real2m16.095s user2m12.132s sys 0m0.562s 8-bit tree code, --disable-checking: real0m55.693s user0m43.734s sys 0m0.414s 9-bit tree code, --disable-checking: real0m58.821s user0m46.122s sys 0m0.443s So, about 16% slower with --enable-checking, 5% slower with --disable-checking. Just because I'm curious and you have a built tree ready... Does the patch that Alex sent to gcc-patches the other day help reduce this 5% penalty? See the patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01234.html There are other bitfield optimization related bugs (Roger Sayle should know more about those) that we can give a higher priority if we decide to go with the 9 bit tree code field. IMHO this is still the better solution than the subcodes idea. Gr. Steven
RE: Has insn-attrtab.c been growing in size recently?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > François-Xavier Coudert > Sent: Monday, March 19, 2007 5:54 AM > To: GCC Development > Subject: Has insn-attrtab.c been growing in size recently? > > Hi all, > > A bootstrap attempt of GCC mainline on a i386-unknown-netbsdelf2.0.2 with: > > > Memory: 378M Act, 264M Inact, 3520K Wired, 4664K Exec, 633M File, 151M > Free > > Swap: 129M Total, 129M Free > > failed due to a compilation error in stage1: > > cc1: out of memory allocating 138677280 bytes after a total of 31484356 > bytes > make: *** [insn-attrtab.o] Error 1 > > The system compiler is gcc version 3.3.3 (NetBSD nb3 20040520). Last > time I tried on this same computer was on 2006-12-03, and it passed > stage1 OK. So I wonder what recent changes could have affected > insn-attrtab.c on this target, and whether there could be a way to get > it down in size. > > Thanks, > FX Well the AMD AMDFAM10, Intel Core2, AMD Geode machine descriptions went in. Unfortunately without either redoing how insn-attrtab is built or reducing the number of machine variants that are supported, it is likely the only solution is to raise the amount of virtual memory you have on the system. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA 01719 [EMAIL PROTECTED]
Re: We're out of tree codes; now what?
> So, about 16% slower with --enable-checking, 5% slower with > --disable-checking. That's about an order of magnitude more than I'd expect and is very strange. To a very close approximation, the speed of integer code on modern machine is affected only by the number of cache misses. Why should this affect that>
Re: We're out of tree codes; now what?
Steven Bosscher wrote on 03/19/07 10:14: > IMHO this is still the better solution than the subcodes idea. Agreed. If the performance hit is not too large, getting a wider tree code is much simpler to maintain.
Re: We're out of tree codes; now what?
On 3/19/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote: > I went ahead and implemented this, to see what the real impact would > be. The following patch frees up TREE_LANG_FLAG_5, and uses that extra > bit for the tree code. > > On tramp3d, memory usage remains the same (obviously), and the > performance results are not as bad as I had imagined: > > 8-bit tree code, --enable-checking: > > real1m56.776s > user1m54.995s > sys 0m0.541s > > 9-bit tree code, --enable-checking: > > real2m16.095s > user2m12.132s > sys 0m0.562s > > 8-bit tree code, --disable-checking: > > real0m55.693s > user0m43.734s > sys 0m0.414s > > 9-bit tree code, --disable-checking: > > real0m58.821s > user0m46.122s > sys 0m0.443s > > So, about 16% slower with --enable-checking, 5% slower with --disable-checking. Just because I'm curious and you have a built tree ready... Does the patch that Alex sent to gcc-patches the other day help reduce this 5% penalty? See the patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01234.html Unfortunately, this patch doesn't bootstrap for me on i686-pc-linux-gnu: /home/dgregor/Projects/mainlinegcc-build/./prev-gcc/xgcc -B/home/dgregor/Projects/mainlinegcc-build/./prev-gcc/ -B/home/dgregor/Projects/mainlinegcc-install/i686-pc-linux-gnu/bin/ -I../../mainlinegcc/libcpp -I. -I../../mainlinegcc/libcpp/../include -I../../mainlinegcc/libcpp/include -O2 -g -fomit-frame-pointer -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I../../mainlinegcc/libcpp -I. -I../../mainlinegcc/libcpp/../include -I../../mainlinegcc/libcpp/include -c -o expr.o -MT expr.o -MMD -MP -MF .deps/expr.Po ../../mainlinegcc/libcpp/expr.c ../../mainlinegcc/libcpp/expr.c: In function '_cpp_parse_expr': ../../mainlinegcc/libcpp/expr.c:701: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. There are other bitfield optimization related bugs (Roger Sayle should know more about those) that we can give a higher priority if we decide to go with the 9 bit tree code field. IMHO this is still the better solution than the subcodes idea. I strongly agree. Subcodes look like they'll either end up being complicated (e.g., what I did with TYPEOF_TYPE as a subcode), slow (the LANG_TREE_CODE option puts a branch into the equivalent of TREE_CODE), or both. Cheers, Doug
Re: MiDataSets for MiBench to enable more realistic benchmarking and better tuning of the GCC optimization heuristic
On 3/19/07, Grigori Fursin <[EMAIL PROTECTED]> wrote: Hi all, In case someone is interested, we are developing a set of inputs (MiDataSets) for the MiBench benchmark. Iterative optimization is now a popular technique to obtain performance or code size improvements over the default settings in a compiler. However, in most of the research projects, the best configuration is found for one arbitrary dataset and it is assumed that this configuration will work well with any other dataset that a program uses. We created 20 different datasets per program for free MiBench benchmark to evaluate this assumption and analyze the behavior of various programs with multiple datasets. We hope that this will enable more realistic benchmarking, practical iterative optimizations (iterative compilation), and can help to automatically improve GCC optimization heuristic. I think this is nice but semi useless unless you look into also why stuff is better. The anylsis part is the hard part really but the most useful part of to figure out why GCC is failing to produce good code. An example of this is I was working on a patch which speeds up most code (and reduces code size there) but slows down some code (and increase the code too) and I found that scheduling, and reordering blocks decisions would change which causes the code to become slower/larger. This anylsis was neccessary to figure out my patch/pass was not directly causing the slower/larger code. This is the same thing with any kind of heuristic tuning is needed. Thanks, Andrew Pinski
RE: MiDataSets for MiBench to enable more realistic benchmarking and better tuning of the GCC optimization heuristic
Yes, that's right that without good analysis part it is semi-useless. Actually, it can even make life harder since instead of one dataset you now have to try many ;) ... We did some preliminary analysis of the compiler optimizations for programs with multiple datasets in our HiPEAC'07 paper using the PathScale compiler and now we continue working on a better program characterization with multiple inputs and how it should be properly used to improve compiler heuristic. So, at the moment it is still more for research purposes. We had some requests to make these datasets public after HiPEAC conference and HiPEAC GCC tutorial so that some researchers and engineers can start looking at this issue. There was an interest from some companies that develop embedded systems - they use GCC more and more and they often use MediaBench and MiBench for the benchmarking but find that using only two datasets may not be representative enough ... I now have a few projects where we use GCC and MiDataSets, so whenever we have more practical results, I will post it here! Hope it will be of any use, Grigori = Grigori Fursin, PhD INRIA Futurs, France http://fursin.net/research On 3/19/07, Grigori Fursin <[EMAIL PROTECTED]> wrote: > Hi all, > > In case someone is interested, we are developing a set of inputs > (MiDataSets) for the MiBench benchmark. Iterative optimization is now > a popular technique to obtain performance or code size improvements > over the default settings in a compiler. However, in most of the > research projects, the best configuration is found for one arbitrary > dataset and it is assumed that this configuration will work well with > any other dataset that a program uses. > We created 20 different datasets per program for free MiBench > benchmark to evaluate this assumption and analyze the behavior of > various programs with multiple datasets. We hope that this will enable > more realistic benchmarking, practical iterative optimizations > (iterative compilation), and can help to automatically improve GCC > optimization heuristic. I think this is nice but semi useless unless you look into also why stuff is better. The anylsis part is the hard part really but the most useful part of to figure out why GCC is failing to produce good code. An example of this is I was working on a patch which speeds up most code (and reduces code size there) but slows down some code (and increase the code too) and I found that scheduling, and reordering blocks decisions would change which causes the code to become slower/larger. This anylsis was neccessary to figure out my patch/pass was not directly causing the slower/larger code. This is the same thing with any kind of heuristic tuning is needed. Thanks, Andrew Pinski
Tree VRP bug: internal compiler error: in build_int_cst_wide, at tree.c:886
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
This happens because we have a VIEW_CONVERT EXPR(double->long) that is
used in a conditional. VRP tries to register an edge assertion for
this expression:
unit size
align 64 symtab 0 alias set -1 canonical type 0x2dfee3c0 precision
64 min max
pointer_to_this chain >
arg 0 unit size
align 64 symtab 0 alias set -1 canonical type 0x2dffa6c0
precision 64
chain >
visited var def_stmt
Which eventually works its way down to:
if (!has_single_use (op))
{
val = build_int_cst (TREE_TYPE (op), 0);
register_new_assert_for (op, code, val, NULL, e, bsi);
retval = true;
}
and this fails with an ICE because TREE_TYPE (op) is real_type, and
you can't build_int_cst with a real_type.
The simplest way of fixing this is simply to disallow
VIEW_CONVERT_EXPR in this context. Comments?
Index: tree-vrp.c
===
--- tree-vrp.c (revision 122839)
+++ tree-vrp.c (working copy)
@@ -3485,7 +3485,6 @@
}
else if (TREE_CODE (rhs) == NOP_EXPR
|| TREE_CODE (rhs) == CONVERT_EXPR
- || TREE_CODE (rhs) == VIEW_CONVERT_EXPR
|| TREE_CODE (rhs) == NON_LVALUE_EXPR)
{
/* Recurse through the type conversion. */
Andrew.
Re: Find the longest float type nodes
On Mar 19, 2007, at 05:44, François-Xavier Coudert wrote: I have the three following questions, probably best directed to middle-end experts and Ada maintainers: * How can I know the longest float type? My first patch uses the long_double_type_node unconditionally, but it surely isn't a generic solution In particular, that has the problem of long double often being a type that is implemented in software only. For Ada, we use WIDEST_HARDWARE_FP_SIZE if defined, or LONG_DOUBLE_TYPE_SIZE otherwise. Using the widest hardware type will at least guarantee that the hardware doesn't implicitly use a wider type. However, it's unnecessarily conservative: on x86 with -mfpmath=sse for example, we could use any type without problems. Similarly, on most architectures other than x86 and PPC, extra precision is never used. * How can I determine if a given type may have extra precision? We should somehow add a new predicate that would give this information per type. Something like FP_TYPE_ROUNDS_P that is true for any type that always rounds results might be useful. The predicate should probably default to TRUE, and be overridden for single and double precision types on non-SSE x86 and x86-64, as well as single precision types for some PPC configurations. * What is this padding code doing, and is it necessary? The Ada front end sometimes adds padding to a type if an explicit alignment is requested (through use of attributes in the source code) that is higher than the default. As the FIXME comment indicates, this should be going away. Don't worry about it for Fortran. -Geert
Re: Tree VRP bug: internal compiler error: in build_int_cst_wide, at tree.c:886
On 3/19/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
This happens because we have a VIEW_CONVERT EXPR(double->long) that is
used in a conditional. VRP tries to register an edge assertion for
this expression:
unit size
align 64 symtab 0 alias set -1 canonical type 0x2dfee3c0 precision 64 min
max
pointer_to_this chain >
arg 0
unit size
align 64 symtab 0 alias set -1 canonical type 0x2dffa6c0
precision 64
chain >
visited var def_stmt
Which eventually works its way down to:
if (!has_single_use (op))
{
val = build_int_cst (TREE_TYPE (op), 0);
register_new_assert_for (op, code, val, NULL, e, bsi);
retval = true;
}
and this fails with an ICE because TREE_TYPE (op) is real_type, and
you can't build_int_cst with a real_type.
The simplest way of fixing this is simply to disallow
VIEW_CONVERT_EXPR in this context. Comments?
Index: tree-vrp.c
===
--- tree-vrp.c (revision 122839)
+++ tree-vrp.c (working copy)
@@ -3485,7 +3485,6 @@
}
else if (TREE_CODE (rhs) == NOP_EXPR
|| TREE_CODE (rhs) == CONVERT_EXPR
- || TREE_CODE (rhs) == VIEW_CONVERT_EXPR
|| TREE_CODE (rhs) == NON_LVALUE_EXPR)
{
/* Recurse through the type conversion. */
It's indeed broken to look through VIEW_CONVERT_EXPRs here. The patch looks
obviously correct.
Thanks,
Richard.
Re: Tree VRP bug: internal compiler error: in build_int_cst_wide, at tree.c:886
Richard Guenther writes: > > It's indeed broken to look through VIEW_CONVERT_EXPRs here. The patch looks > obviously correct. OK, thanks. Forwarding to gcc-patches. Andrew.
Re: Trouble understanding reload dump file format..
Dave Korn wrote: > (define_insn "mulsi3" > [(set (match_operand:SI 0 "register_operand" "=d") > (mult:SI (match_operand:SI 2 "register_operand" "r") > (match_operand:SI 1 "register_operand" "a"))) >(clobber (match_scratch:SI 3 "b"))] You should be using "=b" to designate the operand as *output* only. Otherwise, reload will attempt (unsuccessfully) to load up "scratch:SI" as input value ... B.t.w. if the register class denoted by "b" has just a single element, you might just as well use the hard reg directly in the insn pattern here. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE [EMAIL PROTECTED]
Re: Building mainline and 4.2 on Debian/amd64
On Mon, Mar 19, 2007 at 08:52:26AM +0100, Andreas Jaeger wrote: > Florian Weimer <[EMAIL PROTECTED]> writes: > > > * Steven Bosscher: > > > >> On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote: > >>> I don't need the 32-bit libraries, so disabling their compilation > >>> would be fine. --enable-targets at configure time might do the trick, > >>> but I don't know what arguments are accepted. > >> > >> Would --disable-multilib work? > > > > I'll try, but I doubt it. According to the installation > > documentation, amd64 is not a multilib target. > > It is - if the documentation is not correct, please tell us where it's > not correct, so that we can fix it, This brings up a point: the build procedure doesn't work by default on Debian-like amd64 distros, because they lack 32-bit support (which is present on Red Hat/Fedora/SuSE/etc distros). Ideally this would be detected when configuring.
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On Mon, Mar 19, 2007 at 09:27:25AM -0400, Diego Novillo wrote: > Manuel López-Ibáñez wrote on 03/17/07 14:28: > > > This is the project proposal that I am planning to submit to Google > > Summer of Code 2007. It is based on previous work of Jeffrey Laws, > > Diego Novillo and others. I hope someone will find it interesting and > > Yes, I can act as a mentor. > > I'm particularly interested in what we are going to do at -O0. Ideally, > I would try to build the SSA form and/or a predicated SSA form and try > to phrase the problem in terms of propagation of the uninitialized > attribute. What worries me is that we can't afford to make -O0 run significantly slower than it does now. Cycle speeds are no longer increasing, we have to be very careful about slowing things down. But it does seem that predicated (or gated) SSA or something similar is needed to handle some of the most common cases we get wrong now (when the initialized-ness of a variable is completely correlated with the state of a boolean flag).
Re: Building mainline and 4.2 on Debian/amd64
On 3/19/07, Joe Buck <[EMAIL PROTECTED]> wrote: This brings up a point: the build procedure doesn't work by default on Debian-like amd64 distros, because they lack 32-bit support (which is present on Red Hat/Fedora/SuSE/etc distros). Ideally this would be detected when configuring. Actually it brings up an even more important thing, distros that don't include a 32bit user land is really just broken. Why do these distros even try to get away with this, they are useless to 99.9% of the people and for the 0.1% of the people who find them interesting, they can just compile with --disable-multilib. -- Pinski
RE: Trouble understanding reload dump file format..
On 19 March 2007 17:03, Ulrich Weigand wrote: > Dave Korn wrote: > >> (define_insn "mulsi3" >> [(set (match_operand:SI 0 "register_operand" "=d") >> (mult:SI (match_operand:SI 2 "register_operand" "r") >> (match_operand:SI 1 "register_operand" "a"))) >>(clobber (match_scratch:SI 3 "b"))] > > You should be using "=b" to designate the operand as *output* only. > > Otherwise, reload will attempt (unsuccessfully) to load up "scratch:SI" > as input value ... :) Thanks! I guess that even makes a reasonable amount of sense, all things considered![*] > B.t.w. if the register class denoted by "b" has just a single > element, you might just as well use the hard reg directly in > the insn pattern here. Hmm, well I modelled my approach on the way e.g. MIPS port uses a class-per-register, and that seems to work ok. Also, it's not actually a hard reg, it's in fact a memory-mapped peripheral. This means that I need to specify secondary reloads (can't be loaded directly from memory as I have no mem->mem move insn, needs to go via a gpr) and that implies that the register has to exist as a class because you can only specify secondary reloads on a per-reg-class basis. cheers, DaveK [*] - #1 in an occasional series of "Things you don't hear people say about reload /every/ day of the week." :-) -- Can't think of a witty .sigline today
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On Mon, 2007-03-19 at 10:33 -0700, Joe Buck wrote: > On Mon, Mar 19, 2007 at 09:27:25AM -0400, Diego Novillo wrote: > > Manuel López-Ibáñez wrote on 03/17/07 14:28: > > > > > This is the project proposal that I am planning to submit to Google > > > Summer of Code 2007. It is based on previous work of Jeffrey Laws, > > > Diego Novillo and others. I hope someone will find it interesting and > > > > Yes, I can act as a mentor. > > > > I'm particularly interested in what we are going to do at -O0. Ideally, > > I would try to build the SSA form and/or a predicated SSA form and try > > to phrase the problem in terms of propagation of the uninitialized > > attribute. > > What worries me is that we can't afford to make -O0 run significantly > slower than it does now. Cycle speeds are no longer increasing, we have > to be very careful about slowing things down. I think it was Honza did some preliminary work a year or two ago which made -O0 use the SSA path, and I seem to recall it was either faster or at least very close in speed. It cleaned up the code with some of the basic fast SSA passes, and the cleanups resulted in faster paths through other parts of the compiler which offset the cost of going into ssa. Perhaps this ought to be looked at again with some seriousness. Some of the SSA machinery has been sped up since then, and Diego is doing some work to throttle otherwise crazy cases... perhaps we can throttle the virtual ops completely at -O0 for speed... We also have a pass manager now, which ought to make trying it much easier. It seems like it is worth a revisit... Andrew
Re: Building mainline and 4.2 on Debian/amd64
On Mon, Mar 19, 2007 at 10:35:15AM -0700, Andrew Pinski wrote: > On 3/19/07, Joe Buck <[EMAIL PROTECTED]> wrote: > >This brings up a point: the build procedure doesn't work by default on > >Debian-like amd64 distros, because they lack 32-bit support (which is > >present on Red Hat/Fedora/SuSE/etc distros). Ideally this would be > >detected when configuring. > > Actually it brings up an even more important thing, distros that don't > include a 32bit user land is really just broken. Why do these distros > even try to get away with this, they are useless to 99.9% of the > people and for the 0.1% of the people who find them interesting, they > can just compile with --disable-multilib. Unfortunately, such distros are in common use, and the GCC project jumps through hoops to support many things that get far less use. A platform that contains only 64-bit libraries is fundamentally a different platform than one that has both 32- and 64-. Ideally there would be a different target triplet for such platforms. Maybe x86_64only? But that would have to be handled upstream. In the meantime, the installation instructions should tell people to use --disable-multilib.
Re: Trouble understanding reload dump file format..
Dave Korn wrote: > Also, it's not actually a hard reg, it's in fact a memory-mapped peripheral. > This means that I need to specify secondary reloads (can't be loaded directly > from memory as I have no mem->mem move insn, needs to go via a gpr) and that > implies that the register has to exist as a class because you can only specify > secondary reloads on a per-reg-class basis. I see, that makes sense. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE [EMAIL PROTECTED]
Re: Building mainline and 4.2 on Debian/amd64
Joe Buck writes: > On Mon, Mar 19, 2007 at 10:35:15AM -0700, Andrew Pinski wrote: > > On 3/19/07, Joe Buck <[EMAIL PROTECTED]> wrote: > > >This brings up a point: the build procedure doesn't work by default on > > >Debian-like amd64 distros, because they lack 32-bit support (which is > > >present on Red Hat/Fedora/SuSE/etc distros). Ideally this would be > > >detected when configuring. > > > > Actually it brings up an even more important thing, distros that don't > > include a 32bit user land is really just broken. Why do these distros > > even try to get away with this, they are useless to 99.9% of the > > people and for the 0.1% of the people who find them interesting, they > > can just compile with --disable-multilib. > > Unfortunately, such distros are in common use, and the GCC project jumps > through hoops to support many things that get far less use. > > A platform that contains only 64-bit libraries is fundamentally a > different platform than one that has both 32- and 64-. Ideally there > would be a different target triplet for such platforms. Maybe > x86_64only? But that would have to be handled upstream. > > In the meantime, the installation instructions should tell people to > use --disable-multilib. Will that work? Unless there's some more configury I don't understand, they'll still end up with libraries in /lib64 rather than /lib. Andrew.
RE: Pointer addition/subtraction tree node
Code of the form int[10] a; int* p = a; int* q = a; int i = 3; p = q + i; is transformed into int * D.900; unsigned int D.899; unsigned int i.0; : i = 3; p = &a; q = &a; i.0 = (unsigned int) i; D.899 = i.0 * 4; D.900 = (int *) D.899; p = D.900 + q; by the time it reaches the fixupcfg pass. It has been suggested to me that a solution might be to trace back through the tree to find which of the operands is derived from a non-pointer variable. I am new to GCC development. How might I go about doing this? Another approach I tried was to detect which of the operands was a compiler intermediate (my theory being that this would always be the non-pointer operand) by using DECL_ARTIFICIAL (TREE_OPERAND (t, 0)) but this breaks if tried on an operand that is not a VAR_DECL. I don't think my theory is sounds but if it is, is there a way to get this to work? Thanks. Alex. > -Original Message- > From: Andrew Pinski [mailto:[EMAIL PROTECTED] > Sent: 19 March 2007 00:47 > To: Alexander Lamaison > Cc: gcc@gcc.gnu.org > Subject: Re: Pointer addition/subtraction tree node > > On 3/18/07, Alexander Lamaison <[EMAIL PROTECTED]> wrote: > > As part of adding a new pass to GCC I am intercepting addition to and > > subtraction from pointers. These are represented by PLUS_EXPR and > > MINUS_EXPR tree nodes. I need to be able to find out which of the > node's > > two operands is the actual pointer and which is the integer that has > been > > added to it. > > > > Is there another way to find out which is which? > > Not right now, I have been working on a new representation of pointer > arithmetic for the tree level. The basic implementation is already > done, see the pointer_plus branch. > > Thanks, > Andrew Pinski
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote: > Perhaps this ought to be looked at again with some seriousness. I think this is an idea whose time has either come, or will shortly. GCC's -O0 is much more extreme than that of other compilers I've used. -- Daniel Jacobowitz CodeSourcery
Re: Building mainline and 4.2 on Debian/amd64
On Mon, Mar 19, 2007 at 06:05:05PM +, Andrew Haley wrote: > Will that work? Unless there's some more configury I don't > understand, they'll still end up with libraries in /lib64 rather than > /lib. It does work. You have to do a bit more fiddling if you want to use 'make install' into a system location, but that's about it. And usually one shouldn't do that anyway. There's /lib64 -> lib and /usr/lib64 -> lib symlinks, which help out. -- Daniel Jacobowitz CodeSourcery
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On 19/03/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote: > Perhaps this ought to be looked at again with some seriousness. I think this is an idea whose time has either come, or will shortly. GCC's -O0 is much more extreme than that of other compilers I've used. Is building this early SSA form something that can be tackled by a newbie developer with almost zero middle-end knowledge within the time frame of the Summer of Code? (At least the core idea, I expect to need more time to actually get the code polished enough to reach mainline, as it happened with the Wcoercion project) Cheers, Manuel.
Re: Google SoC Project Proposal: Better Uninitialized Warnings
Manuel López-Ibáñez wrote on 03/19/07 14:45: > Is building this early SSA form something that can be tackled by a > newbie developer with almost zero middle-end knowledge within the time > frame of the Summer of Code? Yes, it should not be too hard. See tree_lowering_passes. You may also want to read on the compilation flow to get some idea on how things are processed after parsing. There are some diagrams at http://people.redhat.com/dnovillo/Papers/#cgo2007
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On Mon, Mar 19, 2007 at 02:34:22PM -0400, Daniel Jacobowitz wrote: > On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote: > > Perhaps this ought to be looked at again with some seriousness. > > I think this is an idea whose time has either come, or will shortly. > GCC's -O0 is much more extreme than that of other compilers I've used. Yes, -O0 code is worse than it needs to be. It would suffice to consider -O0 the "compile fast, no suprises when debugging" mode. It's an optimization problem, but what is being optimized is the speed of the build/debug/fix/build again cycle.
Re: Constrain not satisfied - floating point insns.
Richard Sandiford wrote: That isn't unconditionally true, is it? reload1.c:gen_reload uses gen_move_insn, which is just a start_sequence/end_sequence wrapper for emit_move_insn_1, which in turn calls the move expanders. Yes, you are right. I over simplified. We can use gen_move_insn when we expect that this will result in an insn that won't require any further reloading. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Google SoC Project Proposal: Better Uninitialized Warnings
> Joe Buck writes: Joe> What worries me is that we can't afford to make -O0 run significantly Joe> slower than it does now. Cycle speeds are no longer increasing, we have Joe> to be very careful about slowing things down. Adding more passes does not necessarily slow down the compiler, as IBM found with XLC. If one can remove enough dead code / statements / insns / IR, one performs more processing on less data leading to less overall work and faster compilation at -O0. David
Re: Building mainline and 4.2 on Debian/amd64
Florian Weimer wrote: * Steven Bosscher: On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote: I don't need the 32-bit libraries, so disabling their compilation would be fine. --enable-targets at configure time might do the trick, but I don't know what arguments are accepted. Would --disable-multilib work? I'll try, but I doubt it. According to the installation documentation, amd64 is not a multilib target. Hmmm, I always use it, and I have never run into the problem you mention. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Re: Trouble understanding reload dump file format..
Dave Korn wrote: In particular, I really don't understand what a RELOAD_FOR_INPUT_ADDRESS means when all the operands are regs, or why there should be three reloads for the same operand when it's just a clobber scratch. Is there something special about how reload handles clobber and match_scratch? Reload types are used for a number of purposes. One of them is the ordering used when emitting the actual reload fixup insns. A fixup for an input reload must come before the insn. A fixup for an output reload must come after the insn. A fixup for an address used by an input reload must come before the input reloads. A fixup for an address used by an output reload must come after the insn, but before the output reloads. Etc. Careful ordering allows us to know the lifetimes of every reload, and hence allows us to share reload registers between reload types that don't overlap, thus reducing the total number of spill regs required. In this case, we have an input reload that requires secondary reloads. Obviously, the secondary reloads must be emitted before the input reload, so we just use the "input address" reload type for convenience, even though there is no actual address involved here. That gets the reloads emitted in the right place. As usual, I'm over simplifying. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Building mainline and 4.2 on Debian/amd64
* Andrew Pinski: > Actually it brings up an even more important thing, distros that don't > include a 32bit user land is really just broken. Are they? I haven't run into problems yet. (And pretty please, I misread the documentation. It does *not* state that amd64 is not a multilib target. Sorry about that.)
Re: error: unable to find a register to spill in class 'FP_REGS'
Never top post. On Mar 19, 2007, at 3:13 AM, Markus Franke wrote: Just another issue. Everything is working fine if using "-O1", "- O2" or "-O3". Maybe this helps. Regards, Markus Markus Franke wrote:
Re: Problem with building libgfortran on PPC
On Sun, Mar 18, 2007 at 09:07:32AM -0700, Andrew Pinski wrote: > On 3/18/07, Victor Kaplansky <[EMAIL PROTECTED]> wrote: > > > >I have obtained the same error on my ppc64 yellow dog linux: > > >collect2: ld terminated with signal 11 [Segmentation fault] > > > >> I get the following error on PPC while bootstrapping mainline. > >> Re-runing make I get: > >> collect2: ld terminated with signal 11 [Segmentation fault] > >> make[8]: *** [libstdc++.la] Error 1 > > Usually that means there is a bug in binutil's ld. It might be better > to use a real FSF stable release of binutils instead of what the > vendor (distro) provides you with. I've been using binutils 2.17 on various distributions of powerpc64-linux and have had no problem with it. Janis
Re: Building mainline and 4.2 on Debian/amd64
Florian Weimer wrote: * Andrew Pinski: Actually it brings up an even more important thing, distros that don't include a 32bit user land is really just broken. Are they? I haven't run into problems yet. (And pretty please, I misread the documentation. It does *not* state that amd64 is not a multilib target. Sorry about that.) I believe the OpenOffice Team had to do some rewriting because they assumed 32-bit ints/pointers, but that's about it. If your bread and butter is Fortran programming, you don't even *know* that the pointers are twice the size on AMD64. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
RE: error: unable to find a register to spill in class 'FP_REGS'
Except when travelling backwards in time and replying to a post that hasn't been written yet! cheers, DaveK -- Can't think of a witty .sigline today On 19 March 2007 20:21, Mike Stump wrote: > Never top post. > > On Mar 19, 2007, at 3:13 AM, Markus Franke wrote: > >> Just another issue. Everything is working fine if using "-O1", "- O2" or >> "-O3". >> Maybe this helps. >> >> Regards, >> Markus >> >> Markus Franke wrote:
Bitfield conversion bug in 4.2?
Hi,
The following code compiles fine in GCC 4.1.
enum E { e };
struct S {
E v:5;
};
S s;
int main() { if (!s.v) return 0; }
In 4.2 (20070307), it gives the following error:
test.cpp: In function 'int main()':
test02.cpp:6: error: could not convert 's.S::v' to 'bool'
test02.cpp:6: error: in arguument to unary !
Is this a bug or new behavior? If the latter, what is this attributed
to?
Thanks,
Eric.
Re: We're out of tree codes; now what?
On Mon, 19 Mar 2007, Doug Gregor wrote: > It's going to have a big performance impact. To extract a 9-bit value, > the compiler will need to do a lot of masking every time it accesses > the TREE_CODE. So, about 16% slower with --enable-checking, 5% slower with --disable-checking. Subcodes might still be the way to go, but I'm feeling less bad about the 9-bit tree code option. As an interested outsider: GCC's compile-time speed has been gradually decreasing for a while now. It seems to be acknowledged as an undesirable thing, but not much has happened to change it. AIUI, this is largely because it's very difficult. Nonetheless, seeing a 5% slow-down caused by fixing a data structure design bogon is disappointing. Nick
Re: Building mainline and 4.2 on Debian/amd64
Joe Buck writes: >This brings up a point: the build procedure doesn't work by default on >Debian-like amd64 distros, because they lack 32-bit support (which is >present on Red Hat/Fedora/SuSE/etc distros). Ideally this would be >detected when configuring. The Debian-like AMD64 system I'm using has 32-bit support, but the build procedure breaks anyways because it assumes 32-bit libraries are in "lib" and 64-bit libraries are in "lib64". Instead, this Debian-like AMD64 system has 32-bit libraries in "lib32" and 64-bit libraries in "lib". Ross Ridge
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On Mon, 2007-03-19 at 18:45 +, Manuel López-Ibáñez wrote: > On 19/03/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote: > > > Perhaps this ought to be looked at again with some seriousness. > > > > I think this is an idea whose time has either come, or will shortly. > > GCC's -O0 is much more extreme than that of other compilers I've used. > > > > Is building this early SSA form something that can be tackled by a > newbie developer with almost zero middle-end knowledge within the time > frame of the Summer of Code? I think so. It shouldn't require a huge learning curve since it ought to be a matter of wiring up existing code to run at times when it does not currently run. ie, I don't think there's a lot of new code to write to make this work. The biggest issue with these warnings at -O0 (as others have mentioned) is going to be the potential for compile-time slowdowns. \Jeff
Re: We're out of tree codes; now what?
Nicholas Nethercote <[EMAIL PROTECTED]> writes: | On Mon, 19 Mar 2007, Doug Gregor wrote: | | >> > It's going to have a big performance impact. To extract a 9-bit value, | >> > the compiler will need to do a lot of masking every time it accesses | >> > the TREE_CODE. | >> | > So, about 16% slower with --enable-checking, 5% slower with | > --disable-checking. | > | > Subcodes might still be the way to go, but I'm feeling less bad about | > the 9-bit tree code option. | | As an interested outsider: GCC's compile-time speed has been | gradually decreasing for a while now. It seems to be acknowledged as | an undesirable thing, but not much has happened to change it. AIUI, | this is largely because it's very difficult. Nonetheless, seeing a 5% | slow-down caused by fixing a data structure design bogon is | disappointing. yeah, the trouble is that we don't seem to agree on what is good for long-term, or if and when we agree whether we would find and allocate resources to implement the solution. So, we end up accumulating small% regressions over small% regressions. Then we get busy with short-term fixes, because that is what gets the releases out the door. Until the next trouble. -- Gaby
Re: Building mainline and 4.2 on Debian/amd64
Florian Weimer writes: > Is there a convenient switch to make GCC bootstrap on Debian/amd64 > without patching the build infrastructure? Apparently, GCC tries to > build 32-bit variants of all libraries (using -m32), but the new > compiler uses the 64-bit libc instead of the 32-bit libc, hence > building them fails. > > I don't need the 32-bit libraries, so disabling their compilation > would be fine. --enable-targets at configure time might do the trick, > but I don't know what arguments are accepted. Others already mentioned --disable-multilib. If you do want to build a multilib build, make sure that the libc6-dev-i386 package is installed, and the appended patch is applied (Maybe a patch using some Makefile conditionals could be applied upstream). For historical reasons lib64 is a symlink to lib, and the 32bit libs are installed into lib32. Building the java gtk/x peers doesn't work, because the gtk/gnome libs are not available for 32bit. Matthias --- gcc/config/i386/t-linux64~ 2002-11-28 14:47:02.0 + +++ gcc/config/i386/t-linux64 2004-06-02 16:07:30.533131301 + @@ -6,7 +6,7 @@ MULTILIB_OPTIONS = m64/m32 MULTILIB_DIRNAMES = 64 32 -MULTILIB_OSDIRNAMES = ../lib64 ../lib +MULTILIB_OSDIRNAMES = ../lib ../lib32 LIBGCC = stmp-multilib INSTALL_LIBGCC = install-multilib
Re: Bitfield conversion bug in 4.2?
On Monday 19 March 2007 23:00:09 Eric Lemings wrote:
> Hi,
>
> The following code compiles fine in GCC 4.1.
>
> enum E { e };
> struct S {
> E v:5;
> };
> S s;
> int main() { if (!s.v) return 0; }
>
> In 4.2 (20070307), it gives the following error:
>
> test.cpp: In function 'int main()':
> test02.cpp:6: error: could not convert 's.S::v' to 'bool'
> test02.cpp:6: error: in arguument to unary !
>
> Is this a bug or new behavior? If the latter, what is this attributed
> to?
It should be fixed in 4.2 branch now, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31157 .
--
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)
Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer
pgpF7tmwa88It.pgp
Description: PGP signature
Re: Bitfield conversion bug in 4.2?
Eric Lemings wrote:
test.cpp: In function 'int main()':
test02.cpp:6: error: could not convert 's.S::v' to 'bool'
test02.cpp:6: error: in arguument to unary !
As per my gcc-bugs message. I suggest this untested patch.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
2007-03-19 Jim Wilson
* call.c (standard_conversion): Set fcode after call to
strip_top_quals.
Index: call.c
===
--- call.c (revision 123071)
+++ call.c (working copy)
@@ -632,7 +632,10 @@
tree bitfield_type;
bitfield_type = is_bitfield_expr_with_lowered_type (expr);
if (bitfield_type)
- from = strip_top_quals (bitfield_type);
+ {
+ from = strip_top_quals (bitfield_type);
+ fcode = TREE_CODE (from);
+ }
}
conv = build_conv (ck_rvalue, from, conv);
}
Listing file-scope variables inside a pass
What should I do if I want a list of all file-scope variables inside my own pass ? The file_scope variable is local to c-decl.c . Is there a reason why the scope holding variables are local to c-decl.c ? - Karthik
Re: We're out of tree codes; now what?
Le Mon, Mar 19, 2007 at 05:41:08PM -0500, Gabriel Dos Reis écrivait/wrote:
> Nicholas Nethercote <[EMAIL PROTECTED]> writes:
>
> | On Mon, 19 Mar 2007, Doug Gregor wrote:
> |
> | >> > It's going to have a big performance impact. To extract a 9-bit value,
> | >> > the compiler will need to do a lot of masking every time it accesses
> | >> > the TREE_CODE.
> | >>
> | > So, about 16% slower with --enable-checking, 5% slower with
> | > --disable-checking.
> | >
> | > Subcodes might still be the way to go, but I'm feeling less bad about
> | > the 9-bit tree code option.
> |
> | As an interested outsider: GCC's compile-time speed has been
> | gradually decreasing for a while now. It seems to be acknowledged as
> | an undesirable thing, but not much has happened to change it. AIUI,
> | this is largely because it's very difficult. Nonetheless, seeing a 5%
> | slow-down caused by fixing a data structure design bogon is
> | disappointing.
>
> yeah, the trouble is that we don't seem to agree on what is good for
> long-term, or if and when we agree whether we would find and allocate
> resources to implement the solution. So, we end up accumulating
> small% regressions over small% regressions. Then we get busy with
> short-term fixes, because that is what gets the releases out the door.
> Until the next trouble.
I'm sorry to ask such a (probably naive) question, but do someone have a
precise idea of the performance strengths and weaknesses of GCC and of other
opensource compilers (like LLVM, Open64, TinyCC, ...) or even compiler for
different languages (SBCL, Haskell, SML, Java, ...). I don't have the big
picture of where is GCC strong - speaking about performance - (w.r.t. to
others compilers) and where is GCC weak.
Maybe a Wiki page on this might help, but I don't have any ideas on this.
Just thinking loud (maybe wrongly). And perhaps is it acceptable to lose
temporarily some performance, if we could hope to recover it later
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On Mon, Mar 19, 2007 at 03:32:19PM -0400, David Edelsohn wrote: > > Joe Buck writes: > > Joe> What worries me is that we can't afford to make -O0 run significantly > Joe> slower than it does now. Cycle speeds are no longer increasing, we have > Joe> to be very careful about slowing things down. > > Adding more passes does not necessarily slow down the compiler, as > IBM found with XLC. If one can remove enough dead code / statements / > insns / IR, one performs more processing on less data leading to less > overall work and faster compilation at -O0. Agreed; -O0 could in principle be sped up; the important thing is making sure that it happens. In this case, adding a pass that computes SSA information that is used only for uninitialized variable warnings costs time; it could be compensated for by finding other speedups, but taken alone it is a slowdown.
gcc-4.1-20070319 is now available
Snapshot gcc-4.1-20070319 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070319/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 123071 You'll find: gcc-4.1-20070319.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070319.tar.bz2 C front end and core compiler gcc-ada-4.1-20070319.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070319.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070319.tar.bz2 C++ front end and runtime gcc-java-4.1-20070319.tar.bz2 Java front end and runtime gcc-objc-4.1-20070319.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070319.tar.bz2The GCC testsuite Diffs from 4.1-20070312 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: We're out of tree codes; now what?
On 3/19/07, Nicholas Nethercote <[EMAIL PROTECTED]> wrote: As an interested outsider: GCC's compile-time speed has been gradually decreasing for a while now. It seems to be acknowledged as an undesirable thing, but not much has happened to change it. AIUI, this is largely because it's very difficult. Nonetheless, seeing a 5% slow-down caused by fixing a data structure design bogon is disappointing. GCC has also been getting improved functionality, better optimizations, and better language support. Some of these improvements are going to cost us at compile time, because better optimizations can require more time, and today's languages require more work to compile and optimize than yesterday's. No, I don't want my compiler to be 5% slower, but I'll give up 5% for better standards conformance and improved code generation. It's not all bad news, either. Canonical types got us 3-5% speedup in the C++ front end (more on template-heavy code), so I figure I have at least a 3% speedup credit I can apply against the 9-bit code patch. That brings this patch under 2% net slow-down, so we should just put it in now :) Cheers, Doug
Re: We're out of tree codes; now what?
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote: GCC has also been getting improved functionality, better optimizations, and better language support. Some of these improvements are going to cost us at compile time, because better optimizations can require more time, and today's languages require more work to compile and optimize than yesterday's. No, I don't want my compiler to be 5% slower, but I'll give up 5% for better standards conformance and improved code generation. Of course, the problem is not 5%, but the yet again 5%, on top of, I don't know, 200% since GCC 2.95.3?? Also, it is "better optimizations" for some purposes, but not for others. For example, many of the >140 passes are redundant for typical C code. It's not all bad news, either. Canonical types got us 3-5% speedup in the C++ front end (more on template-heavy code), so I figure I have at least a 3% speedup credit I can apply against the 9-bit code patch. That brings this patch under 2% net slow-down, so we should just put it in now :) But only for C++. I'm still in favor of the 9-bit code patch. But I think the slowdown should not be taken so lightly as you appear to do ;-) Gr. Steven
Re: We're out of tree codes; now what?
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: [...] | I'm sorry to ask such a (probably naive) question, but do someone have a | precise idea of the performance strengths and weaknesses of GCC and of other | opensource compilers (like LLVM, Open64, TinyCC, ...) or even compiler for | different languages (SBCL, Haskell, SML, Java, ...). I have no _direct_ comparison between SBCL and GCC. However, for one project I'm working on, I've been able to use both SBCL and GCL (which uses GNU C as back-end). While I affectionally go with GCL, I must applaud SBCL for its quality, speed, and informative notes. http://lists.nongnu.org/archive/html/axiom-developer/2007-03/msg00047.html I'm only a SBCL user, not developer -- and I'm not familiar with its code base. I work with GCL code base, but its documentation is just as good that of Axiom (which is a constant real pain for us). GCC definitely has an edge there. Camm Maguire (the main GCL developer), Robert Boyer and I all agree that GCC's speed badly affects GCL's speed negatively. [ GCL compiles Lisp codes by translation to C codes, compilation on the fly. ] For HAskell, GHC is the autoritative compiler. Overall, I tend to find it as good as GCC -- except that GHC comes with *lots* of libraries and good documentation; but, we are not comparing libraries here I think. [...] | Maybe a Wiki page on this might help, Definitely. -- Gaby
Re: We're out of tree codes; now what?
"Doug Gregor" <[EMAIL PROTECTED]> writes: [...] | and optimize than yesterday's. No, I don't want my compiler to be 5% | slower, but I'll give up 5% for better standards conformance and | improved code generation. similar justifications for yet another small% of slowdown have been given routinely for over 5 years now. small% build up; and when they build up, they don't not to be convincing ;-) -- Gaby
Fwd: Will you be my mentor for Google's Summer of Code?
Hi. I am looking for someone to mentor me on this project for the GNU Scientific Library. I have already tried asking Brian Gough (forwarded below), and he suggested that someone from the gcc team might be able to mentor me, presumably under the auspices of GNU or something like that. I hope there's someone here who can help or who can suggest a mentor for me. Thank you, - Jordi G. H. -- Forwarded message -- From: Jordi Gutierrez Hermoso <[EMAIL PROTECTED]> Date: 15-Mar-2007 14:39 Subject: Will you be my mentor for Google's Summer of Code? To: "Brian V. Smith" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Hi. Since you seem to be the only currently active developer on the GSL, I thought I would try asking you. I need someone who will agree to mentor me for Google's Summer of Code. As you have probably been reading in the GSL mailing list, my idea is to implement an efficient C++ version of the GSL, oviously using the existent GSL code in C as a base. Specifically, I want to * Replace the gsl_ prefixes in all GSL functions with a GSL namespace. * Implement classes where appropriate, mostly replacing C structs with fully-featured C++ classes. * Use STL classes where appropriate. In particular, the core gsl_vector and gsl_matrix structs ought to be a class implemented as tightly as possible; either with valarrays (my preference) or via whatever classes Boost is using for their BLAS implementation. Relevant arguments against valarrays: http://nkari.uw.hu/Tutorials/CPPTips/musings_valarray * Replace manual memory management with C++ constructors and destructors. * Provide a GSL error handler with exception classes and exception throwing. * Replace preprocessor macro hacks for using various numeric types within the GSL with templated classes, whenever appropriate. * Consider using free code from other numeric libraries, such as CERNLib, TNT, HAL, and Blitz++, as suggested by this discussion thread from the GSL mailing list: http://lists.gnu.org/archive/html/help-gsl/2007-03/msg00030.html This is a very large project, and I do not think it's realistic that I can do all of this for all of the GSL. I propose to begin only with the core GSL functionality, which I see as: * Error handling, * Basic mathematical functions, * Complex numbers (might use std::complex), * Linear algebra structs, linear algebra, and BLAS. If time permits, the other high-priority parts of the GSL I consider to be * Numerical integration and differentiation, * Special functions, * Random number generation, * Eigensystems, * Fast Fourier transform, follow by the rest of the GSL. If you agree to mentor me on this summer coding project, please contact both me and Matt Lee from GNU (CC'ed from this email) so that I can complete my application before March 24 and so that Matt Lee can modify the following webpages appropriately: http://www.gnu.org/software/soc-projects/ideas.html http://www.gnu.org/software/soc-projects/guidelines.html Thank you, - Jordi G. H.
Re: We're out of tree codes; now what?
On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: similar justifications for yet another small% of slowdown have been given routinely for over 5 years now. small% build up; and when they build up, they don't not to be convincing ;-) But what is the solution? We can complain about performance all we want (and we all love to do this), but without a plan to fix it we're just wasting effort. Shall we reject every patch that causes a slow down? Hold up releases if they are slower than their predecessors? Stop work on extensions, optimizations, and bug fixes until we get our compile-time performance back to some predetermined level? We have hit a hard limit in the design of GCC. We need to either use more memory, use more compilation time, re-architect non-trivial portions of GCC, remove functionality, or come up with something very, very clever. Pick one, but if the pick the last one, you have to specify what "something very, very clever" is, because we seem to be running short on ideas. Cheers, Doug
Re: We're out of tree codes; now what?
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote: On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > similar justifications for yet another small% of slowdown have been > given routinely for over 5 years now. small% build up; and when they > build up, they don't not to be convincing ;-) But what is the solution? We can complain about performance all we want (and we all love to do this), but without a plan to fix it we're just wasting effort. Shall we reject every patch that causes a slow down? Hold up releases if they are slower than their predecessors? Stop work on extensions, optimizations, and bug fixes until we get our compile-time performance back to some predetermined level? This usually happens at least for some people. Actually compile time performance is a bug no matter which way we look at it so you are going to introduce one bug for another, no thanks. -- Pinski
Re: We're out of tree codes; now what?
"Doug Gregor" <[EMAIL PROTECTED]> writes: | On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: | > similar justifications for yet another small% of slowdown have been | > given routinely for over 5 years now. small% build up; and when they | > build up, they don't not to be convincing ;-) | | But what is the solution? We can complain about performance all we | want (and we all love to do this), but without a plan to fix it we're | just wasting effort. You're writing that as if no solution (and recoginized shortcomings) had been suggested. | Shall we reject every patch that causes a slow down? I read the comments differently. -- Gaby
4.2 wrong code regression [PR 31136]
Hi, I recently filed a bug against 4.2: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136 The bug does not appear to be in 4.1.2 or mainline. Is it something that could be fixed for 4.2.0? Is this a good place to ask this question? (er... the previous question :) Thanks, Charles J. Tabony
Re: We're out of tree codes; now what?
On Mon, 19 Mar 2007, Doug Gregor wrote: But what is the solution? We can complain about performance all we want (and we all love to do this), but without a plan to fix it we're just wasting effort. Shall we reject every patch that causes a slow down? Hold up releases if they are slower than their predecessors? Stop work on extensions, optimizations, and bug fixes until we get our compile-time performance back to some predetermined level? We have hit a hard limit in the design of GCC. We need to either use more memory, use more compilation time, re-architect non-trivial portions of GCC, remove functionality, or come up with something very, very clever. Pick one, but if the pick the last one, you have to specify what "something very, very clever" is, because we seem to be running short on ideas. GCC is a very ambitious compiler: - it supports a lot of platforms - it supports a lot of languages However, most users do not use most of those combinations. The problem is that supporting all these combinations hurts the specific combinations. For example, I almost always compile C, and usually on x86 or AMD64. So I don't care if the C++ compiler has improved, or a new language front-end is added, or whatever. (Other users will have different priorities.) As for what is best to do, I don't know. But I do know that complexity is bad, and that GCC is very complex. You are absolutely right about there being hard limits. There are trade-offs required. Whether the current and ongoing trade-offs are the right ones is an open question. Nick
RE: Pointer addition/subtraction tree node
> -Original Message- > From: Andrew Pinski [mailto:[EMAIL PROTECTED] > Sent: 19 March 2007 00:47 > To: Alexander Lamaison > Cc: gcc@gcc.gnu.org > Subject: Re: Pointer addition/subtraction tree node > > On 3/18/07, Alexander Lamaison <[EMAIL PROTECTED]> wrote: > > As part of adding a new pass to GCC I am intercepting addition to and > > subtraction from pointers. These are represented by PLUS_EXPR and > > MINUS_EXPR tree nodes. I need to be able to find out which of the > node's > > two operands is the actual pointer and which is the integer that has > been > > added to it. > > > > Is there another way to find out which is which? > > Not right now, I have been working on a new representation of pointer > arithmetic for the tree level. The basic implementation is already > done, see the pointer_plus branch. > > Thanks, > Andrew Pinski Apologies for top-posting before: Code of the form int[10] a; int* p = a; int* q = a; int i = 3; p = q + i; is transformed into int * D.900; unsigned int D.899; unsigned int i.0; : i = 3; p = &a; q = &a; i.0 = (unsigned int) i; D.899 = i.0 * 4; D.900 = (int *) D.899; p = D.900 + q; by the time it reaches the fixupcfg pass. It has been suggested to me that a solution might be to trace back through the tree to find which of the operands is derived from a non-pointer variable. I am new to GCC development. How might I go about doing this? Another approach I tried was to detect which of the operands was a compiler intermediate (my theory being that this would always be the non-pointer operand) by using DECL_ARTIFICIAL (TREE_OPERAND (t, 0)) but this breaks if tried on an operand that is not a VAR_DECL. I don't think my theory is sounds but if it is, is there a way to get this to work? Thanks. Alex.
Re: We're out of tree codes; now what?
On Mar 19, 2007, at 3:41 PM, Gabriel Dos Reis wrote: yeah, the trouble is that we don't seem to agree on what is good for long-term Sure we do, unless you want a slower compiler that doesn't track the ANSI C++ standard.
Re: Google SoC Project Proposal: Better Uninitialized Warnings
Joe Buck wrote: Agreed; -O0 could in principle be sped up; the important thing is making sure that it happens. In this case, adding a pass that computes SSA information that is used only for uninitialized variable warnings costs time; it could be compensated for by finding other speedups, but taken alone it is a slowdown. For one class of users, which includes many Ada users, speeding up is less of an issue than code size. In a large scale (millions of lines of code) application, the sheer size of the -O0 executable can be a serious impediment to development, and slows down the development cycle (compile/debug/fix/recompile), e.g. when this executable is so large that it takes ages to download to an embedded target, or when you have to start fiddling to set -g only in selected units, because the overall size of the executable is too large. We are seeing that GCC 4 is significantly worse than GCC 3 in this respect (although Eric has some ideas on how to help fix this by attacking unused size functions).
Re: We're out of tree codes; now what?
Nicholas Nethercote wrote: > As for what is best to do, I don't know. But I do know that complexity > is bad, and that GCC is very complex. You are absolutely right about > there being hard limits. There are trade-offs required. Whether the > current and ongoing trade-offs are the right ones is an open question. I do think compilation speed -- and memory use -- is important. However, I do also think that it's reasonable to measure compilation speed against workstation speed. Compiling GCC takes me a lot less time than it did even a few years ago because I have much faster computers. I realize that not everyone is so lucky, but most people are at least somewhat as lucky. (And some are luckier; I'm generally using 2-processor Xeon machines that are about a year old, not clusters.) I also think that, if people are motivated, the memory savings (and attendant time savings) are there to be had. The work that Sandra, Kazu, et. al. did was a win. There's plenty more like that, and some of it is probably lower-hanging fruit. The general rule is: look for lists and turn them into vectors. GCC has very few places where it inserts into the middle of a linked list, so this is almost always a win, even for short lists. For a more ambitious project, switch from GC to memory pools. This is definitely a doable thing (I'd be happy to help sketch a design, if someone's motivated enough to do the work) but the level of effort required is measured in person months. I think the reason we (GCC developers, not CodeSourcery) are not working on these projects is that, thus far, nobody's decided it's worth the person-months required to do the work. I believe that LTO may be the driver for that. (And, yes, I expect to see more activity on LTO in the relatively near future.) As for the current problem, I think a 3% hit is pretty big. I didn't find subcodes that ugly, so I guess I'm inclined to go with subcodes, and avoid the hit. I think it's fair for front ends to pay for their largesse. There are also relatively cheap changes in the C++ front end to salvage a few codes, and postpone the day of reckoning. For example: 1. Eliminate HANDLER. Every HANDLER is assocaited with a TRY_BLOCK, so make TRY_BLOCK have a variable-length list of handlers, as part of its operand list. 2. Eliminate TINST_LEVEL. This isn't part of the program representation; it's just a bookkeeping mechanism internal to the front end. As such, it can become a non-TREE data structure. 3. Collapse NEW_EXPR and VEC_NEW_EXPR into a single NEW_EXPR with an IS_VEC bit. Do the same with DELETE_EXPR and VEC_DELETE_EXPR. Especially (2) and (3) are relatively easy transformations. (2) is unquestionably something that we want to do anyhow. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Student applications for Google Summer of Code 2007
Google is now accepting student applications for Google Summer of Code 2007. Students who wish to apply for a gcc project should do so now. The deadline is March 24. Here is a guide for student applicants: http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants Good luck! Ian
Re: We're out of tree codes; now what?
On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: As for the current problem, I think a 3% hit is pretty big. I didn't find subcodes that ugly, so I guess I'm inclined to go with subcodes, and avoid the hit. We know that one still mostly unaddressed problem that tree-ssa left us with, is poorer code for bitfield operations. That means the 3% can probably be reduced further. Another thing I like about the 9-bit tree code approach is that we keep the size of the 'tree' data structure the same, so there is no effect on memory. I think that 3% is unfortunate but worth it because the impact on the structure of the compiler is negligible, while subcodes require significant rewrites of some parts of gcc. Let's be fair here: A 3% hit is small compared to the cumulative slowdown we already have in GCC 4.3 since the start of stage 1, and negligible compared to the total slowdown we've accumulated over the years. I know this is not really an argument, but let's face it: Much larger patches and branch merges have unintentionally increased compile time by more than 3%, and we didn't have a large discussion about it. Those were the power plants, and Doug's patch is the (you've guessed it!) bikeshed! ;-) Back to the technical arguments... Subcodes require a bigger 'tree' data structure so there will be a memory usage hit, I don't think there's disagreement about that. We don't know if subcodes will have no compiler speed hit. At least, I don't recall seeing any numbers yet. But if 'tree' is bigger, the chances are that we'll see poorer cache behavior, and therefore a slower compiler. So the subcodes approach may end up no better than the 9-bit tree code approach wrt. compiler speed. (Of course, for a good technical decision, you'd have to try both approaches and do a fair comparison.) I also think subcudes are bug prone, because you have more cases to handle and people are unfamiliar with this new structure. The impact of subcodes on the existing code bases is just too large for my taste. I think it's fair for front ends to pay for their largesse. There are also relatively cheap changes in the C++ front end to salvage a few codes, and postpone the day of reckoning. I think that day of reckoning will come very soon again, with more C++0x work, more autovect work, OpenMP 3.0, and the tuples and LTO projects, etc., all requiring more tree codes. And if there comes a point somewhen, where we can go back to a smaller tree code field, it is much easier to do so with the 9-bit tree code approach, than with subcodes. Gr. Steven
