Paul Schlie wrote:
the target ports are in gcc/config/...
Sure, I mean which target should I be looking at?
Ned.
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or
With today's mainline I get
stage1/xgcc -Bstage1/
-B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c
-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Werror
On Thu, 3 Mar 2005 07:33:06 -0500, Bradley Lucier
[EMAIL PROTECTED] wrote:
With today's mainline I get
stage1/xgcc -Bstage1/
-B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c
-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic
Original Message
From: Jonathan Wakely
Sent: 03 March 2005 13:00
On Wed, Mar 02, 2005 at 04:36:26PM -0500, Jesus Christ wrote:
Hello,
My name is Caleb Statser and I have recently checked out the book C++
For Dummies
I would
greatly appreciate it if you would send me a direct link
On Thu, 3 Mar 2005 13:37:07 +0100, Christian Joensson
[EMAIL PROTECTED] wrote:
On Thu, 3 Mar 2005 07:33:06 -0500, Bradley Lucier
[EMAIL PROTECTED] wrote:
With today's mainline I get
stage1/xgcc -Bstage1/
-B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c
-g -O2
Paul Schlie wrote:
If the program's address space pointer is more accurately implemented
as a 16-bit pointer combined with an 8-bit segment address; wonder if
it may be worth your while to take a look at how the old segmented x86
GCC targets treat segmented addresses?
Thomas Gill wrote:
also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
Sure? The suspected patch is not present on that branch.
--
Eric Botcazou
On 2005-03-02, Thomas Gill [EMAIL PROTECTED] wrote:
Paul Schlie wrote:
With the arguable exception of function pointers (which need not be literal
address) all pointers are presumed to point to data, not code; therefore
may be simplest to define pointers as being 16-bits, and call functions
On Mar 3, 2005, at 12:36 PM, Eric Botcazou wrote:
also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
Sure? The suspected patch is not present on that branch.
Was this fixed with my/Roger's patch which went in this morning (EST)?
Thanks,
Andrew Pinski
also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
Sure? The suspected patch is not present on that branch.
Was this fixed with my/Roger's patch which went in this morning (EST)?
I'm not convinced this has ever failed on the 4.0 branch, and I don't see any
patch from you or
On Thu, 3 Mar 2005 23:35:28 +0100, Eric Botcazou
[EMAIL PROTECTED] wrote:
also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
Sure? The suspected patch is not present on that branch.
Was this fixed with my/Roger's patch which went in this morning (EST)?
I'm not
On Mar 3, 2005, at 5:35 PM, Eric Botcazou wrote:
Was this fixed with my/Roger's patch which went in this morning (EST)?
I'm not convinced this has ever failed on the 4.0 branch, and I don't
see any
patch from you or Roger there, so I presume you're confusing with
mainline.
I had meant for the
I'm new to the gcc community. I've been asked to modify gcc to allow it
to inject various kinds of instrumentation during compilation. My current
plan is to capture the tree being generated by the front end, augment it,
and pass it on to the back end. It seems like a reasonable approach but I
On Mar 3, 2005, at 6:12 PM, [EMAIL PROTECTED] wrote:
I'm new to the gcc community. I've been asked to modify gcc to allow
it
to inject various kinds of instrumentation during compilation. My
current
plan is to capture the tree being generated by the front end, augment
it,
and pass it on to
Am Mittwoch, 02.03.05 um 03:52 Uhr schrieb Mike Stump:
On Feb 28, 2005, at 3:41 AM, Lars Sonchocky-Helldorf wrote:
I'd like to know what the 'official' position regarding ObjC++ is now.
Anybody willing to clear up?
Sure, why not... Either, someone will submit a clean, safe patch and
it will be
Mike Stump wrote:
If such a patch
were submitted, it would have to go into mainline first anyway, if it
proves safe there and people want to propose a version of it for 4.0.x,
then I think the RM would have to reevaluate it on its merits and risks
and the timing. I don't see the need for the
Bernardo Innocenti wrote:
Joseph S. Myers wrote:
On Wed, 2 Mar 2005, Bernardo Innocenti wrote:
To move strings into program memory, there's a macro like this:
#define PSTR(s) ({ static const char __c[] PROGMEM = (s); __c[0]; })
But this wouldn't work because __func__ does not work like a
Joseph == Joseph S Myers [EMAIL PROTECTED] writes:
Joseph in general tree codes which are not used in GCC CVS have been
Joseph removed and those specific to a language have been made
Joseph language-specific and are lowered to GENERIC tree codes (those
Joseph in tree.def) in gimplification.
On Mar 3, 2005, at 10:12 PM, Tom Tromey wrote:
Speaking of which -- is there any reason FILE_TYPE is still in
tree.def?
I think this is just an over look from people who have not removed it
yet.
I am really talking about myself but there are other people who have
removed
unused tree codes
I am making a back-end compiler to use a gcc front-end
I want to translate gcc intermediate representation to our IR
gcc's IR is tree
so i want to view gcc IR
but i can't find view gcc IR option
-fdump-translation-unit-all make a .tu file , Is this gcc's IR?
but .tu file doesn't have date
Kazu Hirata [EMAIL PROTECTED] writes:
It turns out that the CALL_EXPR case of fold_ternary needs the
original tree like so. (Notice a reference to t.)
...
If we want to change fold_builtin to take operands like op0, op1, and
op2, I would have to change so many things that depend on
On Thu, 3 Mar 2005, Kazu Hirata wrote:
If we want to change fold_builtin to take operands like op0, op1, and
op2, I would have to change so many things that depend on
fold_builtin. (Note that the subroutines of fold_builtin also depends
on fold_builtin in a sense that they need the original
There is no option that does what you want. This is a deliberate,
albeit controversial, design decision which we are not presently
interested in debating.
If you are writing a back end, consider using the existing, well-
understood machinery for porting GCC to a new architecture. If you go
(I and likely others would also be grateful for further insight)
As to enable the efficient use of non-Von-Newman memory architectures
typical of many vector/signal processors, and smaller microcontrollers;
it seems imperative that target specific attributes assigned to an object
remain correct
When I compile the following program with gcc 3.3.5 (debian unstable):
#include xmmintrin.h
int main()
{
int i=1;
float f;
__m128 m[i];
float f2;
__m128 n[i];
printf (%x %x\n, m, n);
}
I get:
% ./align
a8ec a8dc
which is wrong, since m and
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03
10:34 ---
Partial fix proposed here: http://gcc.gnu.org/ml/fortran/2005-03/msg00023.html
This fixes the bug when writing to files, but there still is the case of
preconnected units (stdout, stderr). This will
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03
10:37 ---
Hi,
I see this patch hasn't been commited yet, could you please send it again to the
mailing-lists? With the new approval rules, maybe it should hopefully get
reviewed...
--
--- Additional Comments From micis at gmx dot de 2005-03-03 10:44 ---
I applied you patch and did a full bootstrap on x86_64.
No new regressions.
It fixes my problem.
Michael Cieslinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20122
It should be NULL pointer assignment, but it is not so.
Kernel version 2.4.10 RedHat Linux.
#include stdio.h
#include errno.h
main(){
int err;
err=read(0,NULL,6);
printf(%d %dn,err,errno);
}
Please, reply part of source code with explaination of
bug. Thanks!
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
12:54 ---
I think this is very much related to PR 19199. I almost think when that bug is
fixed this one will also be
fixed.
Your current patch will not fix that PR either.
--
What|Removed
--- Additional Comments From schwab at suse dot de 2005-03-03 12:56 ---
Also happens on i386.
--
What|Removed |Added
Severity|normal
--- Additional Comments From pinskia at physics dot uc dot edu 2005-03-03
12:58 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 3, 2005, at 2:50 AM, Alexandre Oliva wrote:
I'm bootstrapping this on x86_64-linux-gnu, along with the patch for
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20299
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
13:06 ---
Fixed in 3.4.0 and above as you noted that it is fixed in 3.4.4. This is not a
regression so closing as
fixed.
--
What|Removed |Added
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03
13:08 ---
Complete patch is here: http://gcc.gnu.org/ml/fortran/2005-03/msg00024.html
Note: this just makes the limit higher (1 Gb), but there still is a limit on the
size of things you can write to preconnected
--- Additional Comments From bob dot paddock at gmail dot com 2005-03-03
13:13 ---
(In reply to comment #5)
Personally see no problem. The quote above has specifically to do with how to
write a logical 16-bit timer/counter value into a pair of otherwise distinct
8-bit registers, which
The following program results in an ICE:
procedure Undefined_Derived_Char is
type Char is new Character;
C : Char;
begin
case C is
when XXX =
null;
when others =
null;
end case;
end Undefined_Derived_Char;
It seems that the checks in
--- Additional Comments From bangerth at dealii dot org 2005-03-03 14:39
---
I think gcc is right, and icc rejects the code with an almost exact same
error message.
W.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
14:45 ---
(In reply to comment #3)
I think gcc is right, and icc rejects the code with an almost exact same
error message.
But we don't still don't reject the zero sized array which is a bug.
--
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2005-03-03
--- Additional Comments From olh at suse dot de 2005-03-03 14:48 ---
the breakage appeared between 20041027 and 20041101.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From joern dot rennecke at st dot com 2005-03-03
14:59 ---
Subject: Re: If-conversion can't match equivalent code, and cross-jumping only
works for literal matches
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-03
16:28 ---
I think NS::C should remain hidden so the declaration:
C c;
should be OK.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-03-03 17:00
---
That's correct, but that's a dup of PR 16859.
W.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
17:06 ---
I knew I should have looked for this bug.
--
What|Removed |Added
CC|
I am compiling a large jar file.
/opt/gcc-3.4.3-cvs/bin/gcj -c ../../kernel/kernel.jar --classpath=..:../kernel
-o kernel.o
/var/tmp//cct7Jptt.s: Assembler messages:
/var/tmp//cct7Jptt.s:103992: Error: unknown pseudo-op: `.ll'
/var/tmp//cct7Jptt.s:143015: Error: unknown pseudo-op: `.ll'
GCJ does not handle compilation of sub classes with out explicitly defined
constructors to override the super class constructors when the constructors
throw exceptions.
[EMAIL PROTECTED] steve]$ gcj Test.java -c Test.o
Test.java: In class 'Test$1':
Test.java: In constructor
--- Additional Comments From steve at netfuel dot com 2005-03-03 17:32
---
Created an attachment (id=8317)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8317action=view)
Inner class test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
--- Additional Comments From steve at netfuel dot com 2005-03-03 17:33
---
Created an attachment (id=8318)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8318action=view)
Straigt sub class test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
--
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
When
#pragma GCC visibility push(default)
#pragma GCC visibility pop
are used for header file wrappers, we may have more 16
#pragma GCC visibility push(default)
Currently gcc will fail.
--
Summary: Can't push more than 16 nested visibility
Product: gcc
Folks,
We are reporting this issue both to the GCC people and the libsigc++ people,
because the issue could be in either of them or both. On the surface, it looks
like a g++ issue, but when you look deeper, libsigc++ might be relying on a
behavior that is unspecified by any C++ standard.
Input
--- Additional Comments From hpreg at vmware dot com 2005-03-03 18:24
---
Created an attachment (id=8319)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8319action=view)
The code for the small test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20304
--- Additional Comments From hpreg at vmware dot com 2005-03-03 18:25
---
Created an attachment (id=8320)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8320action=view)
Pre-processed file output (.ii file), compressed with bzip2 (-9)
--
--
What|Removed |Added
Severity|critical|normal
Component|target |middle-end
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
18:42 ---
I think this is a dup of another bug, but I am too lazy to find the bug right
now.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
18:43 ---
This is a documented behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
--- Additional Comments From mark at codesourcery dot com 2005-03-03 18:47
---
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
2. The tree-inliner inlines the call. Since the same tree is referenced twice
in the
--- Additional Comments From hjl at lucon dot org 2005-03-03 18:47 ---
It makes it less useful for header file wrappers. Supporting the case of N
(N16)
#pragma GCC visibility push(default)
followed by N
#pragma GCC visibility pop
shouldn't be very hard.
--
--- Additional Comments From pcarlini at suse dot de 2005-03-03 18:47
---
Want to have a look, a fix seems easy...
--
What|Removed |Added
AssignedTo|unassigned at
--- Additional Comments From bugzilla at mdaniel dot scdi dot com
2005-03-03 19:03 ---
In case anyone is curious, this causes the Mozilla HEAD build to fail [at least
with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on
two separate occasions, once with nsprpub
--- Additional Comments From hjl at lucon dot org 2005-03-03 19:11 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00248.html
FYI, gcc 3.4 from RH does include this pragma.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:06 ---
(In reply to comment #2)
In case anyone is curious, this causes the Mozilla HEAD build to fail [at
least
with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on
two separate
It seems that gcc-4_0-branch GCC (both 20050228 and 20050303) miscompiles
libcpp/macro.c if compiled at -O1 and higher. stage1 compiler built that
way dies with:
/usr/include/bits/stdio.h: In function printf':
/usr/include/bits/stdio.h:36: error: syntax error before _restrict__'
/usr/include/bits
--- Additional Comments From bugzilla at mdaniel dot scdi dot com
2005-03-03 19:19 ---
$ gcc --version
gcc (GCC) 3.4.3 20050124 (Red Hat 3.4.3-17)
I stand corrected, Fedora Core 3 must be back-porting some of that
functionality. Should I open a bug with them pointing to this, or is it
--- Additional Comments From hjl at lucon dot org 2005-03-03 19:19 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00238.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
The patch for PR rtl-opt/15289, changed the behavior of emit_move_insn_1 to
invoke emit_block_move on memory to memory moves for optimal behavior,
instead of invoking a movMM pattern on the inner mode. emit_block_move
changes the mode to BLKmode masking the original mode. This sequence of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:23 ---
I want to say this is a dup of bug 20282 which is for ppc64-linux.
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||20305
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:24 ---
PR 20305 is the bootstrap failure for s390x and it looks like the same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From hjl at lucon dot org 2005-03-03 19:25 ---
RH bug is at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150157
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
19:25 ---
It really seems like the C++ front end is doing the right thing,
abstractly -- these functions don't have side-effects! So, either the
inliner or stabilize reference seems like it needs fixing.
--- Additional Comments From dje at gcc dot gnu dot org 2005-03-03 19:26
---
Example Fortran code derived from BLAS ZGEMM routine.
SUBROUTINE Z ( M, N, C, LDC )
* .. Scalar Arguments ..
INTEGERM, N, LDC
* .. Array Arguments ..
COMPLEX*16 C(
--- Additional Comments From steve at netfuel dot com 2005-03-03 19:31
---
I have looked for this bug and did not see one.
15501 is similar but is not the same problem or is a subset of the problems
defined in my report. As my bug also affects any Extends with Exceptions
defined in
--- Additional Comments From mark at codesourcery dot com 2005-03-03 19:34
---
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
19:25 ---
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Target Milestone|---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:48 ---
Confirmed, C testcase which shows that this is defintely a regression:
void f(double _Complex *f,int len)
{
int i = 0;
for(i = 0 ;i20;i++)
{
*f = 0.0;
f++;
}
}
--
What
--- Additional Comments From ericw at evcohs dot com 2005-03-03 19:49
---
Subject: Re: AVR assignment of a value through a 16 bit
pointer generates out of order code
schlie at comcast dot net wrote:
--- Additional Comments From schlie at comcast dot net 2005-03-03 19:47
--
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:52 ---
Just a note from 20282, since I think this is the same bug:
the breakage appeared between 20041027 and 20041101.
--
What|Removed |Added
--- Additional Comments From schlie at comcast dot net 2005-03-03 19:47
---
(In reply to comment #6)
Nope, these are peripheral i/o registers, and like any pheripheral interface
may have
access sequence requirements which need to be satsifyed within it's driver.
These
perpheral
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-03 20:10
---
There are two routines likely miscompiled in libcpp/macro.c:
replace_args and cpp_get_token (I removed all static keywords from the file,
then did a binary search on which routines cause this).
If all of
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-03
20:27 ---
Same thing on i686:
$ gfortran write-many.f
$ time ./a.out
real0m5.576s
user0m5.508s
sys 0m0.038s
$ g77 write-many.f
$ time ./a.out
real0m3.252s
user0m3.185s
sys 0m0.041s
--
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 20:51
---
Working on this.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
21:12 ---
I don't think I'd try to be that clever. We might want the
stabilization to occur even in other cases. In looking at it more
closely, it definitely looks like stabilize_reference should deal with
In the program:
--
extern C int puts(const char*);
templatetypename A, typename B
void foo(A a, B b)
{
puts(ERROR: fooA, B);
}
templatetypename X
void bar(X a)
{
#ifdef ERROR
::foo(a, a);
#else
foo(a, a);
#endif
}
templatetypename A
void foo(A a, A b)
{
puts(OK:
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-03 21:19
---
Thanks Richard,
The patch applies cleanly against 3.4.3 (with an offset of something like 9
lines). I found no regressions with a top level make -k check for an i686-linux
- mipsel-linux cross compiler with
--- Additional Comments From mark at codesourcery dot com 2005-03-03 21:19
---
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
21:12 ---
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 21:36
---
BTW I will also propose a patch to make -fno-second-underscore the default, once
this is fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
In the attached code, the parser gets confused by a use of operator in the
body
of a function template. If the operator is changed (to or == for example)
the code compiles. I've not been able to figure out why it thinks it's in a
constant expression. Changing the variable names involved
--- Additional Comments From igodard at pacbell dot net 2005-03-03 21:47
---
Created an attachment (id=8321)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8321action=view)
Compiler output (-v -save-temps)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
--- Additional Comments From igodard at pacbell dot net 2005-03-03 21:48
---
Created an attachment (id=8322)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8322action=view)
Source code (-save-temps) (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
--- Additional Comments From stevenj at fftw dot org 2005-03-03 21:49
---
Subject: Re: COMPLEX function returns incompatible with
g77
On Thu, 3 Mar 2005, tobi at gcc dot gnu dot org wrote:
BTW I will also propose a patch to make -fno-second-underscore the
default, once this is
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03
21:59 ---
Subject: Bug 20292
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-03 21:59:23
Modified files:
libjava:
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 21:59
---
This is weird. I just came across code (written by me) that should ensure the
right behavior here.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
22:02 ---
There are other places where TREE_SIDE_EFFECTS matters. (Like, do we
have to emit this expression at all, if its result is not used?)
OK.
The counter to your argument is that I don't see why the
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:06
---
I agree with you that -ff2c should imply -fsecond-underscore. I don't agree
that the advantages of -ff2c outweigh the disadvantages of -fno-f2c so far that
-fno-f2c should be the default. If we don't switch
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:08
---
Found the bug. Fixing.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:17
---
Hm, there seems to be some confusion between when to use sym and when
sym-result for a function. My fix won't make it worse, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
1 - 100 of 172 matches
Mail list logo
