On Sun, 2006-04-16 21:30:08 -0700, Ian Lance Taylor ian@airs.com wrote:
http://gcc.gnu.org/projects/
If anybody wants to pull together a single URL of projects suitable
for students, probably on the Wiki page, that would be helpful. Or I
might try to tackle that in the next few days
VASTU BULLETIN VOLUME-29 [APR JUNE 2006]
Environment Landscaping according to vastu
In this issue, we will be focusing on understanding environmental
influences of location. The location must have good energy. Living in a
beautiful environment is much more supportive than living in an
How about a pull-together of all the existing docs on how to create a new
front-end / back-end.. stuff like whats in the gcc internals doc, and
Stallman's Using and porting gcc.. maybe update it all in a single place
for ver 4.x, and update for the undocumented / obsolete macros? It's not
I decided to look into the Yara branch to see if it could even be
bootstrap on PPC (with Yara turned on by default).
I ran into an ICE while compiling libgcc2.c for __muldi3.
The ICE was in emit_secondary_memory_move.
The preprocessed source is:
typedef int SItype __attribute__ ((mode (SI)));
[EMAIL PROTECTED] wrote:
I decided to look into the Yara branch to see if it could even be
bootstrap on PPC (with Yara turned on by default).
Thanks, for the information. It is even a surprise for me that some
tests work correctly for ppc. Last time when I had time and checked ppc
On Mon, 2006-04-17 at 14:48 +0200, Marcin 'Qrczak' Kowalczyk wrote:
There is a missing opportunity for optimization.
int f(void);
void test(int x) {
if (x 1 ? x == 0 : x 0) f();
}
This is gcc-4.1.0-0.20051206 with some patches by PLD Linux
Distribution. gcc -S -O2
Dave Murphy wrote:
install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use make install DESTDIR=e:/devkitPro to install it where
you actually want it.
Ross Ridge
Dan Berlin and I exchanged some email about PR 26435, which concerns a
bug in -ftree-loop-linear, and we now think it would make sense to have
a broader discussion.
The PR in question is about an ice-on-valid regression in 4.1, when
using -O1 -ftree-loop-linear. Dan notes that this optimization
-ftree-loop-linear enables a number of features and
transformations. Which part, exactly, is experimental? You are quoting
from the documentation for the option, but Dan may be referring to a
particular transformation. I thought the failure and algorithm
correctness was related to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Mitchell wrote:
Thoughts?
I don't know which of the loop linear transformations you folks were
debating (the loop linear stuff defines a family of transformations),
but I vote for having no experimental features in releases.
If a feature is
On Apr 17, 2006, at 11:52 AM, Mark Mitchell wrote:
Dan Berlin and I exchanged some email about PR 26435, which concerns a
bug in -ftree-loop-linear, and we now think it would make sense to
have
a broader discussion.
The PR in question is about an ice-on-valid regression in 4.1, when
using
Hi folks.
While investigating a regression from the V_MUST_DEF removal on mem-ssa,
I've noticed that we were missing out on optimization of certain
stores to complex types (on mainline).
For example, here:
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
we end up with:
# t_2 =
Dale Johannesen wrote:
I wasn't aware that it was supposed to be experimental either, and it
wasn't explained that way when it went in (Sep 2004). (Incomplete or
buggy would not be surprising, but it sounds now like we're talking
about fatally flawed design, which is different.)
My
Thanks for reply.
What I am trying to do is something like counting the times of a particular
function call, i.e., whenever there is a CALL_EXPR in the tree, I want to
look at the id to see if that is the function I want to count during
runtime. If the id is the function name I want to
I see the original rationale for inhibiting creation of subvariables
on aggregates here:
http://gcc.gnu.org/ml/fortran/2006-01/msg00195.html
But I don't think, memory wise, it should apply to complex types.
This patch will cause the clearring of t to be redundant on mainline.
On mem-ssa
On 4/17/06, Aldy Hernandez [EMAIL PROTECTED] wrote:
Hi folks.
While investigating a regression from the V_MUST_DEF removal on mem-ssa,
I've noticed that we were missing out on optimization of certain
stores to complex types (on mainline).
For example, here:
_Complex int t = 0;
Hello,
What I am trying to do is something like counting the times of a particular
function call, i.e., whenever there is a CALL_EXPR in the tree, I want to
look at the id to see if that is the function I want to count during
runtime. If the id is the function name I want to count, I
Mark Mitchell writes:
Mark My understanding is we might be able to remove just the
Mark problematic part (or segregate that into a separate option) -- but that
Mark problematic part is the 177.swim bit, so that's an issue.
Well, yes and no. The 177.swim bit is loop interchange and that
Hi folks.
While investigating a regression from the V_MUST_DEF removal on mem-ssa,
I've noticed that we were missing out on optimization of certain
stores to complex types (on mainline).
For example, here:
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
On Mon, Apr 17, 2006 at 11:52:26AM -0700, Mark Mitchell wrote:
My suggestion is that features that are clearly experimental (like this
one) should be (a) documented as such, and (b) should generate a
warning, like:
warning: -ftree-loop-linear is an experimental feature and is not
I am a gcc user at a fininancial institution and IMHO it would not be a
good idea to have non-production ready functionality in gcc. We are
trying to use gcc for mission critical functionality.
Hope this helps,
Ivan
Mark Mitchell wrote:
Dan Berlin and I exchanged some email about PR 26435,
On 4/18/06, Ivan Novick [EMAIL PROTECTED] wrote:
I am a gcc user at a fininancial institution and IMHO it would not be a
good idea to have non-production ready functionality in gcc. We are
trying to use gcc for mission critical functionality.
It has been always the case that additional
I am using
gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
under the Inline::C perl module
and having a very weird situation.
I have a multi-line macro that declares several variables and then does some
work with them, for use in several functions that have similar invocations,
interfacing to an
On Mon, Apr 17, 2006 at 04:42:18PM -0500, David Nicol wrote:
GCC appears to be treating my long macro as some kind of block
and throwing out variables that are not used within it instead of simply
pasting the code in at the macro invocation point.
Is this a known problem with 4.0.2? Is
On Mon, Apr 17, 2006 at 04:42:18PM -0500, David Nicol wrote:
I am using
gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
under the Inline::C perl module
and having a very weird situation.
You vaguely describe your problem, speculate on its cause, and don't
include a complete testcase. Not a
On Apr 17, 2006, at 2:31 PM, Richard Guenther wrote:
On 4/18/06, Ivan Novick [EMAIL PROTECTED] wrote:
I am a gcc user at a fininancial institution and IMHO it would not
be a
good idea to have non-production ready functionality in gcc. We are
trying to use gcc for mission critical
Thank you. Nobody is aware of such a problem.
On Apr 17, 2006, at 2:53 PM, Dale Johannesen wrote:
I'd go further: you should not be trusting a compiler (gcc or any
other) to be correct in mission critical situations.
Or, to use the option that spits out the proof that the
transformation of the code that the compiler did was indeed
On Mon, Apr 17, 2006 at 02:53:37PM -0700, Dale Johannesen wrote:
So from my point of view, the situation with -ftree-loop-linear is
fine - it's ICEing after all, not producing silently wrong-code. For
experimental options (where
I would include all options not enabled by -O[123s]) known
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Nicol wrote:
Thank you. Nobody is aware of such a problem.
What problem? You have provided no evidence that there indeed is a
problem here. Again, please visit our bug submission page at gcc.gnu.org.
-BEGIN PGP SIGNATURE-
Version:
Mark == Mark Mitchell [EMAIL PROTECTED] writes:
Mark In any case, the broader question is: to what extent should we have
Mark experimental options in releases, and how should we warn users of their
Mark experimental nature?
Why not put this into the option name? Something like '-Xoption' or
I should also mention on the mainline, we get the decomposing for the
orginal testcase which means this is a bug only on the MEM-SSA branch.
No we don't. Look at the actual testcase I posted. This is a bug on
mainline.
Well, it's written to only in this testcase. Can you post a more complete
one?
Here's the complete testcase.
int g(_Complex int*);
int f(void)
{
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
return g(t);
}
Well, it's written to only in this testcase. Can you post a more complete
one?
Here's the complete testcase.
int g(_Complex int*);
int f(void)
{
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
return g(t);
}
Yes but that should not matter always as this is going to
losing a slight missed optimization on the tree level.
Yay, exactly what I'm trying to fix. Glad you agree.
Aldy
Ross Ridge wrote:
Dave Murphy wrote:
install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use make install DESTDIR=e:/devkitPro to install it where
you actually want it.
Doesn't help, it's still
Dave Murphy wrote:
Ross Ridge wrote:
Dave Murphy wrote:
install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use make install DESTDIR=e:/devkitPro to install it where
you actually want it.
Doesn't
Hi Geoff
I'm seeing a bootstrap failure on x86 Linux that looks to be due to
your change (noted below):
/home/bje/build/gcc-clean/./gcc/xgcc -B/home/bje/build/gcc-clean/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include
Daniel Jacobowitz wrote:
No, this patch is not correct. Take a wander through set_std_prefix
and the call to update_path in add_prefix.
Expected as much :)
You might want to play around with relocation on a non-MinGW-hosted
system, for comparison. Does that work better? If so, it's
--- Comment #1 from pault at gcc dot gnu dot org 2006-04-17 06:21 ---
I have a fix for this, modulo some nonsense involving character(*) results in
defined interfaces. Expect a patch in ~24hours.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-17 09:51 ---
Confirmed. Number of iteration analysis concludes the loop
ush_4 = label.23_3 + 510B;
if (label.23_3 = ush_4) goto L6; else goto L2;
L6:;
# ush_16 = PHI ush_10(3), ush_4(1);
# csum_14 = PHI csum_9(3),
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-17 10:10 ---
This is a dup of PR26763, which is fixed for 4.1.1.
*** This bug has been marked as a duplicate of 26763 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-04-17 10:10
---
*** Bug 27176 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-17 10:16 ---
This may be fixed by Zdeneks optimization of phi argument rewrite and dominator
updating. Though I bet these are not appropriate for 4.1.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-17 10:34 ---
#5 0x081a8738 in get_val_for (x=0xb7dedea0, base=0xb7d70480)
at /space/rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c:1254
1254 val = fold (TREE_OPERAND (stmt, 1));
(gdb) call
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-17 10:51 ---
Hmm, looks more like a tree sharing problem
Breakpoint 5, fold_ternary (code=CALL_EXPR, type=0xb7d5fa6c, op0=0xb7d55540,
op1=0xb7dd9048, op2=0x0)
at
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-17 11:12 ---
1329aval[j] = get_val_for (op[j], val[j]);
(gdb) call debug_generic_expr(val[0])
__builtin_pow (xD.1278_4, 2.0e+0)
(gdb) call debug_generic_expr(op[0])
xD.1278_3
Program received signal SIGSEGV,
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-17 11:18 ---
Now, the comment before get_val_for is confusing, as it says
* if BASE is NULL_TREE, X must be a constant and we return X.
but we do
if (!x)
return base;
now, I believe a
gcc_assert
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-04-17 12:09
---
The ICE reappeared.
Probably with Jakub's fix for PR26823.
Btw, the testcase in the testsuite didn't trigger, it
probably lacks the line
/* { dg-options -O } */
This should be fixed once this bug gets fixed
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-17 12:17
---
The testcase fails again (with a segfault):
FAIL: gcc.dg/gomp/pr25989.c (test for excess errors)
(from http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg00920.html)
This is probably due to your fix from PR26823,
Consider the following class hierarchy:
struct StorageBase {
int i;
};
struct NonPod1 : StorageBase {
int get() { return i; }
NonPod1() {}
};
struct NonPod {
NonPod() { x[0].i = 0; x[1].i = 0; }
NonPod1 operator[](int i) { return *static_castNonPod1*(x[i]);
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-17 12:31 ---
The tree-combiner requiring function depends on 27084. Also this happens in
tramp3d again. Also related to 27090. Still fold needs to catch it first.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-04-17 12:33
---
Fixed on mainline.
Thanks for fixing this one, Jakub!
Alas there seems to be some fallout: PR25874, PR25989.
@Martin: I tried to reduce your testacse a little and got a segfault in
can_throw_internal_1. So this
--- Comment #6 from patchapp at dberlin dot org 2006-04-17 13:10 ---
Subject: Bug number PR 27136
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/msg00623.html
--
Hi,
gcc-4.1.0 miscompiles on sh4-linux target.
Attached testcase does not trigger this bug on mainline,
and also correctly compiled with gcc-3.4.5.
For attached testcase, source line 514 is incorrectly compiled with
following command line.
g++ -O2 -g -fno-strict-aliasing -fwrapv \
--- Comment #1 from sugioka at itonet dot co dot jp 2006-04-17 13:19
---
Created an attachment (id=11282)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11282action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27182
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-17 13:53 ---
Subject: Bug 26826
Author: rguenth
Date: Mon Apr 17 13:53:19 2006
New Revision: 113007
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113007
Log:
2006-04-17 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-17 13:54
---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from green at redhat dot com 2006-04-17 14:43 ---
Created an attachment (id=11283)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11283action=view)
Sample patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
--- Comment #5 from green at redhat dot com 2006-04-17 14:44 ---
I've uploaded a patch that I've applied to the FC5 gcc RPM. I can't reproduce
the problem with this patch.
--
green at redhat dot com changed:
What|Removed |Added
--- Comment #2 from patchapp at dberlin dot org 2006-04-17 15:00 ---
Subject: Bug number PR27122
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/msg00626.html
--
--- Comment #3 from pault at gcc dot gnu dot org 2006-04-17 15:12 ---
This fellow now gives:
Error: Procedure 'p' at (1) is already defined at (2)
on trunk and 4.1, so it is fixed.
Arigato goziamasu, Iguchi-san!
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-17 15:14 ---
HJ has fixed this one.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2006-04-17 15:18 ---
Fixed on trunk and will be fixed on 4.1, when patch for PR25597 is applied next
weekend.
I will close this now since its purpose is served.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25618
--- Comment #3 from pault at gcc dot gnu dot org 2006-04-17 15:18 ---
Fixed!
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #33 from edmar at freescale dot com 2006-04-17 15:22 ---
The latest round of patches cured the original problem. Unfortunately, the
target itself is still broken. This time because of a bug originaly reported
for the e500v1 target. (27075).
I am not sure what is the right
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-17 15:32 ---
HJ has fixed this one.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-17 15:35 ---
This one now gives:
Error: 's' at (1) must have constant character length in this context
on trunk and 4.1
Fixed - thanks, Philippe!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #34 from mark at codesourcery dot com 2006-04-17 15:37 ---
Subject: Re: [4.1/4.2 Regression] gcc fails to build on
powerpc e500-double targets
edmar at freescale dot com wrote:
--- Comment #33 from edmar at freescale dot com 2006-04-17 15:22 ---
The latest
--- Comment #35 from edmar at freescale dot com 2006-04-17 15:44 ---
The original problem was solved. For futher bootstrap problems on this target,
see bug 27075.
--
edmar at freescale dot com changed:
What|Removed |Added
--- Comment #9 from edmar at freescale dot com 2006-04-17 15:57 ---
This bug also affects target e500v2. The e500v2 is configured with:
--target=powerpc-unknowm-linux-gnuspe --enable-e500_double.
I will try the patch on comment 8 overnight.
--
--- Comment #6 from tromey at gcc dot gnu dot org 2006-04-17 16:00 ---
We could either use gc.h here (see ltdl.c) or we could
use libltdl instead of directly using dlopen...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #22 from law at redhat dot com 2006-04-17 16:40 ---
Here's some code which can be clearly improved with the in-progress patch to
add additional ASSERT_EXPRs:
int f(void);
void test(int x) {
if (x 1 ? x == 0 : x 0) f();
}
Right now we generate something like:
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-04-17 16:54
---
It also helps for propagating loop versioning guard information like
int foo(int i, int j)
{
int res = 0;
if (i==1 j==2)
for (;i0;--i)
res += j;
else
for (;i0;--i)
res += j;
return
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-04-17 17:21
---
The failures in PR25874 and PR25989 are not caused by this patch.
Sorry for blaming your patch, Jakub!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
-darwin8.6.1
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20060417 (experimental)
[pactech01:~/tests] dir%
WARNING: Couldn't find the global config file.
Test Run By dir on Mon Apr 17 09:22:47 2006
Native configuration
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-17 17:23 ---
*** Bug 27183 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-17 17:23 ---
I already filed this before.
*** This bug has been marked as a duplicate of 25765 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-17 17:24
---
RTH, alas there seems to be some fallout: PR25874, PR25989.
(I first blamed Jakub's patch for PR26823 for the fallout, but closer
inspection showed that it's your patch instead.)
Would you mind having a look?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22366
--- Comment #2 from tbm at cyrius dot com 2006-04-17 18:29 ---
What's the status of this bug? Did nobody comment on the proposed patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26725
--- Comment #2 from tbm at cyrius dot com 2006-04-17 18:33 ---
Looks like a duplicate of PR26881
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27036
--- Comment #5 from pcarlini at suse dot de 2006-04-17 18:35 ---
Working on a fix.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-17 18:36 ---
Fixed by:
2006-04-17 Roger Sayle [EMAIL PROTECTED]
* expr.c (expand_assignment): Optimize away no-op moves where the
source and destination are equal and have no side-effects.
--
pinskia at
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-17 18:39 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Testcase (at -O2 and above):
typedef long atype[];
typedef long atype1[];
int NumSift (atype *a, atype1 *a1)
{
(*a)[0] = 0;
(*a1)[0] = 1;
return (*a)[0];
}
int main(void)
{
long a[2];
if (!NumSift(a, a))
__builtin_abort ();
return 0;
}
--
Orginally reported here:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.0.4
--- Comment #9 from janis at gcc dot gnu dot org 2006-04-17 19:36 ---
Subject: Bug 26114
Author: janis
Date: Mon Apr 17 19:35:56 2006
New Revision: 113010
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113010
Log:
PR c++/26114, c++/26115
* typeck.c
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-04-17 19:38 ---
This is now fixed on mainline and 4.1:
$ cat case.f90
program main
logical :: l
select case (l)
case (.true.)
case (.true.)
end select
end program main
$ gfortran case.f90
In file case.f90:4
case
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-17 19:55 ---
Just to add some information from the conversation on this topic:
Shouldn't the aliasing set for the type atype be the same as atype1?
Im not entirely sure, but the C99 standard does at least not suggest
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-17 20:07 ---
And this only fails for array types without their size specified. Confirmed.
Btw. inside NumShift the two array types are
array_type 0xb7d86398 atype
type integer_type 0xb7d1733c long int sizes-gimplified
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-17 20:13 ---
Simplified test case:
public class main {
public static void main(String[] args) {
char x = 56478;
System.out.println(new String(new char[] { x }));
}
}
--
tromey at gcc dot
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-17 20:23 ---
Testing a fix.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Hello.
There is part of build screen:
mkdir -p -- libgcc
if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
/e/build/gcc-4.1-20060414/host-i786-pc-cygwin/gcc/xgcc
-B/e/build/gcc-4.1-20060414/host-i786-pc-cygw
in/gcc/ -B/usr/i786-pc-cygwin/bin/ -B/usr/i786-pc-cygwin/lib/ -isystem
--- Comment #3 from tromey at gcc dot gnu dot org 2006-04-17 21:41 ---
Subject: Bug 27171
Author: tromey
Date: Mon Apr 17 21:41:47 2006
New Revision: 113013
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113013
Log:
PR libgcj/27171:
*
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-17 21:45 ---
Subject: Bug 27171
Author: tromey
Date: Mon Apr 17 21:45:42 2006
New Revision: 113014
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113014
Log:
PR libgcj/27171:
*
--- Comment #5 from tromey at gcc dot gnu dot org 2006-04-17 21:46 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Compiles Booch Components but does not compile a package used for testing the
components. Compiler creates the ali file but no object file.
Cygwin from http://sources.redhat.com/cygwin/
Compiler (GNU Ada, package GNAT/GCC MS-Windows Cygwin, release 4.1.0 R4) from
--- Comment #1 from george dot chapman at lmco dot com 2006-04-17 22:00
---
Created an attachment (id=11287)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11287action=view)
gnatchop input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
1 - 100 of 128 matches
Mail list logo
