--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #11 from patchapp at dberlin dot org 2007-04-22 07:25 ---
Subject: Bug number PR30957
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01378.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-22 07:03 ---
> Using a copy constructor and returning by value is of limited
> applicability. Having to invoke a copy constructor to "simulate" a
> post rvalue operation is not an option for objects that do not support
> copy, a
--- Comment #3 from hayward at loup dot net 2007-04-22 06:40 ---
Subject: Re: postfix increment semantics implemented incorrectly
Thanks for the quick response. I do not, however, agree with this
interpretation of ISO/IEC FDIS 14882:1998(E) 13.5.7/1.
The spec trivially exemplifies th
--- Comment #7 from rth at gcc dot gnu dot org 2007-04-22 02:31 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rth at gcc dot gnu dot org 2007-04-22 02:30 ---
Subject: Bug 28623
Author: rth
Date: Sun Apr 22 02:30:31 2007
New Revision: 124034
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124034
Log:
PR target/28623
* config/alpha/alpha.c (get_unaligned
--- Comment #5 from rth at gcc dot gnu dot org 2007-04-22 02:29 ---
Subject: Bug 28623
Author: rth
Date: Sun Apr 22 02:29:05 2007
New Revision: 124033
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124033
Log:
PR target/28623
* config/alpha/alpha.c (get_unaligned
--- Comment #16 from dannysmith at users dot sourceforge dot net
2007-04-22 02:01 ---
Created an attachment (id=13403)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13403&action=view)
Patch for testcase in 31636
Could you please test the attached patch to tree-ssa-address.c which
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-22 01:28 ---
I am testing this patch also now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30221
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-04-22 01:28 ---
I am testing this patch now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30016
--- Comment #3 from pcarlini at suse dot de 2007-04-22 01:19 ---
In fact, the problem cannot be reproduced on ia64, with current mainline. I
agree that the warning can be very annoying (the underlying issue was already
there before 4.0 and will be there until we break the ABI), therefore
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-04-22 01:18 ---
Subject: Bug 31480
Author: kkojima
Date: Sun Apr 22 01:18:02 2007
New Revision: 124031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124031
Log:
PR target/31480
* config/sh/sh.md (length): C
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
--- Comment #7 from pcarlini at suse dot de 2007-04-22 01:06 ---
(In reply to comment #6)
> I ran additional tests just to make sure that the shift state was valid across
> calls, even though partial is not returned when a chunk ends in a partial
> encoding sequence. I split several 2,3
--- Comment #5 from kargl at gcc dot gnu dot org 2007-04-22 00:10 ---
(In reply to comment #4)
> (In reply to comment #3)
> > The OP doesn't understand his own program.
> Huh? (or did you close the wrong bug report?)
> Here is a simplified testcase that does not call print:
> program tes
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-21 23:56 ---
(In reply to comment #3)
> The OP doesn't understand his own program.
Huh? (or did you close the wrong bug report?)
Here is a simplified testcase that does not call print:
program test_assign
type my_type
inte
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-21 23:51 ---
The OP doesn't understand his own program.
Closing as invalid.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-21 23:49 ---
This is not a bug in GCC but instead a bug in your post fix increment operator:
C & operator++( int ) { v += 100; return *this; }
Really should be implemented as:
C operator++( int ) { C tmp = *this; v += 100;
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-04-21 23:47
---
Thats an interesting approach. I am curious for the results. I also like the
adjustments to errors you have made.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
g++ parses the code correctly and calls the correct overloaded
increment operators, but in the wrong postfix order. The semantics of
postfix are to take the rvalue before invoking the method. Note this
is not related to multiple reference ordering between sequence points
as the object is only re
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-21 23:33 ---
I am finally getting around to testing the patch (been busy with a release of
our own toolchain last week).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-21 23:15 ---
fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-04-21 23:12 ---
Created an attachment (id=13402)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13402&action=view)
proposed patch
This could work. Let's see if this passes regression.
--
tkoenig at gcc dot gnu dot org cha
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-04-21 23:00
---
Subject: Bug 31495
Author: jvdelisle
Date: Sat Apr 21 23:00:38 2007
New Revision: 124026
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124026
Log:
2007-04-21 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-21 22:47 ---
Subject: Bug 30265
Author: pinskia
Date: Sat Apr 21 22:47:35 2007
New Revision: 124024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124024
Log:
2007-04-21 Andrew Pinski <[EMAIL PROTECTED]>
PR C/
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-21 22:47 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-04-21 22:35
---
Fixed on trunk, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-04-21 22:34
---
Subject: Bug 31495
Author: jvdelisle
Date: Sat Apr 21 22:34:04 2007
New Revision: 124022
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124022
Log:
2007-04-21 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from patchapp at dberlin dot org 2007-04-21 22:25 ---
Subject: Bug number PR31495
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01357.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from amacleod at redhat dot com 2007-04-21 22:23 ---
I think this is actually fallout from the removal of V_MUSTDEFs, which predated
mem-ssa going in. Although it may have been checked into mainline at the same
time as mem-ssa now that I think about it. The work was origi
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-21 22:16 ---
How much memory do you have?
20070323 is over a month old, can you try a new snapshot?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-21 22:12 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from ubizjak at gmail dot com 2007-04-21 19:43 ---
Patch for double<->float conversions at
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01346.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-21 18:54 ---
> and the predicate !ZERO_SSA_OPERANDS (def_stmt, SSA_OP_VIRTUAL_USES)
> evaluates differently on them. *sigh*
This sounds more like this was introduced by the mem-ssa work, Diego?
--
pinskia at gcc dot gnu d
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-04-21 18:53
---
Fixed. I split the remaining FRE problems to a new PR31651.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-21 18:52 ---
The missed look-through-loads is a regression from 4.2. On the branch we also
do not fold constant intermediate results.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
Split out from PR31136. Testcase:
struct S {
unsigned b4:4;
unsigned b6:6;
} s;
int main(void){
s.b6 = 31;
s.b4 = s.b6;
s.b6 = s.b4;
return s.b6 == 15 ? 0 : 1;
}
with gcc 4.2 FRE can look through s.b6 to see the 31 for the store to s.b4.
With mainline this no longer happens:
On 4.2
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-04-21 18:47
---
Subject: Bug 31136
Author: rguenth
Date: Sat Apr 21 18:47:13 2007
New Revision: 124020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124020
Log:
2007-04-21 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-04-21 18:44
---
Subject: Bug 31136
Author: rguenth
Date: Sat Apr 21 18:43:57 2007
New Revision: 124019
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124019
Log:
2007-04-21 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-04-21 18:38
---
Actually the handle_ptr_arith change made a difference as we (luckily?)
for D.2147_17 = D.2144_14 + D.2146_16
D.2144_14 = a_11->begin;
D.2145_15 = i_1 * 4;
D.2146_16 = (const int *) D.2145_15;
D.2147_17 =
When I type make (after making various fixes to get make to complete) I get
this far:
/usr/bin/gcjh -jni -bootclasspath ../lib: -o
../../../../../gcc-4_2-branch/libjava/classpath/include/gnu_java_util_prefs_gconf_GConfNativePeer.h
gnu.java.util.prefs.gconf.GConfNativePeer
/usr/bin/gcjh -jni -bootc
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-04-21 18:07
---
This is a regression. Danny?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-04-21 16:58
---
See comment #13.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-04-21 16:56
---
Indeed.
int main(void){
s.b6 = 31;
s.b4 = s.b6 + s.b6;
s.b6 = s.b4;
return s.b6 == 15 ? 0 : 1;
}
Created value VH.0 for 31 + 31
...
:
s.b6 = 31;
D.1530_3 = 31;
D.1531_4 = 31;
D.1530_5 = 31;
D.1
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-04-21 16:37
---
The interesting thing is that we
Created value VH.0 for () 31
The bug (compared to the trunk) is, that tree-ssa-pre.c:try_look_through_load
on the 4.2 branch manages to propagate the 31 while trunk does not
(surp
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-21 16:23 ---
Note you might also need to add support to the preprocessor also (which means
adding it to the C family of languages which is a good thing). You might want
to support more than just the UTF-8 BOM but also the UTF-16
I compiled statically an application with dependencies to javax.xml.parser
using GCJ, replacing DocumentBuilderFactory.newInstance() with new
DomDocumentBuilderFactory() (with -static-gcj switch).
By bad fortune, there is no DomDocumentBuilderFactory entry in the output of
command:
nm --demangle=j
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-04-21 09:55
---
Created an attachment (id=13400)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13400&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31644
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
We should probably take care of files that begin with a byte order mark (BOM;
see http://en.wikipedia.org/wiki/Byte_Order_Mark) because some editors (like
windows notepad) use them. We currently say:
$ xxd bom.f
000: fffe 2020 2020 2020 7072 696e 7420 2a2c .. print *,
010: 2022 4865
The following code snippet fails to compile with -Os -O1 -O2 or -O3. It
compiles fine using -O0
I tested both the Win32 and linux versions of the compiler and they both fail
the same way.
The exact command line used was:
avr-gcc -c -mmcu=atmega168 -Os ee-fail.c
Removing the second call to fill_p
53 matches
Mail list logo
