We should go complete to mapped location. If Ada maintainers feel
like they don't want to play with the team, well they can stay in
their corner -- they more or less have already built they own ghetto;
this issue is not going to make it worse or better.
Sure, with that kind of reasoning, GCC
Eric Botcazou wrote:
On the other hand, I don't see any fundamental reasons why we couldn't use
Gigi to shield the Ada front-end from the differences in the representation
of source locations between successive generations of the core compiler.
That sounds reasonable. I don't think it is
Hi everybody,
I decided to split the modification in two parts:
- add an __asm__ () statement to control the value of
the segment registers from an high level language;
This __asm__ () statement is then used as follow:
register short a __asm__ (es);
int main(int argc, char **argv)
The constant pool placement that sh_reorg does has somewhat hapazard
results.
It does not take execution frequencies into account, so if you are
unlucky, you
can end up with a constant table wedged into some hoit spot of the code,
which not
only adds an extra jump into the critical path, but
Eric Botcazou wrote:
We should go complete to mapped location. If Ada maintainers feel
like they don't want to play with the team, well they can stay in
their corner -- they more or less have already built they own ghetto;
this issue is not going to make it worse or better.
Sure, with that
On Mon, May 15, 2006 at 12:09:00AM +0800, Rémy Saissy wrote:
To manage the manipulation of the register class, I added entries in
the i386.md file.
;; get a value from a segment register.
(define_insn store_seg
[(set (match_operand:SI 0 nonimmediate_operand )
(match_operand:SI 1
Actually, the Fortran and objc people play nice too, and TBQH, i
wouldn't mind if we were only a C/C++/F95/Objc compiler.
Yeah, and I presume Objc is in the basket only because it's essentially C.
F95 is a different case since it's a brand new compiler so it doesn't have to
bother about the
On 5/14/06, Eric Botcazou [EMAIL PROTECTED] wrote:
Actually, the Fortran and objc people play nice too, and TBQH, i
wouldn't mind if we were only a C/C++/F95/Objc compiler.
Yeah, and I presume Objc is in the basket only because it's essentially C.
F95 is a different case since it's a brand
Eric Botcazou wrote:
Actually, the Fortran and objc people play nice too, and TBQH, i
wouldn't mind if we were only a C/C++/F95/Objc compiler.
Yeah, and I presume Objc is in the basket only because it's essentially C.
F95 is a different case since it's a brand new compiler so it doesn't have
I've been on vacation for a week -- but I'm back now and reading through
the 600 or so messages in my GCC folder. I hope to have an
understanding of where we are by the end of the day, and, assuming I can
reach that point, an update as to at least the 4.1.1 release plan.
I see that I've been
That is not an excuse for being so uncooperative as Ada maintainers
can sometimes be when it concerns middle-end changes.
That's the usual tension between backward compatibility and development.
Clearly the Fortran maintainers, by starting again from scratch, and the
C/C++ maintainers, by
Eric Botcazou [EMAIL PROTECTED] writes:
| Actually, the Fortran and objc people play nice too, and TBQH, i
| wouldn't mind if we were only a C/C++/F95/Objc compiler.
|
| Yeah, and I presume Objc is in the basket only because it's essentially C.
| F95 is a different case since it's a brand new
The real problem, as we all know, is that Adacore treats the GCC repo
like an extension of their corporate repo, instead of as the main tree.
The other languages don't do that.
What of Apple and Objective-C++ ?
--
Eric Botcazou
On May 14, 2006, at 12:07 PM, Eric Botcazou wrote:
The real problem, as we all know, is that Adacore treats the GCC repo
like an extension of their corporate repo, instead of as the main
tree.
The other languages don't do that.
What of Apple and Objective-C++ ?
They don't complain and
They don't complain and they update their sources when integrating
into the mainline. They had to update Objective-C++ for the new C++
parser.
Just like AdaCore had to update Ada for tree-ssa?
--
Eric Botcazou
Notice that the C and C++ parts are 10+ years old production compilers
and they were converted.
Right, no disagreement. My reply was intended to be more general, on the same
level as Daniel's.
--
Eric Botcazou
On May 14, 2006, at 12:13 PM, Eric Botcazou wrote:
They don't complain and they update their sources when integrating
into the mainline. They had to update Objective-C++ for the new C++
parser.
Just like AdaCore had to update Ada for tree-ssa?
That's part of maintaining. Sometimes the
Is there no abstract interface that would shield *any*
front end from differences in representation of source locations
between successive generations of the core compiler? Certainly we
have made major changes in the GNAT representation without any change
at all in clients (except to take
Richard Sandiford wrote:
DJ Delorie [EMAIL PROTECTED] writes:
How about this? Tested under mipsisa64-elf with no regressions. The
other two I found by inspection; they're the only other two that have
.sdata and use -G 0.
Looks good to me FWIW, although I can't approve it. I wonder if...
Eric Botcazou wrote:
Is there no abstract interface that would shield *any*
front end from differences in representation of source locations
between successive generations of the core compiler? Certainly we
have made major changes in the GNAT representation without any change
at all in clients
Steven Bosscher wrote:
Anyway, if this can be done in gigi, then let's make a plan and work
on it. I'd really like to see MAPPED_LOCATION become the default, and
Ada is basically the major blocker right now, so we need to agree on
something instead of arguing... ;-)
I think that this is
Kazu Hirata wrote:
Hi Mark,
I have a question about your patch for PR c++/26534.
When build_unary_op builds TRUTH_NOT_EXPR, it calls
perform_implicit_conversion to convert p-field to the boolean type.
(FWIW, p-field is expressed as component_ref indirect_ref ...
field_ref ...). The call
Robert Dewar wrote:
Right, so it seems quite appropriate to have two representations for
source locations, one for the Ada tree, which is completely independent
of the tree IL, and one for the back end. That probably means that back
end messages will lose the generic instantiation information,
dear gcc advancer user:
I am try to install gcc in my MAC OS X 7.9, by down load from apple
s website's gcc-5250, but when I did ./configure
-
Union-Souths-Computer:~/gcc-5250
On May 14, 2006, at 3:48 PM, fsshl plinlin wrote:
dear gcc [developers]:
I am try to install gcc in my MAC OS X 7.9, by down load from apple
s website's gcc-5250, but when I did ./configure
Yes that is correct we (GCC) don't support in 4.1.x building in the
source
directory and yes it
Robert Dewar [EMAIL PROTECTED] writes:
| Steven Bosscher wrote:
|
| Anyway, if this can be done in gigi, then let's make a plan and work
| on it. I'd really like to see MAPPED_LOCATION become the default, and
| Ada is basically the major blocker right now, so we need to agree on
| something
On 5/15/06, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
On Mon, May 15, 2006 at 12:09:00AM +0800, Rémy Saissy wrote:
To manage the manipulation of the register class, I added entries in
the i386.md file.
;; get a value from a segment register.
(define_insn store_seg
[(set
Gabriel Dos Reis wrote:
You mean we should not have taken Ada maintainers' earlier statements
seriously?
No, that's not the case, that discussion as far as I know was
about changing the GNAT front end to adapt to this scheme.
-- Gaby
Robert Dewar wrote:
Right, so it seems quite appropriate to have two representations for
source locations, one for the Ada tree, which is completely independent
of the tree IL, and one for the back end. That probably means that back
end messages will lose the generic instantiation
Per Bothner wrote:
Robert Dewar wrote:
Right, so it seems quite appropriate to have two representations for
source locations, one for the Ada tree, which is completely independent
of the tree IL, and one for the back end. That probably means that back
end messages will lose the generic
Joe Buck wrote:
It would seem that C++ templates would have the same issues as Ada
generic instantiation, right?
I would certainly think so. For the Ada front end we need to be able
to encode a complete nest of generic instantiations using a single
32-bit location indicator. I just don't know
Bootstrapping GCC fails with MinGW with the following error:
make[2]: *** No rule to make target `driver-i386.o', needed by `xgcc.exe'. Stop
.
This is the same bug as in pr27596, but apparently it needs to be reported and
fixed on target by target basis.
--
Summary: [4.2
--- Comment #1 from rridge at csclub dot uwaterloo dot ca 2006-05-14 06:45
---
Created an attachment (id=11458)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11458action=view)
Suggested patch for fixing the bug on all targets
This patch also hardens config.host against similar
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-14 09:00
---
Any progress on this one? It's blocking a few widely-used Fortran codes from
compiling (and being used and benchmarked) with mainline gfortran.
--
fxcoudert at gcc dot gnu dot org changed:
What
Bootstrap failed for me with a recent cygwin.
The error message is
gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/trunk/gcc
-I../../../gcc/trunk/gcc/.
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-05-14 09:42 ---
Created an attachment (id=11459)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11459action=view)
output of configure; build; gcc -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27600
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-14 09:43 ---
Created an attachment (id=11460)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11460action=view)
config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27600
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-14 09:44 ---
Created an attachment (id=11461)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11461action=view)
config.status in main directory
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27600
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-14 09:44 ---
*** This bug has been marked as a duplicate of 27596 ***
*** This bug has been marked as a duplicate of 27596 ***
*** This bug has been marked as a duplicate of 27596 ***
--
pinskia at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-14 09:44 ---
*** Bug 27600 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-14 10:42 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from aldot at gcc dot gnu dot org 2006-05-14 10:49 ---
Subject: Bug 27501
Author: aldot
Date: Sun May 14 10:48:49 2006
New Revision: 113758
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113758
Log:
2006-05-14 Bernhard Fischer [EMAIL PROTECTED]
PR 27501
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-14 10:51 ---
works for me on i686-pc-linux-gnu
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from bo dot berggren at glocalnet dot net 2006-05-14 11:13
---
Subject: Re: Transfer of character to integer array and
vice versa still doesn't work
paulthomas2 at wanadoo dot fr skrev:
--- Comment #15 from paulthomas2 at wanadoo dot fr 2006-05-13 20:00
The C++ file:
struct bar {
static int foo;
};
int a = __builtin_offsetof(bar, foo);
The error:
g++ -c foo.cc
foo.cc:5: internal compiler error: in fold_offsetof_1, at c-common.c:5998
GCC snapshot version:
g++ (GCC) 4.1.1 20060512 (prerelease)
--
Summary: ICE (in
--- Comment #17 from pault at gcc dot gnu dot org 2006-05-14 12:08 ---
Thanks - I will now turn to PR27449.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
--- Comment #2 from pault at gcc dot gnu dot org 2006-05-14 12:12 ---
(In reply to comment #1)
I am sure that this is the same as PR27155, which I undertook to fix.
I don't quite know what made me so sure but would be grateful if you would try
out the patch for pr27155. I don't
--- Comment #1 from pault at gcc dot gnu dot org 2006-05-14 12:36 ---
At the risk of gettin my head bitten off again, I think that this ICE really
is unwarranted. I can write fortran that produces every other expression type,
therby triggering the ICE. It might be that internal
--- Comment #2 from pault at gcc dot gnu dot org 2006-05-14 12:37 ---
Created an attachment (id=11462)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11462action=view)
Patch for this bug, mentioned in comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27584
--- Comment #5 from berndtrog at yahoo dot com 2006-05-14 12:39 ---
- r19 is modified, but not saved
Can you please give the exact command line you used to compile bug.i into
bug.o?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27593
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-05-14 13:43 ---
Subject: Re: Transfer of character to integer array and
vice versa still doesn't work
bo,
Ah, thank goodness for that. I thought that I was going out of my mind!
For you purposes, rather than svn, have you
The mozilla source is there,
http://www.mozilla.org/projects/bonecho/releases/2.0a2.html
My gcc-4.2.0 snapshot works fine with linux-kernel-2.6.17-rc4 and
Nvidia-installer.
...
nsCSSPropList.h:318: warning: (perhaps the âoffsetofâ macro was used
incorrectly)
nsCSSPropList.h:319: warning:
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sayle at gcc dot gnu dot org
|dot org
--- Comment #9 from steven at gcc dot gnu dot org 2006-05-14 14:23 ---
Please take bugs if you post patches for them, it makes it easier to search for
bugs that nobody is looking at.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2006-05-14 14:25 ---
Seb, wrong code regression in your code. Are you working on this??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
--- Comment #18 from apl at alum dot mit dot edu 2006-05-14 14:40 ---
I don't understand why this was changed by sayle to known to work on 4.1.0,
when at least ONE of the test cases (b.cxx) demonstrates the failure on 4.1.0
(for some reason bugzilla won't let me commit the above
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-14 14:49 ---
(In reply to comment #4)
Created an attachment (id=11146)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11146action=view) [edit]
first step
with this patch scev returns (int) (char) {0,+,1} but then
--- Comment #14 from sayle at gcc dot gnu dot org 2006-05-14 15:48 ---
Subject: Bug 22563
Author: sayle
Date: Sun May 14 15:48:11 2006
New Revision: 113762
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113762
Log:
PR rtl-optimization/22563
* expmed.c
--- Comment #7 from kazu at gcc dot gnu dot org 2006-05-14 16:07 ---
Subject: Bug 27538
Author: kazu
Date: Sun May 14 16:07:12 2006
New Revision: 113763
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113763
Log:
PR rtl-optimization/27538
* combine.c
Compile the attached program with:
gcc -O0 wrong-code-tree-vrp.cc
gcc -O2 wrong-code-tree-vrp.cc
gcc -O2 -fno-tree-vrp wrong-code-tree-vrp.cc
with gcc 4.1.0, native i686-pc-linux-gnu.
The -O0 and -O2 -fno-tree-vrp versions produce the correct output: g1[3] ==
100, g1[4] == 100. The -O2
--- Comment #1 from mec at google dot com 2006-05-14 16:55 ---
Created an attachment (id=11463)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11463action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27603
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #5 from s_j_newbury at yahoo dot co dot uk 2006-05-14 17:15
---
(In reply to comment #4)
I tried the gcc 4.1.1 snapshot 20060421. The bug still there. The assembly
code
producted with -Os option is the same as gcc 4.1.0.
Have you got anywhere with this? I wonder if
--- Comment #19 from sayle at gcc dot gnu dot org 2006-05-14 17:20 ---
Subject: Bug 26729
Author: sayle
Date: Sun May 14 17:20:01 2006
New Revision: 113764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113764
Log:
PR middle-end/26729
* gcc.dg/pr26729-1.c: New
--- Comment #20 from roger at eyesopen dot com 2006-05-14 17:39 ---
Hi APL,
Re: comment #18. It was actually stevenb that changed the known to work
line,
and assigned this PR to me, after I'd committed a fix to the gcc-4_1-branch.
See
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-14 17:44 ---
Confirmed. Reduced testcase:
void abort(void);
int g1[6] = { 0, 0, 0, 0, 0, 0 };
int g4 = 0;
void Foo(void)
{
int j;
for (j = 0; j 6; j++) {
if (j == 3 || j == 4)
g1[j] = 100;
g4 += 1000 * (6
Executing on host: /home/dave/gcc-4.2/objdir/gcc/xgcc
-B/home/dave/gcc-4.2/objdi
r/gcc/ /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die2.c
-
O0 -gdwarf-2 -dA -fno-show-column -S -o dwarf-die2.s(timeout = 300)
PASS: gcc.dg/debug/dwarf2/dwarf-die2.c (test for excess errors)
--- Comment #1 from danglin at gcc dot gnu dot org 2006-05-14 17:48 ---
Created an attachment (id=11465)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11465action=view)
Assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27607
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-14
17:54 ---
Subject: Re: New: FAIL: gcc.dg/debug/dwarf2/dwarf-die2.c scan-assembler-not
CIE Version
r/gcc/ /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die2.c
-
O0 -gdwarf-2 -dA
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-14 17:56 ---
We fold (j == 3 || j == 4) to (unsigned)j - 3 = 1, which VRP considers to be
always false.
void exit (int);
void abort (void);
int a;
int main()
{
int j;
for (j = 0; j 6; j++)
{
if ((unsigned)j - 3 = 1)
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-14 18:00 ---
(set_scalar_evolution
(scalar = j_3)
(scalar_evolution = {0, +, 1}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {0, +, 1}_1)
(res = {0, +, 1}_1))
Found new range for j_3: [0, 0]
huh!? (this is
Executing on host: /home/dave/gcc-4.2/objdir/gcc/xgcc
-B/home/dave/gcc-4.2/objdi
r/gcc/ /home/dave/gcc-4.2/gcc/gcc/testsuite/gcc.dg/torture/nested-fn-1.c -O0
-g0 -fno-show-column -S -o nested-fn-1.s(timeout = 300)
PASS: gcc.dg/torture/nested-fn-1.c -O0 (test for excess errors)
FAIL:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-14 18:38 ---
*** This bug has been marked as a duplicate of 27273 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-14 18:38 ---
*** Bug 27602 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-14 18:49 ---
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00531.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Known to work|2.95.3 |2.95.3 4.2.0
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-14 19:05 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-05-14 19:10 ---
We aren't marking smt usage for updating in forwprop, but we need to, because
forwprop is propagating and address and destroying the smt info.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27373
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-14 19:56 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from danglin at gcc dot gnu dot org 2006-05-14 20:11 ---
Created an attachment (id=11467)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11467action=view)
Assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27611
Executing on host: /home/dave/gcc-4.2/objdir/gcc/testsuite/g++/../../g++
-B/home
/dave/gcc-4.2/objdir/gcc/testsuite/g++/../../
/home/dave/gcc-4.2/gcc/gcc/testsui
te/g++.dg/other/unused1.C -nostdinc++
-I/home/dave/gcc-4.2/objdir/hppa-linux/li
bstdc++-v3/include/hppa-linux
--- Comment #2 from danglin at gcc dot gnu dot org 2006-05-14 20:18 ---
This appears to have been introduced between 113549M and 113593M.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27611
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-14 20:24 ---
This is just a testsuite issue:
.stringzclass2
.stringzprinter
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Executing on host: /home/dave/gcc-4.2/objdir/gcc/xgcc
-B/home/dave/gcc-4.2/objdi
r/gcc/ /home/dave/gcc-4.2/gcc/libgomp/testsuite/libgomp.c/critical-1.c
-B/home/
dave/gcc-4.2/objdir/hppa-linux/./libgomp/
-I/home/dave/gcc-4.2/objdir/hppa-linux
/./libgomp
--- Comment #3 from danglin at gcc dot gnu dot org 2006-05-14 22:12 ---
I can't duplicate the shatest failure using gcc 4.1.0 and openssl-0.9.8b.
The test results are clean and identical to those for 3.4.5 on both
hppa64-hp-hpux11.11 and hppa2.0w-hp-hpux11.11. Given that the report
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-05-14 22:26
---
Where is the patch referenced in Comment #3?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from mmitchel at gcc dot gnu dot org 2006-05-14 22:28
---
I'm sorry to hear things have gotten worse for Ada, but I'm none-the-less
downgrading this to P5, as there is no longer any evidence this affects our
primary languages. (I've not fully understood the discussion
--- Comment #3 from ingo dot josopait at gmx dot de 2006-05-14 22:29
---
It fails on i686-pc-linux-gnu if I replace
string arg = something;
by
string arg = s;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
--- Comment #15 from mmitchel at gcc dot gnu dot org 2006-05-14 22:29
---
P5: Ada is not release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27270
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27315
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27329
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27339
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27371
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-05-14 22:32
---
P5: Objective-C is not release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27385
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27447
1 - 100 of 125 matches
Mail list logo
