what you do seems basically OK to me. The problem is that you also need
to fix the ssa form for the virtual operands of the added calls
(i.e., you must call mark_new_vars_to_rename for each of the calls,
and update_ssa once at the end of tree_handle_loop).
Zdenek
Ok, by inserting the
hi,
On Wed, 2006-08-30 at 16:44 -0500, Mark Mitchell wrote:
[snip]
(Implied, but not stated, in your mail is the fact that the abbreviation
table cannot be indexed directly. If it could be, then you wouldn't
have to read the entire abbreviation table for each function; you would
just
Mark Mitchell wrote:
Kenneth Zadeck wrote:
Even if we decide that we are going to process all of the functions in
one file at one time, we still have to have access to the functions that
are going to be inlined into the function being compiled. Getting at
those functions that are going to
This is on a cygwin/winxp system... while building gcc trunk,
currently, and for quite some time, I have been getting this warning:
/usr/local/src/trunk/objdir/./gcc/xgcc
-B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
-B/usr/local/i686-pc-cygwin/lib/ -isystem
again, on cygwin/winxp, I get an error
../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:104:
error: static declaration of 'calloc' follows non-static declaration
am I doing something seriously wrong here?
--
Cheers,
/ChJ
last one, again on cygwin/winxp, I get an error:
../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:105:
error: expected identifier or '(' before '{' token
hints?
--
Cheers,
/ChJ
Christian Joensson writes:
This is on a cygwin/winxp system... while building gcc trunk,
currently, and for quite some time, I have been getting this warning:
/usr/local/src/trunk/objdir/./gcc/xgcc
-B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
On 8/31/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Mark Mitchell wrote:
Kenneth Zadeck wrote:
Even if we decide that we are going to process all of the functions in
one file at one time, we still have to have access to the functions that
are going to be inlined into the function being
hi,
Thanks for your explaination.I just figured out the
problem.actually a pattern named bgtu was generated by gcc and in
my backend ,i defined all branch patterns except bgtu.So when gcc
tried to match bgtu pattern ,it could not find it and generated
above mentioned error.Now i have defined
On Aug 30, 2006, at 9:55 PM, Jack Howarth wrote:
Try building
some of the g++ testcases manually and see what the errors
are.
Perhaps this is a problem:
grep 'Symbol not found' g++.log | sort | uniq -c
1254 dyld: Symbol not found: ___dso_handle
As some few people might already know, the GGCC (globalgcc) project is
just starting (partly funded within the ITEA framework by french,
spanish, swedish public money) - its kick off meeting is next week in
Paris.
GGCC aims to provide a (GPL opensource) extension to GCC for program
wide static
Any idea why ? I've looked around in the code to see how they parse
the data dependance tree but I don't see a difference.
Interesting.
So what statements *are* in the list of data dependences if not these.
Brad,
You build system certainly has issues. Why don't you strip
down your .cshrc or .bashrc to a completely empty file, open
a new terminal session so none of the previous .cshrc settings
are in effect and rebuild gcc trunk. Also, I am assuming you
are running MacOS X 10.4 and have at least
kernel coder [EMAIL PROTECTED] writes:
Thanks for your explaination.I just figured out the
problem.actually a pattern named bgtu was generated by gcc and in
my backend ,i defined all branch patterns except bgtu.So when gcc
tried to match bgtu pattern ,it could not find it and generated
Dear all,
Any idea why ? I've looked around in the code to see how they parse
the data dependance tree but I don't see a difference.
Interesting.
So what statements *are* in the list of data dependences if not these.
Ok apparently it's more a problem of optimization levels in O3 the
On Tue, Aug 30, 2005 at 05:44:52PM -0700, Mike Stump wrote:
On Aug 30, 2005, at 4:34 PM, Steve Ellcey wrote:
I see that it is timing out on a slow machine that I have. I tried
to look around to find out how and where the timeout limit was set
and could not find it.
[snip]
M-x grep
Daniel Berlin wrote:
On 8/31/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Mark Mitchell wrote:
Kenneth Zadeck wrote:
Even if we decide that we are going to process all of the functions in
one file at one time, we still have to have access to the functions
that
are going to be inlined into
On Thu, Aug 31, 2006 at 09:24:20AM -0700, Mark Mitchell wrote:
Here, we won't be making syscalls
Yes, you almost certainly will. If you've got a thousand object files,
you probably don't want to keep them all opened all the time; there are
these pesky things like open file descriptor limits,
Kenneth Zadeck wrote:
I am not so concerned with running out of virtual address space than I
am about being able to break this up so that it can be done in parallel,
on a farm of machines. Otherwise, lto can never be part of anyone's
compile/test loop.
I think we just expanded the scope of
Is there anyone out there who might have a SPARC environment with Ada
support who could run the attached Ada testcase on a version of gcc
patched with the attached patch? I'd like to verify whether the test
behaves correctly when compiled at -O0, -O1, and -O2. The expected
(correct) behavior is
Hello,
what you do seems basically OK to me. The problem is that you also need
to fix the ssa form for the virtual operands of the added calls
(i.e., you must call mark_new_vars_to_rename for each of the calls,
and update_ssa once at the end of tree_handle_loop).
Zdenek
Ok, by
Mark Mitchell wrote:
Kenneth Zadeck wrote:
I am not so concerned with running out of virtual address space than I
am about being able to break this up so that it can be done in parallel,
on a farm of machines. Otherwise, lto can never be part of anyone's
compile/test loop.
I think we
Daniel Jacobowitz wrote:
On Thu, Aug 31, 2006 at 09:24:20AM -0700, Mark Mitchell wrote:
Here, we won't be making syscalls
Yes, you almost certainly will.
OK, good point.
In any case, my concern is that we're worrying a lot about on-disk
encoding, but that there are lots of other hard
Brad,
If you google dyld: Symbol not found: ___dso_handle, you'll
come up with the following messages...
http://gcc.gnu.org/ml/gcc/2006-03/msg00712.html
http://gcc.gnu.org/ml/gcc/2006-03/msg00718.html
http://gcc.gnu.org/ml/gcc/2006-03/msg00735.html
So it certainly sounds like your cctools is
is there the data reference for it in the datarefs array?
Zdenek
Using this code after the construction of the data dependance :
datarefs = VEC_alloc (data_reference_p, heap, 10);
dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
compute_data_dependences_for_loop
Hello,
is there the data reference for it in the datarefs array?
Zdenek
Using this code after the construction of the data dependance :
datarefs = VEC_alloc (data_reference_p, heap, 10);
dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
Geoff,
What happened to regress to allow it to suddenly do make checks
at every svn revision? I assume it isn't a measly G4 anymore (grin).
If you have that many clock cycles to do builds and make checks
every revision how about adding in -m64 make checks now?
Jack
Hello:
We are students of computer sciences in the Santa Maria University,
Chile. We just want to know if the function gets it's too dangerous
for a warning. The fact is that our teacher's assistant give us a
homework, and one restriction was to use gcc to compile our code,
without warnings.
Hello:
We are students of computer sciences in the Santa Maria University,
Chile. We just want to know if the function gets it's too dangerous
for a warning. The fact is that our teacher's assistant give us a
homework, and one restriction was to use gcc to compile our code,
without
On Thu, Aug 31, 2006 at 05:52:16PM -0400, Miguel Angel Champin Catalan wrote:
We ask you for a simple explanation (if it's possible) about our
warning, telling that gets is not too dangerous, because in our case,
works perfectly, under some restrictions obviously.
Really a gcc-help topic but
Sorry I didn't reply to this earlier. I was unexpectedly in a place with
very bad network access.
The one exception to this is if the address of the temp is taken before
I call pop_temp_slots. In that instance, even though I may be done
with the temp, it needs to live until the end of the
Snapshot gcc-4.0-20060831 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060831/
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
I found this description in GCC Internals info file.
11.7 Constant Expression Types
==
...
`(const:M EXP)'
Represents a constant that is the result of an assembly-time
On Fri, Sep 01, 2006 at 07:42:08AM +0900, Mikiya Matsuzaka wrote:
`(const:M EXP)'
Represents a constant that is the result of an assembly-time
arithmetic computation. The operand, EXP, is an expression that
contains only constants (`const_int', `symbol_ref' and
mathieu lacage wrote:
I have spent a considerable amount of time looking at the abbrev tables
output by gcc are not totally random: their entries are sorted by their
abbrev code. That is, the abbrev code of entry i+1 is higher than that
of entry i.
That's an interesting observation.
Has anyone tried SPEC CPU 2006 with gcc mainline and 4.1 branch?
Currently, there is at least one regression affecting SPEC CPU 2006:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
I was wondering if anyone had run into problems with gcc. I need 3
patches for SPEC CPU 2006 to support gcc on
--- Comment #6 from krebbel at gcc dot gnu dot org 2006-08-31 07:43 ---
Subject: Bug 24367
Author: krebbel
Date: Thu Aug 31 07:43:36 2006
New Revision: 116599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116599
Log:
2006-08-31 Andreas Krebbel [EMAIL PROTECTED]
PR
--- Comment #7 from krebbel at gcc dot gnu dot org 2006-08-31 07:50 ---
Subject: Bug 24367
Author: krebbel
Date: Thu Aug 31 07:50:19 2006
New Revision: 116600
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116600
Log:
2006-08-31 Andreas Krebbel [EMAIL PROTECTED]
PR
--- Comment #8 from krebbel at gcc dot gnu dot org 2006-08-31 08:06 ---
Although the bug is latent in gcc 4.0 as well I've applied the patch to 4.1 and
4.2 only. I could not reproduce a failure with gcc 4.0 so I've left it as is
rather than risking new problems.
--
krebbel at gcc
--- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 ---
I have been unsuccessful in reproducing this problem on a i386-redhat-linux.
I don't get a failure compiling the testcase from comment 8.
I tried to compile the testcase from comment 7 and got the following errors:
--- Comment #10 from dorit at il dot ibm dot com 2006-08-31 08:22 ---
I think this can be closed?
(I opened a missed-optimization PR instead - PR28643)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #16 from bkoz at gcc dot gnu dot org 2006-08-31 09:08 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #4 from tbm at cyrius dot com 2006-08-31 09:55 ---
(In reply to comment #3)
I almost think it was caused by the patch which fixed PR 27115.
Martin, can you try a newer gcc 4.1.2 to double check that it is not a
regression there also?
No, 4.1.2 20060831 works
On Thu, 2006-08-31 at 08:08 +, dorit at il dot ibm dot com wrote:
--- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 ---
I have been unsuccessful in reproducing this problem on a i386-redhat-linux.
I think the failure can only reproduce on x86_64-linux-gnu and I
--- Comment #10 from pinskia at physics dot uc dot edu 2006-08-31 10:33
---
Subject: Re: [4.2 regression] ICE with
-ftree-vectorizer-verbose
On Thu, 2006-08-31 at 08:08 +, dorit at il dot ibm dot com wrote:
--- Comment #9 from dorit at il dot ibm dot com
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-08-31 10:34
---
(In reply to comment #10)
I think this can be closed?
Except we still crash on the 4.1 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #17 from bkoz at gcc dot gnu dot org 2006-08-31 10:46 ---
Subject: Bug 28671
Author: bkoz
Date: Thu Aug 31 10:45:59 2006
New Revision: 116601
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116601
Log:
2006-08-31 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-31 10:59 ---
Yes this was casued by that patch.
Anyways we do:
1627 /* ??? The middle-end will error on us for building a VLA outside
a
1628 function context. Methinks that's not it's purvey. So we'll
do
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-08-31 11:00
---
(In reply to comment #12)
So, how's this going for 4.1?
Well a regression was found in 4.2 caused by this patch so I am going to fix
that first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-31 11:06 ---
Doing:
Index: init.c
===
--- init.c (revision 116553)
+++ init.c (working copy)
@@ -1628,7 +1628,7 @@ build_new_1 (tree placement, tree type,
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-31 11:18 ---
Mine, we want/need to use build_distinct_type_copy instead but other than that
it should be ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org
ICE/tree check with ftree-vectorize -O2:
(sid)44:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -ftree-vectorize -O2
-c
xskat-xdial.c
xskat-xdial.c: In function 'di_eigenertisch':
xskat-xdial.c:9694: internal compiler error: tree check: expected class
'constant', have 'declaration'
--- Comment #1 from tbm at cyrius dot com 2006-08-31 12:30 ---
Created an attachment (id=12160)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12160action=view)
test case
Testcase from application xskat.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
build of gfortran fails. Configure is
../configure --prefix=/opt/gcc-4_0 --with-gmp=/sw
--enable-languages=fortran,c++
built fails with
[...rwin8.7.1/libgfortran] /usr/local/gcc-4_0/build/./gcc/xgcc
-B/usr/local/gcc-4_0/build/./gcc/ -B/opt/gcc-4_0/i686-apple-darwin8.7.1/bin/
--- Comment #34 from dje at watson dot ibm dot com 2006-08-31 13:50 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
guenter at roeck-us dot net writes:
guenter Hmm ... what would be the point ? evlwwsplat copies 32 bit memory
content into
guenter the upper and lower
--- Comment #1 from aph at gcc dot gnu dot org 2006-08-31 13:58 ---
-findirect-dispatch doesn't work with Java source. Compile to.class first.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from dje at watson dot ibm dot com 2006-08-31 14:23 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
guenter at roeck-us dot net writes:
guenter Hmm ... what would be the point ? evlwwsplat copies 32 bit memory
content into
guenter the upper and lower
--- Comment #21 from eweddington at cso dot atmel dot com 2006-08-31 15:39
---
Created an attachment (id=12161)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12161action=view)
Patch to select 32 bit DWARF addresses for the AVR target.
--
--- Comment #22 from eweddington at cso dot atmel dot com 2006-08-31 15:41
---
Created an attachment (id=12162)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12162action=view)
Patch to add a note to the ELF file to notify the difference between old ELF
files and new ELF files with
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 16:02 ---
What version of gfortran are you trying to build?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-31 16:13 ---
I cannot reproduce this on either a powerpc64-linux-gnu build or a
i686-linux-gnu build.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from hjl at lucon dot org 2006-08-31 16:57 ---
It also fails with gcc 4.1 revision 116602.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-08-31 16:59
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tromey at gcc dot gnu dot org 2006-08-31 17:24 ---
Subject: Bug 28698
Author: tromey
Date: Thu Aug 31 17:23:57 2006
New Revision: 116603
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116603
Log:
PR libgcj/28698:
* libgcj_bc.c
--- Comment #41 from sayle at gcc dot gnu dot org 2006-08-31 17:35 ---
Subject: Bug 22313
Author: sayle
Date: Thu Aug 31 17:35:32 2006
New Revision: 116604
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116604
Log:
PR other/22313
* dwarf2out.c (add_fde_cfi): Use
--- Comment #13 from paulthomas2 at wanadoo dot fr 2006-08-31 17:41 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
hjl at lucon dot org wrote:
--- Comment #12 from hjl at lucon dot org 2006-08-31 16:57 ---
It also fails with gcc 4.1 revision
--- Comment #42 from pinskia at gcc dot gnu dot org 2006-08-31 17:53
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from janis at gcc dot gnu dot org 2006-08-31 17:57 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=116276
r116276 | mmitchel | 2006-08-20 23:53:10 + (Sun, 20 Aug 2006)
--
janis at gcc dot gnu dot org
--- Comment #14 from hjl at lucon dot org 2006-08-31 18:08 ---
I don't think it is specific to operator. I got the same failure with function:
[EMAIL PROTECTED] wrf-1]$ cat yyy.f90
! { dg-do compile }
! Tests the fix for a further regression caused by the
! fix for PR28788 and posted as
--- Comment #8 from pcarlini at suse dot de 2006-08-31 18:08 ---
Now I know how to fix it...
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-31 18:09 ---
Confirmed by Janis.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from hjl at lucon dot org 2006-08-31 18:11 ---
I think the issue may be that gfc_get_derived_type creates a new TREE_TYPE for
the same type when there is an existing one. type1 == type2 no longer
works when type1 and type2 have different memory locations even if they are
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-08-31 18:16 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01171.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from paulthomas2 at wanadoo dot fr 2006-08-31 18:20 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
HJ
Yes, I think that function interfaces in general are of the same
horrible kind.
Thanks
Paul
--
--- Comment #17 from hjl at lucon dot org 2006-08-31 18:28 ---
The previous gfc_get_derived_type tries to reuse the same TREE_TYPE:
/* In a module, if an equal derived type is already available in the
specification block, use its backend declaration and those of its
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-08-31 18:41 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
hjl,
--- Comment #17 from hjl at lucon dot org 2006-08-31 18:28 ---
The previous gfc_get_derived_type tries to reuse the same
with fixed PR26208 we can throw exceptions from signal handlers.
catch() works pretty fine with complex call-chain but fails on
simple testcase.
#include csignal
void signalHandler( int signalNumber )
{
throw 0;
}
int main()
{
signal( SIGSEGV, signalHandler );
try
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 19:08 ---
I think you forgot -fnon-call-exceptions which is need to be used if you want
non calls to be able to throw.
Can you try with that option and report if that fixes the problem?
--
--- Comment #2 from pluto at agmk dot net 2006-08-31 19:13 ---
it doesn't help. `jmp .L2` skips catch block :)
main:
pushq %rbx
movl$_Z13signalHandleri, %esi
movl$11, %edi
callsignal
movl$0, 0
jmp .L2
.L8:
--- Comment #3 from uros at kss-loka dot si 2006-08-31 19:15 ---
Confirmed on x86_64.
Backtrace:
(gdb) bt
#0 build_vector (type=0x2db3e6e0, vals=0x2db37cc0) at
../../gcc-svn/trunk/gcc/tree.c:973
#1 0x007b829d in force_const_mem (mode=V2DImode, x=0x2da089e0) at
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-31 19:21 ---
Can someone add the dump of -fdump-tree-final_cleanup ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-31 19:27 ---
Actually yes it is branched because it should be but movl$0, 0
Means store 0 into the address of 0 so it works. The branch over is ok because
well this is the way zero overhead exceptions works.
--
--- Comment #5 from tbm at cyrius dot com 2006-08-31 19:28 ---
(In reply to comment #4)
Can someone add the dump of -fdump-tree-final_cleanup ?
;; Function set_names (set_names)
set_names (ob, idx)
{
char * * vect_ptt1.38;
vector char * vect_cst_.34;
static struct tx_typ tt1;
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-08-31 19:34 ---
Subject: Bug 28839
Author: rakdver
Date: Thu Aug 31 19:33:56 2006
New Revision: 116605
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116605
Log:
PR tree-optimization/28839
* tree-into-ssa.c
--- Comment #8 from tbm at cyrius dot com 2006-08-31 20:10 ---
Is this the same bug?
(sid)59:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/g++ -c mini.c
mini.c:40: error: variable-size type declared outside of any function
mini.c:40: error: variable-size type declared
--- Comment #9 from tbm at cyrius dot com 2006-08-31 20:21 ---
Created an attachment (id=12163)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12163action=view)
preprocessed source
Actually, can you please check when you get home if this is the same bug?
--
--- Comment #7 from pluto at agmk dot net 2006-08-31 20:22 ---
(In reply to comment #6)
The author didn't respond to my question about copyright assignment, so I
don't
think the patch can be applied.
it's weird to waiting years for respond about such trivial patch.
--
--- Comment #5 from janis at gcc dot gnu dot org 2006-08-31 20:27 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=99691
r99691 | kazu | 2005-05-14 00:46:12 + (Sat, 14 May 2005)
--
janis at gcc dot gnu dot org
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-31 20:28 ---
(In reply to comment #5)
A regression hunt on powerpc-linux identified this patch:
That means it is a latent bug :) oh well, nothing useful really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
--- Comment #4 from janis at gcc dot gnu dot org 2006-08-31 20:29 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=116213
r116213 | rakdver | 2006-08-17 08:22:05 + (Thu, 17 Aug 2006)
--
janis at gcc dot gnu dot org
We're now rejecting the minimum/maximum operator in some c++ code.
This is a new regression. It works with 20060806.
(sid)106:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c orig.c
orig.c: In member function 'virtual void IBox::Rebuild()':
orig.c:10: error: expected primary-expression
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 20:45 ---
This extension was removed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from hjl at lucon dot org 2006-08-31 21:00 ---
The new patch works for the testcase. But wrf still fails:
[EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.2/bin/gfortran -c -o
ESMF_Clock.fppized.o -I. -I./netcdf/include -O2 -ffast-math
-DSPEC_CPU_LINUX
--- Comment #4 from luke dot powell at bjservices dot com 2006-08-31 21:59
---
(In reply to comment #3)
It is the SVN trunk, so a svn snapshot will be a snapshot of the mainline.
I attempted a rebuild with the trunk at SVN revision 116602. The compilation
did get past the previous
--- Comment #9 from tromey at gcc dot gnu dot org 2006-08-31 22:00 ---
Subject: Bug 28698
Author: tromey
Date: Thu Aug 31 22:00:06 2006
New Revision: 116607
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116607
Log:
PR libgcj/28698:
* libgcj_bc.c
--- Comment #7 from echristo at apple dot com 2006-08-31 22:14 ---
After discussion with DJ I'm going to mark this as WONTFIX. We'll just allow
people to shoot themselves in the foot if they try to disable a directory that
they shouldn't.
--
echristo at apple dot com changed:
--- Comment #19 from bkoz at gcc dot gnu dot org 2006-08-31 22:20 ---
Subject: Bug 28671
Author: bkoz
Date: Thu Aug 31 22:20:09 2006
New Revision: 116608
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116608
Log:
2006-08-31 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #20 from hjl at lucon dot org 2006-08-31 22:24 ---
Here it is:
[EMAIL PROTECTED] wrf-1]$ cat zzz.f90
module bar
implicit none
public
type ESMF_Time
sequence
integer :: MM
end type
public operator (+)
private add
interface operator (+)
module procedure
--- Comment #18 from jconner at gcc dot gnu dot org 2006-08-31 23:44
---
Subject: Bug 25505
Author: jconner
Date: Thu Aug 31 23:44:00 2006
New Revision: 116613
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116613
Log:
2006-08-31 Josh Conner [EMAIL PROTECTED]
PR
1 - 100 of 116 matches
Mail list logo
