Hello,
I appreciate it if someone could explain what is the difference between
gcc.c-torture library and gcc.dg library under the testsuite directory.
Thanks,
Revital
On Thu, 2006-10-05 at 09:27 +0200, Revital1 Eres wrote:
Hello,
I appreciate it if someone could explain what is the difference between
gcc.c-torture library and gcc.dg library under the testsuite directory.
http://gcc.gnu.org/wiki/HowToPrepareATestcase
Should explain it.
If it does not, here
Hi,
I need to get the C/C++ Preprocessor tokens for
perform some operations on them.
How can I write a program interface the Preprocessor
and get the token that it analyze?
Tnaks for help.
Matteo.
__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo!
Hi Matteo,
Do you want the list of tokens present in the source file which is
being compiled ?
-
Regards,
Raghavendra MB.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Matteo Fioroni
Sent: Thursday, October 05,
Zdenek Dvorak [EMAIL PROTECTED] wrote on 28/09/2006
15:04:07:
I have commited the documentation, including the parts from Daniel and
Sebastian (but not yours) now.
Zdenek
I've committed my part.
Ira
Fu, Chao-Ying [EMAIL PROTECTED] writes:
I think there is a bug in mips_pass_by_reference when the mips abi
is EABI to pass TImode parameters.
Good catch.
Does someone know how to pass TImode parameters in EABI? Thanks!
I imagine this case wasn't specifically considered. The EABI calls
Fu, Chao-Ying wrote:
Hello,
I think there is a bug in mips_pass_by_reference when the mips abi
is EABI to pass TImode parameters.
The following code is from the mainline GCC mips.c.
-
mips_pass_by_reference (CUMULATIVE_ARGS *cum ATTRIBUTE_UNUSED,
Matteo Fioroni wrote:
Thanks for your help, I saw the gcc -E output: but it
don't match my needs.
I've to interface the Preprocessor to get the tokens
(keyword, preprocessor directives, grammar, ecc..) it
analyzes on which I've to permorm some operations.
The preprocessor doesn't break C into
Michael Eager wrote:
Matteo Fioroni wrote:
Thanks for your help, I saw the gcc -E output: but it
don't match my needs.
I've to interface the Preprocessor to get the tokens
(keyword, preprocessor directives, grammar, ecc..) it
analyzes on which I've to permorm some operations.
The preprocessor
Are the failures in the new setjmp-3 and
setjmp-4 testcases on Darwin just another
manifestation of PR10901?
Jack
Mark Mitchell [EMAIL PROTECTED] wrote on 29/09/2006 01:55:24:
Razya Ladelsky wrote:
Except for new optimizations, IPCP (currently on mainline) should also
be
transformed to SSA.
IPCP in SSA code exists on IPA branch, and will be submitted to GCC4.3
after IPA branch
is committed
Dear Sirs,
I've successfully compiled a complete application into an executable using
g++. I'm trying to develop a class library and compile into library for use by
other programs. Can any one show me how? Thank you very much in advance.
C.-J. Mei
On Oct 5, 2006, at 11:55 AM, Changjiang Mei wrote:
I've successfully compiled a complete application into an
executable using g++. I'm trying to develop a class library and
compile into library for use by other programs. Can any one show me
how? Thank you very much in advance.
Please
Hi,
I'm trying to adjust an already existing target port of gcc-2.95.2 to
gcc-4.1.0 and I came to a point where I could use some help. Everything
seams fine until xgcc tries to compile libgcc2.c, then I get the following
error messages:
libgcc2.s: Assembler messages:
libgcc2.s:52: Error:
On Oct 5, 2006, at 1:56 PM, Andrija Radicevic wrote:
libgcc2.s:52: Error: unknown pseudo-op: `.lm_0'
.LM_0
.LM_0:
I have found out that the correct labels are written out by the
hook TARGET_ASM_INTERNAL_LABEL and the faulty ones are the result
of the output from the macro
Does your generate look substantially different from:
#undef ASM_GENERATE_INTERNAL_LABEL
#define ASM_GENERATE_INTERNAL_LABEL(LABEL,PREFIX,NUM) \
sprintf (LABEL, *%s%ld, PREFIX, (long)(NUM))
Hint, I put it outputs a label, which is wrong (or calls something
that does).
no, it's simple
Snapshot gcc-4.0-20061005 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20061005/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi all,
I have been trying to place some data into a named section of a .o
file. I can do it currently by hooking into various of the RTL to
assembly routines and emitting the asm code directly, however I am now
trying to do it from within the C++ front end by inserting a VAR_DECL
node and
Michael Eager wrote:
Matteo Fioroni wrote:
Thanks for your help, I saw the gcc -E output: but it
don't match my needs.
I've to interface the Preprocessor to get the tokens
(keyword, preprocessor directives, grammar, ecc..) it
analyzes on which I've to permorm some operations.
The preprocessor
--- Comment #8 from uros at kss-loka dot si 2006-10-05 07:08 ---
try -O2 -msse2, you get:
_Z8todoubledd:
subl$12, %esp
fldl24(%esp)
faddl 16(%esp)
fstpl (%esp)
movsd (%esp), %xmm0
addl$12, %esp
cvttsd2si
--- Comment #4 from federico dot carminati at cern dot ch 2006-10-05 07:44
---
Subject: Re: Ambiguous warning with -Weffc++
Thanks for your answer. However, if I just code in the following way
int f(a lhc) {
if (lhs) return TRUE;
else if g() return TRUE;
--- Comment #6 from pault at gcc dot gnu dot org 2006-10-05 07:45 ---
(In reply to comment #5)
FX,
When the len in call sub(len) is resolved, it is never given its correct
return type, which leads to the ICE. I still don't understand why the
implicit
none is doing this on
--- Comment #2 from uros at kss-loka dot si 2006-10-05 07:51 ---
(In reply to comment #0)
The mode switching for floating point rounding that the i386 backend does
does not actually place mode switches, but rather the calculation of values
used for mode switches. Not only does that
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-05 08:05
---
(In reply to comment #6)
I am glad to see that you are pursuing that one. I nearly bust my head on it
my notes indicate that I had a fix that broke everything else; no details, so
not much help I'm afraid. I
--- Comment #5 from patchapp at dberlin dot org 2006-10-05 08:07 ---
Subject: Bug number PR27588
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-10/msg00234.html
--
When I bootstrap gcc with the commands given below I get a testsuite failure
in libstdc++-v3/testsuite/25_algorithms/rotate/1.cc
It might be a pch problem, since that ice does not occur if I compile the
testsuite file without using any library
Michael Cieslinski
Command to build and test gcc:
--- Comment #3 from roberto dot costa at st dot com 2006-10-05 08:15
---
I tested what happens if the first PHI-OPT pass is moved right before the first
VRP pass in gcc/passes.c
It looks like PHI-OPT should be run both before and after VRP and DOM.
The example reported shows that,
--- Comment #14 from carlos at codesourcery dot com 2006-10-05 08:33
---
GCC_EXEC_PREFIX does not control the search directories for header files. Could
you verify that your target actually compiles before applying the patches?
Both gcc and cpp need to be taught taught not to search
--- Comment #5 from markus dot schoepflin at comsoft dot de 2006-10-05
08:49 ---
(In reply to comment #3)
With the attached patch, at least the unmodified boehm-gc 6.7 tested
successfully.
I stumbled accross this bug when investigating why the boost thread library
tests started to
The function seekp(pos_type) fails on an empty stream,
even when the target position is the value returned
by tellp.
---
#include ostream
#include sstream
#include iostream
int
main()
{
std::ios::pos_type const
err =
--- Comment #1 from pcarlini at suse dot de 2006-10-05 09:28 ---
Ok, thanks for the report. The issue is the following: tellp() calls
pubseekoff, whereas seekp() calls pubseekpos. Since we are implementing the
resolution of DR 453, which allows pubseekoff to not fail when the stream is
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #15 from eweddington at cso dot atmel dot com 2006-10-05 12:49
---
(In reply to comment #14)
GCC_EXEC_PREFIX does not control the search directories for header files.
Could
you verify that your target actually compiles before applying the patches?
In the test that I
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
In this code:
typedef class
{
public:
void m();
} C;
void
C::m()
{
}
void
f()
{
C c;
c.m();
}
// { dg-final { scan-assembler (.globl|.global)\[ \t]+[_]+ZN1C1mEv } }
C is a typedef name which accroding to 7.1.3 is used to denote the unnamed
class. 3.5 ; 4, 3rd item, specifies that this
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 14:25 ---
I think
*** This bug has been marked as a duplicate of 7221 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 14:25 ---
*** Bug 29356 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-10-05 14:30 ---
As far as I can tell this has nothing to do with PCH.
It might be a pch problem, since that ice does not occur if I compile the
testsuite file without using any library
What do you mean by this?
--
pinskia at
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-05 14:33
---
Subject: Bug 28980
Author: pinskia
Date: Thu Oct 5 14:33:46 2006
New Revision: 117456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117456
Log:
2006-10-05 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-05 14:34
---
Fixed in 4.1 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from debian-gcc at lists dot debian dot org 2006-10-05
15:13 ---
are other patches than r111381 (trunk) required for a backport of
long-double-128
to the 4.1 branch?
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
--- Comment #41 from dje at gcc dot gnu dot org 2006-10-05 15:18 ---
Subject: Bug 27287
Author: dje
Date: Thu Oct 5 15:18:18 2006
New Revision: 117458
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117458
Log:
Backport from mainline
2006-09-11 Guenter Roeck
$rstr7-19b
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-05 15:40
---
This looks related to PR 26926.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-05 15:44 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #42 from pinskia at gcc dot gnu dot org 2006-10-05 15:47
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 15:48 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
the form %c0, as in
asm ( movl $42, %c0(%1) : : i(offsetof(...)), r(...) : memory );
is not documented.
--
Summary: inline asm %c0 template form not documented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: trivial
--- Comment #1 from avi at argo dot co dot il 2006-10-05 16:05 ---
Created an attachment (id=12384)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12384action=view)
proposed documentation patch
I don't have a coypright assignment, but most of this is copied verbatim from
the
--- Comment #41 from debian-gcc at lists dot debian dot org 2006-10-05
16:06 ---
the patch was applied in the redhat/gcc-4_1-branch, not in the gcc-4_1-branch.
either the target milestone should be changed or the bug reopened.
Matthias
--
debian-gcc at lists dot debian dot org
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-05 16:17 ---
Subject: Re: ICE using intrinsics as arguments
FX
That bug is fixed by my submitted patch about INTRINSICS
(http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html).
I'll review it tomorrow - I am going to give
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #5 from daney at gcc dot gnu dot org 2006-10-05 17:02 ---
Another idea:
In the SIGCHLD signal handler record the pid of the process that exited. Then
look it up in the pidToProcess map. If it belongs to the libgcj runtime, then
do waitpid(pid, ...) on it. Otherwise
The following snipped of code compiled with -Wall emits two times the same
warning :
#include stdio.h
#include stdint.h
#include stdlib.h
int main(void)
{
uint32_t foo = 42;
char bar[] = bla;
char *buffer = malloc(10);
snprintf(buffer, 10, %lu %s\n, foo, bar);
free(buffer);
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 17:07 ---
uint32_t is unsigned int on those targets and this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joseph at codesourcery dot com 2006-10-05 17:10 ---
Subject: Re: Warning issued two times with snprintf
On Thu, 5 Oct 2006, pinskia at gcc dot gnu dot org wrote:
uint32_t is unsigned int on those targets and this is not a bug.
Did you read the bug report? The
--- Comment #3 from pf dot hugues at gmail dot com 2006-10-05 17:11 ---
I don't contest the warning, but why is it printed 2 times ?!
--
pf dot hugues at gmail dot com changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 17:15 ---
(gdb) p debug_tree (function)
addr_expr 0xb7dd60a0
type pointer_type 0xb7dd3900
type function_type 0xb7dae180 type integer_type 0xb7d122a0 int
SI
size integer_cst 0xb7cff380
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-05 17:17 ---
(In reply to comment #2)
Did you read the bug report? The problem is that the warning is issued
twice when it should be issued once.
Woops, I am too tried
I'd guess that the issue that that the system header
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org
|dot org
--- Comment #4 from patchapp at dberlin dot org 2006-10-05 17:32 ---
Subject: Bug number PR fortran/28415
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-10/msg00258.html
--
--- Comment #9 from patchapp at dberlin dot org 2006-10-05 17:34 ---
Subject: Bug number PR19260
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-10/msg00255.html
--
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-05 17:54 ---
(In reply to comment #0)
1. Whether a certain minimum version of GMP/MPFR is required to avoid known
bugs, etc.
See my recent patch to toplevel configure.in. THe minimum required
versions should be gmp-4.1.x
I have been encountering the following problem for several weeks. I compile and
create few c++ shared libraries (can happen with just one, so it has nothing to
do with the number). I then attempt to link a program and I get the following
type of segv during the link step:
collect2: ld terminated
--- Comment #1 from jmbnyc at gmail dot com 2006-10-05 18:18 ---
Created an attachment (id=12385)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12385action=view)
gzip'd tar file with README that shows how to reproduce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 18:18 ---
*** This bug has been marked as a duplicate of 29244 ***
*** This bug has been marked as a duplicate of 29244 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:18 ---
*** Bug 29359 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29244
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:19 ---
Didn't I already tell you to post this to binutils?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
--- Comment #4 from jmbnyc at gmail dot com 2006-10-05 18:23 ---
(In reply to comment #3)
Didn't I already tell you to post this to binutils?
yes you did and I did what you asked. However, I now believe that the problem
is with the compiler. I also came up with a test case that
--- Comment #5 from jmbnyc at gmail dot com 2006-10-05 18:27 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
Look, I am not trying to be a jerk, but this new filing has a test
case associated with it (another thing that you asked for). In
addition, I took your
--- Comment #6 from jmbnyc at gmail dot com 2006-10-05 18:41 ---
This bug might be a duplicate as you suggest but (my fault for opening new
instead of updating original) it is not 'resolved'. On the original post you
said to report to binutils because you suggested the bug was not in
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-05 18:48 ---
If you disagree with that assertion then please tell me.
Yes I do disagree because GCC only produces a .s file which then binutils
assembles and links.
Then again you are using a GCC and binutils that were modified
--- Comment #8 from jmbnyc at gmail dot com 2006-10-05 18:48 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
One last comment. From the below, I think it is clear that the
compiler is the problem. If I compile with -g then I get the problem,
however if I
--- Comment #9 from jmbnyc at gmail dot com 2006-10-05 18:51 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
Fair enough. I did report it to them, but never heard back. Uli
Drepper is going to try to help me get to the right people. He has
also offered to look
--- Comment #25 from stsp at users dot sourceforge dot net 2006-10-05
19:29 ---
i(var) of course can't work with -fpic,
I tried it on an x86_64 today, and it seems to work.
If I use -m32, then it doesn't. Why?
it would only work at the expense
of text relocations, but those are not
According to 12.2 ; 5, in the following code:
int count;
class C
{
public:
int i;
C() : i(1) { ++count;}
C(const C c) : i(c.i) { ++count;}
~C() { --count;}
};
int
f ()
{
static const C c = C();
return c.i;
}
int
main ()
{
int i = f ();
return count i;
}
the temporary to which
I have some code which when compiled:
Using gcc 4.0.3(ubuntu 4.0.3-lubuntu5) I have no problems.
Using gcc version 4.1.0 (SUSE Linux) and -O2 or -O3, I have no problems.
HOWEVER, using no compile flags, the code seg faults.
Is it worth generating a small test case and test data file?
--
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-10-05 19:58
---
Fixed on mainline by Lee's patch for PR27667.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-10-05 20:31
---
The bug is actually only a 4.2 regression as it only affected mainline
(sorry for the incorrect info).
Yes, indeed affected and not affects: The bug has been fixed by Mark's
patch for PR 29105.
Since the
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-10-05 20:31
---
*** Bug 29021 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 20:36 ---
well a testcase is needed to reproduce the problem in the first place anyways
so yes a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 20:38 ---
*** This bug has been marked as a duplicate of 20416 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 20:38 ---
*** Bug 29360 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The new FC6 eclipse cdt generates a java.lang.NullPointerException everytime it
tries to save the .cdtproject project file. This occurs when changes are made
to a CDT project. For example, adding a new source folder causes the error.
I have isolated the problem to a stand-alone testcase which
--- Comment #1 from jjohnstn at redhat dot com 2006-10-05 20:48 ---
Created an attachment (id=12386)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12386action=view)
Testcase that exhibits problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #10 from drow at gcc dot gnu dot org 2006-10-05 20:49 ---
FYI, the testcase does not build with my system g++ 4.1.2; remove the static
from 'extern C static'. The result does not choke my system's binutils, i.e.
it links successfully.
If I use the provided .s file instead
--- Comment #11 from jmbnyc at gmail dot com 2006-10-05 20:57 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
Thanks for looking at it. Uli Drepper helped me to look at the asm and
conclude (just about one hour ago) that indeed the problem is with
as. It
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-10-05 21:00
---
Fixed on mainline by Lee's patch for PR26938.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jjohnstn at redhat dot com 2006-10-05 21:12 ---
Created an attachment (id=12387)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12387action=view)
sample cdtproject file that is used by test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #8 from pault at gcc dot gnu dot org 2006-10-05 21:20 ---
Created an attachment (id=12388)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12388action=view)
A fix for this PR
This checks for the presence of GFORTRAN module as the first utterances in
the .mod file. The
--- Comment #3 from mark at gcc dot gnu dot org 2006-10-05 22:01 ---
Confirmed with classpath CVS:
$ /usr/local/jamvm/bin/jamvm CDescription
java.lang.NullPointerException
at gnu.xml.transform.TransformerImpl.strip(TransformerImpl.java:452)
at
--- Comment #4 from tromey at gcc dot gnu dot org 2006-10-05 22:03 ---
Also happens with gcc svn head.
I was also going to CC dog :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-10-05 23:28
---
Because of Jason's patch for PR 28346 the code is now wrongly accepted
on the 4.0 branch. With a slightly different testcase I can still
trigger the ICE, though:
==
bool b;
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-10-05 23:29
---
I meant Jason's patch for PR 26696, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28346
The following invalid code snippet triggers an ICE on mainline:
==
templateint void foo()
{
throw A();
struct A {} a;
}
template void foo0();
==
bug.cc: In function 'void foo()':
bug.cc:3: error: there are no arguments to 'A' that
--- Comment #5 from gregory dot fruth at aero dot org 2006-10-06 00:04
---
The patch works perfectly in 4.2.0(svn). My application now
builds and runs successfully under gfortran. Thanks, Jakub!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
If one compiles
-
module test
implicit none
type epot_t
integer :: c
type(nonexist),pointer :: l
end type epot_t
end module test
-
no error (and no warning) is shown. If one removes the keyword pointer, the
error message Derived type at (1) has not
--- Comment #9 from kargl at gcc dot gnu dot org 2006-10-06 00:33 ---
I have a patch, but it requires libm to have ldexp{f,l}.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-10-06
01:20 ---
The last work on this by Andrew was to propose the code fragment
below for remapping the functions...
static void
darwin_patch_builtin (int fncode)
{
tree fn = built_in_decls[fncode];
const char
1 - 100 of 111 matches
Mail list logo
