A Survey on Defect Management Practices in Free/Open Source Software
Sir/Madam I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study to identify practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Some thoughts and quetsions about the data flow infrastracture
> Combiner is an older approach of code selection. Combine can be considered both as code selection or optimization. Likewise, CSE. In many cases, especially now that we have the tree optimizers, CSE does more code selection (best choice of operand) than CSE. So you could say that CSE and Combine are, in some sense, doing the same thing but with different data structures. Well before GCC 4.x there was an attempt that a few of us worked on to try to move the algebraic simplifications from combine to simplify-rtx.c, just like we put tree folding in fold-const.c. At that point, combine just becomes "bookkeeping". The problem with that approach was what to do with such things as nonzero_bits and num sign bit copies. But if those (and more!) become part of a global DF infrastructure, then they are available in *all* RTL passes. Next, one can finish the task of moving the simplifications to simplify-rtx.c (since the global information will always be around) and much of the rest of combine is replaced by the incremental update part of DF. That means we could merge CSE and combine and do a *lot* more than we ever were able to do before while having the code for both passes be much simpler.
Performance regression on the 4.3 branch?
I noticed a performance regression on the following code:
$ cat a.c
#include
#include
void
add256 (uint64_t x[4], const uint64_t y[4])
{
unsigned char carry;
x[0] += y[0];
carry = (x[0] < y[0]);
x[1] += y[1]+carry;
carry = carry ? (x[1] <= y[1]) : (x[1] < y[1]);
x[2] += y[2]+carry;
carry = carry ? (x[2] <= y[2]) : (x[2] < y[2]);
x[3] += y[3]+carry;
}
int
main (void)
{
int i;
uint64_t x[4], y[4];
x[0] = 0; x[1] = 0; x[2] = 0; x[3] = 0;
y[0] = 0x0123456789abcdefULL;
y[1] = 0xfedcba9876543210ULL;
y[2] = 0xdeadbeeff001baadULL;
y[3] = 0x001001001001ULL;
for ( i=0 ; i<1 ; i++ )
add256 (x, y);
printf ("%016llx%016llx%016llx%016llx\n",
(unsigned long long)x[3],
(unsigned long long)x[2],
(unsigned long long)x[1],
(unsigned long long)x[0]);
return 0;
}
$ gcc -march=pentium4 -O3 a.c && time ./a.out
064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00
./a.out 1.81s user 0.00s system 99% cpu 1.818 total
$ gcc-4.3 -march=pentium4 -O3 a.c && time ./a.out
064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00
./a.out 2.40s user 0.01s system 87% cpu 2.746 total
where gcc is gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) and gcc-4.3
is gcc version 4.3.0 20070209 (experimental). I don't have a 4.1 or
4.2 compiler at hand, so I don't know if it's a 4.2 or 4.3 regression,
or even if there's a special patch in redhat 4.1 that makes it
lightning fast. But in any case, I wondered if it was known, and if it
was worth opening a PR.
Thanks,
FX
Re: Some thoughts and quetsions about the data flow infrastracture
Well before GCC 4.x there was an attempt that a few of us worked on to try to move the algebraic simplifications from combine to simplify-rtx.c, just like we put tree folding in fold-const.c. At that point, combine just becomes "bookkeeping". The problem with that approach was what to do with such things as nonzero_bits and num sign bit copies. Actually, simplify-rtx.c now uses nonzero_bits and num_sign_bit_copies: these ask combine for the value in the case of pseudos, via the "RTL hooks" mechanism. The same RTL hooks mechanism allow combine to try using its (clobber (const_int 0)) idiom in gen_lowpart, for example. It was done in 4.1 or 4.2, I don't remember, and it allowed quite a few simplifications to be moved from combine_simplify_rtx to simplify-rtx.c. It is possible to move a lot more indeed. The problems are mainly these two: 1) what to do with (clobber (const_int 0)). This should be not so much of a problem thanks to validate_change, but I'd be weary of having such CLOBBER rtx-en in REG_EQUAL notes! 2) a lot of this is hard to be done incrementally. For example, it is hard to move any one of simplify_and_const_int, make_compound_operation, expand_compound_operation, force_to_mode, simplify_shift_const without moving the others. This means that the patches would be huge. Or it could be possible to move simplify_comparison, but it is a 1200-line function so the almost-mechanic changes needed to move it would be also very hard to review. The problem with fold_rtx is the other way round; it's hard to move the lookup logic into simplify-rtx.c even using RTL hooks. That means we could merge CSE and combine and do a *lot* more than we ever were able to do before while having the code for both passes be much simpler. Unfortunately, we should not forget CSE's secondary functionality, which is to act as garbageman for the GCSE pass. Paolo
Re: Performance regression on the 4.3 branch?
François-Xavier Coudert napisał(a): $ gcc -march=pentium4 -O3 a.c && time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 ./a.out 1.81s user 0.00s system 99% cpu 1.818 total $ gcc-4.3 -march=pentium4 -O3 a.c && time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 ./a.out 2.40s user 0.01s system 87% cpu 2.746 total where gcc is gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) and gcc-4.3 is gcc version 4.3.0 20070209 (experimental). I don't have a 4.1 or 4.2 compiler at hand, so I don't know if it's a 4.2 or 4.3 regression, or even if there's a special patch in redhat 4.1 that makes it lightning fast. But in any case, I wondered if it was known, and if it was worth opening a PR. I see this on 4.2 vs 4.3 on my k8 box. $ gcc42 -O3 a.c --save-temps && time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 ./a.out 0.43s user 0.00s system 92% cpu 0.462 total $ gcc43 -O3 a.c --save-temps && time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 ./a.out 0.60s user 0.00s system 98% cpu 0.610 total
Re: GCC 4.1.2 RC3 Cancelled
On Tue, 13 Feb 2007, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
>
> > What I need to work out is what combinations of target and flags this
> > problem occurs under. E.g. is this problem sparc-solaris only or does it
> > occur on any target using pic? Or is it some subset of all platforms?
> > What about targets that default to pic without any extra flags? Etc.
>
> It will occur on any target where binds_local_p is false for the
> function that does not throw exceptions. That is target-dependent, but,
> in general, it will fail with -fpic of -fPIC. The reason is that the
> default implementation of binds_local_p considers global functions not
> to be locally bound in shared libraries (which it determines by checking
> flag_shlib) and flag_shlib is generally set if flag_pic is true.
How about this patch for mainline/4.2? I can add it to 4.1 after the
release.
Tested via "make check" on the current 4.1.x svn on sparc-sun-solaris2.10
using four passes: generic, -fpic, -fPIC and -m64. I verified in the
g++.sum file that the nothrow-1.C test is skipped in the -fpic/-fPIC cases
but not in the others.
2007-02-13 Kaveh R. Ghazi <[EMAIL PROTECTED]>
* g++.dg/tree-ssa/nothrow-1.C: Skip test if -fpic/-fPIC is used.
diff -rup orig/egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C
egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C
--- orig/egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C
2006-01-23 00:09:00.0 -0500
+++ egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C 2007-02-13
21:58:10.160212524 -0500
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O1 -fdump-tree-cfg" } */
+/* { dg-skip-if "" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
double a;
void t()
{
gcc (lack of) return type warnings
Hi,
I was lately having some issues with a cross platform project where
the code compiled fine with gcc and didn't under vc++. Turned out it had
to do with me forgetting a return statement in an int function.
I find it kind of weird that such misbehavior won't even reported as Warning
unless you compile with -Wall - Is that desired or could that be
considered a bug?
int foo()
{
}
int main()
{
int test = foo();
]
This will compile just fine. When compiled with -Wall it will at least
bring up a warning about the missing return statement in foo(), nothing
about main tho either. Or is there some standard that implicitly declares
main to return 0 when there is no explicit return statement?
regards,
Tobi
Re: Performance regression on the 4.3 branch?
On Wed, Feb 14, 2007 at 02:34:24PM +0100, Paweł Sikora wrote: > François-Xavier Coudert napisał(a): > > >$ gcc -march=pentium4 -O3 a.c && time ./a.out > >064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 > >./a.out 1.81s user 0.00s system 99% cpu 1.818 total > >$ gcc-4.3 -march=pentium4 -O3 a.c && time ./a.out > >064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 > >./a.out 2.40s user 0.01s system 87% cpu 2.746 total > > > >where gcc is gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) and gcc-4.3 > >is gcc version 4.3.0 20070209 (experimental). I don't have a 4.1 or > >4.2 compiler at hand, so I don't know if it's a 4.2 or 4.3 regression, > >or even if there's a special patch in redhat 4.1 that makes it > >lightning fast. But in any case, I wondered if it was known, and if it > >was worth opening a PR. > > I see this on 4.2 vs 4.3 on my k8 box. > > $ gcc42 -O3 a.c --save-temps && time ./a.out > 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 > ./a.out 0.43s user 0.00s system 92% cpu 0.462 total > > $ gcc43 -O3 a.c --save-temps && time ./a.out > 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 > ./a.out 0.60s user 0.00s system 98% cpu 0.610 total Is this the saem as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735 Can you try gcc 4.3 revision 119759? H.J.
Re: How should __attribute__ ((gnu_inline)) behave?
On Tue, Feb 13, 2007 at 06:21:41PM -0800, Ian Lance Taylor wrote:
> Should __attribute__ ((gnu_inline)) be treated the same as a gnu89
> extern inline definition? Or should the extern part be optional?
> That is, should there be a difference between these two definitions?
>
> extern __attribute__ ((gnu_inline)) inline int foo () { return 0; }
> __attribute__ ((gnu_inline)) inline int foo () { return 0; }
The gnu_inline attribute was meant to be a modifier for the inline
keyword, that would make it behave with GNU89 inline semantics.
So, extern __attribute__ ((gnu_inline)) inline int foo () { return 0; }
in -std=gnu99 mode is exactly the same as extern inline int foo () { return 0; }
in -std=gnu89 mode, similarly for
__attribute__ ((gnu_inline)) inline int foo () { return 0; } in -std=gnu99
vs. inline int foo () { return 0; } in -std=gnu89, etc.
The gnu_inline attribute should e.g. allow adding:
#define inline inline __attribute__ ((gnu_inline))
getting the same inline behavior as -std=gnu89 code (unless you #undef
it).
The testsuite/gcc.dg/inline-17.c testcase already verifies this.
Jakub
Re: Some thoughts and quetsions about the data flow infrastracture
> Actually, simplify-rtx.c now uses nonzero_bits and num_sign_bit_copies: > these ask combine for the value in the case of pseudos, via the "RTL > hooks" mechanism. Right. That was certainly a step (and was discussed a while ago), but doing it more globally would make it even easier. > 1) what to do with (clobber (const_int 0)). This should be not so much > of a problem thanks to validate_change, but I'd be weary of having such > CLOBBER rtx-en in REG_EQUAL notes! Just return NULL. The philosophy of simplify_rtx is different from combine. In the former, you're being asked "can you simplify this?" while in the latter, there's a lot of intertwining between simplification and substitution. So you can just return "no, I can't simplify it" and combine would then do what it wants do with that result. > 2) a lot of this is hard to be done incrementally. For example, it is > hard to move any one of simplify_and_const_int, make_compound_operation, > expand_compound_operation, force_to_mode, simplify_shift_const without > moving the others. Indeed. And you can't just move them intact because of the change of philosphy. I originally wrote those routines and so am the most familiar with them. Once the infrastructure is ready, I probably should take a look at what's involved. > > That means we could merge CSE and combine and do a *lot* more than we ever > > were able to do before while having the code for both passes be much > > simpler. > > Unfortunately, we should not forget CSE's secondary functionality, which > is to act as garbageman for the GCSE pass. Right, but much of that functionality is more in the arena of operand selection than true "cse".
minimal version of bison for Gcc?
Hello,
It seems according to http://gcc.gnu.org/install/prerequisites.html that the
minimal version of bison required in GCC (for those hacking the few .y
files) is 1.28 (released in july 1999).
Is there a reason why a 2.x version of bison would not be acceptable? FWIW,
I am not considering using bison in a frontend, but just to parse some kind
of "scripts" or internal data inside a (usually unused) static analysis
pass...
bison 2.0 was released in jan 2006, and bison 2.1 in september 2005.
The current version of bison is 2.3 (released in june 2006).
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: Some thoughts and quetsions about the data flow infrastracture
[trimming down the Cc list] 1) what to do with (clobber (const_int 0)). This should be not so much of a problem thanks to validate_change, but I'd be weary of having such CLOBBER rtx-en in REG_EQUAL notes! Just return NULL. The philosophy of simplify_rtx is different from combine. In the former, you're being asked "can you simplify this?" while in the latter, there's a lot of intertwining between simplification and substitution. So you can just return "no, I can't simplify it" and combine would then do what it wants do with that result. Yes, one possibility is to use a RTX hook for this too. By default you would return NULL (and this would propagate up); in combine you could override it to return the CLOBBER. To some extent, simplify-rtx.c could *know* about CLOBBER. It would just not return it unless in combine. Paolo
Re: gcc (lack of) return type warnings
Tobias Pflug <[EMAIL PROTECTED]> writes: > This will compile just fine. When compiled with -Wall it will at least > bring up a warning about the missing return statement in foo(), nothing > about main tho either. Or is there some standard that implicitly declares > main to return 0 when there is no explicit return statement? If the return value of a function is never used then it is perfectly valid to fall through the end of it. For main, the default action is to return 0 since C99. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Some thoughts and quetsions about the data flow infrastracture
> Yes, one possibility is to use a RTX hook for this too. By default you > would return NULL (and this would propagate up); in combine you could > override it to return the CLOBBER. I really don't see why. Look at when combine calls the simplify routines now. If they return zero, it uses the original value. If the simplify routines do more, that will still be true. I don't see the point in preserving the CLOBBER kludge in an environment that no longer needs it. > To some extent, simplify-rtx.c could *know* about CLOBBER. It *could*, but I think it would be much cleaner if it *didn't*.
Re: gcc (lack of) return type warnings
Andreas Schwab wrote:
Tobias Pflug <[EMAIL PROTECTED]> writes:
This will compile just fine. When compiled with -Wall it will at least
bring up a warning about the missing return statement in foo(), nothing
about main tho either. Or is there some standard that implicitly declares
main to return 0 when there is no explicit return statement?
If the return value of a function is never used then it is perfectly valid
to fall through the end of it. For main, the default action is to return
0 since C99.
Andreas.
Well this might be, but the behavior of gcc does not change depending
on whether or not it is being used.
int foo() {}
int main() { foo(); }
^ No problem here
int foo() {}
int main
{ int test = foo();
test++;
printf("%d\n",test);
}
^ But this compiles without complaining as well. The result is random
values for test.
That's not desirable is it ?
-Tobi
Re: Some thoughts and quetsions about the data flow infrastracture
Richard Kenner wrote: Yes, one possibility is to use a RTX hook for this too. By default you would return NULL (and this would propagate up); in combine you could override it to return the CLOBBER. I really don't see why. Look at when combine calls the simplify routines now. If they return zero, it uses the original value. Some of the combine simplifications (you obviously know that) work by "hoping" that the CLOBBER is simplified away. I don't think you can preserve all their power if you propagate NULL. In most cases you can replace CLOBBER with NULL, but I don't think that's possible everywhere. Paolo
Re: gcc (lack of) return type warnings
Tobias Pflug <[EMAIL PROTECTED]> writes: > That's not desirable is it ? If you are concerned, you are free to use -Wreturn-type. There are many types of undefined behaviour that are not warned by default. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Performance regression on the 4.3 branch?
H. J. Lu wrote on 02/14/07 09:22: Is this the saem as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735 No, it isn't.
mudflap vs bounds-checking
Hi all, I was somewhat used to the bounds-checking patches for GCC 3.x from Herman ten Brugge. Now that GCC-4.x ships with mudflap, I am a bit confused, since the bounds-checking patches also exist at least for until GCC-4.0.2. What is the difference between the two systems? Thanks, Christophe.
Re: gcc (lack of) return type warnings
On 14/02/07, Andreas Schwab <[EMAIL PROTECTED]> wrote: Tobias Pflug <[EMAIL PROTECTED]> writes: > That's not desirable is it ? If you are concerned, you are free to use -Wreturn-type. There are many types of undefined behaviour that are not warned by default. And Wreturn-type is enabled by -Wall. Moreover, there are many types of undefined behaviour that are not warned at all! Gabriel is working on a new -Wundefined option (PR 30334), so if you find any of those, or you think that this should be warned independently of -Wreturn-type, please add a comment to the PR. Perhaps -Wundefined could be enabled by default like -Woverflow. Cheers, Manuel.
Re: Some thoughts and quetsions about the data flow infrastracture
> Some of the combine simplifications (you obviously know that) work by > "hoping" that the CLOBBER is simplified away. I don't think you can > preserve all their power if you propagate NULL. In most cases you can > replace CLOBBER with NULL, but I don't think that's possible everywhere. Yeah, but those are quite rare and I think each could probably be handled some other way on a case-by-case-basis.
Insn canonicalization not only with constant
Hi, Although I have been porting and using gcc for quite a while now, I am still a newbie at the internals and would be grateful if you can help me. I have designed a CPU architecture where most of the instructions only accept data operands as registers and no immediate values are allowed, which is causing me some trouble in gcc. One of the problems is instruction canonicalization. I have some special single instructions to execute operations, which on other processors would take several instructions, e.g. scaling of 64-bit into 32-bit using pre-set, let's say something that looks like: (define_insn "scale_28_4" [(set (match_operand:SI 0 "register_operand" "=r") (ior:SI (ashift:SI (match_operand:SI 1 "register_operand" "r") (const_int 28 )) (lshiftrt:SI (match_operand:SI 2 "register_operand" "r") (const_int 4)) ))] "" "SCALE_28_4 tout= %0 in1= %1 tin2= %2" [(set_attr "type" "logic") (set_attr "length" "1")]) Instruction canonicalization doesn't work, since as explained in http://gcc.gnu.org/onlinedocs/gccint/Insn-Canonicalizations.html it only works if the second operand is a constant. Is it possible to change this to make register operands valid for canonicalization as well? Does the same problem affect 'mem' instructions with offset, and does it makes gcc canonicalizes only the ones with a constant offset? Any help is greatly appreciated! Sami
About implementing new intrinsic
Hi,
I try to introduce a new intrinsic in gcc's back-end, for the alpha
machines. In doing that, I referenced to the implementaions of altivec
intrinsics for the PowerPC. In the mean time I noticed that the
gcc-4.0 and gcc-4.1 implements these in different way which confused
me. The difference is that in 4.0 for each intrinsic is defined a in
inline template function and/or macro. gcc-4.1 and later miss these
definition.
So finally what I did is:
1. Created a file myintrinsics.h where I have the folowing definition:
#define myintrinsic __builtin_alpha_myintrinsic
2. Created myintrinsics.md file where I I have my intrinsic's definition:
(define_insn "myintrinsic"
[(unspec_volatile [(const_int 0)] 101)]
""
"xor $31, $0, $31")
;;This intrinsic does not have any parameters ("void intrinsic()")
3. In file alpha.c I added the following
3.1. In enum alpha_builtin
enum alpha_builtin
{
...
ALPHA_BUILTIN_MYINTRINSIC,
...
}
3.2. In array code_for_builtin I added the following members:
static unsigned int const code_for_builtin[ALPHA_BUILTIN_max] = {
...
CODE_FOR_builtin_myintrinsic,
...
}
3.3. In array zero_arg_builtins I added the following members
static struct alpha_builtin_def const zero_arg_builtins[] = {
...
{ "__builtin_alpha_myintrinsic", ALPHA_BUILTIN_MYINTRINSIC, 0, true },
...
}
I supposed that this is enough but I when I tried this in a simple
test case like the one bellow:
#include
#include "myintrinsics.h"
int main(void)
{
myintrinsic();
printf("Hello world!\n");
}
I got an error that __builtin_alspa_myintrinsic is not defined in this
scope. I think that my implementaion does not work. I don't know where
the problem is, but I am sure that I miss something. I hope for your
comments that would be very helpful.
Thanks,
Ferad Zyulkyarov
--
Ferad Zyulkyarov
Barcelona Supercomputing Center
Re: Insn canonicalization not only with constant
On Wed, Feb 14, 2007 at 05:31:36PM +, Sami Khawam wrote: > (define_insn "scale_28_4" > [(set (match_operand:SI 0 "register_operand" "=r") > (ior:SI > (ashift:SI (match_operand:SI 1 "register_operand" "r") > (const_int 28 )) > (lshiftrt:SI (match_operand:SI 2 "register_operand" "r") > (const_int 4)) > ))] > "" > "SCALE_28_4 tout= %0 in1= %1 tin2= %2" > [(set_attr "type" "logic") >(set_attr "length" "1")]) > > Instruction canonicalization doesn't work, since as explained in > http://gcc.gnu.org/onlinedocs/gccint/Insn-Canonicalizations.html > it only works if the second operand is a constant. It is not clear what isn't being canonicalized. Please provide an example of an insn which isn't canonical and what it should look like canonicalized. -- Rask Ingemann Lambertsen
Re: Insn canonicalization not only with constant
Hi Rask, Basically the CPU has the 'SCALE_28_4' instruction which does the following: output = (operand1 >> 28) | (operand2 << 4) From my understanding the OR operation (ior), doesn't get canonicalized since it's second operand (in this case (lshiftrt:SI (match_operand:SI 2 "register_operand" "r") (const_int 4)) ) is not a constant. Sami
Re: Insn canonicalization not only with constant
> > Hi Rask, > > Basically the CPU has the 'SCALE_28_4' instruction which does the following: > output = (operand1 >> 28) | (operand2 << 4) Isn't that a rotate? if so you can use either rotate or rotatert instead. Thanks, Andrew Pinski
Re: mudflap vs bounds-checking
Christophe LYON <[EMAIL PROTECTED]> writes: > What is the difference between the [bounds-checking and mudflap] > systems? Mudflap is a tree-level rewriting pass amidst the optimizers that limits its attention to pointer dereference and addressable object lifetime events. It's upstream, having been donated to the FSF. Last time I checked (quite some time back), the bounds-checking code instrumented many more low-level pointer operations with first-class function calls, and ran considerably slower as a consequence. It's not (C) FSF. Their runtimes are different and probably have different performance and portability/flexibility/diagnostic capabilities. The development intensity on both projects appears to have come down since around the same point in time. It would be nice not to duplicate so much, but that's how it goes sometimes. - FChE
No notice before, GCC 4.1.2 is RELEASED!
ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.1.2/ Good bye people ;)
gcc-4.2-20070214 is now available
Snapshot gcc-4.2-20070214 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070214/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 121967 You'll find: gcc-4.2-20070214.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20070214.tar.bz2 C front end and core compiler gcc-ada-4.2-20070214.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20070214.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20070214.tar.bz2 C++ front end and runtime gcc-java-4.2-20070214.tar.bz2 Java front end and runtime gcc-objc-4.2-20070214.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20070214.tar.bz2The GCC testsuite Diffs from 4.2-20070207 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
SSSE3 -mssse3 or SSE3 -msse3?
In http://gcc.gnu.org/gcc-4.3/changes.html appears "Support for SSSE3 built-in functions and code generation are available via |-mssse3|." Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)? Is it -mssse3 or -msse3? Note: -msse3 appears in the GCC-3.3.6's info! Is this option -msse3 new in GCC-4.3?
Re: SSSE3 -mssse3 or SSE3 -msse3?
> > In http://gcc.gnu.org/gcc-4.3/changes.html appears > > "Support for SSSE3 built-in functions and code generation are available > via |-mssse3|." > > Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)? > Is it -mssse3 or -msse3? -mssse3 is S-SSE3 which was added for code dual 2. Yes the option is weird but that is what Intel wantted it to be called. I don't want to start another fight with their stupid marketing guys again like what happened with pentium4. -- Pinski
Re: Performance regression on the 4.3 branch?
Then it's filed as PR 30801. FX
Re: SSSE3 -mssse3 or SSE3 -msse3?
Andrew Pinski wrote: In http://gcc.gnu.org/gcc-4.3/changes.html appears "Support for SSSE3 built-in functions and code generation are available via |-mssse3|." Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)? Is it -mssse3 or -msse3? -mssse3 is S-SSE3 which was added for code dual 2. Yes the option is weird but that is what Intel wantted it to be called. I don't want to start another fight with their stupid marketing guys again like what happened with pentium4. Is the hyphen in "S-SSE3" the correct spelling, then? If so, the text of the announcement should probably be edited - Brooks
Re: No notice before, GCC 4.1.2 is RELEASED!
On Wed, Feb 14, 2007 at 11:41:48PM +0100, J.C. noticed that there is a tarball with an interesting name on gcc.gnu.org. The actual announcement is always delayed by 24 hours or so to allow time for all of the mirrors around the world to pick it up. This should not be a surprise, given that there were two release candidates already.
Re: SSSE3 -mssse3 or SSE3 -msse3?
> > Andrew Pinski wrote: > >> In http://gcc.gnu.org/gcc-4.3/changes.html appears > >> > >> "Support for SSSE3 built-in functions and code generation are available > >> via |-mssse3|." > >> > >> Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)? > >> Is it -mssse3 or -msse3? > > > > -mssse3 is S-SSE3 which was added for code dual 2. > > Yes the option is weird but that is what Intel wantted it to be called. > > I don't want to start another fight with their stupid marketing guys > > again like what happened with pentium4. > > Is the hyphen in "S-SSE3" the correct spelling, then? If so, the text > of the announcement should probably be edited No, I just added it so you could see there was an extra S there. Again this is what Intel gets for naming things too close to one another. -- Pinski
Re: GCC 4.1.2 RC3 Cancelled
Kaveh R. GHAZI wrote:
> 2007-02-13 Kaveh R. Ghazi <[EMAIL PROTECTED]>
>
> * g++.dg/tree-ssa/nothrow-1.C: Skip test if -fpic/-fPIC is used.
>
> diff -rup orig/egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C
> egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C
> --- orig/egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C
> 2006-01-23 00:09:00.0 -0500
> +++ egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C
> 2007-02-13 21:58:10.160212524 -0500
> @@ -1,5 +1,6 @@
> /* { dg-do compile } */
> /* { dg-options "-O1 -fdump-tree-cfg" } */
> +/* { dg-skip-if "" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
> double a;
> void t()
> {
I think this makes sense. At worst, it's overly conservative, and the
test would pass on some targets using those flags, but that's not a big
deal.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
4.1 branch open
The 4.1 branch is now open for changes under the usual regression-only
rules for release branches.
Here are the changes that I commited during the release process.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
2007-02-14 Mark Mitchell <[EMAIL PROTECTED]>
* DEV-PHASE: Set to prerelease.
* BASE-VER: Increment.
Index: DEV-PHASE
===
--- DEV-PHASE (revision 121944)
+++ DEV-PHASE (working copy)
@@ -0,0 +1 @@
+prerelease
Index: BASE-VER
===
--- BASE-VER(revision 121944)
+++ BASE-VER(working copy)
@@ -1 +1 @@
-4.1.2
+4.1.3
Index: htdocs/gcc-4.1/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.1/changes.html,v
retrieving revision 1.22
diff -c -5 -p -r1.22 changes.html
*** htdocs/gcc-4.1/changes.html 21 Mar 2006 11:19:31 - 1.22
--- htdocs/gcc-4.1/changes.html 14 Feb 2007 04:32:10 -
***
*** 9,18
--- 9,21
-->
GCC 4.1 Release SeriesChanges, New Features, and Fixes
+ The latest release in the 4.1 release series is
+ GCC 4.1.2.
+
Caveats
General Optimizer Improvements
***
*** 663,669
--- 666,708
various buffer overflow (and format string) vulnerabilities. Compared
to the mudflap bounds checking feature, the safe builtins have far
smaller overhead. This means that programs built using safe builtins
should not experience any measurable slowdown.
+
+ GCC 4.1.2
+
+ This is the http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.1.2";>list
+ of problem reports (PRs) from GCC's bug tracking system that are
+ known to be fixed in the 4.1.2 release. This list might not be
+ complete (that is, it is possible that some PRs that have been fixed
+ are not listed here).
+
+
+ When generating code for a shared library, GCC now recognizes that
+ global functions may be replaced when the program runs. Therefore,
+ it is now more conservative in deducing information from the bodies
+ of functions. For example, in this example:
+
+
+ void f() {}
+ void g() {
+ try { f(); }
+ catch (...) {
+cout << "Exception";
+ }
+ }
+
+
+ G++ would previously have optimized away the catch clause, since it
+ would have concluded that f cannot throw exceptions.
+ Because users may replace f with another function in
+ the main body of the program, this optimization is unsafe, and is no
+ longer performed. If you wish G++ to continue to optimize as
+ before, you must add a throw() clause to the
+ declaration of f to make clear that it does not throw
+ exceptions.
+
+
Index: htdocs/gcc-4.1/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.1/index.html,v
retrieving revision 1.5
diff -c -5 -p -r1.5 index.html
*** htdocs/gcc-4.1/index.html 27 May 2006 20:55:34 - 1.5
--- htdocs/gcc-4.1/index.html 14 Feb 2007 04:32:10 -
***
*** 6,26
GCC 4.1 Release Series
! May 24, 2006
The http://www.gnu.org";>GNU project and the GCC
! developers are pleased to announce the release of GCC 4.1.1.
This release is a bug-fix release, containing fixes for regressions
! in GCC 4.1.0 relative to previous releases of GCC.
Release History
GCC 4.1.1
May 24, 2006
(changes)
--- 6,32
GCC 4.1 Release Series
! February 13, 2007
The http://www.gnu.org";>GNU project and the GCC
! developers are pleased to announce the release of GCC 4.1.2.
This release is a bug-fix release, containing fixes for regressions
! in GCC 4.1.1 relative to previous releases of GCC.
Release History
+ GCC 4.1.2
+ February 13, 2007
+ (changes)
+
+
+
GCC 4.1.1
May 24, 2006
(changes)
Index: htdocs/gcc-4.1/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.1/changes.html,v
retrieving revision 1.23
diff -c -5 -p -r1.23 changes.html
*** htdocs/gcc-4.1/changes.html 14 Feb 2007 04:32:44 - 1.23
--- htdocs/gcc-4.1/changes.html 14 Feb 2007 04:36:22 -
*** are not listed here).
*** 681,701
When generating code for a shared library, GCC now recognizes that
global functions may be replaced when the program runs. Therefore,
it is now more conservative in deducing information from the bodies
of functions. For example, in this example:
void f() {}
void g() {
try { f(); }
catch (...) {
!cout << "Exception";
}
}
G++ would previously have optimized away the catch clause, since it
would have concluded that f cannot throw exceptions
Re: minimal version of bison for Gcc?
> It seems according to http://gcc.gnu.org/install/prerequisites.html that the > minimal version of bison required in GCC (for those hacking the few .y > files) is 1.28 (released in july 1999). > > Is there a reason why a 2.x version of bison would not be acceptable? FWIW, > I am not considering using bison in a frontend, but just to parse some kind > of "scripts" or internal data inside a (usually unused) static analysis > pass... The minimum required version is 1.28. The general wisdom appears to be to set the minimum required version as low as possible (such that things work!) so that as few developers are inconvenienced as possible. This means less package upgrading or building from source to get the minimum specified tools onto your system. Of course, there are sometimes good reasons for lifting the minimum required version. Earlier this year I proposed moving to a 2003 release of flex and was convinced by others on this list that the benefits did not sufficiently justify the headaches. The minimum Bison version is 1.28. What's stopping you from using a version of your choice? Cheers, Ben
