I know that Bohem's GC is used in the Java runtime for GCC. However, the
compiler proper itself can _really_ cramp people's avalible RAM (for those who
don't belive me and have Windows w/ DJGPP, change all the memory controls
from `auto' to the highest value and just try to compile
Daniel Berlin writes:
On Fri, 2005-04-01 at 12:43 +0100, Andrew Haley wrote:
Sam Lauber writes:
I know that Bohem's GC is used in the Java runtime for GCC.
However, the compiler proper itself can _really_ cramp people's
avalible RAM (for those who don't belive me and have
On 04/01/2005 07:35 AM, Andrew Haley wrote:
[snip]
To be fair to the Boehm gc, though: it isn't inherently a conservative
collector, but will also do precise gc.
Wouldn't this require a GC_descr as defined here:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt
for each data
Hi,
On Thu, 31 Mar 2005, zouq wrote:
in gcc3.4.1,i found rest_of_new_handle_regalloc
why in gcc4.0, it has been removed?
It was removed from gcc 4 because it bitrotted and broke on all kinds of
code. If you want to see a more recent and more working version look at
the new-regalloc-branch.
Dale Johannesen [EMAIL PROTECTED] writes:
I've currently got the job of implementing pragma(s) to change
optimization level in the middle of a file. This has come up a few
times before,
Would it be possible to make it a function attribute? I would
really like to have
void
Giovanni Bajo wrote:
James E Wilson [EMAIL PROTECTED] wrote:
IA64 bootstrap failed at abi_check stage reporting undefined
references from libstdc++ (see log at the bottom).
This seems indirectly related to bug 20964. Mark's proposed fix to
stop building abi-check at bootstrap time means the
Andrew Haley schrieb:
Sam Lauber writes:
I know that Bohem's GC is used in the Java runtime for GCC.
However, the compiler proper itself can _really_ cramp people's
avalible RAM (for those who don't belive me and have Windows w/
DJGPP, change all the memory controls from `auto' to the
hi
i have downloaded the gcc4.0 from the gcc web site
and i compiled the above program by the following option
main()
{
float a=88.88,b=99.99,c=0;
c=a*b;
printf(%f,c);
}
arm-elf-gcc -mfpu=vfp -S new.c
but it produces the new.s file without any special kind of (vfp
instructions) instructions.
On Fri, Apr 01, 2005 at 06:48:56PM +0200, Stefan Strasser wrote:
Andrew Haley schrieb:
Sam Lauber writes:
I know that Bohem's GC is used in the Java runtime for GCC.
However, the compiler proper itself can _really_ cramp people's
avalible RAM (for those who don't belive me and have
On Fri, Apr 01, 2005 at 10:16:44AM -0800, Kelly Murphy wrote:
I know we'd find something like that really handy for some of the
embedded stuff we're doing.
There's the case where we'd like to have the files of a subsystem to
be optimized but we want a handful of functions that directly
a) what makes your backend different from gcc's backend so it is worth
porting it?
schrieb:
sorry, my english is not good,
Umm...
my project is that Connect to Gcc's front-end and My back-end
first gcc parse sorce code
there is an IR created while parsing which is simply called
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that negatively.
I think that a #pragma (or attribute) that affects only optimization
options is
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that negatively.
I don't
Diego Novillo wrote:
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that
On Thursday, March 31, 2005, at 10:38 PM, GOEBAX wrote:
my project is that Connect to Gcc's front-end and My back-end
We generally don't support this concept. We'd rather you enhance and
extend gcc's back end. Because of this, this is beyond the scope of
this list.
On topic for this list,
On Friday, April 1, 2005, at 10:16 AM, Kelly Murphy wrote:
There's the case where we'd like to have the files of a subsystem to
be optimized but we want a handful of functions that directly access
hardware be unoptimized. (We found that the optimization did some
write reordering that the
On Fri, 2005-04-01 at 00:38, Nathan Sidwell wrote:
Here it is, ok?
The patch is OK. The ChangeLog entry should refer to INTEGER_CST
instead of INT_CST.
You are missing a ChangeLog entry for the testcase.
The testcase is not portable, as I pointed out in the PR. Trying this
on an x86_64-linux
James E Wilson wrote:
The testcase is not portable, as I pointed out in the PR. Trying this
on an x86_64-linux system, I get 27 excess errors failures. All of
them are
error: cast from 'int*' to 'int' loses precision
Using long works better than int, but is still not fool proof, as there
are
Diego Novillo [EMAIL PROTECTED] writes:
| On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
| Dale Johannesen wrote:
|
| So I guess question 1 is, Mark, do you feel negatively enough about this
| feature to block its acceptance in mainline?
|
| I'm not sure that I *could*
Dale Johannesen wrote:
Agree. (And documentation will be written.)
Yay. It sounds like we're definitely on the same page. I think that as
long as we keep the semantics clear, this will be useful functionality.
That's what I assumed. Anything finer than that is insane. :-)
Actually there are
On Apr 1, 2005 11:07 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Dale Johannesen wrote:
Agree. (And documentation will be written.)
Yay. It sounds like we're definitely on the same page. I think that as
long as we keep the semantics clear, this will be useful functionality.
That's
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will be
smarter than the user trying to override it (and hereby maybe only
On Apr 1, 2005 11:23 PM, E. Weddington [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will be
smarter than the user trying to override it (and hereby maybe only
Richard Guenther wrote:
On Apr 1, 2005 11:23 PM, E. Weddington [EMAIL PROTECTED] wrote:
Is your objection to a grain finer than the function level? Or is it to
the whole concept of having pragmas change the optimization level per
function?
It would be a general objection - I thought we're
Joe Buck wrote:
Are you using volatile correctly? There are situations where volatile
alone does not suffice and you need more locking, but the Linux and BSD
kernel folks manage to optimize their device driver code.
We have just been discussing a similar topic in a de.* newsgroup.
A busy-loop
Georg Bauhaus wrote:
We have just been discussing a similar topic in a de.* newsgroup.
A busy-loop function is used to effect a delay, not too precise,
but portably. Like
#define COUNT 1000
void f() {
/*volatile*/ /*register*/ int i;
for (i = 0; i COUNT; ++i)
;
}
If volatile is used
Georg Bauhaus [EMAIL PROTECTED] writes:
| Joe Buck wrote:
|
| Are you using volatile correctly? There are situations where volatile
| alone does not suffice and you need more locking, but the Linux and BSD
| kernel folks manage to optimize their device driver code.
|
| We have just been
Georg Bauhaus [EMAIL PROTECTED] writes:
| A busy-loop function is used to effect a delay, not too precise,
| but portably. Like
|
| #define COUNT 1000
|
| void f() {
|/*volatile*/ /*register*/ int i;
|
|for (i = 0; i COUNT; ++i)
| ;
On Sat, Apr 02, 2005 at
Joe Buck wrote:
Georg Bauhaus [EMAIL PROTECTED] writes:
| A busy-loop function is used to effect a delay, not too precise,
| but portably. Like
|
| #define COUNT 1000
|
| void f() {
|/*volatile*/ /*register*/ int i;
|
|for (i = 0; i COUNT; ++i)
| ;
Unfortunately,
Snapshot gcc-3.4-20050401 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050401/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050401
You'll find
On Fri, 2005-01-04 at 00:10 -0500, Grzegorz B. Prokopski wrote:
/* Leave the rest as it was. */
FOR_EACH_BB (bb)
if ((bb-next_bb != EXIT_BLOCK_PTR) (!bb-rbi-next))
bb-rbi-next = bb-next_bb;
This code worked well in some other place from which I copied it,
but unfortunatelly for
On 2005-04-01, at 23:17, Richard Guenther wrote:
On Apr 1, 2005 11:07 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Dale Johannesen wrote:
Agree. (And documentation will be written.)
Yay. It sounds like we're definitely on the same page. I think that
as
long as we keep the semantics clear, this
On 2005-04-01, at 23:36, Mark Mitchell wrote:
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will be
smarter than the user
Mike Stump schrieb:
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
if gcc uses more memory than physically available it spends a _very_
long time swapping
Swapping, what's that? Here's $20, go buy a gigabyte.
expect memory to become a problem again with the advent of multicore
On Sat, Apr 02, 2005 at 01:10:42AM -0500, Andrew Pinski wrote:
Memory bloat is a problem for embedded systems. Attitudes about just
buy
another gigabyte is why i use C for everything for speed, portability,
compactness, and conciseness of design.
But you are not compiling on the embedded
I was wondering whether it is possible to have GCC produce a warning
whenever a non-virtual method in the base class is hidden by a method in the
derived class. I know this is possible for virtual methods by using
the -Woverload-virtual switch, but I haven't been able to find the
equivalent for
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-04-01
08:25 ---
Committed fix at http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00019.html
--
What|Removed |Added
--
Bug 19454 depends on bug 20600, which changed state.
Bug 20600 Summary: [4.1 regression] failure for pass.c on x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20600
What|Old Value |New Value
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-01
10:43 ---
Seen in wxGTK on i386:
../../../../contrib/src/ogl/drawn.cpp:1019: internal compiler error: in
cp_tree_equal, at cp/tree.c:1552
../../../../contrib/src/ogl/mfutils.cpp:157: internal compiler error: in
In the C++ standard, section 9.3 paragraph 2:
A member function definition that appears outside of the class definition
shall appear in a namespace scope enclosing the class definition.
This is similar to 7.3.1.2p2 except for class members.
Therefore, the following code should be rejected:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
11:23 ---
Subject: Bug 19454
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-01 11:23:08
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
11:23 ---
Subject: Bug 20600
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-01 11:23:08
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
11:39 ---
Subject: Bug 15700
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-01 11:38:53
Modified files:
gcc/testsuite : ChangeLog
Log message:
Add
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
The following 3 equvalent variants of the same primitive program should lead to
the same code, but they don't:
1. C source:
static inline int f1();
static inline int f2();
int main() { f1(); }
static inline int f1() { f2(); }
static inline int f2() { return 1; }
Its assembler output:
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01
11:45 ---
No write or print statement is necessary:
$ cat assign.f90
program main
assign 1000 to i
1000 format (A)
end
$ gfortran assign.f90
$ gfortran -fdump-parse-tree assign.f90
In file
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
12:41 ---
Subject: Bug 20635
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-01 12:41:19
Modified files:
gcc:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
12:54 ---
Fixed in 3.4.0 and above with unit-at-a-time.
--
What|Removed |Added
character(len = 10),parameter:: a = 'hello'
print *, a, world
end
the output:
helloworld.
--
Summary: Don't pad parameter strings.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
13:08 ---
*** This bug has been marked as a duplicate of 13140 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
13:08 ---
*** Bug 20711 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
13:11 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 20225 depends on bug 20635, which changed state.
Bug 20635 Summary: [4.0 Regression] ICE in cgraph_mark_reachable_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20635
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
13:17 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From ncm at cantrip dot org 2005-04-01 13:24
---
Subject: Re: basic_string::_M_rep() can produce an unnaturally aligned pointer
to _Rep
On Fri, Apr 01, 2005 at 11:42:27AM -, pcarlini at suse dot de wrote:
What|Removed
--- Additional Comments From pcarlini at suse dot de 2005-04-01 13:31
---
Ok, my change was only dictated by consistency, and the original idea of using
enhancement is not mine ;) Let's remove enhancement from both. By the way,
I really noticed yesterday for the first time that
--
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01
13:34 ---
This patch fixes the test case. It also includes my
EOR patch for advancing I/O.
This is regression-tested on mainline. I'll submit a proper
patch when I have finished regression-testing it on 4.0.
When emit_no_conflict_block is handed these insns:
(insn 597 0 598 (set (reg:SI 405)
(mem/i:SI (reg/f:SI 154 virtual-stack-vars) [0 x+0 S4 A32])) -1 (nil)
(nil))
(insn 598 597 599 (parallel [
(set (reg:SI 404)
(ashift:SI (reg:SI 405)
--- Additional Comments From pcarlini at suse dot de 2005-04-01 14:26
---
I think it is not OK to include cassert or assert.h.
I agree. Actually, probably we have already briefly discussed that (privately)
with Benjamin. Is there something wrong with just using if () abort()
--- Additional Comments From pcarlini at suse dot de 2005-04-01 14:34
---
I think we can safely close this one.
--
What|Removed |Added
Status|UNCONFIRMED
When I tried to compile and link java application into an exacutable using GCJ
v3.4.3 in Linux Red Hat 3.4.3-9.EL4, it produces error messages:
[EMAIL PROTECTED]:~/testarea/build$ ./gcjbuild
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Reading specs from
--
What|Removed |Added
Severity|critical|normal
Component|libgcj |java
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
14:52 ---
You might want to try a snapshot of 4.0.0 which has AWT support builtin.
Also this is not a link error, this is at compile time still.
This error usually shows up if you try to compile a .jar and a .java
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From jack dot rong at cloakware dot com 2005-04-01
14:58 ---
Subject: RE: gcj link error
It is a compilation error. Thanks.
Jack
-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
Sent: Friday, April 01, 2005 9:52 AM
To:
--
What|Removed |Added
Summary|gcj link error |gcj compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20715
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
15:01 ---
Subject: Bug 20604
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-01 15:01:31
Modified files:
gcc/treelang : ChangeLog lang-specs.h
Log
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
15:01 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-01
15:20 ---
Created an attachment (id=8507)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8507action=view)
proposed patch
This implements a similar dependency check as in emit_libcall_block,
except that we might
--
What|Removed |Added
OtherBugsDependingO||20695
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20714
--
What|Removed |Added
BugsThisDependsOn||20714
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20695
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-01
15:28 ---
Forget comment #4. The problem is in the testsuite file (I corrected it, this
test now FAILs, but will be fixed soon by Dale's patch).
--
What|Removed |Added
The fortran testsuite routine
/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/execute/backspace.f90 is
actually incorrect - C should actually be 'a' not 'b' - gfortran incorrectly
returns 'b' and passes the bad test.
[dranta:~/tests/gfortran] dir% gfortran -o backspace backspace.f90
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
15:34 ---
This was just fixed by François-Xavier Coudert:
* gfortran.fortran-torture/execute/backspace.f90: Check
after backspace and read was incorrect.
--
What|Removed
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-01 16:23
---
Let me replace the testcase as follows so that
I can remove dependence on PR 20701.
extern void bar (int);
int
foo (int *p, int b)
{
int a;
if (b)
bar (123);
else
bar (321);
a = *p;
if
Many g++ and libstdc++ testcases started failing on mainline on ia64-hpux on
20050331. The failures are of the form:
ld: (Warning) Unsatisfied symbol std::basic_stringbufchar,
std::char_traitschar, std::allocatorchar ::~basic_stringbuf() in file
unsigned long foo (unsigned long *a, unsigned long *b,
unsigned long *c, int d)
{
unsigned long e, f;
if (d = 0) return 0;
asm (# registers %0 %1 %2 %3 %4 %5
: +a (e),+c (d), +r (f)
: r (a), r (b), r (c));
return e;
}
at -O2 results in
# registers %rax
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-01 16:47
---
Before FRE. (That is, the result of copyprop)
foo (array)
{
int D.1134;
int D.1133;
int * D.1132;
bb 0:
D.1132_3 = array_2 + 4B;
# VUSE TMT.0_9;
D.1133_4 = *D.1132_3;
if (D.1133_4 != 0)
Bootstrap on mainline on hppa2.0w-hpux has started failing on 20050401 in the
build of libgcc with the stage1 compiler.
/home/gcc/nightlies/gcc-mainline-2005-04-01/gcc/libgcc2.c: In function
'__muldi3':
/home/gcc/nightlies/gcc-mainline-2005-04-01/gcc/libgcc2.c:533: internal compiler
error
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-01 16:56
---
Created an attachment (id=8508)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8508action=view)
File which ICEs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20719
AWT applications crash when processing certain key events because the
keysym-to-keycode mapping is wrong. The crash is preceded by this warning:
** (:7916): WARNING **: No keyval found for hardware keycode 233
*** glibc detected *** free(): invalid pointer: 0x085819a0 ***
--
the error ``crosses initialization of `...''' is wrongly omited
--
Summary: [regression from 3.4.2 to 3.4.3] crossing of a
initialization left undetected on goto
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
19:19 ---
This is not a regression and here is an example (compile on 3.2.3 with -O2 -
fomit-frame-pointer on i686-pc-linux-gnu and you get the same behavior as
pointed out here):
unsigned long foo (unsigned long
--- Additional Comments From nefercheprure at gmail dot com 2005-04-01
19:22 ---
Created an attachment (id=8509)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8509action=view)
the preprocessed file that demonstrates the regression
g++ -v -c logger.cc produces this message:
--
What|Removed |Added
Keywords||accepts-invalid
Known to fail||3.4.3
Known to work|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
19:42 ---
There is at least an ICE on the mainline.
--
What|Removed |Added
--- Additional Comments From jozef dot behran at krs dot sk 2005-04-01
19:49 ---
This is still valid code because the struct could be defined below still.
But if the struct is not defined anywhere (not even below its use), a warning
should
occur. If you send the first declaration
In varasm.c, function_section() and current_function_section() invoke target
hook select_section with boolean unlikely as the second argument. The
second argument is suppose to specify if the decl contains relocations, not if
it should be placed in the unlikely section.
--
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-04-01
20:00 ---
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00097.html
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|WAITING
--- Additional Comments From joseph at codesourcery dot com 2005-04-01
20:19 ---
Subject: Re: Attempt to use undefined structure tag triggers
no diagnostic
On Fri, 1 Apr 2005, jozef dot behran at krs dot sk wrote:
Note that the code is valid, but unusual. If you see a structure tag
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
20:58 ---
If you deference or do an assignment like:
TType *a, *b;
b-Pointer = a;
You will either get an error or a warning saying the code is invalid.
Also as mentioned by JSM, it is a way to provide opaque
--- Additional Comments From mark at codesourcery dot com 2005-04-01 21:17
---
Subject: Re: [PR debug/19345] remap TYPE_STUB_DECL during inlining
Alexandre Oliva wrote:
TYPE_STUB_DECL was NULL in the testcase given in the bug report
because tree inlining failed to remap
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
21:25 ---
Also reproducable on i686-pc-openbsd3.1.
--
What|Removed |Added
CC|
--
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20719
--- Additional Comments From frederic dot riss at gmail dot com 2005-04-01
21:45 ---
Andrew, I don't fully get what you mean and seeing no activity on this bug makes
me wonder if you expect some feedback from me... Experimenting based on your
comment I tried using -fno-weak, but it
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
21:48 ---
(In reply to comment #2)
Andrew, I don't fully get what you mean and seeing no activity on this bug
makes
me wonder if you expect some feedback from me... Experimenting based on your
comment I tried
1 - 100 of 124 matches
Mail list logo
