--- Comment #17 from pault at gcc dot gnu dot org 2008-11-30 07:50 ---
Fixed on trunk and 4.3.
Comment #13 has migrated to PR38324.
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
This was identified in comment #13 of PR34143 and is not fixed by the patch for
that PR.
The problem of conversion shows up even without -fdefault-integer-8 along with
bound problems as shown by the following code:
integer, parameter :: ik=4
type :: struct
integer(4), allocatable :: ib(:)
end
--- Comment #11 from pault at gcc dot gnu dot org 2008-11-30 07:42 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2008-11-30 03:51 ---
*** This bug has been marked as a duplicate of 37469 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from kargl at gcc dot gnu dot org 2008-11-30 03:51 ---
*** Bug 38323 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-30
03:12 ---
Since the segfault is in f91, how can I obtain a backtrace for this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38323
The gfortran.dg/parameter_array_init_3.f90 -O compilation test ICEs at -m32 on
x86_64-apple-darwin10 as follows...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081129/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
-B/sw/src/fink.build/gcc44-4.3.999-20081129/darwin_objdir/gcc
The gcc.dg/cpp/trad/include.c -fno-show-column compilation test ICEs with...
/sw/src/fink.build/gcc44-4.3.999-20081129/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20081129/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20081129/gcc-4.4-20081129/gcc/testsuite/gcc.dg/cpp/trad
When running make check on a build of current gcc trunk built for the
x86_64-apple-darwin10 target, I discovered that the gcc.misc-tests/linkage.c
link test is failing due to a flaw in the linkage,exp script. The test fails as
follows...
Running
/sw/src/fink.build/gcc44-4.3.999-20081129/gcc-4.4
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2008-11-30
00:57 ---
The problem was a dirty build directory. A clean bootstrap has completed and a
complete make check for -m32 and -m64 is underway under darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-30 00:51 ---
You need -mtune=core to generate "movd %xmm0, %rax". Gcc 4.4 works.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
#include
int foo( __m64 x )
{
int y;
__builtin_memcpy( &y, &x, sizeof( y ) );
return y;
}
gcc movd.c -O2 -S produces:
foo:movq%xmm0, -24(%rsp)
movl-24(%rsp), %eax
ret
while 'movd xmm0, eax' was expected.
--
Summary: missed movd opcode (32bit
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-29 22:42 ---
Looks like something alias related - so CCing Richi.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2008-11-29 22:29
---
> I'm not sure if this bug is fixed, though. -ftrapv is still broken afaik.
Probably, but let's ditch antiquated stuff and start afresh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
--- Comment #15 from steven at gcc dot gnu dot org 2008-11-29 22:23 ---
I'm not sure if this bug is fixed, though. -ftrapv is still broken afaik.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-11-29 22:19
---
libcalls are gone in 4.4 and later.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #32 from ebotcazou at gcc dot gnu dot org 2008-11-29 22:13
---
> BTW, unless the asserts are reenabled again (they are currently disabled for
> these reasons), this isn't a regression, I don't think we ever emitted
> DW_CFA_GNU_args_size correctly in such cases.
OK, thanks
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-11-29 22:08
---
Thanks for the patch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-11-29 22:05
---
Subject: Bug 29987
Author: ebotcazou
Date: Sat Nov 29 22:04:25 2008
New Revision: 142286
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142286
Log:
PR target/29987
* config/sparc/sol2.h (
--- Comment #18 from pault at gcc dot gnu dot org 2008-11-29 21:56 ---
Fixed on trunk and 4.3.
Thanks for the report!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
The following testsuite programs with allocatable components exhibit memory
leaks at runtime:
alloc_comp_assign_2.f90 FOR_ALL problem(lines 27, 28 and 47)
alloc_comp_assign_4.f90 nested constructors(line 56)
alloc_comp_basics_2.f90 repeated ALLOCATE (lines 29, 30 and 35)
alloc_comp_b
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2008-11-29
21:28 ---
It may be due to another patch I was testing. I am doing a clean bootstrap
without the other patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
--- Comment #14 from andreast at gcc dot gnu dot org 2008-11-29 21:20
---
gcc.o differing is severe, while *checksum.o depend on some version information
differing.
I propose to do a real clean build. No build over build.
My build on x86_64-apple-darwin9 is in the last stage, linking
--- Comment #18 from hjl dot tools at gmail dot com 2008-11-29 21:10
---
It isn't totally fixed:
FAIL: gcc.target/i386/pr37843-3.c scan-assembler-not call[t ]*foo
FAIL: gcc.target/i386/pr37843-3.c scan-assembler jmp[t ]*foo
I only checked in x86 backend change since no one has
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2008-11-29
21:09 ---
Why is it okay for cc1-checksum.o and cc1plus-checksum.o to differ but not
gcc.o?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-11-29
21:06 ---
The bootstrap is failing at...
make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH"
"TARGET_SUBDIR=x86_64-apple-darwin10" "bindir=/Users/howarth/inst_gcc/bin"
"datadir=/Users/howarth/inst_gcc/share" "exec_pre
--- Comment #9 from jakub at gcc dot gnu dot org 2008-11-29 21:05 ---
The binutils fix has been checked in, I'll work on configury on Monday.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from jakub at gcc dot gnu dot org 2008-11-29 21:04 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from pault at gcc dot gnu dot org 2008-11-29 20:43 ---
Subject: Bug 34820
Author: pault
Date: Sat Nov 29 20:42:22 2008
New Revision: 142284
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142284
Log:
2008-11-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #17 from pault at gcc dot gnu dot org 2008-11-29 20:43 ---
Subject: Bug 32795
Author: pault
Date: Sat Nov 29 20:42:22 2008
New Revision: 142284
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142284
Log:
2008-11-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #16 from pault at gcc dot gnu dot org 2008-11-29 20:43 ---
Subject: Bug 34143
Author: pault
Date: Sat Nov 29 20:42:22 2008
New Revision: 142284
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142284
Log:
2008-11-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2008-11-29
20:35 ---
Apple wasn't concerned about the multilib issue since they do everything as
lipo files. So I suspect it is rather academic on what we choice for the 32-bit
subdirectory name.
--
http://gcc.gnu.org/bug
--- Comment #10 from andreast at gcc dot gnu dot org 2008-11-29 20:24
---
At the time I did x86_64-apple-darwin* stuff I asked apple people if they
intend to do multilib on this target, the answer was no. So I did not bother
any longer.
I do not know if IA32 is correct. I use i386 for
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-11-29
20:11 ---
Andreas,
Can you try the proposed patch on darwin9 for the x86-64-apple-darwin9
target? I will do a complete make check on darwin10 with the
x86_64-apple-darwin10 triplet. I am surprised by this issue a
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-11-29
20:03 ---
Thanks! With your patch, gcc now makes it into stage 2 and is still building. I
would suggest we use...
MULTILIB_DIRNAMES = IA32
as Apple often using I386 but also builds for i686-apple-darwin as well.
I
--- Comment #7 from andreast at gcc dot gnu dot org 2008-11-29 19:31
---
A starting point would be this:
[wolfram:head/gcc/gcc] andreast% svn diff config/i386/t-darwin64
Index: config/i386/t-darwin64
===
--- config/i386/t-
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-29 19:28 ---
Can an ARM maintainer please check this bug? Comment #4 suggests this bug is
fixed, but it needs re-checking now that IRA has been merged.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-11-29
19:23 ---
The uname output looks like a red herring. I substituted a script for uname
that executes...
#!/bin/sh
uname_aside "$@" | /usr/bin/sed 's/i386/x86_64/'
and the build still fails. I wonder if we could fix
--- Comment #1 from mckelvey at maskull dot com 2008-11-29 18:59 ---
Still getting this bootstrap error, as of yesterday's update.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-11-29
18:44 ---
Ah, I see the problem in the config.log. The inaccurate output of uname under
the i386 kernel on a EMT64 chipset is confusing configure such that...
$ ../gcc/configure --prefix=/Users/howarth/inst_gcc
--
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-29 17:54 ---
Fixed on trunk and 4.3.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pault at gcc dot gnu dot org 2008-11-29 17:52 ---
Subject: Bug 37735
Author: pault
Date: Sat Nov 29 17:51:03 2008
New Revision: 142282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142282
Log:
2008-11-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #12 from paolo dot carlini at oracle dot com 2008-11-29 17:05
---
Subject: Re: STL treats explicit constructors as converting constructors
> The Standard does not require that std::uninitialized_copy be
> invoked when
> constructing an std::vector or...
Sure, but certa
--- Comment #11 from konto dot dydaktyczne at gmail dot com 2008-11-29
16:40 ---
(In reply to comment #10)
> an explicit constructor constructs objects only where the
> direct-initialization syntax or where casts are explicitly used. None of these
> cases occurs in the code above.
I m
--- Comment #10 from konto dot dydaktyczne at gmail dot com 2008-11-29
16:36 ---
(In reply to comment #9)
The Standard does not require that std::uninitialized_copy be invoked when
constructing an std::vector or std::deque.
Moreover, an explicit constructor constructs objects only whe
--- Comment #16 from hjl at gcc dot gnu dot org 2008-11-29 16:33 ---
Subject: Bug 37843
Author: hjl
Date: Sat Nov 29 16:32:35 2008
New Revision: 142278
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142278
Log:
2008-11-29 H.J. Lu <[EMAIL PROTECTED]>
PR middle-end/3784
--- Comment #3 from steven at gcc dot gnu dot org 2008-11-29 16:25 ---
Is this still an issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26307
--- Comment #5 from burnus at gcc dot gnu dot org 2008-11-29 16:18 ---
(In reply to comment #4)
> Timings on x86_64-unknown-linux-gnu:
> matmul =12.840802 s
> subroutine without explicit interface: 0.88805580 s
> subroutine with explicit interface: 0.87605572 s
consider the following source and timings, were a natural form of a subroutine
S1, and two hand optimized forms are timed:
> cat test.f90
SUBROUTINE S1(N,A)
REAL :: A(3)
DO I=1,N
CALL S2(-A)
ENDDO
END SUBROUTINE
SUBROUTINE S1_opt1(N,A)
REAL :: A(3)
REAL, ALLOCATABLE :: B(:)
ALLOCATE(B(SI
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-11-29 15:50
---
'as' is not part of GCC. Report the problem to http://sourceware.org/binutils
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
I am trying to cross-compile DiVinE-MC
(http://divine.fi.muni.cz/page.php?page=divine-mc) into Win32 enviroment at
this moment. I am using Cmake to put the tool together and Mingw to compile it.
The preprocessed source is slightly bigger (1.9MB) but I can't see any way to
attach it anyway. I might
--- Comment #5 from janus at gcc dot gnu dot org 2008-11-29 13:39 ---
Fixed with r142276. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-29 13:38 ---
Subject: Bug 38290
Author: janus
Date: Sat Nov 29 13:36:35 2008
New Revision: 142276
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142276
Log:
2008-11-29 Janus Weil <[EMAIL PROTECTED]>
Mikael Mo
--- Comment #4 from janus at gcc dot gnu dot org 2008-11-29 13:38 ---
Subject: Bug 38289
Author: janus
Date: Sat Nov 29 13:36:35 2008
New Revision: 142276
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142276
Log:
2008-11-29 Janus Weil <[EMAIL PROTECTED]>
Mikael Mo
--- Comment #5 from d dot g dot gorbachev at gmail dot com 2008-11-29
13:08 ---
Hash table entries should be reordered when writing a PCH.
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
-
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #23 from janus at gcc dot gnu dot org 2008-11-29 11:25 ---
Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-29 10:33
---
Subject: Bug 30827
Author: ebotcazou
Date: Sat Nov 29 10:31:53 2008
New Revision: 142274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142274
Log:
PR ada/30827
* g-comver.adb (Ver_Len_Max
I ran into this issue running "gcc ${CFLAGS} -Q --help=optimizers", when
${CFLAGS} happened to contain -pipe.
When -pipe is turned on, the --help=xxx switch will cause the compiler to print
help to stdout, before its usual steps of dumping "help-dummy" assembly code
and letting the driver pipe its
Example code at the end. When I compile it, I get this error:
[EMAIL PROTECTED] gcc -c unclear_override.ads
unclear_override.ads:13:20: not subtype conformant with operation inherited at
line 11
unclear_override.ads:13:20: type of "Item" does not match
The problem is that in real life, Interfac
61 matches
Mail list logo
