Hi all,
Also wanted to announce that we are currently developing run-time adaptation
techniques for GCC for statically compiled programs with varying context
and behavior. Our technique relies on function/loop versioning and
static low-overhead monitoring and adaptation routines.
We extend our
On 06 Mar 2007 21:48:14 -0600, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Manuel López-Ibáñez [EMAIL PROTECTED] writes:
| On 06/03/07, Mark Mitchell [EMAIL PROTECTED] wrote:
| Manuel López-Ibáñez wrote:
| On 05/03/07, Mark Mitchell [EMAIL PROTECTED] wrote:
| After reviewing all of the
Hi,
Noticed libg2c.a is missing in /lib in 4.1.1 hierarchy , whats
the equivalent of libg2c.a in gcc 4.1.1 , any pointers .
Satya
On Wed, 7 Mar 2007, Manuel López-Ibáñez wrote:
| Should we mention Waddress in the GCC 4.2 release notes?
Proper documentation is sufficient I believe.
-- Gaby
Hi all
Two questions about Apple's Objective-C 2.0 work:
1) Does anyone know when the syntax extensions will be available working
in the gcc compiler?
2) Will their garbage collection accelerated message dispatch mechanisms
also be supported?
Thx please feel free to CC me
Michael
Is it time to offer second-strap level of compilation? Ie allow C99 to
bootstrap the creation of a basic GCC compiler, then allow a second compile
using the basic GCC compiler to get the full compiler.
Nick
---Original Message---
From: Paul Brook [EMAIL PROTECTED]
Subject: Re:
On 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
Is it time to offer second-strap level of compilation? Ie allow C99 to
bootstrap the creation of a basic GCC compiler, then allow a second compile
using the basic GCC compiler to get the full compiler.
Nick
Effectively that's what
On 3/7/07, Dave Korn [EMAIL PROTECTED] wrote:
On 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
Is it time to offer second-strap level of compilation? Ie allow C99 to
bootstrap the creation of a basic GCC compiler, then allow a second compile
using the basic GCC compiler to get the full
On 3/7/07, Paulo J. Matos [EMAIL PROTECTED] wrote:
On 3/7/07, Dave Korn [EMAIL PROTECTED] wrote:
On 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
Is it time to offer second-strap level of compilation? Ie allow C99 to
bootstrap the creation of a basic GCC compiler, then allow a second
On 07 March 2007 15:05, Paulo J. Matos wrote:
On 3/7/07, Dave Korn [EMAIL PROTECTED] wrote:
On 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
Is it time to offer second-strap level of compilation? Ie allow C99 to
bootstrap the creation of a basic GCC compiler, then allow a second
compile
On 07 March 2007 15:07, Paulo J. Matos wrote:
Moreover, for some reason when using malloc, a lot of poisonous malloc
warning come up which are solved by using xmalloc instead, which is
another thing I cannot figure out. What is better in xmalloc than
malloc?
Take a look, the source for it
On 3/2/07, Diego Novillo [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote on 03/02/07 10:12:
In an IPA pass, for each CFG node, I have a tree decl member from
which I can access the return type, name of the function, argument
names and its types, but I can't seem to find a way to get the
On Wednesday 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
Is it time to offer second-strap level of compilation? Ie allow C99 to
bootstrap the creation of a basic GCC compiler, then allow a second compile
using the basic GCC compiler to get the full compiler.
Maybe, but I consider rejecting
Paulo J. Matos wrote on 03/07/07 10:36:
Is this normal? It seems there are no basic blocks set for the
functions. Probably my pass is being run before the bbs are created?
Looks like it. Set a breakpoint in build_tree_cfg and your function.
If gdb stops in your function first, you found the
On 3/7/07, Paul Brook [EMAIL PROTECTED] wrote:
On Wednesday 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
Is it time to offer second-strap level of compilation? Ie allow C99 to
bootstrap the creation of a basic GCC compiler, then allow a second compile
using the basic GCC compiler to get the
On 3/7/07, Diego Novillo [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote on 03/07/07 10:36:
Is this normal? It seems there are no basic blocks set for the
functions. Probably my pass is being run before the bbs are created?
Looks like it. Set a breakpoint in build_tree_cfg and your function.
Paulo J. Matos wrote on 03/07/07 11:43:
What am I missing?
You are debugging the wrong binary. I'd suggest you browse through
http://gcc.gnu.org/wiki/DebuggingGCC
You need to debug one of cc1/cc1plus/jc1
On 3/7/07, Diego Novillo [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote on 03/07/07 11:43:
What am I missing?
You are debugging the wrong binary. I'd suggest you browse through
http://gcc.gnu.org/wiki/DebuggingGCC
You need to debug one of cc1/cc1plus/jc1
Thank you. It seems I've not
On 3/7/07, Paulo J. Matos [EMAIL PROTECTED] wrote:
On 3/7/07, Diego Novillo [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote on 03/07/07 11:43:
What am I missing?
You are debugging the wrong binary. I'd suggest you browse through
http://gcc.gnu.org/wiki/DebuggingGCC
You need to debug one
On Wed, Mar 07, 2007 at 04:13:08AM -0600, Gabriel Dos Reis wrote:
On Wed, 7 Mar 2007, Manuel López-Ibáñez wrote:
| Should we mention Waddress in the GCC 4.2 release notes?
Proper documentation is sufficient I believe.
Or the release notes could just say something like:
* New warning
Hi Michael,
Two questions about Apple's Objective-C 2.0 work:
1) Does anyone know when the syntax extensions will be available
working
in the gcc compiler?
2) Will their garbage collection accelerated message dispatch
mechanisms
also be supported?
Fairborz is working on them, I
On 07 March 2007 16:16, Paulo J. Matos wrote:
On 3/7/07, Paul Brook [EMAIL PROTECTED] wrote:
On Wednesday 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
Is it time to offer second-strap level of compilation? Ie allow C99 to
bootstrap the creation of a basic GCC compiler, then allow a second
On 3/7/07, Dave Korn [EMAIL PROTECTED] wrote:
As explained: because it makes it impossible for users running old systems
with pre-C99 compilers to build gcc and thereby excludes them from the world
of free software, which is the opposite of what we're trying to achieve.
Well, I surely
On 07 March 2007 17:44, Paulo J. Matos wrote:
Well, I surely understand that and I find it nice. Still, I was
questioning Paul why he said: I consider rejecting mixed
code/declarations to be a feature
I surely don't know FSF's goals but again I understand gcc code not
containing //, but
On Mar 7, 2007, at 9:13 AM, Eric Christopher wrote:
Hi Michael,
Two questions about Apple's Objective-C 2.0 work:
1) Does anyone know when the syntax extensions will be available
working
in the gcc compiler?
It is work in progress. For current status, you can check out Apple's
4.0
On Mar 7, 2007, at 4:44 AM, Michael Hopkins wrote:
1) Does anyone know when the syntax extensions will be available
working in the gcc compiler?
I'd like to contribute all the Objective-C front end features in time
for 4.3, unfortunately, I've not started doing that work. I'm hoping
Hi,
gfortran provides via ISO C Bindings access to the C types int, float
etc. It also provides access to int_fast8_t, int_fast16_t, etc. of stdint.h.
Using #include stdint.h with e.g. sizeof(int_fast8_t) does not work
with cross compilations. (It actually fails already for -m32 on x86-64.)
On
On 3/6/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote:
I have used strace -f to check where linker looked for -lqt-mt. From
what I have observed, it seems that ld didn't use
$SYSROOT/etc/ld.so.conf.
Well, it's supposed to, so I suggest
On Mar 7, 2007, at 11:21 AM, Tobias Burnus wrote:
Using #include stdint.h with e.g. sizeof(int_fast8_t) does not
work with cross compilations.
Sounds like a bug? When I try it on my compiler, it works just fine
natively and with cross compilations. I'd file a bug report. If it
is an
On Wed, Mar 07, 2007 at 12:05:32PM -0800, Mike Stump wrote:
On Mar 7, 2007, at 11:21 AM, Tobias Burnus wrote:
Using #include stdint.h with e.g. sizeof(int_fast8_t) does not
work with cross compilations.
Sounds like a bug? When I try it on my compiler, it works just fine
natively and
On Mar 7, 2007, at 11:16 AM, Mike Stump wrote:
Does -fobjc-gc work for you now? It's been on mainline for a while
now. As for accelerated message dispatch, I'm not exactly certain
which feature you're
Option may be recognized. But it entirely depends on Leopard runtime
for support.
On Wed, 7 Mar 2007, Tobias Burnus wrote:
Hi,
gfortran provides via ISO C Bindings access to the C types int, float
etc. It also provides access to int_fast8_t, int_fast16_t, etc. of stdint.h.
Using #include stdint.h with e.g. sizeof(int_fast8_t) does not work
with cross compilations. (It
Hi Tobias,
What is the proper way to obtain this information?
I fear the answer to this question is there's no way. We already
discussed that a few months ago, at the thread starting here: http://
gcc.gnu.org/ml/gcc/2006-10/msg00346.html From private discussion,
with Paul Brook Joseph
Snapshot gcc-4.2-20070307 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070307/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
--- Comment #10 from bonzini at gnu dot org 2007-03-07 08:22 ---
Unfortunately, if I fix the fwprop bug (which is actually caused by wrong df
information), I get again
leal-4(%edi), %eax
movl%eax, %edi
movl(%eax), %eax
testl %eax, %eax
The
I tried to build SpiderMonkey 1.60 (http://www.mozilla.org/js/spidermonkey/) on
SunOS 5.9/SPARC, and I got this ICE. That code compiles successfully using GCC
4.1.1 bundled with Linux Fedora Core 6 (x86, 32-bit).
gcc -o SunOS5.9_DBG.OBJ/jscpucfg.o -c -g -DXP_UNIX -DSVR4 -DSYSV -DSOLARIS
--- Comment #1 from bugzilla at poradnik-webmastera dot com 2007-03-07
08:32 ---
Created an attachment (id=13156)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13156action=view)
Preprocessor output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31065
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-07 09:15 ---
The same problem appears in the following testcase.
int a[100];
void test (int real_length_of_a)
{
int x = 110;
if (x real_length_of_a)
a[x]++;
}
--
rakdver at gcc dot gnu dot org changed:
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-07 09:33 ---
But real length of a cannot be greater than 100. I guess VRP could be improved
to derive a value range for x in this case ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-07 09:38 ---
Subject: Re: bogus array overflow warnings in unreachable code
But real length of a cannot be greater than 100. I guess VRP could be
improved
to derive a value range for x in this case
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-07 09:39 ---
Uh, yes. So let's teach CCP to convert a[110]++; to builtin_trap then ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-07 09:41 ---
confirmed - this is an arithmetic error in expr.c(find_array_section).
The following fixes the problem, although it has not yet been regtested.
Paul
Index: gcc/fortran/expr.c
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-07 09:55 ---
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-07 10:07 ---
Confirmed. For reference:
struct Dummy
{
int operator(signed int ) { return 4; }
};
struct ICE
{
template typename T
void aj(void)
{
signed int kalle = 9;
int size = Dummy()
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-07 10:09 ---
*** This bug has been marked as a duplicate of 26881 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-03-07 10:09
---
*** Bug 31065 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #45 from michael dot klein at fazi dot de 2007-03-07 10:13
---
Created an attachment (id=13157)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13157action=view)
Patch to configure test for comdat support work with binutils snapshots
gcc's configure test for COMDAT
On the following testcase:
program test
integer, parameter :: n = 25000
integer :: i
real, dimension(n) :: iener, dens, pres, temp, gamma, cs
do i = 1, 3
call eos (iener, dens, pres, temp, gamma, cs, sheat, cgamma)
end do
contains
subroutine eos (iener, dens, pres, temp,
--- Comment #46 from michael dot klein at fazi dot de 2007-03-07 10:20
---
Created an attachment (id=13158)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13158action=view)
Non-reversed patch to make configure test for comdat support work with binutils
snapshots
--
michael dot
[see http://www.polyhedron.co.uk/pb05/linux/f90bench_AMD.html for the original
polyhedron benchmark results, an explanation of what the benchmark is and the
source code]
Typical timings for the gas_dyn.f90 benchmark on my AMD64/linux system are:
* ifort -O3 -xW -ipo -static -V gas_dyn.f90 -o
I saw the -fipa-pta option in the GCC manual, and decided to try it on
mainline. But... I can't get it to work with any C code (or Fortran):
$ cat a.c
void foo() { ; }
$ gcc -c -O1 -fipa-pta a.c
a.c: In function foo:
a.c:5: error: stmt (0x2a983e4140) marked modified after optimization pass:
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-07 10:53 ---
(In reply to comment #3)
fortran/trans-const.c:278 (because the expr is not an EXPR_CONSTANT). This
will
all be fixed when the simplifcation routine for TRANSFER is written.
FX, You are correct - this is
--- Comment #7 from mueller at gcc dot gnu dot org 2007-03-07 10:59 ---
I don't think this is the same testcase. you will get any warning in this case,
because the compiler cannot determine that it is supposed to be dead code.
--
mueller at gcc dot gnu dot org changed:
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-07 11:02 ---
Subject: Re: bogus array overflow warnings in unrolled loops
I don't think this is the same testcase. you will get any warning in this
case,
because the compiler cannot determine that it
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-07 11:27 ---
(In reply to comment #0)
Maybe we should have MINLOC inlined when there's no mask, stride 1 and
one-dimensional?
Definitely. We do this for minval, and from glancing at
gfc_conv_intrinsic_minmaxval and
--- Comment #9 from mueller at gcc dot gnu dot org 2007-03-07 11:34 ---
well, the unrolled body is generated code, it could set TREE_NO_WARNING (for
example). or it could avoid unrolling if its not a flex array.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-07 12:18
---
(In reply to comment #1)
We do this for minval, and from glancing at
gfc_conv_intrinsic_minmaxval and gfc_conv_intrinsic_minmaxloc,
it should happen already.
No, because we never get into
This bug only occurs with gcc 4.x.x on hpux.
In certain circumstances the parameter for the environment will be assigned as
argument for the command.
I've written some code which will show you the exact problem. You need openssl
to reproduce this test.
The expected output is:
Generating a 1024
--- Comment #1 from b dot krumboeck at rewe-group dot at 2007-03-07 12:33
---
Created an attachment (id=13161)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13161action=view)
example code to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
Aurora SPARC Linux release 2.90 (Aurora Corona)/TI UltraSparc IIi (Sabre)
sun4u:
binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
In spec langauge, %{...} and %W{...} are exactly same, except that %W{...} mark
last argument supplied within as a file to be deleted on failure. According to
this definition, the handling of these two commands is descrepant.
In do_spec_1, the handling of %W{...} is:
4943 case 'W':
{
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-03-07 14:24 ---
*** Bug 31053 has been marked as a duplicate of this bug. ***
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-07 14:24 ---
(In reply to comment #2)
I believe this has been fixed already by PR30005 since December 5.
Correct. The fix isn't in 4.2 though (which is what I tried :-)
Closing as a duplicate of 30005.
*** This bug has
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-03-07 14:31 ---
Subject: Re: New: ICE at -O1 -fipa-pta
On 7 Mar 2007 10:32:37 -, fxcoudert at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
I saw the -fipa-pta option in the GCC manual, and decided to try it on
mainline.
--- Comment #47 from hjl at lucon dot org 2007-03-07 14:33 ---
(In reply to comment #45)
Created an attachment (id=13157)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13157action=view) [edit]
Patch to configure test for comdat support work with binutils snapshots
gcc's
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-07 14:34 ---
Your argv array is too small.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from lloyd at randombit dot net 2007-03-07 14:47 ---
This is also true for C++ unless -pedantic is specified (which is confusing
since I thought -pedantic-errors was the default for C++, but apparently this
changed at some point). Using '-Wall -Wextra -ansi -std=c++98'
--- Comment #3 from b dot krumboeck at rewe-group dot at 2007-03-07 15:27
---
Oh, you're right! Thank you!
I tried to debug for 3 days, without success.
Linux, HPUX, GCC 4.X and GCC 3.4.2, .
You are a hero!
Once again, thank you very much.
PS: Sorry for wasting your time.
best
I tracked it down to the following code, which is not compiled as expected, if
optimization ( O1) is turned on.
Contents of fg.c:
---8--8-8---
extern volatile int ReadyFlag_NotProperlyInitialized;
volatile int ReadyFlag_NotProperlyInitialized=1;
volatile int
--- Comment #1 from a_fisch at gmx dot de 2007-03-07 15:41 ---
Created an attachment (id=13162)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13162action=view)
Preprocessed source of code sample
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
--- Comment #2 from a_fisch at gmx dot de 2007-03-07 15:44 ---
Created an attachment (id=13163)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13163action=view)
Generated assembler output: powerpc-elf-gcc -O1 -S -o fg_O1.s fg.i
--
GNU Fortran 95 (GCC) 4.3.0 20061021 (experimental), MINGW build
I am trying to compile f90 code into objects that generate the symbol names
in stdcall syntax, i.e. [EMAIL PROTECTED]
We need the stdcall decorations since we build a dll that is called from an
app that needs to do all calls with
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-07 17:11 ---
.sbss is .sdata but in the bss part of it.
If your loader does not zero bss, then you can use -fno-zero-initialized-in-bss
to get the variable not stored in the bss section.
--
pinskia at gcc dot gnu dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-07 17:13 ---
I am trying to compile f90 code into objects that generate the symbol names
in stdcall syntax, i.e. [EMAIL PROTECTED]
I think you are not looking for -mrtd but for versioned symbols.
-mrtd does:
Use a different
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-07 17:15 ---
actually this function should be inlined as it is a nested function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31066
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-07 17:19
---
(In reply to comment #1)
actually this function should be inlined as it is a nested function.
It is inlined. It's the vectorization of the inlined function that is
suboptimal (at least, that's what I diagnose,
--- Comment #4 from a_fisch at gmx dot de 2007-03-07 17:43 ---
Subject: Re: Wrong code for volatile var with initalization
and optimization
My runtime environment is clearing .bss but the problem is that the
initialization value is != 0 . Because of the value != 0 it's not
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-07 17:57 ---
The documentation says that you should use -pedantic to warn about GCC
extensions[*], so I am not sure whether this is valid. But honestly, from the
description of -std=, I would understand that GNU extensions are
--- Comment #3 from joseph at codesourcery dot com 2007-03-07 18:04 ---
Subject: Re: -std=c89 doesn't warn about gcc's ?: extension
On Wed, 7 Mar 2007, manu at gcc dot gnu dot org wrote:
The documentation says that you should use -pedantic to warn about GCC
extensions[*], so I am
--- Comment #4 from satyaakam at yahoo dot co dot in 2007-03-07 18:07
---
Created an attachment (id=13164)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13164action=view)
assembly code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31049
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-07 18:11 ---
(In reply to comment #3)
Subject: Re: -std=c89 doesn't warn about gcc's ?: extension
Where the standard specified with @option{-std} represents a GNU
extended dialect of C, such as @samp{gnu89} or @samp{gnu99},
--- Comment #2 from rth at gcc dot gnu dot org 2007-03-07 18:13 ---
Subject: Bug 30848
Author: rth
Date: Wed Mar 7 18:13:29 2007
New Revision: 122669
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122669
Log:
PR target/30848
* reg-stack.c (emit_swap_insn): If a
--- Comment #9 from ahs3 at fc dot hp dot com 2007-03-07 18:43 ---
Ah, my fault; I wasn't being clear. I still get the error message with -E,
that is true. However, the resulting code from cpp I thought was correct -- it
just produces what I thought was a normal C label, and if I
When casting a const reference of a derived class (which inherits from multiple
classes with virtual methods) to a non-const reference of one of it's base
classes, the resulting non-const base class reference points to an incorrect
address.
system type/gcc build options/version:
Target:
--- Comment #3 from pcarlini at suse dot de 2007-03-07 19:05 ---
Well Ahmed, right now you can't possibly see the exact same error, because
stl_algobase.h does *not* include iosfwd anymore... Please provide more info.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
--- Comment #3 from rth at gcc dot gnu dot org 2007-03-07 19:16 ---
Subject: Bug 30848
Author: rth
Date: Wed Mar 7 19:15:46 2007
New Revision: 122671
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122671
Log:
PR target/30848
* reg-stack.c (emit_swap_insn): If a
--- Comment #4 from rth at gcc dot gnu dot org 2007-03-07 19:18 ---
Subject: Bug 30848
Author: rth
Date: Wed Mar 7 19:18:22 2007
New Revision: 122672
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122672
Log:
PR target/30848
* reg-stack.c (emit_swap_insn): If a
--- Comment #5 from rth at gcc dot gnu dot org 2007-03-07 19:21 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
testing if LLONG_MIN-1 == LLONG_MAX gives different results with -O3 and
without. Here's a short example and the output I get on my machine.
mamie:/home/distrib/lang/pas$cat mini64.c
#include stdio.h
typedef signed long long int int64;
#define MAXINT64 9223372036854775807LL
#define MININT64
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-07 20:23 ---
Signed integer overflow is undefined. Either use unsigned or -fwrapv.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-07 20:37
---
well, the unrolled body is generated code, it could set TREE_NO_WARNING (for
example). or it could avoid unrolling if its not a flex array.
Except it cannot tell sorry, this is exactly the same issue as the
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-07 20:54
---
Sorry, but I don't agree a bit with you. It doesn't have as much false
positives
as other warnings in -Wall. And I think a warning for the testcase in comment
#3
is ok -- the code looks very suspicious. Also
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-07 21:00 ---
(In reply to comment #2)
No, because we never get into gfc_conv_intrinsic_minmaxloc. We translate the
expression directly into a function call by calling
gfc_conv_intrinsic_funcall() at the head of
--- Comment #5 from joseph at codesourcery dot com 2007-03-07 21:06 ---
Subject: Re: -std=c89 doesn't warn about gcc's ?: extension
On Wed, 7 Mar 2007, manu at gcc dot gnu dot org wrote:
Sorry, I still don't understand what is the difference between -std=c89 and
-std=gnu89.
--- Comment #4 from fxcoudert at gmail dot com 2007-03-07 21:09 ---
Subject: Re: MINLOC should sometimes be inlined (gas_dyn is so slw)
In gfc_conv_intrinsic_function, expr-rank is 0 for minval
and 1 for minloc (which is bogus).
It's not bogus. The MINLOC is an array of
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-03-07 21:09 ---
(In reply to comment #3)
In gfc_conv_intrinsic_function, expr-rank is 0 for minval
and 1 for minloc (which is bogus). I wonder where this is
set...
To answer my own question: This is set in
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-07 21:21
---
(In reply to comment #11)
Sorry, but I don't agree a bit with you. It doesn't have as much false
positives
as other warnings in -Wall.
Actually if you read the documention for -Wall, it says enable warnings
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-07 21:22
---
Actually comment #3 shows this warning is not easy to avoid at all and should
not be turned on with -Wall at all.
I still had allways said it should not be included in -Wall.
--
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-07 21:22
---
This is why we have this bug -- because loop unrolling creates possibly
unreachable code with out-of-bounds array access.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-03-07 21:24
---
(In reply to comment #14)
This is why we have this bug -- because loop unrolling creates possibly
unreachable code with out-of-bounds array access.
But the warning code is the real cause, sorry but there is no
1 - 100 of 134 matches
Mail list logo
