I am facing issuue in upgrading of gcc-3.3.1 to gcc-4.1.1 in HP-UX 11.11.
Not getting any error while compilation, but showing the version 3.3.1 only
after compilation.
Steps we have followed is
1. downloded gcc-4.1.1.tar from gnu.org
2. Untar the file
3. ./configure
4. gmake all
5. gmake install
Santhosh1 C wrote:
I am facing issuue in upgrading of gcc-3.3.1 to gcc-4.1.1 in HP-UX 11.11.
Your question would be more suitable for [EMAIL PROTECTED] This
list is for those developing GCC, not its users.
3. ./configure
Read the instructions. Building in the source directory is not
[EMAIL PROTECTED] wrote on 28/05/2007 09:05:24:
Can you help to upgrade the gcc to 4.1.1 by providing the steps and
procedure etc
I think you should try the gcc-help mailing list.
Revital
On Fri, 2007-05-25 at 12:41 -0700, Zack Weinberg wrote:
but there are still a lot left to go:
arc bfin c4x cris crx fr30 frv h8300 iq2000 m32c m32r m68hc11 mcore mmix
mn10300 mt pa pdp11 score sh sparc stormy16 v850 vax
I can provide the patch for arc sometime soon
regards
saurabh
Hi,
I am building the C/C++ GCC toolchain for i386 target on x86/Linux
platform. The native gcc version is gcc (GCC) 3.2 20020903
(Red Hat Linux 8.0 3.2-7) and the version of the sources are:
GCC : gcc-4.3-20070302
Binutils : binutils-070204
Newlib : newlib-1.15.0
To enable
Hi,
I'm working on a new gcc port for which I'm writing a loop reorganization as a
part of the machine dependant pass. This reorg requires information regarding
the number of iterations in each loop. I tried to rebuild current_loops and
extract the info from there using different loop
On Wed, May 23, 2007 at 10:02:02AM -0700, Joe Buck wrote:
Mark Mitchell wrote:
1. Add a field to bugzilla for the SVN revision at which a particular
regression was introduced. Display that in bugzilla as a link to the
online SVN history browser so that clicking on a link takes us from the
3. ./configure
Read the instructions. Building in the source directory is not supported.
Often buggy and thus not suggested, but in principle supported.
Paolo
H. J. Lu [EMAIL PROTECTED] wrote on 27/05/2007 21:00:38:
On Sun, May 27, 2007 at 06:52:30PM +0100, Rafael Espindola wrote:
On 5/27/07, Razya Ladelsky [EMAIL PROTECTED] wrote:
Hi,
Getting failure during bootstrap for libjava on powerpc linux:
configure: error: `CXX' has changed
On Thu, 17 May 2007, Dave Korn wrote:
Should section GCC 4.2.0 manuals of
http://gcc.gnu.org/onlinedocs/
not also list the GNU OpenMP Manual that is available for 4.2?
Yes, it probably should. The released docs have been prepared correctly:
Hi all,
I have defined a target hook TARGET_EXPAND_BUILTIN_SAVEREGS (GCC
4.1.1) as an alternative to TARGET_SETUP_INCOMING_VARARGS so as to
code ___builtin_saveregs as per my target. But this target hook is not
getting recognized.
Is there anything else this target hook depends on?
Regards,
On Fri, May 25, 2007 at 12:41:32PM -0700, Zack Weinberg wrote:
I see that many of
the more popular CPUs have already been done:
alpha arm avr i386 ia64 m68k mips rs6000 s390 spu xtensa
but there are still a lot left to go:
arc bfin c4x cris crx fr30 frv h8300 iq2000 m32c m32r
On Fri, May 25, 2007 at 09:26:35PM +0200, Thomas Neumann wrote:
Therefore I am offering a deal to potential reviewers: If you promise to
review some of my patches, I will code something _you_ care about.
Within reasonable limits, of course :)
A more traditional approach would be to use
looking for something to review. And when posting a patch, try to make it
easy for reviewers to tell that your patch is for their part of GCC.
I see your point. I originally thought I would be sending one patch for
whole gcc (as I have the complete patch ready), just broken into smaller
parts
On 5/27/07, Daniel Berlin [EMAIL PROTECTED] wrote:
Oh, some more details for those who want them:
The repo contains the complete history of gcc trunk (125000 svn revisions).
It takes roughly 350 meg of disk space (450 on mac due to inode size).
Curiosity, any plans to convert the full gcc
On 5/28/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
Just in case you've forgotten: You posted a patch for h8300 here:
URL:http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
Yes, but it's got bugs, and it will be more efficient for an actual
h8300 expert to fix them than for
On Mon, May 28, 2007 at 07:04:01PM +0200, Thomas Neumann wrote:
I see your point. I originally thought I would be sending one patch for
whole gcc (as I have the complete patch ready), just broken into smaller
parts for reviewing.
If possible,
1) Break patches up into parts which can be
I have built and installed gmp, mpfr and GNU make on gcc04 using
--prefix=/home/rask/opt, so you can build GCC if you pass
--with-gmp=/home/rask/opt --with-mpfr=/home/rask/opt to configure. You will
need let the dynamic linker know this:
export LD_LIBRARY_PATH=/home/rask/opt/lib
GNU make
On 5/28/07, Rafael Espindola [EMAIL PROTECTED] wrote:
On 5/27/07, Daniel Berlin [EMAIL PROTECTED] wrote:
Oh, some more details for those who want them:
The repo contains the complete history of gcc trunk (125000 svn revisions).
It takes roughly 350 meg of disk space (450 on mac due to inode
Thanks to those who advised on hardware.
FSF France has ordered 3x Dell SC1345, bi-Opteron 2212 (dual core
2GHz) with 4GB of RAM and plenty of disk, these should be in place
sometimes in june and at least three of the old Pentium 3 Dell will be
removed from the farm. OS will likely be debian this
Andrew --
I'm trying to firm up GCC 4.3 planning a bit. One of the things I'm
considering is whether or not the POINTER_PLUS branch should be merged
as part of 4.3. My understanding from looking at your emails is that
the branch is in pretty good shape.
Would you please give me a summary of
Joseph, Richard --
As C maintainers, have either of you looked at Chao-Ying's fixed-point
branch?
My understanding (from the note on the Wiki page) is that the
fixed-point support is now in reasonably good shape, and works on all
architectures, using an emulation library. So, I'm wondering if
Snapshot gcc-4.1-20070528 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070528/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
At this point, I do not plan to do any further GCC 4.1.x releases. The
GCC 4.1.x series was a great success, and is very widely used. I think
it's a fine idea for people to continue to apply fixes to the 4.1.x
branch, under the usual release-branch rules, so that people interested
in longer-term
I would like to try to keep the GCC 4.2.x release branch on the
time-driven release cycle for point releases that is part of the GCC
development plan. I left an embarrassing gap in the GCC 4.1.x release
cycle, and I plan to avoid that mistake for GCC 4.2.x.
Therefore, I plan to make the GCC
Now that GCC 4.2.0 is finally out the door, I'm looking at 4.3.0. Stage
1 has been going on a *long* time, and there have been a lot of changes
made. (The Wiki page has an impressive list.) We also seem to have the
dataflow stuff ready for merge to mainline, and it looks like
POINTER_PLUS may
On Mon, May 28, 2007 at 03:48:39PM -0700, Mark Mitchell wrote:
Therefore, I plan to make the GCC 4.2.1 release on or about July 13th.
As with the 4.2.0 release, I will be most concerned about P1 regressions
in 4.2.x, not present in 4.1.x. At present, that looks to be:
* PR 30252
On 5/28/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Andrew --
Would you please give me a summary of the status? Are there regressions
on major platforms?
The summary is that powerpc-darwin, powerpc64-linux-gnu, spu-elf,
i686-linux-gnu bootstraps and tests with two regression (explained
below).
--- Comment #15 from bonzini at gnu dot org 2007-05-28 06:38 ---
Subject: Bug 32078
Author: bonzini
Date: Mon May 28 06:38:00 2007
New Revision: 125125
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125125
Log:
2007-05-27 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-05-28 07:06
---
The missed load PRE for the testcase below is fixed on the pointer plus banch
as the addition is done in unsigned int for both the ++k and the
array[k+1]. If we change ++k into k+=2 and array[k+1] into
A testcase which we should optimize all the way to return true:
int f(int a, int b)
{
int c = a+2;
int d = c*2;
int e = a*2;
int f = e+4;
return d == f;
}
--
Summary: missed PRE/FRE of a*2+4 and (a+2)*2
Product: gcc
Version: 4.3.0
Status:
According to our documentation, __label__ declarations have to come first but
the C++ accepts code where they don't which can be shown to be a bit weird with
two labels with the same name.
Here is a testcase which shows that the C++ front-end can accept a case where
we have two labels with the
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.0.1 4.1.0 4.2.0 4.3.0
Known to work|
GCC accepts this:
void foo() { goto *1; }
The Labels as Values section of the doc states that indirect gotos take Any
expression of type void *. 1 is not of type void*.
it looks like gcc accepts anything convertible to a pointer type. Trying to
jump to a structure yields:
t.c:15: error:
--- Comment #1 from sabre at nondot dot org 2007-05-28 07:36 ---
isn't this also likely a 3.4 regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
This testcase fails for:
gcc -O2 -msse2 -mtune=k8 sse2-vec-6.c
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inline static-var pure-const
type-escape-varAssembling functions:
i386_cpuid_ecx i386_cpuid_edx i386_extended_cpuid_ecx
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 07:54 ---
(In reply to comment #1)
isn't this also likely a 3.4 regression?
Yes but I don't have 3.4 to test with right now. Also the summary only
includes information about the currently maintained branches. The known to
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-28 07:58 ---
I think the problem now is related to data-ref and I think this might get fixed
after I fix PR 32075.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-05-28 08:35 ---
Standalone testcase, compile with -O2 -msse2 -mtune=k8:
--cut here--
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16)));
void sse2_test (void)
{
--- Comment #16 from rob1weld at aol dot com 2007-05-28 08:35 ---
Comment #11 From [EMAIL PROTECTED] 2007-05-27 07:24
Getting stuck at ?:
libtool: compile: mv -f process-Posix.o java/.libs/process-Posix.o
...
This isn't a fix.
Actually I tought if you had got that far that I had
The attached program never reaches the error message printout, contrary to the
fact that stat= is specified in the allocate statement (if the runtime aborts,
what's the point of stat= ?)
[EMAIL PROTECTED] bugtest]$ gfortran -o tryalloc tryalloc.f90
[EMAIL PROTECTED] bugtest]$ ./tryalloc
Fortran
--- Comment #1 from sfilippone at uniroma2 dot it 2007-05-28 09:35 ---
Created an attachment (id=13620)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13620action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-28 10:27 ---
Confirmed. Maybe fixed by sccvn.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-28 10:29 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118
--- Comment #161 from rguenther at suse dot de 2007-05-28 11:14 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
Btw, it could save us many bugs (or bug reports) if if PTA says must-alias
we'd trust it, instead of using TBAA to
--- Comment #162 from dberlin at gcc dot gnu dot org 2007-05-28 11:24
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 28 May 2007 11:14:20 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
--- Comment #161
--- Comment #107 from simon dot strandman at telia dot com 2007-05-28
11:49 ---
(In reply to comment #106)
I haven't tried the fix in 20218. surprisingly, moving to binutils
2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is
going on? how did the latest
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-28 12:07 ---
I had to change huge(1_4) to huge(1_8) as the former was not enough to trigger
an allocation error on my system.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-28 12:23 ---
Created an attachment (id=13621)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13621action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-28 12:28 ---
Confirmed. Another mangling problem:
Program received signal SIGSEGV, Segmentation fault.
0x0827e9b8 in write_expression (expr=0xb7cdd870)
at /home/richard/src/trunk2/gcc/cp/mangle.c:2175
warning: Source file
--- Comment #3 from manu at gcc dot gnu dot org 2007-05-28 12:54 ---
Worse, with __builtin_sin(M_PI), I get an error:
test.c:2: error: initializer element is not constant
Maybe this is fixed now in GCC 4.3 by using MPFR.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #3 from patchapp at dberlin dot org 2007-05-28 13:15 ---
Subject: Bug number PR32124
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-05/msg01870.html
--
--- Comment #3 from eedelman at gcc dot gnu dot org 2007-05-28 15:41
---
(In reply to comment #2)
Created an attachment (id=13618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618action=view) [edit]
decl.c patch (not check-gfortran tested)
Erik, are you still working on
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-05-28 16:17
---
Removing the wrong-code keyword until we manage to find if it actually happens
on 4.2, or if it's just not exposed. I'm reluctant to backport the patch unless
we have a proof of it happening on 4.2 (and if it
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2007-05-28 16:38
---
Patch was approved...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-28 16:39 ---
Subject: Bug 32124
Author: burnus
Date: Mon May 28 16:39:35 2007
New Revision: 125133
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125133
Log:
2007-05-28 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-28 16:41 ---
Fixed in GCC 4.3.0, won't backport to 4.2.0 (no regression)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from bkoz at gcc dot gnu dot org 2007-05-28 16:56 ---
Created an attachment (id=13622)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13622action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
The following invalid code snippet triggers an ICE on mainline:
templatetypename... struct A;
templatetypename...T struct AT*
{
A();
A(T);
};
bug.cc:3: error: parameter packs
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-05-28 16:53
---
A similar testcase crashes in a different place:
templatetypename... struct A;
templatetypename...T struct AT*
{
A() {}
};
--- Comment #8 from bkoz at gcc dot gnu dot org 2007-05-28 16:57 ---
This should do it. I'll put it on 4.2.x branch after some testing on mainline.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-05-28 16:58 ---
This path:
$GCC_SRC_ROOT\mingw_build\mingw32\libstdc++-v3\include\ext\pb_ds\detail
Looks wrong. Are you building in the source directory?
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32092
The following invalid code snippet triggers an ICE on mainline:
templatetypename... struct A;
templatetypename...T struct AT
{
static int i;
};
Achar a;
Aint b;
bug.cc:3: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32126
--- Comment #9 from bkoz at gcc dot gnu dot org 2007-05-28 17:02 ---
Subject: Bug 31717
Author: bkoz
Date: Mon May 28 17:02:30 2007
New Revision: 125134
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125134
Log:
2007-05-28 Benjamin Kosnik [EMAIL PROTECTED]
PR
The following invalid code snippet triggers an ICE on mainline:
templatetypename...T struct A
{
static T i;
};
int j = Aint::i;
bug.cc:3: error: parameter packs not expanded with
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32127
The following invalid code snippet triggers an ICE on mainline:
templatetypename... struct A;
templatetypename...T, typename...U struct AT..., U... {};
Aint a;
bug.cc:3: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32128
This is kind of a split up of PR31564, which is unrelated.
The program is invalid as we pass an array as actual argument to the scalar
dummy argument; somehow gfortran does not detect this.
Interestingly, compare_actual_formal is never called if the actual argument is
an array section with
Starting with the patch
URL:http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html, committed as
revision 12, linking fails. From libffi/configure.log:
configure:2261: checking for C compiler default output file name
configure:2264: /home/rask/build/gcc-ppc/./gcc/xgcc
--- Comment #163 from ian at airs dot com 2007-05-28 17:30 ---
Richi, I tested my patch on every test case I saved. Can you just point me at
the one I missed? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-28 17:42 ---
I know what the trouble is:
Since the variable 'a' is not used, the equivalence is scrubbed and the
compiler goes off to look for a module variable, rather than a member of an
external union.
I have tried one or two
--- Comment #6 from sabre at nondot dot org 2007-05-28 17:44 ---
This is very useful for compilers generating C code (e.g. LLVM, and various
other source - C compilers). Why remove it? These compilers are generating
partially structured code, that don't have syntactic blocks required
--- Comment #108 from funtoos at yahoo dot com 2007-05-28 17:47 ---
but comments in bug 20218 say that its fixed in mainline, which means there was
a fix put into gcc for hidden visibility. So, are both the fix from prerelease
binutils and gcc mainline needed to fix this completely?
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-28 18:13 ---
Some debugging shows:
resolve_call calls resolve_actual_arglist, which fails.
resolve_call propagates the failure to resolve_where, which does not check for
errors.
In resolve_actual_arglist it fails here:
--- Comment #4 from eedelman at gcc dot gnu dot org 2007-05-28 18:51
---
(In reply to comment #3)
(In reply to comment #2)
Created an attachment (id=13618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618action=view) [edit]
decl.c patch (not check-gfortran tested)
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-28 19:08 ---
(In reply to comment #6)
This is very useful for compilers generating C code (e.g. LLVM, and various
other source - C compilers). Why remove it? These compilers are generating
partially structured code, that
Hopefully this is everything you need: output from the gfortran
command, the source file, and the .mod and .s files that were
generated. GFORTRAN was installed from binary using fink a day or so
ago. Since this was my first use of fink, I'm not sure why it got the
experimental version.
$
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-28 19:43 ---
Subject: Bug 32100
Author: pinskia
Date: Mon May 28 19:43:10 2007
New Revision: 125139
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125139
Log:
2007-05-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-28 19:48 ---
Subject: Bug 32100
Author: pinskia
Date: Mon May 28 19:47:53 2007
New Revision: 125140
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125140
Log:
2007-05-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-28 19:48 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-28 19:52 ---
A partial fix can be found at
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01873.html
Some discussions can be found by following the thread.
--
dominiq at lps dot ens dot fr changed:
What
--- Comment #3 from fang at csl dot cornell dot edu 2007-05-28 19:53
---
Yup, also fails with 3.4.0 (accepts-invalid).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
Look at this:
$ cat allocate-loop.f90
program main
implicit none
real, allocatable, dimension(:) :: a, b, c
real, dimension(10) :: d, e, f
real :: s
allocate (a(10), b(10), c(10))
call random_number(a)
call random_number(b)
c = a+b
s = sum(c)
print *,s
call random_number(d)
attached testcase produces unexpected warning at -O3:
$ g++ -Wall -Woverloaded-virtual -Werror -O3 -gdwarf-2 -g1 -fPIE \
-Wno-error -c auHexCastTest.ii
../../au/h/auHexCast.hpp: In function #8216;R au::hex_cast(const
stlp_std::string) [with R = int]#8217;:
../../au/h/auHexCast.hpp:50:
--- Comment #1 from pluto at agmk dot net 2007-05-28 20:08 ---
Created an attachment (id=13623)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13623action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 20:13 ---
This might not be a bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #3 from pluto at agmk dot net 2007-05-28 20:16 ---
(In reply to comment #2)
This might not be a bug
so, how 'r' can be used uninitialized in this case?
template typename R
R hex_cast ( const std::string s )
{
if ( s.empty ()
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-28 20:26 ---
so, how 'r' can be used uninitialized in this case?
Because istringstream r could have caused an error. so you need to check if
there is an error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-28 20:48
---
The following two codes are handled differently:
$ cat u.f90
call foo()
contains
subroutine foo(x)
integer, dimension(:), optional :: x
interface
subroutine bar(x)
integer,
--- Comment #7 from brooks at gcc dot gnu dot org 2007-05-28 20:53 ---
Subject: Bug 31972
Author: brooks
Date: Mon May 28 20:53:09 2007
New Revision: 125141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125141
Log:
PR 31972/fortran
* target-memory.c (gfc_target_expr_size): Add
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-28 20:54
---
Created an attachment (id=13624)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13624action=view)
Patch for this issue
This patch builds on top of Lee Millward's patch to trans-intrinsic:
--- Comment #8 from brooks at gcc dot gnu dot org 2007-05-28 20:54 ---
Subject: Bug 31972
Author: brooks
Date: Mon May 28 20:54:49 2007
New Revision: 125142
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125142
Log:
PR fortran/31972
* transfer_hollerith_1.f90: New test.
Added:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 20:56 ---
This is an aliasing issue. The reason why we don't optimize this is because we
think a/b and escape except in Fortran that is not the case.
I think there is another bug about this case somewhere too.
--
--- Comment #9 from brooks at gcc dot gnu dot org 2007-05-28 20:57 ---
Fixed, as per above commits.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from brooks at gcc dot gnu dot org 2007-05-28 21:09 ---
Paul, I don't think that's solving the right problem. The code is legal; the
inner TRANSFER creates an array of CHARACTER with len=1 and size=20, which
conforms with a CHARACTER scalar of len=20.
In reducing this,
1 - 100 of 134 matches
Mail list logo
