--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-06
22:03 ---
The "floating constant exceeds range" message comes from interpret_float in
c-lex.c, which does test just "pedantic", rather than CPP_PEDANTIC(pfile). So,
while the preprocessor warning about use of a hexa
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06
22:26 ---
Fixed on the mainline.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06
22:27 ---
Subject: Bug 8972
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-06 22:26:59
Modified files:
gcc: ChangeLog
gcc/config/arc : ar
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06
22:29 ---
Fixed on the mainline for 4.1.0.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06
22:29 ---
Subject: Bug 8973
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-06 22:29:46
Modified files:
gcc: ChangeLog
gcc/config/arc : ar
--- Additional Comments From sje at cup dot hp dot com 2005-09-06 22:35
---
It looks like there are some patches to increase ARG_MAX on HP-UX 10.* OS
releases. They might provide a workaround.
>From HP Chart/bug report JAGaa11744:
A patch has been provided which will allow the kernel
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06
22:43 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23756
--- Additional Comments From sje at cup dot hp dot com 2005-09-06 22:53
---
It looks like this is the same kind of bug as PR 23556 but in a different place.
I fixed convert_real in io/read.c to resolve PR 23556, this is extract_real in
io/write.c. I will submit a patch in the next day o
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-06 23:09
---
(In reply to comment #0)
This is incorrect code, which should generate an error, rather than an ICE.
As ifort9.0 puts it:
fortcom: Error: ../pr21986.f90, line 11: This procedure cannot be PUBLIC since
it ha
I will attach the test.ii file later, but here's the sample source code:
#include
using namespace std;
int main()
{
cout << dec << -1 << endl;
cout << hex << -1 << endl;
return 0;
}
The expected output is:
-1
-1
The actual output is:
-1
I found the problem in local_facet
--- Additional Comments From x at xman dot org 2005-09-06 23:51 ---
Created an attachment (id=9674)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9674&action=view)
Preprocessed file from g++ --save-temp
This is what the sample program looks like after running it through the
preproc
--
What|Removed |Added
Component|c++ |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
--- Additional Comments From x at xman dot org 2005-09-06 23:53 ---
This bug seems to exist in the version of g++4 included with RHEL4. I haven't
tested against the latest release, but I'm guessing it's still there.
--
What|Removed |Added
-
--- Additional Comments From x at xman dot org 2005-09-06 23:55 ---
Realized this should be filed against libstdc++
--
What|Removed |Added
Component|c++
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06
23:55 ---
Subject: Bug 22211
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-06 23:53:46
Modified files:
libjava: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06
23:55 ---
Subject: Bug 22211
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-06 23:53:46
Modified files:
libjava: Change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06
23:56 ---
ICC also produces the same output.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-09-07 00:14 ---
Subject: Re: [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list
too long
> It looks like there are some patches to increase ARG_MAX on HP-UX 10.* OS
> releases. They might provide a
--
What|Removed |Added
Known to fail||2.95 3.4.0 4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
java::lang::ConcreteProcess::nativeSpawn appears to call several functions that
are not async-signal-safe between the fork and exec in the child, including
_Jv_Malloc. This is unsafe by Posix rules. I'm unsure whether it can deadlock
on Linux.
These actions should be performed before the fork
I'm cross compiling for an embedded PowerPC/Altivec processor on an i386
solaris box. When cpp is invoked on the file attached to this report, the
system thrashes the disk for few minutes, then runs out of memory. I tried
increasing swap space, but the preprocessor really shouldn't need about
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
00:24 ---
This is a dup of bug 19411. This is fixed in 4.1.0 by a re-implementation of
altivec functions.
*** This bug has been marked as a duplicate of 19411 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
00:25 ---
*** Bug 23759 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-07 00:38
---
gcc is correct. Ambiguation of base class members does not happen based
on assigning to different types.
W.
--
What|Removed |Added
--
--- Additional Comments From x at xman dot org 2005-09-07 00:47 ---
Created an attachment (id=9676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9676&action=view)
Removed unneeded #include
I realized the sample test.ii output was including the header even
though it wasn't necess
--- Additional Comments From Daniel dot Davies at xerox dot com 2005-09-07
00:49 ---
Any idea when 4.1.0 will be released? Comments on gcc.gnu.org from July says
Stage 3 will complete on Thursday.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23759
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
00:49 ---
Confirmed based on:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
--
What|Removed |Added
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-09-07 01:01 ---
Subject: Re: [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list
too long
> It looks like there are some patches to increase ARG_MAX on HP-UX 10.* OS
> releases. They might provide a
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 01:07
---
It turns out that Sun handles this in a strange way. To ensure that libjawt.so
is found automatically, Sun's java executable prepends $JAVA_HOME/jre/lib/i386
to LD_LIBRARY_PATH then re-exec's itself within the n
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07
01:26 ---
Indeed, that is what is happening. -m64 ought to normally imply
-mpowerpc-gfxopt, because all powerpc64 capable chips also support the insns
enabled by -mpowerpc-gfxopt as far as I know. However, I guess
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07
01:42 ---
Also even when -mstrict-align if using
typedef char align_char __attribute__ ((aligned (4)));
void foo (align_char *input) ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-07 01:55
---
You could also disable the test for lp64, if you felt that better.
But then you should document that the various isa extension options
are non-functional.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23704
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
03:46 ---
The first thing is that ccp_initialize sets DONT_SIMULATE_AGAIN on the
statement so don't simulate
that statement and then we don't call fold_ccp on them.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
03:51 ---
(In reply to comment #2)
> The first thing is that ccp_initialize sets DONT_SIMULATE_AGAIN on the
> statement so don't simulate
> that statement and then we don't call fold_ccp on them.
And then we hit an
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 04:09
---
This is actually a GTK bug; a GtkButton doesn't center its child vertically when
the child's size requisition exceeds its size allocation. I'm going to write a
GTK test case and submit a bug report and patch.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
04:19 ---
(In reply to comment #3)
> And then we hit an assert if we change evaluate_stmt to be always call
> fold_ccp.
> The assert is in set_lattice_value, when we are changing from VARRYING to
> CONSTANT which sh
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
04:46 ---
Actually there needs some improvements to ccp_fold to do this fully.
--
What|Removed |Added
The following testcase from gfortran.dg/g77/1832.f runs successfully with
gfortran. With g77 it goes into a spin cycle.
This was discovered while testing new patches for array_io in 4.1 branch. With
new patches, gfortran correctly gives am end-of-record error.
Test case should be dropped or rev
101 - 140 of 140 matches
Mail list logo
