http://www.kb.cert.org/vuls/id/162289
Any comments?
Rainer Emrich wrote:
http://www.kb.cert.org/vuls/id/162289
Any comments?
See http://www.airs.com/blog/archives/120 for a good blog post by Ian
Lance Taylor about this issue. -Wstrict-overflow=5 can be used to find
cases where optimizations break not standard specified overflow cases,
On Mon, Apr 7, 2008 at 1:16 AM, Tan, Jeffri [EMAIL PROTECTED] wrote:
Would you happen to know which file the fix is in, so I can apply it as a
patch to 4.2.2? Thanks.
It is in the complete alias analysis rewrite in tree-ssa-alias.c and
tree-ssa-structalias.c. No chance of backporting this.
Ian Lance Taylor [EMAIL PROTECTED] wrote on 04.04.2008 16:53:53:
Kai Tietz [EMAIL PROTECTED] writes:
While running testsuite for target x86_64-pc-mingw32, I noticed that
the
stack segement has for this target no execution permission. May
somebody
could help me, how to avoid the use
Hi ,
I've been looking to sort out a case where one sees the possibility of
doing some kind of redundancy elimination with auto-increment
expressions across basic blocks. I understand based on earlier
conversations as well as looking at auto-inc-dec.c that all
infrastructure for auto-inc-dec
Hi DJ,
I agree that an infinite loop isn't exactly helpful. I believe the
original code for that aspect of contrib/gcc_update was contributed
by Alexandre; perhaps he's got an idea?
Gerald
On Tue, 1 Apr 2008, DJ Delorie wrote:
we use the following logic:
... :
@for f in $? $@; do
Laurent GUERBY wrote:
On Fri, 2008-04-04 at 15:07 -0500, Joel Sherrill wrote:
Beyond those, I am left with:
All targets had the following three failures:
c64005c - WRONG ITERATIVE TRACE LENGTH.
c64005d - WRONG ITERATIVE TRACE LENGTH.
c953002 -
On Mon, Apr 7, 2008 at 3:31 AM, Ramana Radhakrishnan [EMAIL PROTECTED] wrote:
The basic case is as explained below.
for (i = 0; i 100; i ++)
{
if ()
{
a[i] = something;
}
else
a[i] = something else..
}
If it is this case, I think the store to a[i] should really
The web page documentation at http://gcc.gnu.org/contribute.html
doesn't really have the specifics of getting a copyright assignment
done in the simple case of an individual contributing on his free
time. I've set up a wiki page that we can refer people to, at
Hi,
It seems to me that as of ARMv6, the arm family supports the REV*
instructions, in order to endian swap 32 and 16 bit values.
Would it be complicated to implement e.g. __builtin_bswap32 on armv6
with inline semantics (I mean, without generating a library call)?
Thanks,
Alexandre
Paolo Bonzini wrote:
http://www.kb.cert.org/vuls/id/162289
The GCC SC was aware of this CERT posting before it was public. Our
feeling is that this is not a GCC bug, although it is something that we
would like GCC to warn about. I talked to Ian Taylor and he agreed to
work on the
Kenneth Zadeck [EMAIL PROTECTED] writes:
in reorg.c:3155 there is the following code:
/* If we reach a CALL which is not calling a const function
or the callee pops the arguments, then give up. */
if (CALL_P (our_prev)
(! CONST_OR_PURE_CALL_P (our_prev)
||
On Mon, Apr 07, 2008 at 05:09:35PM +0100, FX wrote:
The web page documentation at http://gcc.gnu.org/contribute.html
doesn't really have the specifics of getting a copyright assignment
done in the simple case of an individual contributing on his free
time. I've set up a wiki page that we can
On Mon, Apr 07, 2008 at 05:09:35PM +0100, FX wrote:
The web page documentation at http://gcc.gnu.org/contribute.html
doesn't really have the specifics of getting a copyright assignment
done in the simple case of an individual contributing on his free
time. I've set up a wiki page that we
Hi Andrew,
On Mon, Apr 7, 2008 at 4:41 PM, Andrew Pinski [EMAIL PROTECTED] wrote:
On Mon, Apr 7, 2008 at 3:31 AM, Ramana Radhakrishnan [EMAIL PROTECTED]
wrote:
The basic case is as explained below.
for (i = 0; i 100; i ++)
{
if ()
{
a[i] = something;
}
This page has a major problem. The FSF wants the employer disclaimer
in all cases.
The process that I describe is the one I went through, and other
people as well to my knowledge. If you (truthfully) answer no to the
question about employer/university ownership claims, I don't think
they ask
Mark,
Comments below.
The GCC SC was aware of this CERT posting before it was public. Our
feeling is that this is not a GCC bug, although it is something that
we would like GCC to warn about. I talked to Ian Taylor and he agreed
to work on the warning.
I agree with you that the behavior that
On Mon, Apr 7, 2008 at 10:28 AM, Robert C. Seacord [EMAIL PROTECTED] wrote:
I believe the vulnerability is that gcc may *silently* discard the overflow
checks and that this is a recent change in behavior.
No it is not recent, unless you consider 1998 recent :). I don't know
how many times but
Would it be complicated to implement e.g. __builtin_bswap32 on armv6
with inline semantics (I mean, without generating a library call)?
Probably not.
Paul
Andrew,
We'll also add:
-Wstrict-overflow=5
As a work around.
You are right, I don't regularly read the GCC mailing lists as GCC is not our
only concern. This problem came to our attention because it affected one of
your users. We did consult with Mark before publishing.
rCs
On
Andrew Pinski [EMAIL PROTECTED] writes:
On Mon, Apr 7, 2008 at 10:28 AM, Robert C. Seacord [EMAIL PROTECTED] wrote:
I believe the vulnerability is that gcc may *silently* discard the overflow
checks and that this is a recent change in behavior.
No it is not recent, unless you consider 1998
On Mon, Apr 07, 2008 at 01:28:21PM -0400, Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons we
decided to publish on this. If you identify other compilers that a) are
relatively popular, b) have changed their behavior recently, and c)
silently
Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons we
decided to publish on this. If you identify other compilers that a) are
relatively popular, b) have changed their behavior recently, and c)
silently optimize out overflow checks we will consider
Joe,
Response below.
On Mon, Apr 07, 2008 at 01:28:21PM -0400, Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons we
decided to publish on this. If you identify other compilers that a) are
relatively popular, b) have changed their behavior
Robert C Seacord writes:
Robert I believe the vulnerability is that gcc may *silently*
Robert discard the overflow checks and that this is a recent change in
behavior.
Robert You are also right that the popularity of gcc is one of the reasons we
Robert decided to publish on this. If you
Mark,
comments below.
Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons
we decided to publish on this. If you identify other compilers that
a) are relatively popular, b) have changed their behavior recently,
and c) silently optimize out overflow
Mark Mitchell wrote:
Some compilers (including, at least, GCC, PathScale, and xlc) optimize
away incorrectly coded checks for overflow. Applications containing
these incorrectly coded checks may be vulnerable if compiled with these
compilers.
I've now been told that the LLVM compiler also
Robert C. Seacord wrote:
The advisory suggests that people not use GCC.
no, it does not. it suggests they may not want to use the latest
versions. this is one possible work around. we never say use another
compiler.
Fair enough. However, it does suggest that recent versions of GCC are
Robert C Seacord writes:
Robert my thinking is that if this behavior has been in place for many years,
Robert for example, users will have had the opportunity to discover the
changed
Robert behavior.
This explanation seems to be premised on users never moving an
application to a new
On Mon, Apr 07, 2008 at 02:10:04PM -0400, Robert C. Seacord wrote:
Joe,
Response below.
On Mon, Apr 07, 2008 at 01:28:21PM -0400, Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons we
decided to publish on this. If you identify other compilers
On Mon, Apr 7, 2008 at 2:15 PM, Robert C. Seacord [EMAIL PROTECTED] wrote:
Mark,
ok, i'll review again for tone. generally we don't try to make these notes
overly broad; they are only meant to draw attention to a specific issue.
Speaking as a completely random observer who has had to
Hi,
I created an x86 gcc 4.3 branch to backport upcoming AMD and Intel
processor support from mainline:
svn://gcc.gnu.org/svn/gcc/branches/ix86/gcc-4_3-branch
The initial backports will be AES/PCLMUL, amdfam10 and sse5. Michael
and I are maintainers of the branch.
H.J.
---
Index: svn.html
On Mon, 7 Apr 2008, FX wrote:
The web page documentation at http://gcc.gnu.org/contribute.html
doesn't really have the specifics of getting a copyright assignment
done in the simple case of an individual contributing on his free
time. I've set up a wiki page that we can refer people to, at
Mark Mitchell wrote:
I've been told that Intel's ICC compiler also does this optimization:
ICC 10.0 and earlier releases perform
the same optimization, but not on straight-line code, such as the
testcase. ICC performs the transformation inside loops.
Thanks,
--
Mark Mitchell
CodeSourcery
Here is an unintended bug I encountered recently, hopefully the cert warning
will catch this one too.
int okay_to_increment (int i)
{
if (i + 1 i)
return 0; /* adding 1 would cause overflow */
return 1;/* adding 1 is safe */
}
Any sort of bug can cause a
Tom Truscott [EMAIL PROTECTED] writes:
Here is an unintended bug I encountered recently, hopefully the cert
warning will catch this one too.
int okay_to_increment (int i)
{
if (i + 1 i)
return 0; /* adding 1 would cause overflow */
return 1;/* adding 1 is
Tom Truscott wrote:
Here is an unintended bug I encountered recently, hopefully the cert warning
will catch this one too.
int okay_to_increment (int i)
{
if (i + 1 i)
return 0; /* adding 1 would cause overflow */
return 1;/* adding 1 is safe */
}
Any sort of
Oops, sorry! That is a very nice warning (apparently in gcc newer than 4.2).
-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
Sent: Monday, April 07, 2008 4:40 PM
To: Tom Truscott
Cc: gcc@gcc.gnu.org
Subject: Re: US-CERT Vulnerability Note VU#162289
Tom Truscott
On Mon, Apr 7, 2008 at 1:44 PM, Tom Truscott [EMAIL PROTECTED] wrote:
Oops, sorry! That is a very nice warning (apparently in gcc newer than 4.2).
It was added in at least 4.2.3.
-- Pinski
On Mon, 2008-04-07 at 09:40 -0700, Joe Buck wrote:
On Mon, Apr 07, 2008 at 05:09:35PM +0100, FX wrote:
The web page documentation at http://gcc.gnu.org/contribute.html
doesn't really have the specifics of getting a copyright assignment
done in the simple case of an individual contributing
This is probably true for a country like the USA, but like FX
the FSF didn't ask a disclaimer from my employer: in France
as long as you don't use your employer ressources to contribute
your employer has absolutely no say on what you do outside your work.
That's true in the US as well, but
That's true in the US as well, but what happens later on if your
employer
comes by later on and claims you DID use employer resources? Where
would
that leave the FSF? Very few employees have deep enough pockets to
indemnify the FSF from their employer!
Then, I think the FSF has no
On Mon, 2008-04-07 at 17:03 -0400, Richard Kenner wrote:
This is probably true for a country like the USA, but like FX
the FSF didn't ask a disclaimer from my employer: in France
as long as you don't use your employer ressources to contribute
your employer has absolutely no say on what you
I'm afraid I have to ask to remove the form from that Wiki. :-(
You're welcome to remove it yourself, but please replace them with
appropriate, *clear* documentation of the copyright assignment
process. The recent past (including my own experience some years ago)
has shown that
On Sat, 2008-04-05 at 06:57 -0400, Andy H wrote:
There are several test in testsuite that use trampolines that are still
run with dejagnu switch set to no_trampolines.
Its on my TODO list for AVR target but a recent email reminded me that
it affects testing of other targets than can't or
If you know of a non-GCC compiler that optimizes away
the test (so that the function always returns 0), please
post here, and let me know the name, version number,
command-line options, etc. you used to demonstrate that.
The lovely TI Code Composer Studio compiler does the same
FX Coudert [EMAIL PROTECTED] writes:
That's true in the US as well, but what happens later on if your
employer
comes by later on and claims you DID use employer resources? Where
would
that leave the FSF? Very few employees have deep enough pockets to
indemnify the FSF from their employer!
Paul Brook escreveu:
Would it be complicated to implement e.g. __builtin_bswap32 on armv6
with inline semantics (I mean, without generating a library call)?
Probably not.
Paul
Also, it would be interesting to have an inline version for
architectures older than armv6, when
On 07/04/2008, FX Coudert [EMAIL PROTECTED] wrote:
Then, I think the FSF has no solution but to discard contributions from
quite a few people. How many employers actually are going to issue such a
disclaimer? In all academic places I know, at least, you'll never get
anything like that, just
Snapshot gcc-4.1-20080407 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080407/
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
Thank you so much.
I can test it easily and will let you know of any divergence from
original other than the those you mention.
Andy
Janis Johnson wrote:
On Sat, 2008-04-05 at 06:57 -0400, Andy H wrote:
There are several test in testsuite that use trampolines that are still
run with
FX Coudert wrote:
Moreover, our contribute page says the GCC maintainer that is taking
care of your contributions and there is no documentation to
maintainers, so that part at least is wrong: maintainers don't know what
to do. Or else, I just didn't receive the maintainer welcome package
I will apply the following if you confirm this fixes m32c-elf.
It fixed that particular bug, but another one elsewhere stopped the
build and I don't know what caused the other one.
m32c-elf is easily cross-build with newlib and binutils if you want to
see for yourself.
Mark Mitchell wrote:
I've been told that Intel's ICC compiler also does this optimization:
Apparently, IAR's Atmel AVR compiler does this optimization as well.
That CPU has 16-bit addresses, so the tester changed the test case to
use 1 14 instead of 1 30.
The generated code is:
\
It now dies here:
In file included from ../../../../../gcc/libstdc++-v3/src/strstream.cc:49:
/greed/dj/m32c/gcc/m32c-elf/m32c-elf/m32cm/libstdc++-v3/include/backward/strstream:
In member function 'void std::ostrstream::_ZTv0_n12_NSt10ostrstreamD0Ev()':
--- Comment #3 from zuxy dot meng at gmail dot com 2008-04-07 06:00 ---
Created an attachment (id=15437)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15437action=view)
Proposed patch against 4.3.0, marking .text.unlikely as executable.
--
--- Comment #3 from vapier at gentoo dot org 2008-04-07 06:00 ---
this is in gcc-4.3.0 and that's fine by me
--
vapier at gentoo dot org changed:
What|Removed |Added
the gcc build system has some awk scripts that use unsafe character ranges:
$ grep a-z gcc/*.awk
gcc/optc-gen.awk: gsub( [^A-Za-z0-9_], X, macros[i] )
gcc/optc-gen.awk: gsub ([^A-Za-z0-9], _, enum)
gcc/opt-functions.awk: gsub ([^A-Za-z0-9], _, name)
gcc/opth-gen.awk: gsub(
Hello.
I have binutils 2.18
$ ld --version
GNU ld (GNU Binutils) 2.18
...
But during compilation of gcc-4.3.0 I get following:
configure: WARNING: === Linker version 1800 is too old for
configure: WARNING: === full symbol versioning support in this release of GCC.
configure: WARNING:
--- Comment #7 from irar at il dot ibm dot com 2008-04-07 07:06 ---
I am testing the following patch:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 132478)
+++ tree-vect-transform.c
// Test case: should print 0 but it prints 10 when compiled at -O or -O2. The
culprit is very likely ccp1.
#include stdio.h
int g;
int foo(int i, int j, int* flag)
{
int t;
if (i 0 || j 0)
{
t = 10;
*flag = 1;
}
if (*flag)
g+= t;
}
int main()
{
int
Sent from my iPhone
On Apr 7, 2008, at 0:06, xinliangli at gmail dot com [EMAIL PROTECTED]
wrote:
// Test case: should print 0 but it prints 10 when compiled at -O
or -O2. The
culprit is very likely ccp1.
I don't think it should t used uninitialized if *flag is true and both
I and
--- Comment #1 from pinskia at gmail dot com 2008-04-07 07:10 ---
Subject: Re: New: Wrong CCP -- yielding wrong results at O1 and above
Sent from my iPhone
On Apr 7, 2008, at 0:06, xinliangli at gmail dot com
[EMAIL PROTECTED]
wrote:
// Test case: should print 0 but it
--- Comment #2 from xinliangli at gmail dot com 2008-04-07 07:30 ---
Right, the source is buggy, but looks the compiler misses uninitialized warning
-- with -Wuninitialized -- no warning is given.
(In reply to comment #1)
Subject: Re: New: Wrong CCP -- yielding wrong results at O1
--- Comment #3 from xinliangli at gmail dot com 2008-04-07 07:39 ---
It is debatable whether the const prop should happen in the presence of
unitilaized variable, but a warning should be given.
--
xinliangli at gmail dot com changed:
What|Removed
--- Comment #3 from singler at gcc dot gnu dot org 2008-04-07 08:28 ---
Subject: Bug 35588
Author: singler
Date: Mon Apr 7 08:27:34 2008
New Revision: 133975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133975
Log:
2008-04-07 Johannes Singler [EMAIL PROTECTED]
*
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-07 08:51 ---
Only if you extend refs_may_alias_p, as for pointers you have
p_2 = p_1 + 1;
*p_2
*p_1
and it doesn't follow def-use chains to see the pointer-plus to disambiguate
both pointer de-references. With arrays you
--- Comment #8 from oder at eleks dot lviv dot ua 2008-04-07 08:58 ---
Created an attachment (id=15438)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15438action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-04-07 09:00
---
This is because the oracle is confused by the link_error () call which clobbers
*ex2 and *ex1. Note that SCCVN does not consider control-dependence as it
considers all edges executable all the time.
--
--- Comment #15 from jakub at gcc dot gnu dot org 2008-04-07 10:52 ---
I've tried the first step - putting the attributes that require type to
TYPE_ATTRIBUTES rather than DECL_ATTRIBUTES, see below.
Unfortunately tsubst doesn't call apply_late_template_attributes in that case
(the only
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-07 10:10 ---
It's all optimized away before the may-be-used-uninitialized warning is emitted
(we only execute warn_uninitialized_phi in the late pass).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-07 11:56 ---
Eventually a fallout from rvalue references? CCing Dough.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
i noticed that --disable-shared also disables the libgcc_eh.a
in libgcc/Makefile.in:
(...)
ifeq ($(enable_shared),yes)
all: libgcc_eh.a libgcc_s$(SHLIB_EXT)
ifneq ($(LIBUNWIND),)
all: libunwind$(SHLIB_EXT)
endif
endif
(...)
imho this looks like a bug.
libgcc_eh.a is used with libgcc.a in
--- Comment #9 from ktietz at gcc dot gnu dot org 2008-04-07 13:35 ---
Committed revision 133981.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
i've checked 4.1 vs 4.3 on my c++ codebase and 4.3 doesn't look good.
more time/mem details are in attached logs.
testcase was compiled with following options:
-m32 -D_STLP_DEBUG -D_STLP_DEBUG_MODE_THROWS -D_DEBUG -pthread \
-Wall -Wno-uninitialized -Woverloaded-virtual -Werror \
-march=i686
--- Comment #1 from pluto at agmk dot net 2008-04-07 14:58 ---
Created an attachment (id=15439)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15439action=view)
4.1 stats.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #2 from pluto at agmk dot net 2008-04-07 14:58 ---
Created an attachment (id=15440)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15440action=view)
4.3 stats.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #3 from pluto at agmk dot net 2008-04-07 14:59 ---
Created an attachment (id=15441)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15441action=view)
testcase for 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-07 15:29 ---
Please try --param max-fields-for-field-sensitive=0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #3 from janis at gcc dot gnu dot org 2008-04-07 16:48 ---
Argh, this is an excellent of example of why full testing is necessary for
small changes to a patch that has been fully tested; I thought I could get away
with just bootstrapping C and running tests that use decimal
--- Comment #8 from jason at redhat dot com 2008-04-07 17:29 ---
Subject: Re: namespace association doesn't handle parallel
namespaces
bkoz at gcc dot gnu dot org wrote:
Hey Jason, can we get this fixed on 4_3-branch? (Could probably get away with
just gcc/cp/name-lookup.c fix,
Build command: cat M
--
Summary: preprocessor segfaults when #include directive passed to
macro
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: preprocessor
--- Comment #1 from kulhanek dot 5 at wright dot edu 2008-04-07 19:29
---
(oops, hit enter on the wrong screen)
Error message:
In file included from test.h:2:
test.def:2:2: warning: embedding a directive within macro arguments is not
portable
In file included from
--- Comment #5 from pluto at agmk dot net 2008-04-07 20:25 ---
(In reply to comment #4)
Please try --param max-fields-for-field-sensitive=0
it helps.
TOTAL: 67.59 3.99 71.69 1220782 kB
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #2 from jason at gcc dot gnu dot org 2008-04-07 20:51 ---
Subject: Bug 35734
Author: jason
Date: Mon Apr 7 20:50:21 2008
New Revision: 133987
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133987
Log:
PR c++/35734
* class.c
Command:
avr-gcc -O1 -S div32_7.c
or
avr-gcc -O1 -fno-split-wide-types -S div32_7.c
Code size 4.1.2: 0x28
Code size 4.3.0: 0x68
Code size 4.3.0: 0x28 with -fno-split-wide-types
//
unsigned long udivr32_7( unsigned long a, unsigned char b, unsigned char *r )
{
unsigned char
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-07 21:38 ---
I think this is already fixed on the trunk, fword prop was not proping as much
as it should have.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
In 4.3.0 -finline-small-functions cause excessive code bloat even though
according to the docs this option should not significantly increase code size.
Code size 4.1.2: 0x8A
Code size 4.3.0: 0x1EA
Code size 4.3.0: 0x88 with -fno-inline-small-functions
Command line:
avr-gcc -Os -c rf12.c
or
--- Comment #1 from a dot kaiser at gmx dot net 2008-04-07 21:54 ---
Created an attachment (id=15442)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15442action=view)
sample code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35861
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-07 21:59 ---
I think this is just a miscounting of inline-asm.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jaydub66 at gmail dot com 2008-04-07 22:01 ---
Another thing I just noticed is that dummy procedures are currently not checked
for being called with the right arguments (- compare_actual_formal), e.g. in
the above test case call f([1,2,3]) could also be called with a
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:06
---
Subject: Bug 25829
Author: jvdelisle
Date: Mon Apr 7 22:05:52 2008
New Revision: 133988
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133988
Log:
2008-04-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:08
---
Subject: Bug 25829
Author: jvdelisle
Date: Mon Apr 7 22:07:44 2008
New Revision: 133989
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133989
Log:
2008-04-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:11
---
Subject: Bug 25829
Author: jvdelisle
Date: Mon Apr 7 22:10:41 2008
New Revision: 133991
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133991
Log:
2008-04-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #3 from a dot kaiser at gmx dot net 2008-04-07 22:14 ---
Created an attachment (id=15443)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15443action=view)
sample code w/o inline assembly
Same situation when inline asm is removed.
--
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:29
---
Now completed. INQUIRE functions work. Closing this PR will open seorate PRS
for the run time items UTF-8 and ROUNDing modes.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
The front-end parsing and translation are completed. We now need to determine
how to implement UP, DOWN, COMPATIBLE, NEAREST, etc. in output_float.
--
Summary: [F2003] Implement new rounding modes for run time
Product: gcc
Version: 4.4.0
Status:
Front end and library are ready to handle this when implemented.
--
Summary: [F2003] Implement ENCODING=UTF-8
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
--- Comment #7 from hutchinsonandy at gcc dot gnu dot org 2008-04-07 23:16
---
Subject: Bug 34210
Author: hutchinsonandy
Date: Mon Apr 7 23:15:35 2008
New Revision: 133993
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133993
Log:
PR target/34210 PR target/35508 * config.host
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-04-07 23:16
---
Subject: Bug 35508
Author: hutchinsonandy
Date: Mon Apr 7 23:15:35 2008
New Revision: 133993
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133993
Log:
PR target/34210 PR target/35508 * config.host
1 - 100 of 112 matches
Mail list logo
