Steven Bosscher wrote:
Ed Smith-Rowland [EMAIL PROTECTED] wrote:
All,
FWIW, I would like to add my support for creating a branch for gpc
with
the eventual goal
of integrating Pascal into mainline.
While I agree with most of the the points you make, the issue is not
whether GCC should
The fact is, that the GNU Pascal crew did not want integration with
gcc the last time this was discussed. GCC, the project, can not just
suck in every front end out there if the maintainers of that front end
do not want that.
Apparently, the GNU Pascal crew did not want integration with every
Adriaan van Os writes:
Steven Bosscher wrote:
Ed Smith-Rowland [EMAIL PROTECTED] wrote:
All,
FWIW, I would like to add my support for creating a branch for gpc
with
the eventual goal
of integrating Pascal into mainline.
While I agree with most of the the points you
negate_expr_p currently contains
switch (TREE_CODE (t))
{
case INTEGER_CST:
if (TYPE_UNSIGNED (type) || ! flag_trapv)
return true;
/* Check that -CST will not overflow type. */
return may_negate_without_overflow_p (t);
where it looks bogus to simply return
Rafael Espíndola writes:
The attached patch removes the convert callback by
1) copying the c implementation of convert to convert2
2) changing all calls to convert in gcj and gfortran into calls to convert2
3) adding a lang prefix to the remaining implementations (cxx_, c_, gnat_)
4)
hi there.
i just enabled -Wextra to catch broken if statements,
i.e. to enable warnings on:
* An empty body occurs in an if or else statement.
however this unfortunately triggers other warnings that i can't
reasonably get rid of. here's a test snippet:
== test.c
I've just upgraded to Fedora Core 5 (kernel 2.6.15-1.2054_FC5) and with the
program below I get results which didn't occur before (Fedora Core 3). I
posted them to [EMAIL PROTECTED] but I think something is up with GCC
4.1.0. I no longer have Core 3 so I've compared output with Mandrake. These
I hope I am viewed as an impartial but interested third party. I
would really like to see this happen. I did not know about gpc until
a few weeks ago when I did a google search. I may be mistaken but I
think the TeX community would be very interested in a GNU based Pascal.
I am aware
The attached patch duplicates convert_and_check into the c++ front
end. I would like to include it to be able to remove the convert
callback latter on. Duplicating convert_and_check makes it is easy to
use cxx_convert in the c++ front end and c_convert in the c front end.
Thanks,
Rafael
Steven Bosscher wrote:
The fact is, that the GNU Pascal crew did not want integration with
gcc the last time this was discussed. GCC, the project, can not just
suck in every front end out there if the maintainers of that front end
do not want that.
Not did not want integration. At leat I
On 4/3/06, Waldek Hebisch [EMAIL PROTECTED] wrote:
Steven Bosscher wrote:
The fact is, that the GNU Pascal crew did not want integration with
gcc the last time this was discussed. GCC, the project, can not just
suck in every front end out there if the maintainers of that front end
do not
On Mon, Apr 03, 2006 at 11:21:35PM +1200, Nick Roberts wrote:
I've just upgraded to Fedora Core 5 (kernel 2.6.15-1.2054_FC5) and with the
program below I get results which didn't occur before (Fedora Core 3). I
posted them to [EMAIL PROTECTED] but I think something is up with GCC
4.1.0. I
Hi,
I've run into a piece of code on ppc405 that does the wrong thing when a
function is automatically inlined. I don't really do ppc asm so I
haven't been able to isolate what exactly the problem is, but the code
blatantly takes the wrong branch.
The toolchain I'm using is a cross compiler
On 4/3/06, Rafael Espíndola [EMAIL PROTECTED] wrote:
The attached patch duplicates convert_and_check into the c++ front
end.
*cough* Non-normatively speaking, code duplication sucks :-)
Is there a reason why you can't use c-common.* and c_dialect_cxx() instead?
Gr.
Steven
On Mon, 3 Apr 2006, Richard Guenther wrote:
negate_expr_p currently contains
...
where it looks bogus to simply return true for signed types but
unset flag_trapv.
...
which is bogus as it should read || (!flag_trapv flag_wrapv) - no?
I hit this with a patch to fold A +- CST to A -+ CST
On Mon, 3 Apr 2006, Roger Sayle wrote:
On Mon, 3 Apr 2006, Richard Guenther wrote:
negate_expr_p currently contains
...
where it looks bogus to simply return true for signed types but
unset flag_trapv.
...
which is bogus as it should read || (!flag_trapv flag_wrapv) - no?
I hit
On Mon, 3 Apr 2006, Richard Guenther wrote:
|| (TREE_CODE (type) == INTEGER_TYPE
(TREE_CODE (arg1) == INTEGER_CST
|| TYPE_UNSIGNED (type)
|| (flag_wrapv !flag_trapv)))
Does this sound reasonable?
Yes, this sounds
On Apr 3, 2006, at 09:34, Waldek Hebisch wrote:
2) Adjusting gpc development model. In particular, gpc uses rather
short
feedback loop: new features are released (as alphas) when they
are ready.
This is possible because gpc uses stable backend, so that users are
exposed only to
Mark Mitchell wrote:
You also need documentation for this feature, discussing both the new
configure switch, and what you have to do to replace the generic
functions, and what the semantics of those functions are, so that people
know how to replace them.
The semantics of these functions are
They've been optimized away. Not surprising, since they are unused,
although slightly surprising that it happened with -O0.
The manual says:
`-O0'
Do not optimize. This is the default.
so that seems to be a documentation bug at least. More generally, it seems
odd to force an
On Tue, Apr 04, 2006 at 09:05:28AM +1200, Nick Roberts wrote:
It also causes GDB to generate errors on the output of other commands:
(gdb) info locals
argc = Cannot access memory at address 0x0
as well as the GDB/MI equivalent -stack-list-locals. This breaks the front
end that I'm
On Apr 1, 2006, at 7:26 AM, Ed Smith-Rowland wrote:
3. GPC would get much wider exposure. It would probably eventually
ship
along with the rest of gcc in OS distributions including *ahem*
MacOSX.
The GNU project doesn't set what is or becomes product for Apple.
Or, put another way,
On Apr 3, 2006, at 6:34 AM, Waldek Hebisch wrote:
2) Adjusting gpc development model. In particular, gpc uses rather
short
feedback loop: new features are released (as alphas) when they
are ready.
This is possible because gpc uses stable backend, so that users are
exposed only to
On Apr 2, 2006, at 3:20 AM, Steven Bosscher wrote:
The fact is, that the GNU Pascal crew did not want integration with
gcc the last time this was discussed. GCC, the project, can not just
suck in every front end out there if the maintainers of that front end
do not want that.
Actually, it can
Nick Roberts wrote:
Its
interesting that a quote on Bugzilla says that debugging is twice as hard as
writing code.
This need not be the case, if you adopt sufficient discipline to write
correct code the first time, debugging can be a minor part of the
development process. Far too many
On Mon, Apr 03, 2006 at 08:09:05PM -0400, Robert Dewar wrote:
In fact I agree that -O0 should not do any optimizations visible to
the user of the debugger at the source level (I wish it would do a
bit better job of generating reasonable code, subject to this criterion!)
Let's be careful to
Joe Buck wrote:
Let's be careful to distinguish code optimizations, and optimizations that
avoid the generation of unnecessary debug information. It used to be that
every once in a while, in response to a bug report, a GCC developer would
make a change that doubles or triples the size of a
Roberto Bagnara [EMAIL PROTECTED] writes:
Hi there,
I have read the files darwin-ldouble* in GCC 4.1.0.
What I would like do know is whether I can expect
long doubles on Darwin to comply with ISO C99 7.6
(Floating-point environment).
They can be made compliant with that section, but it
This is something I should have announced several weeks ago; to make up
for this delay, I went ahead and took care of the patch to the MAINTAINERS
file right away.
I guess it's not a real surprise for those on this list, but let's thank
Richard for contributing and agreeing to maintain
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-04-03 06:51
---
Recently updated glibc on my i686-pc-linux-gnu box and csqrt is now working.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25370
--- Comment #8 from kgardas at objectsecurity dot com 2006-04-03 06:59
---
Subject: Re: linking of C++ app fail on OpenBSD 3.9 due
POSIX threading unresolved symbols
Now if this works, then we have a problem in libstdc++ check to enable weakref
for some reason.
Could you be so
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-03 07:06 ---
(In reply to comment #8)
It's interesting it's working in gcc then...
Not really as we emulate what the weakref asm op does with weak and alias.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
--- Comment #10 from kgardas at objectsecurity dot com 2006-04-03 07:08
---
Subject: Re: linking of C++ app fail on OpenBSD 3.9 due
POSIX threading unresolved symbols
Small addition to previous post. Although .weakref is not supported, .weak
is:
$ cat /tmp/weak-conftest.s
--- Comment #5 from stigge at antcom dot de 2006-04-03 07:12 ---
It's not that we need special casing for a certain language: The TP robot is
generally broken (doesn't respond to translator's requests). I reported it
there several times, to no avail.
--
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-03 07:21
---
Wait a minute, libstdc++ is being built only as a static library looking at the
error message from comment #0. But that should not really.
Can you try an objective-C compiling for me to see if it is just
We ICE on the air Polyhedron test with -march=pentium4 -ffast-math
-funroll-loops -O3 -ftree-vectorize:
/space/rguenther/tramp3d/pb05/lin/source/air.f90: In function bound:
/space/rguenther/tramp3d/pb05/lin/source/air.f90:1119: internal compiler error:
in fold_convert, at fold-const.c:2089
#1
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-03 07:54 ---
The simplest solution looks like to punt on vector types in
interpret_rhs_modify_expr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26996
--- Comment #12 from kgardas at objectsecurity dot com 2006-04-03 08:01
---
Subject: Re: linking of C++ app fail on OpenBSD 3.9 due
POSIX threading unresolved symbols
Sorry, I've enabled only c++ for this build and I would prefer not to
rebuild if possible, since c/c++ took about
--- Comment #3 from pluto at agmk dot net 2006-04-03 08:07 ---
(In reply to comment #0)
(...) This is as expected: they are not used by
any actual code, so there is no need to emit debug info for them.
so, what for is the -feliminate-unused-debug-symbols?
--
The program below reports the following compiler errors:
bug.cpp:17: error: expected primary-expression before '*' token
bug.cpp:17: error: expected primary-expression before ')' token
bug.cpp:17: error: expected `;' before 'malloc'
which seem to refer to the first occurence of identifier t
on
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-04-03 09:12
---
With the patch we now can no longer figure out the number of iterations of the
inner loop, because we have an exit condition of i1D.1522_6 != 2147483647 now!?
Which we cannot simplify against i1D.1522_6 = 0 (I
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-04-03 09:19
---
Hmm, this cannot be simplified.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
--- Comment #4 from spop at gcc dot gnu dot org 2006-04-03 09:59 ---
Subject: Bug 26992
Author: spop
Date: Mon Apr 3 09:59:38 2006
New Revision: 112635
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112635
Log:
PR bootstrap/26992
* tree-scalar-evolution.c
Bootstrap fails because we have
Starting program: /abuild/rguenther/obj/prev-gcc/cc1 -quiet -v
-I../../trunk/libdecnumber -I. -I../../trunk/libdecnumber -I. -iprefix
/abuild/rguenther/obj/prev-gcc/../lib/gcc/ia64-unknown-linux-gnu/4.2.0/
-isystem /abuild/rguenther/obj/./prev-gcc/include
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-03 10:17 ---
Created an attachment (id=11187)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11187action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-03 10:17 ---
Jeff messed with VRP, so I guess he may have a clue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Trying to workaround the ia64 bootstrap problem with --disable-libdecnumber
causes
gcc -c -DUSE_LIBUNWIND_EXCEPTIONS -g -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
On the testcases below GCC marks even instantiated templates
with the currently pushed visibility, in case of the first testcase
that's hidden (anonymous namespace) and in the third testcase hidden as well
(namespace with visibility attribute).
But the template really wasn't declared as hidden and
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-03 11:11 ---
Created an attachment (id=11188)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11188action=view)
firsttest.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-03 11:11 ---
Created an attachment (id=11189)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11189action=view)
secondtest.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
--- Comment #3 from jakub at gcc dot gnu dot org 2006-04-03 11:12 ---
Created an attachment (id=11190)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11190action=view)
thirdtest.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
--- Comment #4 from jakub at gcc dot gnu dot org 2006-04-03 11:18 ---
I'd say we should remember template's visibility and use that during
instantiation, rather than the currently pushed visibility.
The question is if we want to do that for all template instantiations, or have
cases
--- Comment #24 from bonzini at gnu dot org 2006-04-03 11:20 ---
Subject: Bug 19653
Author: bonzini
Date: Mon Apr 3 11:20:07 2006
New Revision: 112637
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112637
Log:
2005-08-08 Paolo Bonzini [EMAIL PROTECTED]
Dale
--- Comment #25 from bonzini at gnu dot org 2006-04-03 11:20 ---
fixed on mainline.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
The following code snippet causes an ICE on x86_64-unknown-linux-gnu
when compiled with -fschedule-insns -fstack-protector-all.
This happens since 4.1.0 when -fstack-protector-all was introduced.
=
int foo(int i)
{
i /=
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-03 11:25 ---
Also fails on x86_64
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-03 11:26 ---
Created an attachment (id=11191)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11191action=view)
patch that may be needed to trigger the problem
This patch is what I am trying to bootstrap/regtest.
--
The following Fortran code snippet causes an ICE (segfault) when compiled
with -fipa-pta -O:
==
subroutine BAR()
call FOO (0)
end subroutine BAR
==
--
Summary: ICE with -fipa-pta when
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-03 11:33 ---
Note we have NEGATE_EXPR X where X has VR of
(gdb) print vr0
$4 = {type = VR_ANTI_RANGE, min = 0x2a95891b40, max = 0x2a95891b40,
equiv = 0xf73b20}
(same min/max!) Also,
if (code == NEGATE_EXPR
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-03 11:35 ---
Something like
Index: tree-vrp.c
===
*** tree-vrp.c (revision 112634)
--- tree-vrp.c (working copy)
*** extract_range_from_unary_expr
unsigned int
foo (unsigned int x)
{
unsigned int r = x;
while (--x)
r *= x;
return r;
}
unsigned long long
bar (unsigned long long x)
{
unsigned long long r = x;
while (--x)
r *= x;
return r;
}
extern void abort (void);
int
main (void)
{
if (foo (5) != 120 || bar (5) !=
--- Comment #3 from green at redhat dot com 2006-04-03 13:02 ---
Azureus users on FC5 see this as well (gcj 4.1.0). Here's a slightly
different stack trace.
[12:31:21.648] {stderr} DEBUG::Mon Apr 03 12:31:21 GMT
--- Comment #25 from bonzini at gnu dot org 2006-04-03 13:37 ---
Subject: Bug 26830
Author: bonzini
Date: Mon Apr 3 13:37:07 2006
New Revision: 112639
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112639
Log:
2006-04-03 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #26 from bonzini at gnu dot org 2006-04-03 13:40 ---
compile-time should be fixed on 4.1 (richard, could you confirm). spinning a
separate bug for the salias memory hog problems.
zdenek wanted to investigate manual SSA update of real operands for 4.2
--
bonzini at gnu
spinning a separate bug from PR26830. we are creating a lot of field memory
tags, each of which is present in a 900-argument phi, which causes us to use
more memory than 4.0.
to some extent this is unavoidable, but I wonder if we could throttle things
down a bit?
--
Summary:
--- Comment #27 from rakdver at gcc dot gnu dot org 2006-04-03 14:16
---
With a bit simplified testcase (my computer does not have enough memory for
this one), we spend 30% of compile time in rewrite_update_phi_arguments.
However, only 1.6% (less then 1% of compile time) of the
--- Comment #8 from aph at gcc dot gnu dot org 2006-04-03 14:31 ---
Subject: Bug 26858
Author: aph
Date: Mon Apr 3 14:31:56 2006
New Revision: 112640
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112640
Log:
2006-04-03 Andrew Haley [EMAIL PROTECTED]
PR java/26858
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-04-03 14:37 ---
Subject: Re: New: [4.1/4.2 Regression]
Insane amount of memory needed at -O1 and above because of salias
On Mon, 2006-04-03 at 13:43 +, bonzini at gnu dot org wrote:
spinning a separate bug from
--- Comment #2 from rguenther at suse dot de 2006-04-03 14:39 ---
Subject: Re: [4.1/4.2 Regression] Insane amount
of memory needed at -O1 and above because of salias
On Mon, 3 Apr 2006, dberlin at dberlin dot org wrote:
On Mon, 2006-04-03 at 13:43 +, bonzini at gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 14:59 ---
This option should not exist, try --disable-libcpp and you will get even
worse.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26999
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-03 15:02 ---
The patch is bogus, but the problem in the source looks still valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-03 15:04 ---
I bet you can reproduce this with using #pragma GCC visibility, without
namespaces. Related to PR 26984.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 15:06 ---
This is the normal problem of using specific registers for multiplication on
x86 and x86_64 so running out of registers is easy :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from aph at gcc dot gnu dot org 2006-04-03 15:22 ---
Subject: Bug 26858
Author: aph
Date: Mon Apr 3 15:22:21 2006
New Revision: 112641
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112641
Log:
2006-04-03 Andrew Haley [EMAIL PROTECTED]
PR java/26858
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 15:22 ---
I still say x86 should be using HWI of 64bits anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 15:34 ---
types are not expressions though.
It is not incorrect but just misleading.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pavel dot petrovic at gmail dot com 2006-04-03 16:03
---
(In reply to comment #1)
types are not expressions though.
sure, but I wouldn't mind that, the compiler complains
about expression, not about type. isn't typecasting
an expression after all?
It is not
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-03 16:16 ---
In fact this is a latent bug shown by:
/* { dg-do compile } */
/* { dg-require-visibility } */
/* { dg-final { scan-not-hidden _ZN1SIiED1Ev } } */
/* { dg-final { scan-not-hidden _ZN1SIiEC1ERKi } } */
template
--- Comment #28 from rguenth at gcc dot gnu dot org 2006-04-03 16:20
---
I confirm, that with -fno-tree-salias -O1 4.1.1 is on-par with -O1 4.0.3. So
all remaining compile-time/memory problems are due to extra virtual operands.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
--- Comment #6 from orion at cora dot nwra dot com 2006-04-03 16:24 ---
Hmm, tried adding -save-temps to my flags so that I could collect .s and .i
files, but it appears that the segfault also goes away. Removing -save-temps
indeed goes back to the previous behavior. Removing -pipe
--- Comment #29 from rakdver at gcc dot gnu dot org 2006-04-03 16:31
---
(In reply to comment #27)
With a bit simplified testcase (my computer does not have enough memory for
this one), we spend 30% of compile time in rewrite_update_phi_arguments.
However, only 1.6% (less then 1% of
--- Comment #7 from patchapp at dberlin dot org 2006-04-03 16:45 ---
Subject: Bug number PR26763
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/2006-04/msg00082.html
--
I am using gcc 3.4.3 on solais 10.
g++ -v:
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
--- Comment #1 from boris dot breidenbach at physik dot uni-erlangen dot de
2006-04-03 16:51 ---
Created an attachment (id=11192)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11192action=view)
buggy code with comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27005
--- Comment #2 from boris dot breidenbach at physik dot uni-erlangen dot de
2006-04-03 16:52 ---
Created an attachment (id=11193)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11193action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27005
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-04-03 16:52 ---
(In reply to comment #6)
I believe c-common.c:pointer_int_sum is wrong in relying on pointer overflow
during conversion of the integer offset to an unsigned pointer. I'm sending
a patch that fixes this for
--- Comment #9 from rguenther at suse dot de 2006-04-03 16:59 ---
Subject: Re: [4.1 Regression] wrong final value
of induction variable calculated
On Mon, 3 Apr 2006, rakdver at gcc dot gnu dot org wrote:
(In reply to comment #6)
I believe c-common.c:pointer_int_sum is wrong in
--- Comment #3 from boris dot breidenbach at physik dot uni-erlangen dot de
2006-04-03 17:00 ---
(In reply to comment #0)
Maybe I should say, that I am using an Opteron system. I ran the code on
an linux-operton box and it showed the same behaviour.
On gcc version 3.4.4 20050314
--- Comment #10 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-03 17:22 ---
Subject: Re: [4.1 Regression] wrong final value of induction variable
calculated
(In reply to comment #6)
I believe c-common.c:pointer_int_sum is wrong in relying on pointer
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-03 17:28 ---
I happened to try this out this weekend.
I don't see an ICE in build_java_check_indexed_type
(with 4.0, 4.1 and head). Now I see:
+ gcj -c --classpath=jakarta-poi.jar joone-engine.jar -o joone-engine.o
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-03 17:35 ---
Fixed in 4.0.0 at least so closing as 3.4.x is not being updated anymore.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-03 17:42 ---
Just a note here, we really always want to deal with a + CST and not worry
about if CST is negative or not, I had a patch to do but there was a testsuite
regression because of VRP, see PR 25148. In fact currently
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-03 17:45 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 17:50 ---
From:
http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg00107.html
FAIL: g++.dg/ext/visibility/anon1.C scan-hidden private_extern[
\\t_]*_?_ZN.*1fEv
So we have a testsuite failure also :).
--
--- Comment #4 from rittle at latour dot labs dot mot dot com 2006-04-03
17:57 ---
Subject: Re: FreeBSD 5 support for libjava
In article [EMAIL PROTECTED],
gerald at pfeifer dot com[EMAIL PROTECTED] writes:
--- Comment #3 from gerald at pfeifer dot com 2006-04-03 04:58 ---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-03 18:16 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
When compiling the following code with -O0 -maltivec:
typedef union
{
int i[4];
__attribute__((altivec(vector__))) int v;
} vec_int4;
int main (void)
{
vec_int4 i1;
i1.v = (__attribute__((altivec(vector__))) int){31, 31, 31, 31};
printf (%d\n, i1.i[0]);
return 0;
}
the output
This function always returns 1, but gcc misses the optimization:
int foo(unsigned char x)
{
return (x+1) != 0;
}
fold-const.c converts the comparison to x != -1, but that's it.
shorten_compare() in c-common.c would optimize it, but it doesn't get called.
fold-const.c has similar code on
gcc version 3.3, Apple build 1495, ppc-darwin.
command-line: gcc -O3 file.c
output: 1 2 0 0 5 6 0 0 9 10 0 0 13 14 0 0 17 18
command-line: gcc -O0 file.c
output: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Compile and run the following file with optimization O2. The output is a list
of
1 - 100 of 160 matches
Mail list logo
