The error makes perfect sense. __pthread_mutex has only one
assignment operator for it (implicitly generated by the compiler):
__pthread_mutex operator=(const __pthread_mutex).
When you try to pass a volatile __pthread_mutex (named as
pthread_mutex_t), the compiler can't pass it to the
--- Kean Johnston [EMAIL PROTECTED] wrote:
System V Release 5 (UnixWare / OpenServer 6).
Your system is NOT supported by GCC, please read
http://www.fsf.org/licensing/sco/
___
How much free photo storage do you get?
--- Kean Johnston wrote:
The GCC team has been urged to drop support for
SCO
Unix from GCC, as a protest against SCO's
irresponsible
aggression against free software and GNU/Linux.
We have decided to take no action at this time,
as we
no longer believe that SCO is a serious threat.
Such an example can't be compiled:
#include stdio.h
void x()
{
printf(__FUNCTION__ \n);
}
$ gcc printf.c -o fprintf
printf.c: In function `x':
printf.c:5: error: syntax error before string constant
Then, the problem is not printf-specific and is not depend of
stdio.h. The next example
On 7/25/05, Denis Zaitsev [EMAIL PROTECTED] wrote:
Such an example can't be compiled:
#include stdio.h
void x()
{
printf(__FUNCTION__ \n);
}
$ gcc printf.c -o fprintf
printf.c: In function `x':
printf.c:5: error: syntax error before string constant
__FUNCTION__ expands to a
Richard Guenther wrote:
Btw, this list is for the development _of_ gcc, not with gcc.
Use gcc-help for that.
By the way, since we have to point out that *so often*, maybe there is
something wrong on our part: I wonder whether changing the names of
those lists would help!?!? I don't know:
On Mon, Jul 25, 2005 at 10:51:23AM +0200, Richard Guenther wrote:
On 7/25/05, Denis Zaitsev [EMAIL PROTECTED] wrote:
Such an example can't be compiled:
#include stdio.h
void x()
{
printf(__FUNCTION__ \n);
}
$ gcc printf.c -o fprintf
printf.c: In function `x':
Paolo Carlini wrote:
By the way, since we have to point out that *so often*, maybe there is
something wrong on our part: I wonder whether changing the names of
those lists would help!?!? I don't know: gcc-development, gcc-users, ...
one problem is that people often say something like:
Btw,
Hello
I have taken the opensoruce from
http://www-personal.engin.umich.edu/~wagnerr/ConfigFile.html for reading
configuration file. It perfectly works fine with gcc 3.2.3 and it fail
to compile with gcc 3.4.3 on RHEL 4
I am getting following error
g++ -Wno-trigraphs -Wno-unused
On Fri, 22 Jul 2005, Mark Mitchell wrote:
We have been in Stage 3 for a little while now. I'm sure a few more
patches that were proposed in Stage 2 will find their way into 4.1,
but we're approximately feature-complete at this point.
I just committed the following update for our main page.
On Mon, Jul 25, 2005 at 11:35:27AM +0200, Paolo Bonzini wrote:
Ok, but such a code used to be compiled succesively with gcc for
years. Then, some change _in_ gcc has occured. That is why I've
posted to here.
Yes, it was deprecated in 3.1 (released three years ago) and removed in
3.3
Coming back to this topic.
Nobody has answered to one of my questions: if the mingw/cygwin
maintainers can't approve such a patch, who can?
FX
On Monday, July 25, 2005, at 01:58 AM, Paolo Carlini wrote:
By the way, since we have to point out that *so often*, maybe there is
something wrong on our part: I wonder whether changing the names of
those lists would help!?!? I don't know: gcc-development, gcc-users,
...
No, randomly changing
Mike Stump [EMAIL PROTECTED] writes:
| On Monday, July 25, 2005, at 01:58 AM, Paolo Carlini wrote:
| By the way, since we have to point out that *so often*, maybe there is
| something wrong on our part: I wonder whether changing the names of
| those lists would help!?!? I don't know:
Gabriel Dos Reis wrote:
After
all, people doing development *with* GCC might also think tha
gcc-development is the proper place ot sned mails instad of gcc-help
:-)
Yes ;-) On the other hand, some people may believe that gcc-help
On Mon, 2005-07-25 at 11:41 +0200, Gabriel Dos Reis wrote:
Hi,
The SC has agreed me taking up the GCC-3.4.5 ball.
I'm planning for two releases from the GCC-3.4.x series this year:
(a) GCC-3.4.5 on September 30, and
(b) GCC-3.4.6 on December, 15.
The number of bugs
I have done quite a few experiments with this to
narrow down the problem. The performance numbers are
slower compared to *No Feedback optimization with just
-O3* Here are some of them. All the experiments were
done on a new build-area in order to eliminate effects
of old feedback files.
1. I
On Mon, 2005-07-25 at 14:01 +0400, Vladimir A. Merzliakov wrote:
Hi all,
Are there any open-source(or free) front-end which translates C++ to C?
I could find some commercial things - Comeau, ATT Cfront, etc., but
these have many limitations(especially, It's too difficult to get cfront
Daniel Berlin [EMAIL PROTECTED] writes:
| Fixed.
| It was counting a slightly higher number of bugs than it actually sent
| (it does some of the query filtering client-side in the script)
Thanks.
-- Gaby
The full list of bugs is produced below. Maintainers, please look
into any of those and see which ones you can fix or give guidance for
fixes in ways that are suitable for a stable branch.
Do I still have time / opportunity to refresh the SCO ports?
If Sept 30 is the deadline I will definately
Dan == Daniel Berlin [EMAIL PROTECTED] writes:
Dan You can't take the output of the gcc llvm frontend on one platform, and
Dan run it on another, like cfront could.
Dan The sizes, alignments, etc, of things will be different, where people
Dan use sizeof(x), etc, in their code.
Dan Unless you
Hello All
I've built gcc-3.4.4 as a linux to Solaris (on SPARC) cross compiler. If I
change my path to include my new compiler executables, I can compile and
link a simple hello world program.
However, I want to be able to specify the target architecture and compiler
version number with gcc's
Gabriel Dos Reis wrote:
Kean Johnston [EMAIL PROTECTED] writes:
| The full list of bugs is produced below. Maintainers, please look
| into any of those and see which ones you can fix or give guidance for
| fixes in ways that are suitable for a stable branch.
| Do I still have time /
Kean Johnston [EMAIL PROTECTED] writes:
| Here is how Mark and I have agreed on those sort of things. If such a
| patch is accepted in 3.4.x but not in 4.0.x, then we've introduced a
| regression in 4.0.x. So, the way we deal with it is that, the patch
| is first applied to
| 4.0.x, then to
LLVM ( http://llvm.cs.uiuc.edu/ ) ?
It use modified gcc 3.4 as C/C++ frontend and it can emits portable C
code.
Depends what you mean by portable.
You can't take the output of the gcc llvm frontend on one platform, and
run it on another, like cfront could.
emits portable C code just copied
Maybe one solution would be to patch pex-win32 for mingw so that it
could understand '#!' style shell scripts? That would at least
allow bootstrapping.
That would be wonderful, and that's exactly the right place to put it
too. I'm assuming I can persuade one of you to do that? ;-)
I'm
On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote:
Maybe one solution would be to patch pex-win32 for mingw so that it
could understand '#!' style shell scripts? That would at least allow
bootstrapping.
That would be wonderful, and that's exactly the right place to put it
too. I'm
On Tuesday 19 July 2005 10:34, Sean PH wrote:
Hello,
I'm currently working on implementing a tool chain for a 'pet
language' of mine called O (for Obscure, since my preferred name was
taken). You can see the [unfinished] language specification here:
On Jul 23, 2005, at 8:44 PM, Mark Mitchell wrote:
Actually, I think the best fix would be just not to set
DECL_IGNORED_P in the first place, and let the debug-generators
sort it out.
OK. I'll see how dbxout reacts.
-
Devang
On 07/25/05 05:15 PM, Giovanni Bajo sat at the `puter and typed:
Louis LeBlanc [EMAIL PROTECTED] wrote:
The problem is I'm getting core dumps (SEGV) that appears to come from
this code when I know it shouldn't be in the execution path. The code
in question is switched on by a command
From: Christopher Faylor
Sent: Tuesday, July 26, 2005 9:33 AM
On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote:
Maybe one solution would be to patch pex-win32 for mingw so that it
could understand '#!' style shell scripts? That would at
least allow
bootstrapping.
That
Louis LeBlanc [EMAIL PROTECTED] wrote:
I added the -fstack-check switch to my makefile and recompiled with
various optimizations. I was pretty surprised at the file sizes that
showed up:
No Optimization:
-rwxr-xr-x 1 leblanc daemon 1128660 Jul 25 16:25 myprocess*
Optimized with -O2
Louis LeBlanc wrote:
I would have expected much different results. Shouldn't the file
sizes be smaller (at least a little) with the -O3 switch? Maybe
there's a loop unrolled to make it faster, resulting in a larger
codebase?
you generally expect -O3 files to be larger. inlining does not
O Jul 25, 2005, at 3:50 PM, Robert Dewar wrote:
The unoptimized version completed a 401,900 transaction test with no
problem. All day, I've been playing with different things,
there are many bugs, most notably uninitialed vars, that show
up only when you turn on optimization.
Also
We are seeing tons of regressions (9 of 2377 for fink, over 100 or so
out of 8000 was it for internal projects) in the build state of
projects with code like:
class bar {
friend class foo;
void baz(foo *x) {}
};
from 4.0.0 in 4.0.1. This is really unfortunate. What we
Mike Stump [EMAIL PROTECTED] writes:
| We are seeing tons of regressions (9 of 2377 for fink, over 100 or so
| out of 8000 was it for internal projects) in the build state of
| projects with code like:
|
| class bar {
|friend class foo;
|void baz(foo *x) {}
| };
|
| from
With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code
like
double d = atof(foo);
int i = d;
callatof
fstpl -8(%ebp)
movsd -8(%ebp), %xmm0
cvttsd2si %xmm0, %eax
(This is Linux, Darwin is similar.) I think the difficulty is
Which leads me to the old saying that friends don't let friends use friends.
On 26 Jul 2005 03:07:49 +0200, Gabriel Dos Reis
[EMAIL PROTECTED] wrote:
Mike Stump [EMAIL PROTECTED] writes:
| We are seeing tons of regressions (9 of 2377 for fink, over 100 or so
| out of 8000 was it for internal
On 23/07/2005, at 6:12 PM, Paul Schlie wrote:
Geoffrey Keating wrote:
Mirco Lorenzon wrote:
.., are comparisons in the following program legal code?
No.
...
void *a, *b;
...
if (a b)
Because 'a' and 'b' are not part of the same array,
the behaviour is undefined.
Although I
Gabriel Dos Reis wrote:
The full list of bugs is produced below. Maintainers, please look
into any of those and see which ones you can fix or give guidance for
fixes in ways that are suitable for a stable branch.
This m68k patch:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00783.html
--- Additional Comments From relf at os2 dot ru 2005-07-25 07:34 ---
(In reply to comment #1)
This is not a bug. You are overflowing the stack.
Should it be more intelligent error message like Stack overflow ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23054
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25
07:39 ---
Subject: Bug 20303
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-25 07:38:58
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From chris at bubblescope dot net 2005-07-25 07:46
---
Actually according to the TR1 spec (n1745 at least), there should be a
non-const version which returns an
iterator, and a const version which returns a const_iterator.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25
07:51 ---
Subject: Bug 20063
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-25 07:51:12
Modified files:
gcc/fortran: ChangeLog data.c
--- Additional Comments From chris at bubblescope dot net 2005-07-25 07:52
---
Apologises, I misread the problem. Ignore my previous comment. Yes, I agree
that find_node (which is a
private function) should be const. An identical problem exists calling
equal_range
--
--- Additional Comments From pcarlini at suse dot de 2005-07-25 08:39
---
Ok, thanks.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25
08:47 ---
Subject: Bug 20063
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-25 08:47:01
Modified files:
gcc/fortran:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25
08:47 ---
Subject: Bug 22515
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-25 08:47:34
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/src:
--- Additional Comments From pcarlini at suse dot de 2005-07-25 08:50
---
Fixed for 4.1.0.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From chris at bubblescope dot net 2005-07-25 09:03
---
I'm not personally 100% sure that this should be fixed, I've used partial_sum
where I've assumed this
behaviour, and adding the things in the output type would have broken...
I've attached the work-around
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-25 09:51 ---
Subject: Re: partial_sum is too constrained
chris at bubblescope dot net [EMAIL PROTECTED] writes:
| I'm not personally 100% sure that this should be fixed, I've used
| partial_sum where I've
--- Additional Comments From 27roses at daum dot net 2005-07-25 10:23
---
Here is details of the build procedure.
linux-2.4.20-31.9
AMD Athlon XP 2500+
[EMAIL PROTECTED] root]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure
--- Additional Comments From 27roses at daum dot net 2005-07-25 10:53
---
There is some miss spelling in my last connents.
NOT 'gcc-4.0.1-noF' BUT 'gcc-4.0.1-F90'
SORRY!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22608
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
11:47 ---
Smaller testcase:
==
struct A
{
operator A*();
};
void foo(int A::* p)
{
A() -* p;
}
==
--
What|Removed |Added
When a function or variable has its assembler name given through an
__asm__, the __attribute__((__visibility__(default))) present on the
same declaration is ignored.
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /freebsd/gnu/linuxarchive/gcc-4.0.1/configure
--- Additional Comments From olh at suse dot de 2005-07-25 11:53 ---
Is there a workaround (some --foo option for gcc/ld) for these link errors?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17828
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
11:57 ---
Shorter testcase:
===
struct A
{
~A();
};
void foo()
{
A a = ({ A b; b; });
}
===
--
What|Removed |Added
When I compile my application with the actual snapshot of gcc41 I get an ICE
when I enable autovectorisation and -Woverloaded-virtual.
last working snapshot is: gcc-4.1-20050625
first failing snapshot is: gcc-4.1-20050702
Michael Cieslinski
g++41h -O3 -ftree-vectorize -Woverloaded-virtual
--- Additional Comments From micis at gmx dot de 2005-07-25 12:22 ---
Created an attachment (id=9359)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9359action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23059
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25
12:36 ---
(In reply to comment #2)
Should it be more intelligent error message like Stack overflow ?
That is still not a GCC bug, report this enhancement to the OS you are using
since that is where the
message is
--
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23058
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25
12:53 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
12:58 ---
Here's a similar example with valid code:
struct A
{
templateint struct B
{
void foo(const struct C);
};
};
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:11 ---
Here's an example that only contains one error:
==
struct A;
struct B
{
virtual A* foo();
};
namespace N
{
struct A : B
{
virtual A*
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:22 ---
*** This bug has been marked as a duplicate of 21592 ***
--
What|Removed |Added
--
Bug 21352 depends on bug 20549, which changed state.
Bug 20549 Summary: [3.4/4.0/4.1 Regression] ICE in
resolve_overloaded_unification on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20549
What|Old Value |New Value
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:22 ---
*** Bug 20549 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:26 ---
Just for completeness, a slightly reduced version of the testcase from
PR 20549:
===
templatetypename T void unique(T,T);
struct A
{
int begin();
};
templateint
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:40 ---
The problem now also appears on the 4.0 branch.
--
What|Removed |Added
CC|
--
What|Removed |Added
Target Milestone|4.1.0 |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22405
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:54 ---
Here's an example with valid code:
=
templateint struct A
{
A(void(A::*)() = A::operator+);
void operator+ ();
};
=
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:56 ---
Btw, apart from the missing semicolon at the end of the class,
the original example was valid, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22454
--- Additional Comments From squell at alumina dot nl 2005-07-25 14:01
---
(In reply to comment #13)
I've attached the work-around I personally use to this kind of problem, which
is
wrapping the iterator in another iterator which changes the value_type.
I tried this approach as
--- Additional Comments From timo dot lindfors at iki dot fi 2005-07-25
14:02 ---
Actual results have changed between builds 2005-07-22T100134+ and
2005-07-23T221620+. Now the output is:
java.lang.NullPointerException
at gnu.java.awt.peer.gtk.GdkFontMetrics.init
--- Additional Comments From squell at alumina dot nl 2005-07-25 14:04
---
Mentally fix the typographical errors in that last post. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
--- Additional Comments From roman at kennke dot org 2005-07-25 14:17
---
Whoops, this was an accident. I don't really know why the Gtk peers can't cope
with that. I checked in a fix for that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22567
--- Additional Comments From bangerth at dealii dot org 2005-07-25 14:25
---
As for the initial testcase (Andrew's testcase in comment #1),
- gcc3.3 rejects it with and without the template declaration
- icc rejects it with and without the template declaration
- gcc3.4 (and
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25
14:26 ---
Subject: Bug 22624
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-25 14:26:37
Modified files:
gcc/testsuite : ChangeLog
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-25
14:26 ---
Fixed (again). Hopefully.
--
What|Removed |Added
Status|NEW
--
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ICE: verify_ssa failed with |[4.1 Regression] ICE:
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
14:37 ---
If one removes the class instance helper, the code compiles.
This is an accepts-invalid bug (which also appeared in gcc 3.4.0).
--
What|Removed |Added
--- Additional Comments From timo dot lindfors at iki dot fi 2005-07-25
14:45 ---
The testcase works flawlessly now, thanks!
--
What|Removed |Added
--- Additional Comments From sje at cup dot hp dot com 2005-07-25 15:04
---
I tested the proposed patch on IA64 HP-UX and Linux and it did fix the EH
problems I saw without the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22284
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25
15:14 ---
Subject: Bug 22337
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-25 15:14:21
Modified files:
gcc: ChangeLog ggc-zone.c
Log message:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25
15:14 ---
Fixed, I applied the fix.
--
What|Removed |Added
Status|NEW
--- Additional Comments From bangerth at dealii dot org 2005-07-25 15:21
---
This basically boils down to this question:
-
template class struct S { typedef int type; };
template class T
int foo(T, typename ST::type * ret);
int j = foo(1, 0);
The %VAL construct is used for passing arguments by value, rather than the
usual by reference or descriptor. It is vital for interoperability with other
languages such as C.
This feature is available in g77:
http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/_0025VAL_0028_0029.html#_0025VAL_0028_0029
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-25 15:28 ---
Subject: Re: overload resolution does not find templated function
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| This basically boils down to this question:
| -
|
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-25
15:28 ---
The example from comment #3 now optimizes to identical inner loops:
;; Function foo (foo)
foo ()
{
int i.54;
int lsm_tmp.32;
int lsm_tmp.31;
int i;
int D.1628;
int D.1627;
int
--
Bug 20121 depends on bug 13761, which changed state.
Bug 13761 Summary: [tree-ssa] component refs to the same struct should not alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
What|Old Value |New Value
--
Bug 16538 depends on bug 13761, which changed state.
Bug 13761 Summary: [tree-ssa] component refs to the same struct should not alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
What|Old Value |New Value
--
Bug 20121 depends on bug 13761, which changed state.
Bug 13761 Summary: [tree-ssa] component refs to the same struct should not alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
What|Old Value |New Value
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-25
15:31 ---
Oddly, the test case from comment #1 is not fixed. Sorry for the
inconvenience.
--
What|Removed |Added
--
Bug 16538 depends on bug 13761, which changed state.
Bug 13761 Summary: [tree-ssa] component refs to the same struct should not alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25
15:34 ---
Confirmed.
--
What|Removed |Added
OtherBugsDependingO||19292
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-25
15:40 ---
Yes, it won't be fixed till 4.2, or the aliasing branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25
15:50 ---
Hmm, Jim posted a patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00377.html but
never applied it.
--
What|Removed |Added
--
What|Removed |Added
Known to work||4.1.0
Summary|[4.0/4.1 Regression] ICE|[4.0 Regression] ICE while
|while
In http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01345.html there are
treelang test suite failures like this:
Test Run By chj on Mon Jul 25 03:19:50 2005
Native configuration is sparc64-unknown-linux-gnu
=== treelang tests ===
Schedule of variations:
unix/-m64
unix
The %VAL construct is used for passing arguments by value, rather than the
usual by reference or descriptor. It is vital for interoperability with other
languages such as C.
This feature is available in g77:
http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/_0025VAL_0028_0029.html#_0025VAL_0028_0029
1 - 100 of 175 matches
Mail list logo
