--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-11 07:21 ---
This was fixed long ago.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Status|UNCONFIRMED |WAITING
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-11 07:20 ---
This was fixed long ago.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I just tried to compile the lapack package
version 3.3.1 with the GNU Fortran compiler
version 4.4 snapshot 20080509
The compiler said
sspr.f: In function 'sspr':
sspr.f:1: internal compiler error: tree check: expected integer_cst, have
plus_expr in int_cst_value, at tree.c:8002
Please submit
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-11 07:54 ---
Most likely the same issue as PR 36198.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36206
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|expected integer_cst, have
The type size seems to be getting set to zero when calling
Build_Signed_Integer_Type in cstand.adb. It's possible that the stage2 gnat
has been miscompiled.
/mingw/src/gccsvn/obj/./prev-gcc/xgcc -B/mingw/src/gccsvn/obj/./prev-gcc/
-B/mingw/i386-pc-mingw32/bin/ -c -g -O2 -D__USE_MINGW_ACCESS
--- Comment #2 from mh+gcc at glandium dot org 2008-05-11 09:18 ---
Usually, when you're using visibility hidden, that means you want to avoid
exporting a lot of cruft symbols from a shared library... that the std::
namespace is always visibility default is an annoyance. Especially
Sorry in advance if this is a dup or known issue. While writing
a patch for IRA, I came across a hang in libgomp.fortran/do2.f90.
The problem is that gomp_loop_ordered_static_next friends
return a C _Bool, which on i686-pc-linux-gnu is a single byte
(i.e. it has QImode). But omp-builtins.def
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-11 11:00
---
This should be double-checked by someone who understand this weird printf
format better than me, but I think it's a __mingw_snprintf bug:
$ cat u.c
#include stdio.h
extern int __mingw_snprintf (char *, size_t,
--- Comment #2 from dcb314 at hotmail dot com 2008-05-11 10:35 ---
Most likely the same issue as PR 36198.
Maybe, but that one only happens with -fprofile-use,
and this one is -O3.
The code compiled fine last week with 20080502,
so the bug looks to be introduced sometime between
--- Comment #15 from joseph at codesourcery dot com 2008-05-11 12:15
---
Subject: Re: Werror problem in build
On Sun, 11 May 2008, aaronavay62 at aaronwl dot com wrote:
--- Comment #13 from aaronavay62 at aaronwl dot com 2008-05-11 03:04
---
What would be an acceptable
--- Comment #16 from joseph at codesourcery dot com 2008-05-11 12:17
---
Subject: Re: I64d format Werror problem in build
On Sun, 11 May 2008, aaronavay62 at aaronwl dot com wrote:
Another question: why does lld not cause warnings on linux here? I don't
see
what the difference
Whilst building the 'procps'
package, using a 4.3.0 (ARM) cross-compiler
the compiler segment faulted.
arm-3d-linux-gnueabi-gcc -c -D_GNU_SOURCE
-I proc -I/usr/include/ncurses -fno-common -ffast-math -W -Wall
-Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast
-Wcast-qual
--- Comment #1 from john dot spelis at 3dlabs dot com 2008-05-11 13:32
---
Created an attachment (id=15625)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15625action=view)
The sysinfo.i output for the segment fault compilation
--
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-11 13:32
---
I will see if I can sort this out.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
$ arm-linux-gcc -Wp,-MD,arch/arm/mm/.mmu.o.d -nostdinc -isystem
/usr/local/DIR/gcc-arm-4.3-20080508/lib/gcc/arm-linux/4.3.1/include
-D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -mlittle-endian
--- Comment #1 from bunk at stusta dot de 2008-05-11 14:01 ---
Created an attachment (id=15626)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15626action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36210
--- Comment #2 from bunk at stusta dot de 2008-05-11 14:02 ---
Created an attachment (id=15627)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15627action=view)
assembler generated by 4.3-20080501 (working)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36210
--- Comment #3 from bunk at stusta dot de 2008-05-11 14:03 ---
Created an attachment (id=15628)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15628action=view)
assembler generated by 4.3-20080508 (broken)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36210
libstdc++ testsuite cases which require libiconv fail on account of trying the
wrong choice in __iconv_adaptor:
/cygdrive/c/gnu/gcc-4.4-20080509/xp/i686-pc-cygwin/libstdc++-v3/include/ext/code
cvt_specializations.h:302: undefined reference to `_libiconv'^M
#ifndef LIBICONV_PLUG
#define iconv
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-11 14:25
---
Here is proposed patch:
Index: list_read.c
===
--- list_read.c (revision 135150)
+++ list_read.c (working copy)
@@ -347,20 +347,12 @@ eat_separator
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-11 14:53
---
Bug reported to mingw:
http://sourceforge.net/tracker/index.php?func=detailaid=1961893group_id=2435atid=102435
Closing here.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-05-11 14:58
---
Closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-05-11 15:03
---
Subject: Bug 36202
Author: jvdelisle
Date: Sun May 11 15:02:41 2008
New Revision: 135177
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135177
Log:
2008-05-11 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-05-11 15:10
---
Fixed on trunk
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tprince at computer dot org 2008-05-11 15:57 ---
2 unicode.cc tests fail. Several other tests with -liconv pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
--- Comment #4 from flameeyes at gentoo dot org 2008-05-11 16:31 ---
I think this applies to 4.3 as well, as the following code does only warn in
the second function:
#include stdlib.h
#include string.h
char* oldstyle(const char *foo) {
size_t foolen;
if ( foo == NULL )
--- Comment #5 from dominiq at lps dot ens dot fr 2008-05-11 16:40 ---
For the record: after fixing the syntax errors, the executable gives an
infinite loop when compiled with gfortran 4.3.0 on *i-apple-darwin9 and 4.4.0
(patched) on i686-apple-darwin9, but not on 4.4.0 (also patched)
--- Comment #2 from paolo dot carlini at oracle dot com 2008-05-11 17:13
---
Why, exactly, do you believe the problem is with the const? The code and the
comment in codecvt_specializations.h appear to indicate that we are already
dealing correctly with the issue and indeed you are
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
--- Comment #2 from michael dot a dot richmond at nasa dot gov 2008-05-11
17:16 ---
(In reply to comment #1)
Though I do not get segfault, I can confirm valgrind errors.
The segfault does not occur in the snapshot of May 9. I suspect the valgrind
errors occur on multiple platforms,
--- Comment #3 from tprince at computer dot org 2008-05-11 17:26 ---
I see that the failing case is looking for a libiconv in the library to match
the char ** prototype, and failing to find one, while the one in the actual
library is set up for the const char ** version. The comment in
--- Comment #4 from paolo dot carlini at oracle dot com 2008-05-11 17:31
---
Please add pointers to the discussions on those mailing lists.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-05-11 17:34
---
Use the following
valgrind --leak-check=full f951 pr36139.f90
In my case f951 is in my search path as a link:
f951 - /home/jerry/gcc/obj44/gcc/f951
obj44 is the build directory
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-11 17:48 ---
I think this is related to PR36009.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-11 17:51 ---
I bet this is a regression in fact and not really an enhancement. Lim was
doing the store motion in previous versions of GCC but was disabled when the
aliasing oracle patch went in (there was no explication for
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-11 17:54 ---
Which is good, as in the end these are the same bugs. But - where's the
testcase
for this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-11 17:55 ---
I think this was fixed on the 4.3 branch by
2008-05-08 David Edelsohn [EMAIL PROTECTED]
PR target/36090
* config/rs6000/rs6000.c (print_operand_address): If the TOC
address RHS contains
--- Comment #5 from tprince at computer dot org 2008-05-11 18:04 ---
Only the gcc-testresults reports where others report the same thing are clearly
relevant:
http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg01444.html
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01528.html
In
--- Comment #6 from paolo dot carlini at oracle dot com 2008-05-11 18:13
---
Frankly, we badly need more details and/or the help of a cygwin maintainer,
because by looking statically at the code I don't see how possibly
__iconv_adaptor can be wrong and most (all?) the active libstdc++
--- Comment #15 from uros at gcc dot gnu dot org 2008-05-11 18:54 ---
Subject: Bug 36129
Author: uros
Date: Sun May 11 18:54:15 2008
New Revision: 135180
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135180
Log:
Backport from mainline:
2008-05-09 Uros Bizjak
--- Comment #16 from ubizjak at gmail dot com 2008-05-11 18:56 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from dcb314 at hotmail dot com 2008-05-11 19:11 ---
Created an attachment (id=15629)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15629action=view)
Fortran source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36206
--- Comment #5 from dcb314 at hotmail dot com 2008-05-11 19:12 ---
(In reply to comment #3)
But - where's the testcase for this?
Sorry - now attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36206
For avr we have multiple failures of testcases due to alignment warnings such
as:
gcc/gcc/testsuite/gcc.dg/debug/const-1.c:3: warning: alignment of 'Foo' is
greater than maximum object file alignment. Using 1
Which in this example occurs due to:
typedef float FloatVect
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-05-11 19:33
---
Subject: Bug 35578
Author: reichelt
Date: Sun May 11 19:32:51 2008
New Revision: 135181
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135181
Log:
PR c++/35578
* parser.c
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-05-11 19:36
---
Subject: Bug 35578
Author: reichelt
Date: Sun May 11 19:35:20 2008
New Revision: 135182
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135182
Log:
PR c++/35578
* parser.c
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-05-11 19:37
---
Now also fixed on the 4.3 and 4.2 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-11 19:38 ---
Problem 3) gcc provide no hooks for the target or testsuite to elegantly
disable vector extensions (that I can find anyway).
Problem 3 is bogus as vector extensions are generic and use what ever exist for
your
The gcc version 4.4.0 20080511 (experimental) (GCC) when compiled with these
options:
$ gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../../../gcc-SVN-20080511/gcc-SVN-20080511/configure
--build=x86_64-pc-linux-gnu --prefix=/usr/local/opt/MDL/opt/gcc
--- Comment #1 from martin dot drab at fjfi dot cvut dot cz 2008-05-11
19:43 ---
Moreover, I think that the ../../ that also appears in some of the search
paths that are found as nonexistent should actually be ../../../.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
--
martin dot drab at fjfi dot cvut dot cz changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-11 19:52 ---
Sebastian - this has a way simpler testcase than PR36198.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-05-11 19:53
---
I was just covering bases with 3. I'll be quite content if the vectors could
obey BIGGEST_ALIGNMENT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36212
--- Comment #4 from michael dot a dot richmond at nasa dot gov 2008-05-11
19:56 ---
(In reply to comment #3)
Use the following
valgrind --leak-check=full f951 pr36139.f90
I downloaded http://valgrind.org/downloads/valgrind-3.3.0.tar.bz2 and attempted
to build valgrind on HP-PA
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-05-11 20:29 ---
Subject: Bug 35719
Author: tkoenig
Date: Sun May 11 20:28:52 2008
New Revision: 135187
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135187
Log:
2008-05-11 Thomas Koenig [EMAIL PROTECTED]
PR
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-05-11 20:39 ---
Fixed on trunk.
I don't think this really needs to be fixed on 4.3, so
I am closing this.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dannysmith at gcc dot gnu dot org 2008-05-11 21:04
---
Subject: Bug 35661
Author: dannysmith
Date: Sun May 11 21:03:27 2008
New Revision: 135188
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135188
Log:
Backport from mainline:
2008-04-15
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-05-11
21:09 ---
Fixed on 4_3 branch
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #17 from aaronavay62 at aaronwl dot com 2008-05-11 21:24
---
(In reply to comment #16)
-Wno-long-long disables warnings in gnu89 -pedantic mode for certain
standard C99 usages, not for non-standard usages. You could add
-Wno-long-long-windows-formats to disable
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
--- Comment #3 from channelzero at web dot de 2008-05-11 21:54 ---
I can confirm a make error in tar, last step of build fails:
gcc -std=gnu99 -g -O2 -o tar buffer.o compare.o create.o delete.o extract.o
xheader.o incremen.o list.o misc.o names.o sparse.o system.o tar.o transform.o
$ cat u.f90
implicit none
real, parameter :: r = transfer(0,0.)
real(kind=8), parameter :: rd = dble(b'
0110100101010001')
if (cmplx(b'
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-05-11
22:46 ---
Following is with mingw but it applies to cygwin as well
This is the command line from log for FAILing 22_locale/locale/cons/unicode.cc
Executing on host: /develop/svn/trunk/build/./gcc/g++
I've had at least three different (but possibly related) problems when trying
to bootstrap Fortran in 4.4 20080510
1) I get a popup message telling me gfortran.exe has crashed in some configure
scripts, which I have not investigated further
2) When compiling _abs_c4.F90, build fails. Strangely,
--- Comment #9 from aaronavay62 at aaronwl dot com 2008-05-11 23:21 ---
I didn't fix it, but this apparently has been resolved some sort of way in
4.3.0.
--
aaronavay62 at aaronwl dot com changed:
What|Removed |Added
Meta bug for issues blocking all languages, all subdirectories bootstrap on
i386-pc-mingw32 on 4.4.0 experimental.
These should all be regressions, as this works (except for libmudflap) in
4.3.0.
--
Summary: [meta-bug] Bootstrap problems on mingw32
Product: gcc
--- Comment #8 from tprince at computer dot org 2008-05-12 01:58 ---
Yes, -liconv precedes the source file, where it must follow:
Executing on host: /cygdrive/c/gnu/gcc-4.4-20080509/xp/./gcc/g++ -shared-libgcc
-B/cygdrive/c/gnu/gcc-4.4-20080509/xp/./gcc -nostdinc++
72 matches
Mail list logo
