--- Comment #2 from gcc at magfr dot user dot lysator dot liu dot se
2008-04-14 06:34 ---
I think I was wrong.
--
gcc at magfr dot user dot lysator dot liu dot se changed:
What|Removed |Added
--- Comment #12 from amodra at bigpond dot net dot au 2008-04-14 07:19
---
Created an attachment (id=15476)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15476action=view)
proposed patch
I think we want something like the attached patch (as yet untested). Besides
the epilogue
--- Comment #13 from jakub at gcc dot gnu dot org 2008-04-14 07:30 ---
Couldn't it use hard_frame_pointer_rtx if frame_pointer_needed, to avoid the
load from 0(1) ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
I understood -pedantic such that it gives warnings if a construct does not
match the Fortran standard. Currently, it seems to be partially used such but
also used to warn for non-Fortran-95 (!) constructs.
I think one should go through the pedantic sections in the source and check
whether they
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-14 09:18 ---
This is setting up the frame pointer which is needed for unwinding/debugging
on some targets. You can use -fomit-frame-pointer to avoid this.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-14 09:39 ---
Subject: Bug 35050
Author: sam
Date: Mon Apr 14 09:38:34 2008
New Revision: 134256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134256
Log:
gcc/ada/
PR ada/35050
* xref_lib.adb
--- Comment #7 from sam at gcc dot gnu dot org 2008-04-14 09:48 ---
Thanks Rolf, patch applied in SVN.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from sam at gcc dot gnu dot org 2008-04-14 09:42 ---
Bug fixed in SVN version.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from sam at gcc dot gnu dot org 2008-04-14 09:40 ---
Subject: Bug 20822
Author: sam
Date: Mon Apr 14 09:39:39 2008
New Revision: 134257
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134257
Log:
2008-04-14 Rolf Ebert [EMAIL PROTECTED]
gcc/ada/
PR
--- Comment #7 from dmixm at marine dot febras dot ru 2008-04-14 10:55
---
Possible the
(isgreater(fabs(x), DBL_MAX) ? (signbit(x) ? -1 : 1) : 0)
will be fast with common finite numbers?
Question: in case of AVR target, is it possible to call extern
isinf() function regardless of
--- Comment #14 from amodra at bigpond dot net dot au 2008-04-14 10:25
---
Yes, I think you could use hard_frame_pointer_rtx in rs6000_emit_epilogue if
frame_pointer_needed, anywhere up to the point where gprs are restored.
Probably done best as a separate patch.
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-04-14 11:06 ---
I propose that we do the following:
- add a warning to the C/C++ frontends that isinf (x) CMP isinf (y) is
only well-defined for !isinf (x) !isinf (y).
this doesn't result in a runtime penalty and informs
--- Comment #3 from ubizjak at gmail dot com 2008-04-14 11:12 ---
(In reply to comment #2)
This is setting up the frame pointer which is needed for unwinding/debugging
on some targets. You can use -fomit-frame-pointer to avoid this.
No, -fomit-frame-pointer uses %ebp.
%ebx is
--- Comment #6 from rsandifo at gcc dot gnu dot org 2008-04-14 11:27
---
Created an attachment (id=15477)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15477action=view)
Possible fix
Sorry for the problems. Can you give this patch a try?
I'd wrongly assumed that one of the
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-14 12:11 ---
Subject: Bug 15915
Author: sam
Date: Mon Apr 14 12:10:16 2008
New Revision: 134261
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134261
Log:
gcc/ada/
PR ada/15915
* sem_util.ads, sem_util.adb
--- Comment #2 from sam at gcc dot gnu dot org 2008-04-14 12:11 ---
Subject: Bug 16098
Author: sam
Date: Mon Apr 14 12:11:06 2008
New Revision: 134262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134262
Log:
gcc/ada/
PR ada/16098
* sem_prag.adb
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-14 12:12 ---
This is fixed in SVN.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-14 12:12 ---
Fixed in SVN.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from david dot griffiths at gmail dot com 2008-04-14 12:25
---
Well there is no ecj1 - that's the problem I think. It didn't build it.
Presumably nobody has noticed this before because they are picking up an old
version of ecj1? Anyway, here's the -v output:
My target machine is an HP Jornada 720 (sa1100 based). Found this when trying
to boot from flashrom.
Using gcc 3.4.5 / glibc 2.3.5 memset.S is compiled without any errors. However
the kernel boots and freezes on memset.S (never returns from function). On
early_printk this is just seen as freezing
--- Comment #1 from kristoffer dot ericson at gmail dot com 2008-04-14
12:42 ---
Created an attachment (id=15478)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15478action=view)
memset.o compiled with 3.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35931
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-14 12:43 ---
gcc 3.4 is no longer maintained. Please try 4.2.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-14 13:42 ---
Subject: Bug 18680
Author: sam
Date: Mon Apr 14 13:41:25 2008
New Revision: 134266
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134266
Log:
gcc/ada/
PR ada/18680
* sem_prag.adb
--- Comment #2 from dgregor at gcc dot gnu dot org 2008-04-14 13:56 ---
The links on the C++0x status web pages have been fixed.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2008-04-14 14:17 ---
Yes. Note that it requires an argument of *class* type, not *pointer to
class* type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35929
--- Comment #2 from bangerth at dealii dot org 2008-04-14 14:28 ---
(In reply to comment #1)
I don't think this is a bug as you did not mark the operations on s
as atomic.
Yes, exactly.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:21 ---
I too believe that z1.cc is valid. icc accepts it.
Not a regression, the code fails back to 2.95.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:34 ---
You are asking for too much. The problem is that in your first example
the compiler knows that you want to call the grab() function and therefore
can give you an informative error message. But in the second example it
The following program generates an ICE.
program FA0005
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]
CHARACTER(1) CDA1(10)
INTEGER IDA(10)
CDA1 = CHAR ( IDA, KIND(A )) !fails
CDA1 = CHAR ( IDA )
I finally got to the bottom of some unexpected behavior from the
amreb-linux target of the 4.1.2 compiler.
I'm hoping that someone can say if is this an optimization bug
(optimizes away too much) or a problem with this code.
extern int ReadChar( char *p);
/* grab a character from input
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-14 16:21 ---
Confirm. The following assert seemingly fails:
gcc_assert (lse.ss == gfc_ss_terminator
rse.ss == gfc_ss_terminator);
--
burnus at gcc dot gnu dot org changed:
What
I just tried to compile the GNU C compiler version
4.4 snapshot 20080411 with the Intel C compiler.
The Intel compiler said
gcc-4.4-20080411/gcc/fold-const.c(14101): warning #592: variable arg1 is used
before its value is set
The source code is
tree arg1 = arg1;
if
--- Comment #5 from sam at gcc dot gnu dot org 2008-04-14 16:46 ---
This is fixed in the current SVN tree.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
From http://gcc.gnu.org/ml/libstdc++/2008-04/msg00034.html
In gcc-4.0.0 search was instantiated in string-inst.cc:
// Used in str::find.
template
const C*
search(const C*, const C*, const C*, const C*, bool(*)(const C, const C));
and if a user compiled their code with -frepo, they can
From http://gcc.gnu.org/ml/libstdc++/2008-04/msg00034.html
In gcc-4.0.0 search was instantiated in string-inst.cc:
// Used in str::find.
template
const C*
search(const C*, const C*, const C*, const C*, bool(*)(const C, const C));
and if a user compiled their code with -frepo, they can
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 ---
*** This bug has been marked as a duplicate of 35934 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 ---
*** Bug 35935 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35934
--- Comment #2 from jb at gcc dot gnu dot org 2008-04-14 18:09 ---
Well, your test case is invalid anyway (i0 is referenced before being defined).
Here's a standard conforming portable version that compiles with -Wall
-pedantic -std=f2003:
program short_test_inf
Mariusz Janiak wrote:
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:
Assembler messages:
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:123:
Error: SP not allowed in register list -- `stmea a1!,{v1-v7,fp,ip,sp,lr}'
John Breitenbach wrote:
char can't be less-than zero. However, can't make up my mind as to
whether or not it should be allowed to optimize away the
post-increment.
It is not OK to optimize away the post-increment. This is a gcc
optimization bug.
Jim
--- Comment #24 from tkoenig at gcc dot gnu dot org 2008-04-14 18:51
---
Subject: Bug 32972
Author: tkoenig
Date: Mon Apr 14 18:50:57 2008
New Revision: 134286
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134286
Log:
2008-04-14 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #1 from jb at gcc dot gnu dot org 2008-04-14 18:55 ---
Confirmed.
This could be a bit tricky to get right. OTOH Fortran is fortunate enough that
there are real strings and not char arrays like in C, so from a user
perspective it should be pretty transparent. But certainly
/home/sam/tmp/gcc-avr/./gcc/xgcc -B/home/sam/tmp/gcc-avr/./gcc/
-B/home/sam/local/i386-linux/avr/bin/ -B/home/sam/local/i386-linux/avr/lib/
-isystem /home/sam/local/i386-linux/avr/include -isystem
/home/sam/local/i386-linux/avr/sys-include -g -O2 -mmcu=avr31 -O2 -g -O2
-DIN_GCC
$ gfortran -g -fdefault-integer-8 char_result_5.f90
$ gdb ./a.out
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO
With a clean svn checkout (gcc version 4.4.0 20080414 (experimental) (GCC)),
--enable-languages=c,c++
I can successfully make bootstrap and make install, and the resulting
compiler seems to work.
However, trying to 'make check' results in the output below:
~/gccbin$ make check
autogen -T
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-14 19:36 ---
The last failures are white space differences and can be ignored, the BSD sed
causes them.
Anyways you should be using make -k check
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35938
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-04-14 19:37 ---
Ah. Well, I see that this is the second time I broke stuff on stdint.h.
I must fix this correctly, apparently.
Mine...
--
bkoz at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from andreast at gcc dot gnu dot org 2008-04-14 19:42
---
happens on sparc-solaris2.8 as well. sparc-solaris2.10 is not affected.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-04-14 19:45 ---
The right way around...
See the attached file in comment #7 of PR32770.
Yes, I'm trying to make indiviual PRs of all failures that
I see.
--
tkoenig at gcc dot gnu dot org changed:
What
--- Comment #1 from dominiq at lps dot ens dot fr 2008-04-14 19:39 ---
See the attached file in comment #7 of PR32770.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
--- Comment #8 from sam at gcc dot gnu dot org 2008-04-14 20:04 ---
Well, as far as I can tell, the bug doesn't have anything to do with shared
memory. It's just that GNAT does not emit any information for imported
entities, as demonstrated in the following example:
package P is
--- Comment #6 from bkoz at gcc dot gnu dot org 2008-04-14 20:08 ---
David, can you put this fix on gcc-4_3-branch and close this PR please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35597
--- Comment #3 from dominiq at lps dot ens dot fr 2008-04-14 20:27 ---
On i686-apple-darwin9, the tests pass with -m64, but fail with -m32.
The errors are due to all the tests with f5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
When compiled with -fdefault-integer-8, maxloc_bounds_[457].f90 give the
following error:
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/maxloc_bounds_4.f90:19.11:
call foo(res)
1
Error: Type mismatch in argument 'res' at (1); passed INTEGER(4) to INTEGER(8)
A possible fix is to
The following gives the wrong answers. It may have to do
with broadcasting things to arrays. The all scalar case works
and an array first argument works.
program FA1031
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]
INTEGER IDA1(10)
--- Comment #3 from dmarkman at mac dot com 2008-04-14 21:47 ---
Hi, first of all thanks for your comment
I don't use i0 in the program - it's inside of the quotes
so test is fine
I made all changes you made
and still in 4.3 (opt) I'm getting (+Inf, Nan)
it looks like that 4.4 fixes
--- Comment #1 from dick dot hendrickson at gmail dot com 2008-04-14 21:49
---
I forgot to include the output
C:\gfortrangfortran fa1031.f
C:\gfortrana
T F T F T F T F T F
1 1 1 1 1 1 1 1 1 1
4 1 4 1 4 1 4 1 4 1
4
--
dick dot hendrickson at gmail dot com changed:
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-04-14 22:48 ---
Wow. Confirmed. This does not happen at -O2 with gcc-4.1.2
However, on gcc-4.3.0 branch:
$bld/H-x86-gcc-4_3-branch.20080227/bin/g++ -O2 -S -march=i386 testatomic.cc
gives:
.file testatomic.cc
--- Comment #1 from bkoz at gcc dot gnu dot org 2008-04-14 22:49 ---
Fixing reported against, target milestone.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
20080414 (experimental) (GCC)
and
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind
--- Comment #5 from kargl at gcc dot gnu dot org 2008-04-14 23:10 ---
(In reply to comment #4)
Anyway, I'm reassigning this to middle-end, since regardless of optimization
level the gfortran frontend generates identical trees. Attached is a roughly
equivalent C testcase for the
bootstrap fails with the trailing error messages below
[...]
gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o
build/gencheck \
build/gencheck.o ../build-i686-pc-linux-gnu/libiberty/libiberty.a
build/gencheck
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-14 23:20 ---
What make version are you using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35941
--- Comment #10 from wilson at gcc dot gnu dot org 2008-04-14 23:47 ---
Fixed on mainline and 4.3 branch.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dannysmith at gcc dot gnu dot org 2008-04-14 23:48
---
Subject: Bug 35661
Author: dannysmith
Date: Mon Apr 14 23:47:39 2008
New Revision: 134296
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134296
Log:
2008-04-16 Zuxy Meng [EMAIL PROTECTED]
PR
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-14 23:54 ---
Subject: Bug 35816
Author: bkoz
Date: Mon Apr 14 23:53:15 2008
New Revision: 134297
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134297
Log:
2008-04-14 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #4 from dannysmith at gcc dot gnu dot org 2008-04-14 23:54
---
Subject: Bug 35921
Author: dannysmith
Date: Mon Apr 14 23:53:54 2008
New Revision: 134298
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134298
Log:
PR target/35921
* optimize.c
--- Comment #1 from wilson at gcc dot gnu dot org 2008-04-14 23:56 ---
There is a conflict between the gcc and gas debug info support here. This
can't be fixed in gcc. It will have to be fixed in binutils.
-g1 tells gcc to emit debug info, but not line number info. We do emit file
--- Comment #2 from hp at gcc dot gnu dot org 2008-04-15 00:06 ---
It looks exactly like what Janis saw with make 3.79.1.
I'll close this as fixed with the since then committed
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01018.html
(though the reporter also needs to update to GNU make
--- Comment #5 from wilson at gcc dot gnu dot org 2008-04-15 00:25 ---
Gcc-2.5.8 uses the code I suggested was correct. gcc-2.6.3 does not. The
ChangeLog entry is
Fri Aug 5 12:29:42 1994 Jim Wilson ([EMAIL PROTECTED])
* expmed.c (expand_mult): Accept DImode for synth_mult
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-04-15 00:26 ---
Subject: Bug 35816
Author: bkoz
Date: Tue Apr 15 00:25:45 2008
New Revision: 134305
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134305
Log:
2008-04-14 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #6 from bkoz at gcc dot gnu dot org 2008-04-15 00:26 ---
fixed in trunk and on gcc-4_3-branch
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from anhvofrcaus at gmail dot com 2008-04-15 00:35 ---
[sjswdev2]:{71#}% make -version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i386-redhat-linux-gnu
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
Free
--- Comment #9 from ghazi at gcc dot gnu dot org 2008-04-15 00:38 ---
(In reply to comment #7)
Possible the
(isgreater(fabs(x), DBL_MAX) ? (signbit(x) ? -1 : 1) : 0)
will be fast with common finite numbers?
Yes, it seems to be slightly faster (~5%), but you get larger code
--- Comment #1 from wilson at gcc dot gnu dot org 2008-04-15 01:03 ---
Translation errors must be reported to the FSF translation team instead of to
us. I have forwarded this to the French translation team. See
http://translationproject.org/team/index.html
--
--- Comment #4 from anhvofrcaus at gmail dot com 2008-04-15 01:13 ---
I upgraded to make-3.81 as suggested. This problem has gone away. Thank you all
for your quick help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35941
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-04-15 01:36 ---
(In reply to comment #8)
I propose that we do the following:
- add a warning to the C/C++ frontends that isinf (x) CMP isinf (y) is
only well-defined for !isinf (x) !isinf (y).
this doesn't result in a
--- Comment #3 from brian at dessent dot net 2008-04-15 04:07 ---
Subject: Re: gcj: error trying to exec 'ecj1': execvp: No such
file or directory
david dot griffiths at gmail dot com wrote:
Well there is no ecj1 - that's the problem I think. It didn't build it.
ecj1 is just a
79 matches
Mail list logo
