A common technique is to benchmark a function by calling it many times i.e.
void foo(void);
int main(void)
{
}
--
Summary: benchmark function attribute.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
--- Comment #1 from svfuerst at gmail dot com 2010-05-10 06:36 ---
A common technique is to benchmark a function by calling it many times i.e.
void foo(void)
{
/* foo's implementation */
}
int main(void)
{
int i;
for (i = 0; i LARGE_NUM; i++) foo();
return 0;
}
The
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-10 06:55 ---
Re. comment #1:
(1) For this, there is the noinline attribute, as you already knew.
(2) See the noclone attribute
(3) See the regparm attribute
(4) You could use volatile and things like that, or put the unit in a
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-10 07:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #11 from jakub at gcc dot gnu dot org 2010-05-10 07:59 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #16 from irar at il dot ibm dot com 2010-05-10 08:17 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenther at suse dot de 2010-05-10 08:41 ---
Subject: Re: Optimizing integer power
On Sun, 9 May 2010, dfranke at gcc dot gnu dot org wrote:
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-09 21:08
---
Situation still the same with gcc
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-10 08:55 ---
Subject: Bug 44050
Author: rguenth
Date: Mon May 10 08:55:32 2010
New Revision: 159214
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159214
Log:
2010-05-10 Richard Guenther rguent...@suse.de
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-10 08:56 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-10 09:13 ---
4) is already fine with noclone,noinline
for 3) you can add artificial side-effects by an empty asm();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44053
--- Comment #4 from burnus at gcc dot gnu dot org 2010-05-10 10:05 ---
(In reply to comment #2)
... should give a runtime error, since fun(0) evaluates to NULL.
F08 section 16.5.1.6 demands that, if the selector is a pointer, it should be
associated.
In the same way, having an
--- Comment #2 from burnus at gcc dot gnu dot org 2010-05-10 10:10 ---
I/O: Currently both READ an WRITE map to the same function; this should be
changed such that for WRITE the arguments are marked as EAF_NOCLOBBER. This can
be done using aliases, cf.
--- Comment #9 from jakub at gcc dot gnu dot org 2010-05-10 10:13 ---
Created an attachment (id=20617)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20617action=view)
gcc46-pr44023.patch
The bug is that if a debug insn references more than one dead pseudo, only the
first one is
The middle end now supports besides -Werror also -Werror=list, where
-Werror=foo implies -Wfoo. Additionally, the middle end also annotates via
-fdiagnostics-show-option (enabled by default) the messages with the
warning-flag name in parentheses:
-Wuninitialized (or, e.g.: -Wall)
foo.c:4:2:
--- Comment #1 from burnus at gcc dot gnu dot org 2010-05-10 10:30 ---
-Werror= was added 2006 (
http://gcc.gnu.org/viewcvs?view=revisionrevision=109907 ) and the
-fdiagnostics-show-option already exists since 2005
(http://gcc.gnu.org/viewcvs?view=revisionrevision=99169 ) - though it
With the patch http://gcc.gnu.org/ml/fortran/2010-05/msg00067.html (for PR
27866, PR 35003, PR 42809) the number of conversion warnings has drastically
been cut down by drastically cutting down the number of unintended warnings.
However, it no longer warns for
real(8) :: sqrt2
sqrt2 =
--- Comment #20 from mkuvyrkov at gcc dot gnu dot org 2010-05-10 10:46
---
Subject: Re: this fortran program is too slow
On 5/7/10 1:38 AM, steven at gcc dot gnu dot org wrote:
--- Comment #19 from steven at gcc dot gnu dot org 2010-05-06 21:38
---
One possibility is to
--- Comment #4 from steven at gcc dot gnu dot org 2010-05-10 11:00 ---
In other words: not an issue.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Tried native compile gcc-4.50 on both x86_64-linux and i686-linux, and install
into separate directory, it can compile small plugin demo, and demo plugin also
worked well;
but while writing a useful gcc plugin with FOR_EACH_LOOP from cfgloop.h, it
exited with error:
gcc -I.
bin/bash: ar: command not found
gmake[2]: *** [libiberty.a] Error 127
gmake[2]: Leaving directory `/home/jkrell/obj/gcc.x86.sol9/libiberty'
gmake[1]: *** [all-libiberty] Error 2
gmake[1]: Leaving directory `/home/jkrell/obj/gcc.x86.sol9'
gmake: *** [all] Error 2
This is a common occurence for
--- Comment #5 from burnus at gcc dot gnu dot org 2010-05-10 11:51 ---
James Van Buskirk post:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7681f2c8f86c4687/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19168
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-10 12:51 ---
+1 for the idea of a new plugin category.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44056
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-10 12:54 ---
Subject: Bug 44044
Author: janus
Date: Mon May 10 12:54:25 2010
New Revision: 159217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159217
Log:
2010-05-10 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #1 from michael dot a dot richmond at nasa dot gov 2010-05-10
12:58 ---
In http://gfortran.org/download/ there is a binary built from this snapshot.
Was the source code patched?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44048
--- Comment #1 from baldrick at gcc dot gnu dot org 2010-05-10 13:17
---
This bug fires when trying to build LLVM using trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44017
Build_Class_Wide_Master in exp_ch3.adb starts with this check:
-- Nothing to do if there is no task hierarchy
if Restriction_Active (No_Task_Hierarchy) then
return;
end if;
This early return should obviously also occur if tasking is not allowed, for
example if the
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-10 13:26 ---
Created an attachment (id=20618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20618action=view)
gcc46-pr44028.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
With g++ 4.5.0 static initializers can be executed more than once.
Here's how. Let a.cc contain the following code:
#include stdio.h
struct A {
A() {
static int x = printf(x initialized at @%p\n, x);
}
};
extern C void inita();
void inita()
{
A x;
A y;
}
And let b.cc be the copy
--- Comment #1 from ivan dot stankovic at avl dot com 2010-05-10 13:40
---
Created an attachment (id=20619)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20619action=view)
The test case
Just unpack and run 'make; make run'. The output
should be something like:
x initialized at
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-10 13:54 ---
It works for me. You need to build shared libraries with -fPIC.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-10 13:57 ---
Or rather as you use dlopen you need to use RTLD_GLOBAL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44059
--- Comment #10 from ubizjak at gmail dot com 2010-05-10 13:58 ---
(In reply to comment #9)
I'll bootstrap/regtest the patch on x86_64-linux and i686-linux, Uros, can you
please do the same on alpha*-*?
The patch bootstraps OK on alphaev68-pc-linux-gnu. Regression test just
started,
--- Comment #13 from hjl at gcc dot gnu dot org 2010-05-10 14:02 ---
Subject: Bug 44012
Author: hjl
Date: Mon May 10 14:02:43 2010
New Revision: 159223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159223
Log:
Nullify regno_allocno_map of the removed allocno.
gcc/
2010-05-10
--- Comment #19 from dougmencken at gmail dot com 2010-05-10 14:03 ---
It works on powerpc-uclibc host, but if bootstrapped the following way:
Configured with: ./configure --prefix=/usr --sysconfdir=/etc
--mandir=/usr/share/man --build=powerpc-gnu-linux-uclibc
--- Comment #14 from hjl at gcc dot gnu dot org 2010-05-10 14:05 ---
Subject: Bug 44012
Author: hjl
Date: Mon May 10 14:05:16 2010
New Revision: 159224
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159224
Log:
Nullify regno_allocno_map of the removed allocno.
gcc/
2010-05-10
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-10 14:09 ---
Re: #c2, that's just because you are using too old binutils I guess.
The bug seems to be in:
.type _ZGVZN1AC1EvE1x, @object
.type _ZZN1AC1EvE1x, @gnu_unique_object
I believe the guard needs to be
--- Comment #5 from ivan dot stankovic at avl dot com 2010-05-10 14:14
---
Indeed, using RTLD_GLOBAL works around the problem. However, I don't think
one should just resort to using this flag with dlopen everywhere. The problem
was originally found with Python modules written in C, and
Gcc 4.5 miscompiles the following code:
char buf[1024];
void add_input_file(int file)
{
(*((int **)buf))[0] = file;
}
it results in this asm:
Disassembly of section .text:
add_input_file:
0: c3 ret
The file argument is completly ignored.
gcc4.4
int a[2];
int foo (int q)
{
if (__builtin_constant_p (q))
{
if (q == 4)
return a[4];
else
return a[0];
}
else
return a[q];
}
--
Summary: [4.5/4.6 Regression] Warns about out-of-bounds array
access inside
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-10 14:38 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-10 14:39 ---
I guess the problem is in the !DECL_ARTIFICIAL (DECL) test in
ASM_DECLARE_OBJECT_NAME macro - the guard is artificial.
Not sure why that has been added.
/* For template static data member instantiations or
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-10 14:39 ---
Reopening.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #1 from schwab at linux-m68k dot org 2010-05-10 14:43 ---
Try -Wstrict-aliasing.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #5 from svfuerst at gmail dot com 2010-05-10 14:53 ---
The problem is that the list of these workarounds tends to increase with each
release of gcc. (i.e. noclone was added in gcc 4.5) It would be nice if there
was a single attribute to use that would work with all future
--- Comment #2 from bernhardloos at googlemail dot com 2010-05-10 14:57
---
(In reply to comment #1)
Try -Wstrict-aliasing.
It does produce a warning about dreferencing a type-punned pointer.
I tried to compile the snipped with both -fstrict-aliasing and
-fno-strict-aliasing and it
Doing
(void)var;
does not 'use' the var, eg:
void f()
{
int i = 6; // or a fn call whose return value you don't care about
(void)i;
}
j...@shade:~$ g++ -Wall -Wextra unused.cpp
unused.cpp: In function void f():
unused.cpp:3:8: warning: variable i set but not used
--- Comment #3 from vmakarov at redhat dot com 2010-05-10 15:22 ---
It is caused by revision 152533:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00182.html
If it is so, the patch triggered some reload bug IMO. The patch itself was
very safe because it resulted in creation of
--- Comment #9 from jason at gcc dot gnu dot org 2010-05-10 15:30 ---
The testcase is invalid; 5.17 doesn't allow assignment to an array from an
initializer list (although I'm not sure why not). But certainly we should give
an error rather than crash.
--
jason at gcc dot gnu dot
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-10 15:32 ---
It is caused by revision 158806:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00913.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-10 15:48 ---
Oops, seems something I should have covered in the testsuite. For C it works
correctly.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-10 15:51 ---
Created an attachment (id=20620)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20620action=view)
testcases
2 new testcases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44062
--- Comment #4 from ramana at gcc dot gnu dot org 2010-05-10 16:03 ---
Confirmed - marking as a target bug .
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-10 16:16 ---
Gcc 4.6 generates expected code.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #20 from dougmencken at gmail dot com 2010-05-10 16:23 ---
But how to rebuild binutils to remove libgcc_s.so.1 dependency from ld?
$ ./print-sharedlib-deps.sh /usr/bin/ld
/usr/bin/ld:
libz.so.1
libc.so.0
libgcc_s.so.1
Now I'm using libgcc_s.so.1
--- Comment #4 from pluto at agmk dot net 2010-05-10 16:26 ---
(In reply to comment #3)
Gcc 4.6 generates expected code.
PR43987 dupllication?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44060
With revision 159199 the trunk built for cris-elf.
With revision 159204 and on, including at least 159229, build was broken as
follows:
/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/
--- Comment #21 from pluto at agmk dot net 2010-05-10 16:31 ---
(In reply to comment #20)
But how to rebuild binutils to remove libgcc_s.so.1 dependency from ld?
configure binutils with --disable-shared --enable-static and build
with make AM_LDFLAGS=-all-static. you also need to have
--- Comment #1 from hp at gcc dot gnu dot org 2010-05-10 16:35 ---
Created an attachment (id=20621)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20621action=view)
Preprocessed code, slightly reduced.
Compile with ./cc1 -O2 t.i, observe ICE as in the description.
--
--- Comment #5 from bernhardloos at googlemail dot com 2010-05-10 16:48
---
It is a duplicate, my problem happens in exactly the same place.
Sorry I missed the other bug.
*** This bug has been marked as a duplicate of 43987 ***
--
bernhardloos at googlemail dot com changed:
--- Comment #21 from bernhardloos at googlemail dot com 2010-05-10 16:48
---
*** Bug 44060 has been marked as a duplicate of this bug. ***
--
bernhardloos at googlemail dot com changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-10 16:50 ---
Created an attachment (id=20622)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20622action=view)
gcc46-pr44062.patch
Actually, I've found 2 issues even in the C FE related to comma expressions
with
LHS or RHS
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-10 16:58 ---
This probably superseeds (accompanies?) PR31601.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from ubizjak at gmail dot com 2010-05-10 17:01 ---
On alphaev68-pc-linux-gnu, I'm getting:
make[4]: Entering directory
`/space/uros/gcc-build/alphaev68-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-10 17:02 ---
I think -Wconversion-extra would be a good choice.
We could enable -Wconversion with -Wall and -Wconversion-extra with -Wextra?!
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-10 17:11 ---
Subject: Bug 27866
Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159238
Log:
gcc/fortran/:
2010-05-10 Daniel Franke
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-10 17:11 ---
Subject: Bug 35003
Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159238
Log:
gcc/fortran/:
2010-05-10 Daniel Franke
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-10 17:11 ---
Subject: Bug 42809
Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159238
Log:
gcc/fortran/:
2010-05-10 Daniel Franke
The following testcase segfaults in 4.6:
module module_myclass
implicit none
type :: inner
contains
procedure :: set
end type inner
type :: myclass
type(inner) :: slice
end type myclass
contains
subroutine set(this)
class(inner),
--- Comment #11 from ubizjak at gmail dot com 2010-05-10 17:15 ---
(In reply to comment #10)
I'd say that the patch is OK.
Regression test results at [1], everything looks OK.
[1] http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00960.html
--
--- Comment #8 from mikael at gcc dot gnu dot org 2010-05-10 17:16 ---
(In reply to comment #7)
With -fwhole-file I now get the same timings either way. I call that fixed.
Unless there is one other bug tracking inlining of use-associated functions,
one cannot close this yet.
The
--- Comment #3 from burnus at gcc dot gnu dot org 2010-05-10 17:16 ---
(In reply to comment #2)
This probably superseeds (accompanies?) PR31601.
Not really. This is about warnings - the other is about errors due to -std=.
For warnings, the purpose is to help fine-tuning the warnings -
In the following testcase (tested against 4.6), a procedure bound to an
attribute of a super class is not resolved in the subclass.
The test case below doesn't go through the linker.
The error message is:
gfortran -c -ffree-form module.f test.f
gfortran -o test test.o module.o
module.o: In
--- Comment #10 from dougsemler at gmail dot com 2010-05-10 17:18 ---
Well, is it really invalid code with -std=c++0x?
The virutal destructor seems to be causing the issue.
With gcc 4.4.3 (after changing virtual ~base() to virtual void func()):
$ g++ gcc_bug.cc
gcc_bug.cc: In
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-10 17:19 ---
On x86_64-apple-darwin10 at revision 159234 (+ a few patches) I get:
[macbook] f90/bug% gfc pr44064.f90
Undefined symbols:
_vtab$inner.1583, referenced from:
___module_mysubclass_MOD_init in cc4CUNex.o
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-10 17:21 ---
On powerpc-apple-darwin9 at revision 159191 (without gfortran patch) I get:
[karma] f90/bug% gfc pr44064.f90
/var/tmp//ccpUV3i0.s:65:non-relocatable subtraction expression,
_vtab$inner.1183 minus L001$pb
--- Comment #22 from redi at gcc dot gnu dot org 2010-05-10 17:28 ---
(In reply to comment #17)
So can you please tell me how to install libgcc then?
make install should do it. if it's not, look to see if libgcc_s.so is built,
is it in the build tree? does the one in the build tree
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-10 17:32 ---
On x86_64-apple-darwin10, I do not see any difference between this PR and
pr44064. On powerpc-apple-darwin9, I get the errors reported in pr44064#c2 when
compiling the module file.
--
--- Comment #11 from redi at gcc dot gnu dot org 2010-05-10 17:32 ---
(In reply to comment #10)
So you can see that g++ sees this as valid code.
I think that's a bug too
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44045
--- Comment #3 from mikael at gcc dot gnu dot org 2010-05-10 17:35 ---
If I understand correctly, an external symbol can be used for a common block
name in f2003.
Thus, there should be no error with -std=f2003.
--
mikael at gcc dot gnu dot org changed:
What|Removed
Description:
Compiling an array with an initializer list takes memory roughly 140 times the
size of the array. For example, and array of unsigned char with 1M entries
(i.e., sizeof is 1MB), takes 140 MB to compile. An array of 5MB requires over
600MB of memory to compile. Below are some rough
--- Comment #2 from mikael at gcc dot gnu dot org 2010-05-10 18:25 ---
(In reply to comment #1)
Confirmed. Dependency analysis should see that no temporary is required here.
As both Rx and Ry have the pointer attribute, I'm not so sure about it.
Note that if one removes the pointer
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-10 18:28 ---
Subject: Bug 44028
Author: jakub
Date: Mon May 10 18:28:03 2010
New Revision: 159240
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159240
Log:
PR debug/44028
* haifa-sched.c (schedule_insn):
--- Comment #6 from jason at gcc dot gnu dot org 2010-05-10 18:37 ---
Subject: Bug 43719
Author: jason
Date: Mon May 10 18:37:45 2010
New Revision: 159242
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159242
Log:
PR c++/43719
* decl.c (check_initializer): strip
--- Comment #12 from jason at gcc dot gnu dot org 2010-05-10 18:38 ---
Subject: Bug 44045
Author: jason
Date: Mon May 10 18:37:56 2010
New Revision: 159243
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159243
Log:
PR c++/44045
* typeck.c (cp_build_modify_expr):
--- Comment #13 from jason at gcc dot gnu dot org 2010-05-10 18:40 ---
Fixed for 4.6.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #9 from mikael at gcc dot gnu dot org 2010-05-10 18:42 ---
This depends on the double decl problem, which is :
if a module is both defined and used in the same file, we create new symbols
when we load the module, instead of reusing/sharing them.
(In reply to comment #8)
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-10 19:24 ---
Fixed. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-10 19:26 ---
(In reply to comment #6)
The bad pointer position is another instance of the many PRs complaining about
this. I think this PR should be closed after a patch for -Wconversion was
applied and a new one for the
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-10 19:29
---
We should now have about the same behaviour as with C.
The additional requests in comment #4 (integer division) are not handled by the
patch in #9. These are special cases and not necessarily related to
--- Comment #16 from rsandifo at gcc dot gnu dot org 2010-05-10 19:49
---
Thanks Andreas. I don't have access to m68k-elfy targets these days, so could
someone test it just to be sure? I'll commit if everything goes OK.
--
rsandifo at gcc dot gnu dot org changed:
What
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-10 20:05 ---
Subject: Bug 44028
Author: jakub
Date: Mon May 10 20:05:09 2010
New Revision: 159244
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159244
Log:
PR debug/44028
* haifa-sched.c (schedule_insn):
--- Comment #9 from jakub at gcc dot gnu dot org 2010-05-10 20:15 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from davek at gcc dot gnu dot org 2010-05-10 20:54 ---
(In reply to comment #16)
On alphaev68-pc-linux-gnu, I'm getting:
FAIL: leaktest
1 of 4 tests failed
Is this failure something to worry about?
The honest answer is: I can't tell you. These are test cases that
--- Comment #3 from fabien dot chene at gmail dot com 2010-05-10 21:12
---
This is valid code, the use of the temporary value-initializes the const
member.
--
fabien dot chene at gmail dot com changed:
What|Removed |Added
gcc 4.5.0 fails to build libgcc when configured as follows
/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/configure
--build=x86_64-linux --host=x86_64-linux --target=powerpc-oe-linux-gnuspe
--prefix=/scratch/oe/calamari/cross/ppce500v2
--- Comment #3 from jason at gcc dot gnu dot org 2010-05-10 21:21 ---
Subject: Bug 44017
Author: jason
Date: Mon May 10 21:20:47 2010
New Revision: 159246
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159246
Log:
PR c++/44017
* semantics.c (baselink_for_fns):
--- Comment #8 from steven at gcc dot gnu dot org 2010-05-10 21:29 ---
IMA will not be fixed. Actually, it never worked properly to begin with...
GCC 4.5 has -flto, but I don't expect it will do much better than IMA, from a
memory usage point of view. GCC 4.5 also has -fwhopr, but that
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-10 21:59 ---
For me, compiling the code in comment #0 in a single file seems to get stuck in
an endless loop (trunk rev. 159217 on x86_64-unknown-linux-gnu).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44064
1 - 100 of 135 matches
Mail list logo
