You can't put new features and bug fixes in the same basket. They can even be
viewed as steering the compiler in opposite directions quality-wise. If you
don't want to increase the patches-per-day ratio, the only solution is to
prioritize bug fixes over new features. For example we could
I need to make the following change to gcc:
- Once every 7 assembler instructions , I need to
generate a nop. ( for each cache block insert a nop
).My whole code (statically linked) needs to have this
so I also need to insert the noops for the entire
libc.
Inserting the nops in the asm code does
On 15/06/06, Mike Stump [EMAIL PROTECTED] wrote:
For example, would be nice to have a batch tester that
would bootstrap and regression test on 2-5 platforms for all patch
submitters post approval but pre-checkin. If any regressions, dump
all patches and move on to the next set, repeat as fast
On 14/06/06, Eric Botcazou [EMAIL PROTECTED] wrote:
For example we could introduce
secondary maintainers with approval rights for bug fixes only or something
along these lines.
Or the secondary maintainers could review patches and reject them but
not approve them for commit. They may add
(We should really update contribute.html to explicitly said what must be done)
Hi Pedro, as far as I know, you just need to email [EMAIL PROTECTED] and
request a personal copyright assignment for GCC.
You'll need to include your physical mailing address so they can send
some forms to you. They
hi,
I'm trying to figure out the code flow of gcc.But i'm not been
able to locate the location at which an expression is compared with
pattern given in .md file.
I think .md file is resposible fo generation of emit-insn.c
file.But again at which point the functions in emit-insn.c
kernel coder writes:
hi,
I'm trying to figure out the code flow of gcc.But i'm not been
able to locate the location at which an expression is compared with
pattern given in .md file.
I think .md file is resposible fo generation of emit-insn.c
file.But again at which
is there any way in gdb to step backward.
On 6/15/06, Andrew Haley [EMAIL PROTECTED] wrote:
kernel coder writes:
hi,
I'm trying to figure out the code flow of gcc.But i'm not been
able to locate the location at which an expression is compared with
pattern given in .md file.
kernel coder wrote:
is there any way in gdb to step backward.
not yet, and if this feature is implemented it should be quite
restricted, think about undoing side effects, as disk read/write...
But you can put a breakpoint before the current point, and then run
again gdb on your program.
David Ayers wrote:
(I assume you didn't configure with --enable-objc-gc or java.)
No, I didn't. I've used a unified tree, created like this:
mv trunk gcc
mkdir srcw-l
cd srcw-l
ln -s ../gcc/* .
rm libgfortran
ln -s ../src/* .
rm include
mkdir include
cd include
ln -s
Sebastian Pop wrote:
kernel coder wrote:
is there any way in gdb to step backward.
not yet, and if this feature is implemented it should be quite
restricted, think about undoing side effects, as disk read/write...
But you can put a breakpoint before the current point, and then run
again gdb
On Thu, Jun 15, 2006 at 10:05:10AM -0400, Robert Dewar wrote:
You don't need to undo side effects for debugging purposes, you just
need to be able to recreate previous states from the point of view
of the application. So for I/O operations, you need to restore memory
to the state before the
Daniel Jacobowitz wrote:
The point of going backwards (a feature quite familiar to me from
the use of hardware debuggers on PC's in bygone years) is to figure
out what went wrong, and for that purpose you only need to worry
about the machine/memory state.
Not when you're debugging userspace
On Jun 15, 2006, at 2:34 AM, Manuel López-Ibáñez wrote:
I am new to the project so please don't take me too seriously if I am
saying some dumb thing: why review a patch that doesn't pass bootstrap
and check?
This is not usually an issue. Yes most people will only test one target
but that is
On Thu, Jun 15, 2006 at 10:31:55AM -0400, Robert Dewar wrote:
Daniel Jacobowitz wrote:
The point of going backwards (a feature quite familiar to me from
the use of hardware debuggers on PC's in bygone years) is to figure
out what went wrong, and for that purpose you only need to worry
about
On 15/06/06, Andrew Pinski [EMAIL PROTECTED] wrote:
On Jun 15, 2006, at 2:34 AM, Manuel López-Ibáñez wrote:
I am new to the project so please don't take me too seriously if I am
saying some dumb thing: why review a patch that doesn't pass bootstrap
and check?
This is not usually an issue.
Daniel Jacobowitz wrote:
It doesn't have an actual reverse debugging implementation yet - but
it's been proposed.
Here it is, but I don't know the exact current status of the proposal:
http://sourceware.org/ml/gdb/2006-01/msg00013.html
Is there a standard process we use to eliminate -f options? or is it
more on a per options basis.
Im reworking out-of-ssa for 4.3 and there are a couple of options that
were initially added which I prefer to no longer support.
-ftree-combine-temps attempts to coalesce non-related ssa_names into
Manuel López-Ibáñez wrote on 06/15/06 05:34:
I mean, there is a patch queue, you put your patch or patch
set in the queue, it gets bootstrapped and tested as you said on 2-5
patforms, then either it passes and a notification is send to the
Actually, the patch queue only stores the patches.
On Thu, Jun 15, 2006 at 03:57:05PM +0100, Manuel López-Ibáñez wrote:
Mike Stump proposed a batch tester that
would bootstrap and regression test on 2-5 platforms for all patch
submitters post approval but pre-checkin. My point is that a batch
tester post-approval is just wasting reviewers
On Thu, Jun 15, 2006 at 01:03:17PM -0400, Diego Novillo wrote:
Manuel López-Ibáñez wrote on 06/15/06 05:34:
I mean, there is a patch queue, you put your patch or patch
set in the queue, it gets bootstrapped and tested as you said on 2-5
patforms, then either it passes and a notification
On 6/15/06, Joe Buck [EMAIL PROTECTED] wrote:
On Thu, Jun 15, 2006 at 01:03:17PM -0400, Diego Novillo wrote:
Manuel López-Ibáñez wrote on 06/15/06 05:34:
I mean, there is a patch queue, you put your patch or patch
set in the queue, it gets bootstrapped and tested as you said on 2-5
On 15 June 2006 18:09, Joe Buck wrote:
On Thu, Jun 15, 2006 at 01:03:17PM -0400, Diego Novillo wrote:
Manuel López-Ibáñez wrote on 06/15/06 05:34:
I mean, there is a patch queue, you put your patch or patch
set in the queue, it gets bootstrapped and tested as you said on 2-5
patforms, then
On 6/15/06, Joe Buck [EMAIL PROTECTED] wrote:
Right, but Manuel was commenting on Mike Stump's proposal, wondering
why Mike proposed to run the bootstrap tests *after* reviewer approval
instead of before.
On Thu, Jun 15, 2006 at 07:12:38PM +0200, Richard Guenther wrote:
It might be a
Diego Novillo wrote:
Manuel López-Ibáñez wrote on 06/15/06 05:34:
I mean, there is a patch queue, you put your patch or patch
set in the queue, it gets bootstrapped and tested as you said on 2-5
patforms, then either it passes and a notification is send to the
Actually, the patch queue
Hello,
Diego Novillo wrote:
Manuel López-Ibá?ez wrote on 06/15/06 05:34:
I mean, there is a patch queue, you put your patch or patch
set in the queue, it gets bootstrapped and tested as you said on 2-5
patforms, then either it passes and a notification is send to the
Actually, the
In http://gcc.gnu.org/ml/gcc/2006-06/msg00549.html, you wrote:
-ftree-live-range-split splits live ranges on exit from ssa. This is
on by default, and in fact it is more work to NOT split unrelated live
ranges, and creates extra register pressure.
I've found that in 4.1, -fno-web is often
I know, for example, SuSE has such a build farm that is accessible by
email (IE you email patches to it).
If they were willing to let the patchapp submit emails (or xmlrpc or
whatever), and there was a way for it to notify the patchapp about the
results (xmlrpc or http post would be
On 6/15/06, Joern RENNECKE [EMAIL PROTECTED] wrote:
In http://gcc.gnu.org/ml/gcc/2006-06/msg00549.html, you wrote:
-ftree-live-range-split splits live ranges on exit from ssa. This is
on by default, and in fact it is more work to NOT split unrelated live
ranges, and creates extra register
In http://gcc.gnu.org/ml/gcc/2006-06/msg00533.html, you wrote:
Inserting the nops in the asm code does not work,
because will cause some offets to go out of range.
It should when you adjust the ranges used by gcc to anticipate
the insertion of nops by the assembler.
On Thu, 2006-06-15 at 19:06 +0100, Joern RENNECKE wrote:
In http://gcc.gnu.org/ml/gcc/2006-06/msg00549.html, you wrote:
-ftree-live-range-split splits live ranges on exit from ssa. This is
on by default, and in fact it is more work to NOT split unrelated live
ranges, and creates extra
Steven Bosscher wrote:
Well, is that something you have to blame live range splitting for, or
is perhaps flow just too stupid to see through the split live ranges?
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
On Jun 15, 2006, at 9:36 AM, Andrew MacLeod wrote:
Is there a standard process we use to eliminate -f options? or is it
more on a per options basis.
I think we should take into consideration the option. For corner
case options that aren't used very often, removing them outright be
well be
Hi,
FYI I've created a branch boehms-gc for my work. I'm about to commit
wwwdocs patch describing it -
boehms-gc
The goal of this branch is to test Boehm's GC feasibility as the
garbage collector for GCC proper. This is a part of Google Summer of
Code project, described in detail at
On Jun 15, 2006, at 2:34 AM, Manuel López-Ibáñez wrote:
Maintainers said that they are overwhelmed by the amount of work
required to review. Post-approval testing seems just a waste of time
to me.
It is, well, unless you want mainline to build and pass a regression
suite. No amount of
Steven Bosscher wrote:
On 6/15/06, Joern RENNECKE [EMAIL PROTECTED] wrote:
In http://gcc.gnu.org/ml/gcc/2006-06/msg00549.html, you wrote:
-ftree-live-range-split splits live ranges on exit from ssa. This is
on by default, and in fact it is more work to NOT split unrelated live
ranges,
On 15/06/06, Joe Buck [EMAIL PROTECTED] wrote:
This is understandable. In any case, it would probably best to have
a human in the loop before submitting patches to autobuilders, both
for security reasons and as a sanity check, to avoid wasting resources
on an unacceptable patch. Machine donors
thus, the pre-review batch test was a way to avoid wasting (human)
resources on an unacceptable patch.
You are confusing the review process with whether the patch works.
To a large extent, those two issues are very different. A reviewer
will always presume the patch works and is
I haven't had to to do this with the new mechanism for a while, but now I
need to do the equivalent of the old make unstage1 and can't find
any documentation on how to do that (I thought this would be discussed
inside Makefile.tpl).
I basically had something blow up in stage2, so I want to go
Snapshot gcc-4.0-20060615 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060615/
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,
while looking into a recent mismatch between GCC-4.x and a C dialect
EH implemented as setjmp/longjmp, I recalled there was a talk about
extending GNU C with __try/__finally construct:
http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00239.html
What happened to that project? Is it dead
while looking into a recent mismatch between GCC-4.x and a C dialect
EH implemented as setjmp/longjmp, I recalled there was a talk about
extending GNU C with __try/__finally construct:
http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00239.html
What happened to that project? Is it dead
On Thu, Jun 15, 2006 at 07:21:03PM -0400, Andrew Pinski wrote:
while looking into a recent mismatch between GCC-4.x and a C dialect
EH implemented as setjmp/longjmp, I recalled there was a talk about
extending GNU C with __try/__finally construct:
On Thu, Jun 15, 2006 at 07:21:03PM -0400, Andrew Pinski wrote:
while looking into a recent mismatch between GCC-4.x and a C dialect
EH implemented as setjmp/longjmp, I recalled there was a talk about
extending GNU C with __try/__finally construct:
Andrew Pinski [EMAIL PROTECTED] writes:
|while looking into a recent mismatch between GCC-4.x and a C dialect
| EH implemented as setjmp/longjmp, I recalled there was a talk about
| extending GNU C with __try/__finally construct:
|
|
On Thu, 15 Jun 2006, Andrew Pinski wrote:
|
| On Thu, Jun 15, 2006 at 07:21:03PM -0400, Andrew Pinski wrote:
| while looking into a recent mismatch between GCC-4.x and a C dialect
|EH implemented as setjmp/longjmp, I recalled there was a talk about
|extending GNU C with
Andrew Pinski [EMAIL PROTECTED] writes:
|while looking into a recent mismatch between GCC-4.x and a C dialect
| EH implemented as setjmp/longjmp, I recalled there was a talk about
| extending GNU C with __try/__finally construct:
|
|
On Thu, 15 Jun 2006, Andrew Pinski wrote:
|
| Andrew Pinski [EMAIL PROTECTED] writes:
|
| |while looking into a recent mismatch between GCC-4.x and a C dialect
| | EH implemented as setjmp/longjmp, I recalled there was a talk about
| | extending GNU C with __try/__finally construct:
|
On Jun 15, 2006, at 4:47 PM, Andrew Pinski wrote:
The front-end in question has stopped working because the traditional
setjmp/longjmp translation of try/catch constructs is no longer
working correctly with versions of GCC higher than 4.0.
How is it no longer working? I don't understand how
Here are just a few more issues I was wondering about for VLAs:
static int i;
static int new_i() { i++; return i; }
static int bar(int a[new_i()][new_i()]);
void foo(int n) {
/* Presently an error, but, should it be (due to bar having a VM
type and bar having other than no linkage)? */
I add AS_NEEDED directive in /usr/lib/libc.so and then anything is ok.
Thanks to Ian and Jakub!
yxx
2006/6/13, Jakub Jelinek [EMAIL PROTECTED]:
On Tue, Jun 13, 2006 at 08:35:17AM -0700, Ian Lance Taylor wrote:
Well, your libstdc++ was configured for a system which supports TLS
(Thread Local
David Edelsohn [EMAIL PROTECTED] writes:
Daniel Jacobowitz writes:
Daniel On Mon, Jun 12, 2006 at 10:22:17AM -0400, David Edelsohn wrote:
Typing make in the gcc subdirectory does not do what I expect.
Daniel Then could you clarify what happens, and what you expect, please?
The
I actually like the existing behaviour, which I'm pretty sure hasn't
changed for many years.
It has, at least for make quickstrap.
--
Eric Botcazou
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-15 06:01
---
Subject: Bug 27648
Author: mmitchel
Date: Thu Jun 15 06:00:49 2006
New Revision: 114672
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114672
Log:
PR c++/27648
* parser.c
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu
|
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-06-15 06:25
---
Eric --
Here, valid_initializer_constant_p returns true -- but output_constant aborts,
saying:
/* Make sure eliminating the conversion is really a no-op, except with
VIEW_CONVERT_EXPRs to
--- Comment #25 from kspiteri at ieee dot org 2006-06-15 06:25 ---
In reply to comment #24:
No it should not be. a() is a temporary so it cannot be bound to a. At
least it should not be.
Then this is not a bug. The C++ standard in 27.6.2.1 defines
* basic_ostreamcharT,traits
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-15 06:32
---
The error orginally came from:
2005-09-01 DJ Delorie [EMAIL PROTECTED]
* varasm.c (output_constant): Let the target resolve
conversions of addresses to non-default pointer sizes.
And then there
--- Comment #3 from bonzini at gnu dot org 2006-06-15 06:33 ---
I agree it is a packaging issue, but we can work around it and it can be useful
for other front ends as well. Taking the bug.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-06-15
06:33 ---
(In reply to comment #0)
According to section 4.5 of the Fortran95 standard:
If the ac-value expressions are of type character, each ac-value expression in
the array-constructor shall have the same
--- Comment #4 from bonzini at gnu dot org 2006-06-15 06:35 ---
Also, fixing this PR would allow us to ship Objective-C++ in the objc tarball.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27063
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-06-15 06:39
---
I don't understand the assertion, given that removing it seems to generate
correct output for this test case. Since you edited this code not to long
ago,
do you have thoughts?
Not really. I've only
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28015
--- Comment #12 from bonzini at gnu dot org 2006-06-15 07:21 ---
Created an attachment (id=11670)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11670action=view)
updated configure script for libdecnumber
Gerald, here it is. Again, don't forget to disable fortran.
--
The program
#include stdio.h
main()
{
double d;
int i;
printf(Starting at 32758\n);
for (d=32758.0, i=0; i20; i++) {
printf(d is %f, as integer is 0x%0.8x, and (ushort)d is 0x%0.4x
while (unsigned char)d is 0x%0.2x\n,
--- Comment #1 from falk at debian dot org 2006-06-15 10:16 ---
If the value of the integral part cannot be represented by the integer type,
the behavior is undefined. So this is not a bug.
--
falk at debian dot org changed:
What|Removed |Added
Assume the following case:
One had somewhere '(3(a,),f)', now one copies this and realizes that one
does not need the 3(..) anymore. Result:
'(a,),f)'
Ups, the ,f) is ignored.
Currently, gfortran does not warn in such a case.
Expected: gfortran warns at compile time
Ifort (9.1) even
Hi
I think gcc-4.1.1 generates wrong outputs on coldfire v4 at this code.
-
struct ab {
int a;
unsigned int b;
};
int
main () {
struct ab _ab;
short a = 0;
unsigned short b = 0;
_ab.a = -999;
_ab.b = 1000;
a = _ab.a;
b = _ab.b;
printf(%d\n, a );
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-06-15 11:17
---
Hello,
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00241.html suggests we
still
have the bug. Can someone confirm this still passes with
-fno-move-loop-invariants?
Confirmed.
could you please
--- Comment #2 from aph at gcc dot gnu dot org 2006-06-15 11:23 ---
gcj creates all its trampolines on the heap, so exec stack shouldn't be needed.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-06-15 11:31 ---
Ccing people responsible for data dependence analysis. I have hacked this over
on predcom branch, but I would prefer if someone who understands the code could
fix it properly.
--
rakdver at gcc dot gnu dot org
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-15 12:26 ---
.so, an error is definitely in order.
Maybe one could spit out a default warning and only with -std=f90 an error as
this is might be a commonly used Fortran extension. Or one simply always
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-06-15 12:34
---
I fixed this problem. But, as I don't have a Solaris box,
I can't test whether this means that the build works.
This report was actually invalid, we don't support /bin/sh on Solaris.
--
ebotcazou at gcc
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-06-15 12:36
---
See http://gcc.gnu.org/install/specific.html#x-x-solaris2
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
The compilation crashes in
/* Gimplify an OMP_ATOMIC statement. */
static enum gimplify_status
gimplify_omp_atomic (tree *expr_p, tree *pre_p)
{
tree addr = TREE_OPERAND (*expr_p, 0);
tree rhs = TREE_OPERAND (*expr_p, 1);
tree type = TYPE_MAIN_VARIANT (TREE_TYPE
--- Comment #9 from sebastian dot pop at cri dot ensmp dot fr 2006-06-15
13:19 ---
Subject: Re: [4.2 Regression] segfault in fold_convert with -ftree-vectorize
rakdver at gcc dot gnu dot org wrote:
Ccing people responsible for data dependence analysis.
Thanks, for the ping, this
--- Comment #21 from amacleod at redhat dot com 2006-06-15 13:30 ---
Subject: Bug 27793
Author: amacleod
Date: Thu Jun 15 13:30:17 2006
New Revision: 114678
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114678
Log:
2006-06-15 Andrew MacLeod [EMAIL PROTECTED]
PR
See lower part of my article at
http://www.ba-stuttgart.de/~helbig/st80/bsearch.txt
--
Summary: optimizer (-O2) changes the semantics of my programs
Product: gcc
Version: 2.95.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-15 14:15 ---
The tesstcase works in 4.2.0 20060608 but fails with Apple's gcc version
4.0.1 (Apple Computer, Inc. build 5341). I bet I have seen this bug before.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-06-15 14:21
---
Daniel, this bug was exposed by your 2006-02-20 patch. It's been blocking
testing/submission of one of my libgfortran patches for more than two months
now. It's in an area of the compiler I don't have any
--- Comment #10 from dberlin at gcc dot gnu dot org 2006-06-15 14:35
---
Uh, nobody told me it was exposed by my patch, and it's certainly not in the
bug history, or else i would be working on the bug.
In fact, as comment 8 shows, even if you disable the code i added in
2006-02-20, an
--- Comment #10 from sebastian dot pop at cri dot ensmp dot fr 2006-06-15
14:52 ---
Subject: Re: [4.2 Regression] segfault in fold_convert with -ftree-vectorize
You said that you had a fix in predcom, is that fix in your local
tree, or have you sent a patch to gcc-patches?
Here is a
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-06-15 15:04
---
This should fix it
It looks like gimplify_val never calls mark_new_vars_to_rename, but may create
new statements that nothing else gets a handle to.
Index: tree-cfg.c
--- Comment #12 from dberlin at gcc dot gnu dot org 2006-06-15 15:18
---
Subject: Bug 27341
Patch I am testing for all the testcases here.
It turns out to be a problem not actually in the 02-20-06 patch.
Index: gcc/tree-complex.c
--- Comment #12 from dj at redhat dot com 2006-06-15 15:19 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from
4 to 8 bytes in initializer
I don't understand the assertion, given that removing it seems to
generate correct output for this test case.
--- Comment #13 from mark at codesourcery dot com 2006-06-15 15:27 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error:
no-op convert from 4 to 8 bytes in initializer
dj at redhat dot com wrote:
--- Comment #12 from dj at redhat dot com 2006-06-15 15:19 ---
--- Comment #5 from patchapp at dberlin dot org 2006-06-15 15:30 ---
Subject: Bug number PR27781
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-06/msg00808.html
--
--- Comment #2 from barryb at cwipapps dot net 2006-06-15 15:54 ---
The integers in the example ARE all within the range of unsigned short.
Therefore Falk's comments may be true, but are not relevant.
Note also that the same code works as expected on sparc.
We think that the problem
--- Comment #3 from schwab at suse dot de 2006-06-15 16:04 ---
It is still undefined to convert a float to an integer that is too narrow. The
range of short is irrelevant when converting to char. Since the behaviour is
undefined there is no requirement on the resulting value. If you
--- Comment #6 from sje at cup dot hp dot com 2006-06-15 16:14 ---
Could I get clarification if the following error is a desired effect of this
change. Prior to this, the included program gave no error. I believe the
change was caused by this patch. This is causing a problem with the
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-15 16:19 ---
(In reply to comment #6)
e.c:1: error: previous declaration of 'int i' with 'C++' linkage
e.c:4: error: conflicts with new declaration with 'C' linkage
extern int i;
extern C {
extern int i;
}
Not
--- Comment #12 from hp at gcc dot gnu dot org 2006-06-15 16:50 ---
In reply to comment #11, i *is* an appropriate constraint, if any.
I see the problem with the reduced test-case in comment #3,
so I'm going to limit the scope of my involvement to fixing that.
Hopefully we can leave
--- Comment #4 from barryb at cwipapps dot net 2006-06-15 17:15 ---
Sorry, you are right; you have to cast it twice.
I'd moved on to
d is 32765.00, as integer is 0x7ffd, and (ushort)d is 0x7ffd while
(uchar)(ushort)d is 0xfd
d is 32766.00, as integer is 0x7ffe, and
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-15 17:23 ---
Subject: Bug 27781
Author: rguenth
Date: Thu Jun 15 17:23:41 2006
New Revision: 114681
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114681
Log:
2006-06-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-06-15 17:30 ---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2006-06-15 17:39 ---
Created an attachment (id=11675)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11675action=view)
A near submission level patch for the PR
I have not marked the previous version as obsolete because it could well
See below; G++ appears to correctly handle the use of 'struct B' to declare the
function template g(), but if there is no prior declaration of the class (as in
the declaration of f()), the class is erroneously taken as a class template.
extern C int printf( const char*, ... );
struct B{ int n;
I assume I'm not the only one seeing this build failure:
make[5]: Entering directory
`/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools'
/bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc
-B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-15 18:31 ---
This works correctly in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 137 matches
Mail list logo
