I really do not like the current name either, but i do not have a better
one.
Since the whole file is about MAINTAINERS, I would suggest changing the
categories to:
- Committers (i.e. committing maintainers)
- Reviewers (i.e. reviewing maintainers)
- Non-algorithmic committers
Paolo
On Fri, 27 Jul 2007, Richard Smith wrote:
| Gabriel Dos Reis wrote:
|
| On Wednesday July 18, 2007 I brought factual evidence to
| that claim by showing g++ behaviour on all of the examples
| discussed (including those from the decltype proposal).
| (All I did was to encode call expressions,
I liked the idea of 'Reviewers' more than any of the other options.
I would like to go with this patch, unless we find a much better
option?
Thanks.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 126951)
+++ MAINTAINERS
Hello,
I liked the idea of 'Reviewers' more than any of the other options.
I would like to go with this patch, unless we find a much better
option?
to cancel this category of maintainers completely? I guess it was
probably discussed before (I am too lazy to check), but the existence
of
On 27/07/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
On Thu, Jul 26, 2007 at 05:13:30PM -0400, Diego Novillo wrote:
I would like to propose the creation a new mailing list:
[EMAIL PROTECTED]
IMHO, DJ hit the nail on the head. Those people who can't figure out to
post to
On Thu, Jul 26, 2007 at 05:13:30PM -0400, Diego Novillo wrote:
I would like to propose the creation a new mailing list:
[EMAIL PROTECTED]
IMHO, DJ hit the nail on the head. Those people who can't figure out to
post to gcc-help@ instead of gcc@ surely won't figure out to post to
gcc-newbies@
The test there is sort of hack, I would just remove it at this stage and
we can work out better fix for that testcase later. I hope that with my
plans for declaration merging pass we can get round such weird side
effects of in place declaration replacement.
Will do.
How about all the other
I am working on gcc 4.1.1 and itanium2 architecture. I instrumented
each ld and st instruction in final_scan_insn() by looking at the insn
template (These instrumentations are used to do some security checks).
These instrumentations incur high performance overhead when running
specint benchmarks.
If we do not manage to answer such mails on gcc@ (due to ressource reasons
I suppose) than I doubt we will do better on a separate mailinglist. The
amount of traffic with newbie questions is not dominant on gcc@ or
gcc-patches@ anyway, so I see little point in directing them elsewhere
where
I am not sure if a new list will help. Some have argued that long time
developers may be discouraged to participate in such list and that new
developers would be discouraged from participating in the main list. I
think both are pretty good arguments.
That's my concern as well. Moreover, how
Since the whole file is about MAINTAINERS, I would suggest changing the
categories to:
- Committers (i.e. committing maintainers)
- Reviewers (i.e. reviewing maintainers)
- Non-algorithmic committers
I like the idea of reviewers, but think committers is confusing. Perhaps
full and
http://gcc.gnu.org/svn/gcc/branches/lto/ChangeLog
http://gcc.gnu.org/svn/gcc/branches/gimple-tuples-branch/ChangeLog
2007-07-17 Nick Clifton [EMAIL PROTECTED]
* COPYING3: New file. Contains version 3 of the GNU General
Public License.
* COPYING3.LIB: New file.
Since I have been around no more than one year, perhaps my perspective
could have some interest for the discussion.
I am not sure if a new list will help. Some have argued that long time
developers may be discouraged to participate in such list and that new
developers would be discouraged from
Laurent GUERBY wrote:
On Thu, 2007-07-26 at 17:13 -0400, Diego Novillo wrote:
Or maybe this is not a good idea, but I have certainly seen some folks
that complain about our less than friendly practices.
Alternative would be to keep gcc@ and document that
emails with subject tag [BEGINNER]
On Jul 27, 2007, at 07:54, Diego Novillo wrote:
+Note that individuals who maintain parts of the compiler as reviewers
+need approval changes outside of the parts of the compiler they
+maintain and also need approval for their own patches.
s/approval changes/approval for changes/ ?
Gabriel Dos Reis wrote:
At the C++ language level, there are concerns of how to specify the
interaction. All I claimed was that the observable semantics
does not need further specification to make the examples work.
At the compiler internals level, how overloads are handled has a much
On Fri, 27 Jul 2007, Richard Smith wrote:
| | The general philosophy in the current ABI would seem to be
| | that the expression is encoded in terms of its template
| | parameters, and not with the evaluated expression with the
| | subsituted argument.
|
| That is correct. For a compiler,
On 7/27/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
Another recent example: http://gcc.gnu.org/ml/gcc/2007-07/msg00456.html
(Not a single answer).
Summing up, I am not sure whether a separate list would help but in my
opinion there are a few things that will:
If we do not manage to
On Thu, Jul 26, 2007 at 12:36:19PM -0700, Ian Lance Taylor wrote:
Rask Ingemann Lambertsen [EMAIL PROTECTED] writes:
For example, several targets would build/bootstrap and regtest fine with
reload's find_valid_class() implemented as gcc_abort(). And guess what,
there seems to be an
On Fri, Jul 27, 2007 at 11:26:22AM +0100, Manuel López-Ibáñez wrote:
Just an example. There are people that post patches in bugzilla and
they seem interested in getting them integrated but normally they
break coding style or don't have changelog or didn't even run the
testsuite. Of course, the
On 27/07/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
On Fri, Jul 27, 2007 at 11:26:22AM +0100, Manuel López-Ibáñez wrote:
Just an example. There are people that post patches in bugzilla and
they seem interested in getting them integrated but normally they
break coding style or
2007/7/27, Joe Buck [EMAIL PROTECTED] wrote:
On Fri, Jul 27, 2007 at 04:22:31PM +0200, J.C. Pizarro wrote:
The users don't want to join and detach to many mailing lists to post
only a message once by week or month. He wants to post quickly,
not to post slowly more than 10 minutes.
You're
On 7/27/07 11:53 AM, J.C. Pizarro wrote:
It's too early Nick Clifton! Delay a little until 31th of July, please. ;)
These came in via merges with mainline. I doubt that either branch has
any issues with this change. The tuples branch certainly welcomes these
changes.
吴曦 [EMAIL PROTECTED] writes:
I am working on gcc 4.1.1 and itanium2 architecture. I instrumented
each ld and st instruction in final_scan_insn() by looking at the insn
template (These instrumentations are used to do some security checks).
These instrumentations incur high performance overhead
On 7/27/07 11:55 AM, Joe Buck wrote:
Why not provide a permanent home for the GCC summit proceedings at
gcc.gnu.org? It seems the logical place.
That's what I've done. The .pdf is *in* gcc.gnu.org. The others could
be sucked in as well. They're now pointing to gccsummit.
Dennis Clarke [EMAIL PROTECTED] writes:
SUMMARY : the stage 2 compiler produces the wrong binary type for this
machine
This question is appropriate for the [EMAIL PROTECTED] mailing list
rather than the gcc@gcc.gnu.org list. Please take any followups to
gcc-help. Thanks.
I was not
Dennis Clarke [EMAIL PROTECTED] writes:
Dennis Clarke [EMAIL PROTECTED] writes:
SUMMARY : the stage 2 compiler produces the wrong binary type for this
machine
This question is appropriate for the [EMAIL PROTECTED] mailing list
rather than the gcc@gcc.gnu.org list. Please take any
Hi all,
Bootstrap including gfortran has been broken on native i386-pc-mingw32
for at least 10 days, with the C compiler having an ICE while
compiling libgfortran/io/write.c. I finally found the opportunity to
reduce the ICE to the following code:
$ cat write.i
extern void fflush (int);
extern
So, the idea of a new mailing list does not seem to be too popular. I'm
interested in trying to attract new developers and provide basic
information to get folks started.
The basic motivation was that I've heard from several people both
outside and inside GCC development that we can be a pretty
Pranav Bhandarkar [EMAIL PROTECTED] writes:
I am working on a private port and am seeing the following problem.
For a function returning a double the value is stored by the function
in memory. cse removes one of the two loads (to retrieve this returned
value) after the function is called.
what options do I need to set on the configure line in order for this to
work?
See http://gcc.gnu.org/gcc-4.2/changes.html , SPARC section.
--
Eric Botcazou
Hi All,
I am working on a private port and am seeing the following problem.
For a function returning a double the value is stored by the function
in memory. cse removes one of the two loads (to retrieve this returned
value) after the function is called.
To elaborate, the following is the dump
Where does reg 178 come from? It does not appear in the other insns
you listed.
I am sorry, my mistake. I meant to say that the dump was only a part
of the entire dump of the function. reg 178 is the result of a
previous call to __floatsidf and is defined by the following insn.
(insn 19 18 21
what options do I need to set on the configure line in order for this to
work?
See http://gcc.gnu.org/gcc-4.2/changes.html , SPARC section.
You Sir are magnificent and wonderful !
Thank you so very much.
Dennis
Dennis Clarke wrote:
At the moment GCC 4.2.1 seems to be tied to the UltraSparc processor and
thus the older sun4m and 32-bit Sparc machines are being ignored.
The default cpu is v8plus. You can change that by using the configure
option --with-cpu=v8 or --with-cpu=v7 depending on how old
Dennis Clarke wrote:
At the moment GCC 4.2.1 seems to be tied to the UltraSparc processor and
thus the older sun4m and 32-bit Sparc machines are being ignored.
The default cpu is v8plus. You can change that by using the configure
option --with-cpu=v8 or --with-cpu=v7 depending on how old
Hi Naren
From the description that you just gave me, it looks like you aren't doing
anything special, just compiling a simple hello world program on SFU3.5.
The only known issues wrt to this is that you might have DEP(Data Execution
Protection) enabled which could be causing this. We have
unshare_all_rtl used to unshare DECL_RTLs as well as expressions in the
instruction stream. That changed with:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00541.html
I think that patch was in itself the right thing to do. However, in
anticipation of the old unshare_all_rtl behaviour,
I have updated ecj.jar and ecj-source.tar.bz2 on sourceware.org.
This is the reference ecj that is used to build the .class files in
libjava.
If you have a build where compiling from .java to .class is enabled,
you must update your ecj.jar. You can do this by running
contrib/download_ecj.
I
On Fri, Jul 27, 2007 at 02:51:00PM +0100, Manuel López-Ibáñez wrote:
On 27/07/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
If you ask me, we should rename gcc@ to gcc-development@ and maybe rename
gcc-help@ to [EMAIL PROTECTED]
... gcc-dev@, keep gcc@ as an alias for gcc-dev@,
On Fri, 27 Jul 2007, Phil Edwards wrote:
Putting gcc-help as the first address mentioned in lists.html is a
good idea.
That's a good idea. Done thusly.
Gerald
Index: lists.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
Snapshot gcc-4.3-20070727 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070727/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
I am working on gcc 4.1.1 and itanium2 architecture. I instrumented
each ld and st instruction in final_scan_insn() by looking at the insn
template (These instrumentations are used to do some security checks).
These instrumentations incur high performance overhead when running
Hi
I am in the process of verifying that gcc (3.3.2) produces traceable
object code (ie. gcc does not introduce 'hidden' structure into the
object code).
I have created a file with several functions containing various
combinations of C constructs and I intend to examine the resulting
object code
--- Comment #11 from patchapp at dberlin dot org 2007-07-27 06:22 ---
Subject: Bug number PR32522
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/2007-07/msg01962.html
--
--- Comment #10 from belyshev at depni dot sinp dot msu dot ru 2007-07-27
06:18 ---
(In reply to comment #9)
Patch posted.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2007-07-27 06:50
---
Hum, I don't see anything in rev. 123623
(http://gcc.gnu.org/viewcvs?view=revrevision=123623) that looks too
suspicious. What would need to be done now, in my opinion, is to:
1. check that rev. 123622 passes,
In GNOME's gobject object-oriented code, each type has a get_type function.
Something like, eg:
GType
pango_layout_line_get_type(void)
{
static GType our_type = 0;
if (our_type == 0)
our_type = g_boxed_type_register_static (I_(PangoLayoutLine),
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-27 09:04 ---
Fixed as obvious.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-07-27 14:28
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-07-27 14:26
---
Subject: Bug 32035
Author: fxcoudert
Date: Fri Jul 27 14:26:43 2007
New Revision: 126978
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126978
Log:
PR fortran/32035
* trans-stmt.c
--- Comment #1 from danglin at gcc dot gnu dot org 2007-07-27 14:46 ---
Also occurs on hppa-linux.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Testcase
test-ice.cpp
#include iostream
#include emmintrin.h
const __m128i tmp={0,0};
g++ -O3 -g -c -msse2 test-ice.cpp
I get the following error:
test-ice.cpp:5: internal compiler error: in rtl_for_decl_init, at
dwarf2out.c:10071
Please submit a full bug report,
with preprocessed source if
--- Comment #11 from eweddington at cso dot atmel dot com 2007-07-27 14:23
---
Subject: RE: [avr-gcc] Optimization decrease performance of
struct assignment.
--- Comment #10 from dmixm at marine dot febras dot ru
2007-07-27 01:24 ---
Yes, results are:
avr-gcc-3.3.6:
--- Comment #1 from patchapp at dberlin dot org 2007-07-27 16:00 ---
Subject: Bug number PR testsuite/32471
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/2007-07/msg01988.html
--
Bootstrap including gfortran has been broken on native i386-pc-mingw32 for at
least 10 days, with the C compiler having an ICE while compiling
libgfortran/io/write.c. I finally found the opportunity to reduce the ICE to
the following code:
$ cat write.i
extern void fflush (int);
extern
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-07-27 16:30
---
Subject: Bug 32760
Author: jvdelisle
Date: Fri Jul 27 16:30:10 2007
New Revision: 126981
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126981
Log:
2007-07-27 Jerry DeLisle [EMAIL PROTECTED]
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-07-27 11:24
---
(In reply to comment #6)
should one add a mingw maintainer to the CC?
Adding Danny Smith to the CC list.
BTW, this one misses the wrong-code keyword (and I don't have permission to
add
it, which is
Compiling the test case below gives the following ICE:
bug.C: In function 'void bar()':
bug.C:30: internal compiler error: in build_int_cst_wide, at tree.c:890
Please submit a full bug report,
I think this might be related to bug 20103, except that gcc-4.1 handles the
test case just fine. The
--- Comment #3 from pault at gcc dot gnu dot org 2007-07-27 09:03 ---
Subject: Bug 32903
Author: pault
Date: Fri Jul 27 09:03:41 2007
New Revision: 126974
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126974
Log:
2007-07-27 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-27 09:35 ---
The Java front-end has the same problem.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from pinskia at gcc dot gnu dot org 2007-07-27 09:42
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-27 09:50 ---
Subject: Bug 32903
Author: burnus
Date: Fri Jul 27 09:49:55 2007
New Revision: 126975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126975
Log:
2007-07-27 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #1 from pcarlini at suse dot de 2007-07-27 09:26 ---
Note that we are talking about one of the *legacy*, extension, HP/SGI
containers: those in general are only minimally maintained these days because
standard replacements are being prepared for C++0x and already available
--- Comment #8 from patchapp at dberlin dot org 2007-07-27 10:55 ---
Subject: Bug number PR31211
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/2007-07/msg01975.html
--
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-27 15:09 ---
(In reply to comment #5)
Paul, any plans to get the fix from comment #3 into trunk?
Gee, Daniel - I had totally forgotten this one. Will do.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-07-27 14:47
---
Here is the shortest Fortran testcase I could come with:
$ cat a.f90
subroutine foo
integer :: i
do
i = i + 1
select case (' ')
case default
call bar (i + 1, i - 1)
end select
enddo
--- Comment #8 from jv244 at cam dot ac dot uk 2007-07-27 12:03 ---
(In reply to comment #7)
Added. I can't give you permission to add keywords, the only thing I can do is
make you a CONFIRMer (which I just did).
OK, I might use that from time to time. Who has the power to allow me
This is with the polyhedron test fatigue on AMD Athlon64 X2 4800+ with
openSUSE 10.3b6 x86-64 and today's GCC 4.3.0 20070727.
Test case available from:
http://www.polyhedron.co.uk/MFL6VW74649
Using on one hand
gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear
-ftree-vectorize
--- Comment #2 from debian-gcc at lists dot debian dot org 2007-07-27
16:57 ---
this is not a bug in gij, but in glibc (2.6?), apparently fixed by:
2006-11-30 Jan Kratochvil [EMAIL PROTECTED]
* sysdeps/unix/sysv/linux/x86_64/clone.S: Provide CFI for the outermost
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2007-07-27 16:34
---
Subject: Bug 32760
Author: jvdelisle
Date: Fri Jul 27 16:33:50 2007
New Revision: 126982
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126982
Log:
2007-07-27 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #2 from pcarlini at suse dot de 2007-07-27 17:14 ---
... actually, if you are on a 32-bit machine, your code is invalid, because
ostream::write takes a streamsize as second argument, which is a ptrdiff_t.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32916
--- Comment #3 from paolo at gcc dot gnu dot org 2007-07-27 17:25 ---
Subject: Bug 32907
Author: paolo
Date: Fri Jul 27 17:25:04 2007
New Revision: 126988
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126988
Log:
2007-07-27 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from pcarlini at suse dot de 2007-07-27 17:25 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from kargl at gcc dot gnu dot org 2007-07-27 17:00 ---
Fixed on trunk.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
g++ (or libstdc++ to be more exact) failed on the following simple testcase:
#include iostream
#include fstream
#include cstdlib
int main()
{
try {
const size_t bufsize = 2252778560;
char* buf = new char[bufsize];
std::memset(buf, 0x22, bufsize);
std::ofstream o(test.data);
--- Comment #25 from zadeck at naturalbridge dot com 2007-07-27 17:29
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
This patch rearranges the updating of the local dataflow info when
building reg_dead notes. The need for this was that processing was not
correctly
--- Comment #1 from pcarlini at suse dot de 2007-07-27 17:08 ---
We badly need more information about your system and a tescase easier to use:
you are allocating on the heap more than 2GB at once! Anyway, actually only
4.1.2 has large file support on selected, linux, platforms, which
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-07-27 17:13
---
Subject: Bug 32346
Author: mmitchel
Date: Fri Jul 27 17:13:29 2007
New Revision: 126986
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126986
Log:
PR c++/32346
* call.c
--- Comment #24 from zadeck at gcc dot gnu dot org 2007-07-27 17:22 ---
Subject: Bug 32749
Author: zadeck
Date: Fri Jul 27 17:22:14 2007
New Revision: 126987
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126987
Log:
2007-07-26 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2007-07-27 16:53
---
Fixed on 4.3
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2007-07-27 16:59 ---
Subject: Bug 32899
Author: kargl
Date: Fri Jul 27 16:59:32 2007
New Revision: 126985
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126985
Log:
2007-07-26 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #4 from patchapp at dberlin dot org 2007-07-27 17:35 ---
Subject: Bug number PR32880
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/2007-07/msg01998.html
--
--- Comment #26 from zadeck at naturalbridge dot com 2007-07-27 17:33
---
revision 126987
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #3 from debian-gcc at lists dot debian dot org 2007-07-27
18:19 ---
Reopened:
http://lists.debian.org/debian-glibc/2007/07/msg00346.html:
On Thu, Jul 26, 2007 at 09:16:00PM +, [EMAIL PROTECTED] wrote:
+2006-11-30 Jan Kratochvil [EMAIL PROTECTED]
+
+ *
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-27 18:47 ---
While I'm working on namelists anyway ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from satyaakam at yahoo dot co dot in 2007-07-27 18:40
---
its on X86_64 bit box.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32916
--- Comment #4 from pcarlini at suse dot de 2007-07-27 18:43 ---
then, assuming everything is ok, you have enough memory, etc, your code works,
something is wrong with your specific system and we need more details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32916
--- Comment #5 from pcarlini at suse dot de 2007-07-27 19:23 ---
In any case, just tried your specific testcode on an up to date x86_64-linux
machine and the problem cannot be reproduced. Make sure the system where you
are trying to install the 4.1.x compiler is up to date as regards
--- Comment #1 from jb at gcc dot gnu dot org 2007-07-27 19:53 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02008.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32909
--- Comment #12 from rosana07a at gmail dot com 2007-07-27 19:56 ---
Thanks gfortran team!
--
rosana07a at gmail dot com changed:
What|Removed |Added
--- Comment #19 from dominiq at lps dot ens dot fr 2007-07-27 19:34 ---
Subject: Re: [4.3 regression] HUGE(1.0d0) output as
+Infinity on ppc-darwin8
Hum, I don't see anything in rev. 123623
(http://gcc.gnu.org/viewcvs?view=revrevision=123623) that looks too
suspicious. What would
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-27 20:27 ---
Try this testcase instead ...
subroutine test(cha)
implicit none
character(len=10) :: cha(1:) ! added lower-bound
namelist /z/ cha
end subroutine test
--
Tried a make profiledbootstrap with gcc 4.2 branch as of 070727; it failed
with
../../gcc/gcc/varasm.c: In function 'default_elf_asm_named_section':
../../gcc/gcc/varasm.c:6227: error: coverage mismatch for function
'default_elf_
asm_named_section' while reading counter 'arcs'
--- Comment #5 from tromey at gcc dot gnu dot org 2007-07-27 20:11 ---
I don't think we should use this particular patch. My reason is that
ordering alone is insufficient to guarantee success here, if the user
uses make -j.
Instead, explicit dependencies should be used. In addition
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2007-07-27 20:40
---
Dominique,
I have the same problem as FX. I do not have access to this platform. If I
could secure shell (ssh) into one of these, I would work on this.
Your idea on the order of #defines is probably on the
--- Comment #5 from dougkwan at google dot com 2007-07-27 20:54 ---
Created an attachment (id=13989)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13989action=view)
Proposed fix for SEGV problem in dwarf2out.c in bug 31899
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-07-27 20:51
---
(In reply to comment #12)
Thanks gfortran team!
Hum, thanks for the thanks! However, I feel it would be better to keep this
open because the code that the front-end previously generated was OK and
exposed a
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-07-27 21:06
---
This is the same bug as PR 32873 so I am going to close it as a dup.
*** This bug has been marked as a duplicate of 32873 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
1 - 100 of 148 matches
Mail list logo
