logical error with 16bit arithmatic operations
Hello,
I am porting gcc to a 32bit RISC chip, and I met a logical
error with 16bit arithmetic operations in generating assemble code.
the error is between two 16bit data movement(unsigned short).
While like A = B, A, and B are all unsigned short type. B is a
result of a series of computation, which may have value in high 16bit.
Because A , B are both HImode, so the move insn doesn't take zero
extend operation, so A will have value in high 16bit which will caused
a wrong result in computation. Like the following CRC calculation.
There is a comment added with "//" in logical error position.
Here is the .sched2 script:
;; ==
;; -- basic block 0 from 10 to 92 -- after reload
;; ==
;;0--> 10 R3=R4 :nothing
;;1--> 11 R7=R5 :nothing
;;2--> 89 R0=`x25_crc_table' :nothing
;;3--> 92 pc=L58 :nothing
;; Ready list (final):
;; total time = 3
;; new head = 10
;; new tail = 92
;; ==
;; -- basic block 1 from 25 to 53 -- after reload
;; ==
;;0--> 25 R6=[post_modify] :rice_load,nothing
;;1--> 57 R7=R7-0x1 :nothing
;;2--> 26 R4=R6 0>>0x4 :nothing
;;3--> 27 R4=zxn(R4) :nothing
;;4--> 28 R4=R5^R4 :nothing
;;5--> 32 R4=zxn(R4) :nothing
;;6--> 35 R4=R4+R4 :nothing
;;7--> 37 R5=[R4+R0] :rice_load,nothing
;;8--> 42 R6=zxn(R6) :nothing
;;9--> 38 R5=R5^R13 :nothing
;; 10--> 40 R4=R5 0>>0xc :nothing
;; 11--> 43 R4=R4^R6 :nothing
;; 12--> 47 R4=zxn(R4) :nothing
;; 13--> 48 R4=R4&0xf :nothing
;; 14--> 50 R4=R4+R4 :nothing
;; 15--> 52 R4=[R4+R0] :rice_load,nothing
;; 16--> 46 R5=R5<<0x4 :nothing
;; 17--> 53 R6=R5^R4 :nothing
;; Ready list (final):
;; total time = 17
;; new head = 25
;; new tail = 53
;; ==
;; -- basic block 2 from 23 to 62 -- after reload
;; ==
;;0--> 87 R2=zxn(R6) :nothing
;;1--> 23 R5=R6 0>>0xc :nothing
//R5 and R6 are both unsigned short type. But R6 will
have it's value in high 16bit because of series of logical operations
(AND, OR, XOR and so on). Doing it like this way will cause R5 also
being valued in high 16bit. This will cause a wrong value. The correct
one is : R5 = R2 0 >> 0xC. because R2 did zero extend in former insn
from R6. But How I let gcc know it.
;;2--> 31 R13=R2<<0x4:nothing
;;3--> 62 pc={(R7>0x0)?L20:pc} :nothing
;; Ready list (final):
;; total time = 3
;; new head = 87
;; new tail = 62
;; ==
;; -- basic block 3 from 100 to 100 -- after reload
;; ==
;;0--> 100 return :nothing
;; Ready list (final):
;; total time = 0
;; new head = 100
;; new tail = 100
PS, I compile the c code with -Os command. Here is C code:
static const unsigned short x25_crc_table[16] =
{
0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF
};
/*
** FUNCTION:crc_X25
**
** DESCRIPTION: This function generates a crc on from the data given
** using the X 25 CRC lookup table.
**
**
** PARAMETERS: Data to check:
** Array of data: UTINY *
** Length of data in array:LONG
** CRC initial value: USHORT
**
** RETURNS: USHORT, The CRC calculated.
**
*/
unsigned short crc_X25(unsigned char *data, long length, unsigned short crc_reg)
{
unsigned short temp;
/* Use 4 bits out of the data/polynomial at a time */
while (length > 0)
{ /* step through the data */
temp = crc_reg;
temp >>= 12u;
temp ^= (*data) >> 4u; /* xor data (MS 4 bits) with the MS 4 bits */
temp &= 0xf;/* of the CRC reg to be used as index in array */
temp = crc_reg = (unsigned short )((crc_reg << 4u) ^ x25_crc_table[temp]);
/* Now do sec
Re: New no-undefined-overflow branch
Hi Ho! On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote: > > So while trapping variants can certainly be introduced it looks like > > this task may be more difficult. > > I don't think you need to introduce trapping tree codes. You can > introduce them directly in the front-end as > >s = x +nv y >(((s ^ x) & (s ^ y)) < 0) ? trap () : s Could you please kindly explain a bit about it? Suppose s, x, and y are 8-bit signed integer. If x and y are -128, s = (-128) + (-128), which will overflow. Now if suppose s is 0, ((0 ^ -128) & (0 ^ -128)) == -128, which is less than zero and will trap. This is correct. But, if s is -128, ((-128 ^ -128) & (-128 ^ -128)) is zero and will not trap. This is incorrect, isn't this? In short, why should s be included in the calculation? Is it assumed that s is always zero? Thank you very much for the explanation. >d = x -nv y >(((d ^ x) & (x ^ y)) < 0) ? trap () : d > >(b == INT_MIN ? trap () : -nv b) > >(int)((long long) a * (long long) b) == a *nv b ? trap () : a *nv b > > Making sure they are compiled efficiently is another story, but > especially for the sake of LTO I think this is the way to go. > > Paolo -- Best regards, Eus (FSF member #4445) In this digital era, where computing technology is pervasive, your freedom depends on the software controlling those computing devices. Join free software movement today! It is free as in freedom, not as in free beer! Join: http://www.fsf.org/jf?referrer=4445
GCC EH unwinding bug and libjava calling std::terminate ()
Hi, current mainline is buggy in EH unwinding effectivly ignoring MUST_NOT_THROW regions when reached via RESX from local handlers. See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01285.html for details. Unfortunately this patch causes bootstrap failure when building libjava, because std::terminate() is now called. The call comes from run_proxy in natVMProxy.cc where we have cleanup code calling destructor of: _Jv_InterpFrame frame_desc (self->self, thread, proxyClass, NULL, frame_proxy); Now the desctuctor is pretty simple but because of: 'if a destructor called during stack unwinding exits with an exception, std::terminate is called' and because we use -fnon-call-excpetion and destructor is accessing memory, we keep MUST_NOT_THROW terminate () call accessible because after inlining the destructor, cleanup might unwind up to that MUST_NOT_THROW. Questio is how to fix this situation? Shall we link with C++ runtime, or use -fno-non-call-exceptions to build this file or somehow restruture code to avoid this case? Honza
Re: New no-undefined-overflow branch
Eus wrote: > Hi Ho! > > On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote: >>> So while trapping variants can certainly be introduced it looks like >>> this task may be more difficult. >> I don't think you need to introduce trapping tree codes. You can >> introduce them directly in the front-end as >> >>s = x +nv y >>(((s ^ x) & (s ^ y)) < 0) ? trap () : s > > Could you please kindly explain a bit about it? > > Suppose s, x, and y are 8-bit signed integer. > If x and y are -128, s = (-128) + (-128), which will overflow. > Now if suppose s is 0, ((0 ^ -128) & (0 ^ -128)) == -128, which is less > than zero and will trap. This is correct. > But, if s is -128, ((-128 ^ -128) & (-128 ^ -128)) is zero and will not > trap. This is incorrect, isn't this? Don't look at it as an arithmetic test, "< 0" is just a shortcut for "the most significant bit of the first operand is 1". So the formula's outcome only depends on the ANDs and XORs of the sign bits; it means, "trap if the result's sign is different from both addends' signs" or equivalently "check that the result's sign matches at least one addend's sign". You can also say "((s ^ x) & ~(x ^ y)) < 0", or equivalently "((s ^ y) & ~(x ^ y)) < 0". These mean "trap if the two addends have the same sign and the sum has a different sign". It is easy to prove that they are equivalent: sxy s^xs^y ~(x^y) equal? 000 0 0 1 yes (0) 001 0 1 0 yes (0) 010 1 0 0 yes (0) 011 1 1 1 yes (1) 100 1 1 1 yes (1) 101 1 0 0 yes (0) 110 0 1 0 yes (0) 111 0 0 1 yes (0) Paolo
Re: GCC EH unwinding bug and libjava calling std::terminate ()
Jan Hubicka wrote:
> current mainline is buggy in EH unwinding effectivly ignoring
> MUST_NOT_THROW regions when reached via RESX from local handlers.
> See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01285.html for details.
>
> Unfortunately this patch causes bootstrap failure when building libjava,
> because std::terminate() is now called. The call comes from
> run_proxy in natVMProxy.cc where we have cleanup code calling
> destructor of:
>
> _Jv_InterpFrame frame_desc (self->self, thread, proxyClass,
> NULL, frame_proxy);
>
> Now the desctuctor is pretty simple but because of:
> 'if a destructor called during stack unwinding exits with an exception,
> std::terminate is called'
>
> and because we use -fnon-call-excpetion and destructor is accessing
> memory, we keep MUST_NOT_THROW terminate () call accessible
> because after inlining the destructor, cleanup might unwind up
> to that MUST_NOT_THROW.
>
> Questio is how to fix this situation? Shall we link with C++ runtime,
Please don't.
> or use -fno-non-call-exceptions
No, because it might segfault, and we need to catch it.
> to build this file or somehow restruture
> code to avoid this case?
/* Gimplify a MUST_NOT_THROW_EXPR. */
static enum gimplify_status
gimplify_must_not_throw_expr (tree *expr_p, gimple_seq *pre_p)
{
tree stmt = *expr_p;
tree temp = voidify_wrapper_expr (stmt, NULL);
tree body = TREE_OPERAND (stmt, 0);
tree termination;
if (pragma_java_exceptions)
termination = terminate_node;
else
termination = abort_node;
stmt = build_gimple_eh_filter_tree (body, NULL_TREE,
build_call_n (termination, 0));
Andrew.
Re: logical error with 16bit arithmatic operations
daniel tian writes: > I am porting gcc to a 32bit RISC chip, and I met a logical > error with 16bit arithmetic operations in generating assemble code. > the error is between two 16bit data movement(unsigned short). > While like A = B, A, and B are all unsigned short type. B is a > result of a series of computation, which may have value in high 16bit. > Because A , B are both HImode, so the move insn doesn't take zero > extend operation, so A will have value in high 16bit which will caused > a wrong result in computation. The relevant types in your code are "unsigned short". I assume that on your processor that is a 16 bit type. An variable of an unsigned 16 bit type can hold values from 0 to 0x, inclusive. There is nothing wrong with having the high bit be set in such a variable. It just means that the value is between 0x8000 and 0x. > ;; 1--> 23 R5=R6 0>>0xc :nothing > //R5 and R6 are both unsigned short type. But R6 will > have it's value in high 16bit because of series of logical operations > (AND, OR, XOR and so on). Doing it like this way will cause R5 also > being valued in high 16bit. This will cause a wrong value. The correct > one is : R5 = R2 0 >> 0xC. because R2 did zero extend in former insn >>From R6. But How I let gcc know it. No. 0>> means a logical right shift, not an arithmetic right shift (LSHIFTRT rathre than ASHIFTRT). When doing a logical right shift, the sign bit is moved right also; it is not sticky. This instruction is fine. Perhaps there is a problem in your implementation of LSHIFTRT. Ian
Getting variable attribute from rtx
I need to add support for some custom attributes that I need to know during
operand matching. I have no problem adding the attributes, but I don't know
what to do so that I can access the information later. My function that is
called to handle the attribute looks like this:
static tree
attr_myattr_handler(tree *node, tree name, tree args, int flags,
bool *no_add_attrs) {
/* What should I do here */
}
In the source code:
int __attribute__((__myattr__)) a;
When 'a' is being matched as an operand to, say, 'addsi3', I would like to
be able to check the rtx to see if that attribute was set with a function
like this:
int
myattr_operand (op, mode)
rtx op;
enum machine_mode mode;
{
/* What do I need here */
}
Thanks for the help. Sorry, if this is simple, I'm a bit of a noob in this
area.
--
View this message in context:
http://www.nabble.com/Getting-variable-attribute-from-rtx-tp22745207p22745207.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: GCC EH unwinding bug and libjava calling std::terminate ()
> Jan Hubicka wrote:
>
> > current mainline is buggy in EH unwinding effectivly ignoring
> > MUST_NOT_THROW regions when reached via RESX from local handlers.
> > See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01285.html for details.
> >
> > Unfortunately this patch causes bootstrap failure when building libjava,
> > because std::terminate() is now called. The call comes from
> > run_proxy in natVMProxy.cc where we have cleanup code calling
> > destructor of:
> >
> > _Jv_InterpFrame frame_desc (self->self, thread, proxyClass,
> > NULL, frame_proxy);
> >
> > Now the desctuctor is pretty simple but because of:
> > 'if a destructor called during stack unwinding exits with an exception,
> > std::terminate is called'
> >
> > and because we use -fnon-call-excpetion and destructor is accessing
> > memory, we keep MUST_NOT_THROW terminate () call accessible
> > because after inlining the destructor, cleanup might unwind up
> > to that MUST_NOT_THROW.
> >
> > Questio is how to fix this situation? Shall we link with C++ runtime,
>
> Please don't.
>
> > or use -fno-non-call-exceptions
>
> No, because it might segfault, and we need to catch it.
>
> > to build this file or somehow restruture
> > code to avoid this case?
>
> /* Gimplify a MUST_NOT_THROW_EXPR. */
>
> static enum gimplify_status
> gimplify_must_not_throw_expr (tree *expr_p, gimple_seq *pre_p)
> {
> tree stmt = *expr_p;
> tree temp = voidify_wrapper_expr (stmt, NULL);
> tree body = TREE_OPERAND (stmt, 0);
> tree termination;
>
> if (pragma_java_exceptions)
> termination = terminate_node;
> else
> termination = abort_node;
OK, pragma_java_exceptions variable is not there, does something like
this work for you?
I would like to commit this to mainline so the MUST_NOT_THROW fix can go
as well. I am commiting it to pretty-ipa in meantime.
Honza
Index: cp/except.c
===
*** cp/except.c (revision 145101)
--- cp/except.c (working copy)
*** choose_personality_routine (enum languag
*** 353,358
--- 353,359
case lang_java:
state = chose_java;
+ terminate_node = built_in_decls [BUILT_IN_ABORT];
eh_personality_libfunc = init_one_libfunc (USING_SJLJ_EXCEPTIONS
? "__gcj_personality_sj0"
: "__gcj_personality_v0");
Re: GCC EH unwinding bug and libjava calling std::terminate ()
Jan Hubicka wrote: > OK, pragma_java_exceptions variable is not there It's in mainline now. > does something like this work for you? Yes. Andrew.
Re: GCC EH unwinding bug and libjava calling std::terminate ()
> Jan Hubicka wrote: > > > OK, pragma_java_exceptions variable is not there > > It's in mainline now. > > > does something like this work for you? > > Yes. OK, I will do full testing cycle (x86_64-linux) and commit it. Thanks! Honza > > Andrew.
Re: Minimum GMP/MPFR version bumps for GCC-4.5
From: "Joe Buck" Debian stable, and Ubuntu Hardy (most recent LTS release) have 2.3.1. Same with OpenSUSE 11.0. So I think 2.3.1 is typical of current stable releases; Fedora tends to be bleeding edge and not typical. I still have to deal with older distros (e.g. RHEL 4), but it's already necessary to use newer gmp and gas versions, as well as a newer mpfr version, in that case. Thanks to all who responded. Based on the various feedback, it seem like for most (all?) people their box arrives with a recent enough GMP/MPFR or they already have to get a sufficiently recent copy from source and build it in-tree. So upgrading GCC's requirements to gmp-4.2 and mpfr-2.3.1 should be minimally disruptive. I'll prepare a patch for 4.5. Regards, --Kaveh
Re: Getting variable attribute from rtx
> I need to add support for some custom attributes that I need to know during
> operand matching. I have no problem adding the attributes, but I don't
> know what to do so that I can access the information later. My function
> that is called to handle the attribute looks like this:
>
> static tree
> attr_myattr_handler(tree *node, tree name, tree args, int flags,
> bool *no_add_attrs) {
> /* What should I do here */
> }
See the SYMBOL_REF_FLAGS stuff in rtl.h and various examples in the back-ends.
--
Eric Botcazou
Re: GCC 4.4.0 Status Report (2009-03-13)
Ian Lance Taylor wrote: By the way, from reading this messages I think that people have a slightly rosier recollection of the egcs split than I do. I think the egcs split was the right thing to do, but it was also a power play on the part of Cygnus because we could not continue operating under the existing gcc maintainership regime, and we could not get the FSF to change it. We signed up most of the non-Cygnus contributors because we needed political cover; we were able to sign them up because they were facing the same problems that we were. Certainly, and I, as one of the non-Cygnus maintainers (of g77) definitely understood it that way. That was why I was so nervous about it - if the split went off the deep end, it could have hurt gcc/g++/g77 development for years ... -- Toon Moene - e-mail: t...@moene.org (*NEW*) - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html
Re: Getting variable attribute from rtx
Eric Botcazou writes:
>> I need to add support for some custom attributes that I need to know during
>> operand matching. I have no problem adding the attributes, but I don't
>> know what to do so that I can access the information later. My function
>> that is called to handle the attribute looks like this:
>>
>> static tree
>> attr_myattr_handler(tree *node, tree name, tree args, int flags,
>> bool *no_add_attrs) {
>> /* What should I do here */
>> }
>
> See the SYMBOL_REF_FLAGS stuff in rtl.h and various examples in the back-ends.
Or, better, look for uses of lookup_attribute.
Ian
Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )
Bernd Roesch schrieb: without changed headers old ompiler and libs do not work, because for C there is no sqrtf and other C99 funcs and many C++ programs get also many errors. Ok, you are trying to add C99 functions to your libc. Apparently you made a mistake if you get linker errors. i see old libstdc++ contain sqrtf but get many other linker errors. What is an "old libstdc++"? AFAICT there was/is no sqrtf function in libstdc++. In the sqrt case there are inline wrapper functions with either a float or a double arg. These inlines use an appropriate sqrt builtin. Since these builtins do not exist for your target the compiler generates a call to the real function without the __builtin prefix. there is also a sqrtf not undef in cmath as many other functions are. When i define sqrtf in math.h then the sqrtf func in libstdc++ is maybe not add and this strange linker error come.but wy it work not correct when i add sqrtf to libc i dont know.only solution below work. libstdc++ _requires_ real functions to be present in your libc. If you get linker errors then the linker cannot locate functions. There really is no need to play #define games on __builtin names to get it work. Gunther
Re: Minimum GMP/MPFR version bumps for GCC-4.5
Steven Bosscher wrote: On Thu, Mar 26, 2009 at 10:39 PM, Kaveh R. Ghazi wrote: If there are no objections, I'll create a patch. P... for those of us who just install the latest-and-greatest fedora/suse/ubuntu/... once and don't change installations for two or three years (stable machine, etc.) it becomes increasingly harder to install all required libraries to build GCC... But why do you want to work this way (assuming that people who need a stable OS don't want to upgrade their compiler on a whim). We're in the process of developing the next GCC. Therefore, my modus operandi is to "apt-get update && apt-get dist-upgrade" my Debian testing OS every Sunday morning. -- Toon Moene - e-mail: t...@moene.org (*NEW*) - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html
Re: Minimum GMP/MPFR version bumps for GCC-4.5
On Fri, Mar 27, 2009 at 8:40 PM, Toon Moene wrote: > Steven Bosscher wrote: > >> On Thu, Mar 26, 2009 at 10:39 PM, Kaveh R. Ghazi >> wrote: >>> >>> If there are no objections, I'll create a patch. >> >> P... for those of us who just install the latest-and-greatest >> fedora/suse/ubuntu/... once and don't change installations for two or >> three years (stable machine, etc.) it becomes increasingly harder to >> install all required libraries to build GCC... > > But why do you want to work this way (assuming that people who need a stable > OS don't want to upgrade their compiler on a whim). The problem doesn't happen on machines I own or have root access to. It's only a problem when you try to do gcc development on machines hosted by 3rd parties (SF compile farm, HP cluster, machines at places where I work and/or where I try to convince people to use gfortran instead of e.g. sunf90, etc.). Ciao! Steven
Re: Minimum GMP/MPFR version bumps for GCC-4.5
Steven Bosscher wrote: The problem doesn't happen on machines I own or have root access to. It's only a problem when you try to do gcc development on machines hosted by 3rd parties (SF compile farm, HP cluster, machines at places where I work and/or where I try to convince people to use gfortran instead of e.g. sunf90, etc.). I fully agree. Therefore, I practice, and advice anyone to apply RRTC (reverse reverse telecommuting): "When arriving at your work place, log in to your home system using ssh -X and continue from there." Works for me. -- Toon Moene - e-mail: t...@moene.org (*NEW*) - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html
GCC 4.4 Branch Created
[Joseph, Danny, see below for request.] At long last, I have created the GCC 4.4 release branch. We are now in Stage 1 on the mainline. Please go ahead and begin checking in approved patches. Please try to coordinate so that we do not have multiple overlapping radical changes. Please announce your intent to commit a major in advance of doing so, and avoid committing two major changes within a day of each other. I apologize to all for how long this took. I understand full well -- and share -- the frustration expressed with the FSF and the SC. If there's a positive from this, it is that it has stimulated useful discussion about the roles of the SC and the FSF and the broader development community. Speaking only for myself, I believe that the SC needs to take a more assertive role in the future, and I will encourage that assertiveness. However, part of the delay has been due to the FSF considering the comments made by various people about the new runtime exception. The FSF listed to those objections and carefully considered them. That does take time. The FSF hopes to have a new version of this shortly. Several steps from the branch checklist remain. Joseph, Danny, would you be able to take care of these? As I will be out much of next week, and have some interfering personal obligations at present, I would appreciate your help. Joseph, if I have failed to do something correctly, please also feel free to correct that. The tasks that remain from branching.html are: 7. Generating a snapshot manually with gcc_release -p. 8. Regenerating .pot files. 12. Updating the email parsing script. AFAICT, this hasn't been done in a while, so I wasn't sure if it was considered obsolete. 13. Asking Danny Berlin to adjust PRs. I've attached the mechanical patch set made to the web site. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 Index: htdocs/buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/buildstat.html,v retrieving revision 1.17 diff -c -5 -p -r1.17 buildstat.html *** htdocs/buildstat.html 2 Nov 2008 19:25:54 - 1.17 --- htdocs/buildstat.html 27 Mar 2009 20:54:58 - *** *** 8,17 --- 8,18 Build status for GCC These pages summarize build reports for GCC. + GCC 4.4.x GCC 4.3.x GCC 4.2.x GCC 4.1.x GCC 4.0.x GCC 3.4.x Index: htdocs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.692 diff -c -5 -p -r1.692 index.html *** htdocs/index.html 14 Mar 2009 12:15:03 - 1.692 --- htdocs/index.html 27 Mar 2009 20:54:58 - *** Ulrich Drepper of Red Hat, Inc. *** 95,145 Status Current release series: ! GCC 4.3.3 Status: http://gcc.gnu.org/ml/gcc/2009-01/msg00358.html";>2009-01-24 (regression fixes and docs only). http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.2.5&target_milestone=4.3.4&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>Serious regressions. http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.2.5&target_milestone=4.3.4&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>All regressions. Previous release series: ! GCC 4.2.4 Status: ! http://gcc.gnu.org/ml/gcc/2008-05/msg00216.html";>2008-05-19 (regression fixes and docs only). http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.2.5&known_
Re: GCC 4.4 Branch Created
On Fri, 27 Mar 2009, Mark Mitchell wrote:
> 12. Updating the email parsing script. AFAICT, this hasn't been done in
> a while, so I wasn't sure if it was considered obsolete.
I have done this. I'll deal with the snapshot and .pot files later.
I'll close 4.2 branch at some point after the PR summaries have been
updated to mention 4.5 (to avoid conflicts between two sets of bulk
Bugzilla changes), though probably not until next week.
If we want to deprecate gccbug in 4.4 and remove it in 4.5 (and so not
need 4.5.1 or subsequent versions in this script), there is still time to
do so (though not to get it in the first deprecated-features-removal patch
for 4.5 - that has already been approved for 4.5 and I am retesting it
tonight before committing it to trunk).
Index: bug_email.pl
===
RCS file: /cvs/gcc/wwwdocs/bugzilla/contrib/bug_email.pl,v
retrieving revision 1.49
diff -u -r1.49 bug_email.pl
--- bug_email.pl24 Jan 2009 10:28:08 - 1.49
+++ bug_email.pl27 Mar 2009 22:29:41 -
@@ -284,6 +284,9 @@
{
$version = "unknown";
}
+elsif ($release =~ /.*4\.5\.0.*/o) {
+ $version = "4.5.0";
+}
elsif ($release =~ /.*4\.4\.0.*/o) {
$version = "4.4.0";
}
--
Joseph S. Myers
jos...@codesourcery.com
gcc-4.4-20090327 is now available
Snapshot gcc-4.4-20090327 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090327/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 145135 You'll find: gcc-4.4-20090327.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090327.tar.bz2 C front end and core compiler gcc-ada-4.4-20090327.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090327.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090327.tar.bz2 C++ front end and runtime gcc-java-4.4-20090327.tar.bz2 Java front end and runtime gcc-objc-4.4-20090327.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090327.tar.bz2The GCC testsuite Diffs from 4.4-20090320 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: GCC 4.4 Branch Created
On Fri, Mar 27, 2009 at 6:34 PM, Joseph S. Myers wrote: > On Fri, 27 Mar 2009, Mark Mitchell wrote: > >> 12. Updating the email parsing script. AFAICT, this hasn't been done in >> a while, so I wasn't sure if it was considered obsolete. > > I have done this. I'll deal with the snapshot and .pot files later. > I'll close 4.2 branch at some point after the PR summaries have been > updated to mention 4.5 (to avoid conflicts between two sets of bulk > Bugzilla changes), though probably not until next week. > > If we want to deprecate gccbug in 4.4 and remove it in 4.5 (and so not > need 4.5.1 or subsequent versions in this script), there is still time to > do so (though not to get it in the first deprecated-features-removal patch > for 4.5 - that has already been approved for 4.5 and I am retesting it > tonight before committing it to trunk). I think we should. We haven't received a bug through gccbug in quite a while :)
Re: GCC 4.4 Branch Created
Daniel Berlin wrote: >> If we want to deprecate gccbug in 4.4 and remove it in 4.5 (and so not >> need 4.5.1 or subsequent versions in this script), there is still time to >> do so (though not to get it in the first deprecated-features-removal patch >> for 4.5 - that has already been approved for 4.5 and I am retesting it >> tonight before committing it to trunk). > I think we should. > We haven't received a bug through gccbug in quite a while :) Let's kill it, then. Do we really need to deprecate this in 4.4? If nobody's using it, I think we can just remove it. It's not part of GCC proper. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
gcc-4.5-20090327 is now available
Snapshot gcc-4.5-20090327 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090327/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 145140 You'll find: gcc-4.5-20090327.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090327.tar.bz2 C front end and core compiler gcc-ada-4.5-20090327.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090327.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090327.tar.bz2 C++ front end and runtime gcc-java-4.5-20090327.tar.bz2 Java front end and runtime gcc-objc-4.5-20090327.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090327.tar.bz2The GCC testsuite Diffs from 4.4-20090320 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
Merging the alias-improvements branch
I plan to merge the alias-improvements branch next weekend (in 7 days) if all goes well. I will do bootstrap & regtesting on the archs I have available (x86_64, i?86, ppc, ppc64, ia64, s390 and s390x). During the next week I will try to extract all bugfixes from the branch and apply them separately. I will also post a merge diff upfront (I hope it isn't too big), but diffing the branch against the last trunk revision that it was merged is of course possible as well in case you want to review it (it now only contains middle-end changes, so technically I do not need approval, and thanks to Diego most changes already got one review). There is ongoing compile-time and runtime performance measurements on x86_64 with acceptable results (faster compile-time, overall slight improvements in SPEC numbers), I do not plan to add to that - volunteers are welcome for other architectures, but as this is tree level changes I do not expect architecture specific differences. I will announce the time I am doing the last trunk -> alias-improvements branch merge and freeze the trunk for that. Thus, this is a heads-up - if I collide with your planned merge schedule just tell me and we can sort it out. Thanks, Richard.
Re: Merging the alias-improvements branch
On Fri, Mar 27, 2009 at 19:38, Richard Guenther wrote: > I plan to merge the alias-improvements branch next weekend (in 7 days) Looking forward to that! Thanks for doing this. Diego.
