Hi,
I just want to ask whether we have any special pass to reduce cache
miss? Or any idea or branch to enhance it.
Thanks
Eric Fisher
I have a problem with gcc not finding location for stddef.h include
file when it is invoked from directory other than
install_prefix/bin.
Output from gcc invocation with -v option contains the following:
ignoring nonexistent directory ../lib/gcc...
i.e. gcc is trying to find include files in
Denis Onischenko wrote:
I have a problem with gcc not finding location for stddef.h include
file when it is invoked from directory other than
install_prefix/bin.
Questions about the usage of GCC should go to the gcc-help mailing list,
rather than this one which is about the development of
I just want to ask whether we have any special pass to reduce cache
miss? Or any idea or branch to enhance it.
There are various data layout optimisations. There is also -Os ;-)
Ben
Hello,
I would like to kindly ask somebody to fix PR38064,
as the bug is very annoying -- it makes the use of
enum class virtually impossible. Most of my GCCBUG
workaround comments refer to this one.
For a quick reference:
enum class E { elem };
int main()
{
E e = E::elem;
if
On Sun, May 24, 2009 at 10:23 PM, Joern Rennecke amyl...@spamcop.net wrote:
Quoting Ian Lance Taylor i...@google.com:
Joern Rennecke amyl...@spamcop.net writes:
* config/sh/sh.c (sh_attribute_table): Use extern in forward
declaration.
Common issue with declaring/defining const
On Sun, May 24, 2009 at 11:13 PM, Ian Lance Taylor i...@google.com wrote:
Joern Rennecke amyl...@spamcop.net writes:
Quoting Ian Lance Taylor i...@google.com:
Joern Rennecke amyl...@spamcop.net writes:
* config/sh/sh.c (sh_attribute_table): Use extern in forward
declaration.
Common
for a loop like
1 for(i=0;iN;i++)
2 for(j=0;jN;j++)
3 a[i][j] = a[i][j]+b[i][j];
GCC 4.3.* is unable to get the information for the inner loop that
array reference 'a' is alias of each other and generates code for
runtime aliasing check during vectorization. Is
From: Michael Meissner meiss...@linux.vnet.ibm.com
To: Jamie Prescott jpre...@yahoo.com
Cc: gcc@gcc.gnu.org
Sent: Sunday, May 24, 2009 1:57:19 PM
Subject: Re: Seeking suggestion
One way is to use match_scratch, and different register classes for the two
cases.
(define_insn add3
Piotr Wyderski wrote:
Hello,
I would like to kindly ask somebody to fix PR38064,
as the bug is very annoying -- it makes the use of
enum class virtually impossible. Most of my GCCBUG
workaround comments refer to this one.
Since this is particularly important to you, why not take
the
On May 13, 2009, at 5:26 AM, Duncan Sands wrote:
Hi Richard,
-mpc64 sets the x87 floating point control register to not use the
80bit
extended precision. This causes some x87 floating point operations
to operate faster and there are no issues with the extra roundings
you
get when
On 2009-05-25 12:53:49 -0700, Chris Lattner wrote:
On May 13, 2009, at 5:26 AM, Duncan Sands wrote:
-mpc64 sets the x87 floating point control register to not use the
80bit extended precision. This causes some x87 floating point
operations to operate faster and there are no issues with the
--- Comment #20 from jv244 at cam dot ac dot uk 2009-05-25 06:13 ---
(In reply to comment #19)
It's good news that cp2k is now OK - did the performance improve?
I didn't check that, I suspect that, since everything is module based, it needs
the stuff for module procedure inlining
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-25 07:48 ---
this is likely being fixed by Ira
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from irar at gcc dot gnu dot org 2009-05-25 07:56 ---
Subject: Bug 40238
Author: irar
Date: Mon May 25 07:56:32 2009
New Revision: 147844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147844
Log:
PR tree-optimization/40238
* tree-vect-stmts.c
--- Comment #2 from irar at il dot ibm dot com 2009-05-25 08:20 ---
(In reply to comment #1)
this is likely being fixed by Ira
I committed the fix. Could you please check if it really fixes this one as
well?
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40240
The ?: operators are supposed to group right. In gcc they do, but in cpp they
do not (i.e., they seem to group left in #if statements).
Example:
#include iostream
using std::hex;
using std::dec;
using std::cout;
using std::endl;
int main()
{
# if ( 1 ? 0x0DFF : 3 5 ? 1ull 36 : 1ull 40
--- Comment #3 from jv244 at cam dot ac dot uk 2009-05-25 10:04 ---
fixed on current trunk.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-25 10:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from ro at gcc dot gnu dot org 2009-05-25 12:12 ---
Subject: Bug 40027
Author: ro
Date: Mon May 25 12:12:08 2009
New Revision: 147845
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147845
Log:
PR bootstrap/40027
* config/i386/i386.c
--- Comment #7 from ro at gcc dot gnu dot org 2009-05-25 12:13 ---
Subject: Bug 40027
Author: ro
Date: Mon May 25 12:13:38 2009
New Revision: 147846
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147846
Log:
PR bootstrap/40027
* config/i386/i386.c
--- Comment #8 from ro at gcc dot gnu dot org 2009-05-25 12:56 ---
Fixed for 4.4.1, 4.5.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-25 13:28 ---
This has been fixed for 4.4 and above somewhen between r134840 and r136241,
likely http://gcc.gnu.org/viewcvs?root=gccview=revrev=134989.
I don't think it was a regression, so fixing it just in 4.4 is sufficient.
--
Hello,
during cross compilation of gcc, the libffi build for the target breaks with
this error message:
libtool: compile: /home/frogger/pengutronix/toolchain/libffi/build/./gcc/xgcc
-B/home/frogger/pengutronix/toolchain/libffi/build/./gcc/
-B/usr/local/arm-1136jfs-linux-gnueabi/bin/
Even a simple program like:
for(i=0;i1000;i++)
a[i]= b[i]+c[i];
is vectorized using -ftree-vectorize -msse2 -O2 flag. Unaligned instruction are
generated. For any program, Not even a single aligned instruction is generated.
As, the variable STACK_BOUNDARY in function
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-25 14:23 ---
Works for me (your simple program is not a valid program).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40243
--- Comment #2 from abhishek dot shrivastav24 at gmail dot com 2009-05-25
14:36 ---
(In reply to comment #1)
Works for me (your simple program is not a valid program).
The whole program is like this:
/* sample.c */
#include stdio.h
#define N 1000
int main()
{
int a[N], b[N],
On Linux/ia64, revision 147829:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html
caused:
FAIL: Matrix4f -O3 compilation from source
FAIL: gcc.dg/vect/bb-slp-10.c scan-tree-dump-times slp unsupported alignment
in basic block. 1
FAIL: gcc.dg/vect/bb-slp-4.c scan-tree-dump-times slp basic block
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-25 14:48 ---
Subject: Bug 40176
Author: janus
Date: Mon May 25 14:48:24 2009
New Revision: 147850
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147850
Log:
2009-05-25 Janus Weil ja...@gcc.gnu.org
PR
On Linux/ia32 and Linux/x86-64, revision 147829:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html
breaks SPEC CPU 2K/2006 at -O3:
http://gcc.gnu.org/ml/gcc-regression/2009-05/msg00239.html
http://gcc.gnu.org/ml/gcc-regression/2009-05/msg00238.html
They haven't been fixed as of revision
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-25 14:58 ---
Please try gcc 4.4. We have fixed a bunch of alignment issues.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-05-25 16:11
---
CC-ing Jason...
--
paolo dot carlini at oracle dot com 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 #6 from ian at airs dot com 2009-05-25 18:32 ---
With unscoped enums the similar code works because cp_build_binary_op applies
the default integral promotions to the enums, and winds up comparing two int
values. The promotions are not applied to scoped enums because
--- Comment #4 from vvv at ru dot ru 2009-05-25 19:54 ---
(In reply to comment #2)
This is very odd? What is the assembler doing that the compiler isn't?
There are exist some optimizations impossible without exact knowledge of
address and opcodes,
One example avoiding of branch
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-25 20:05 ---
The following invalid code (reduced from the original code):
! { dg-do compile }
! This tests various error messages for PROCEDURE declarations.
! Contributed by Janus Weil jaydu...@gmail.com
program prog
contains
--- Comment #12 from astrange at ithinksw dot com 2009-05-25 20:26 ---
I noticed this is still accepted by gcc 4.5; one stuck into ffmpeg and broke
the build with another compiler.
For instance, this only fails in c():
int as(int a)
{
asm ( : : m((int)a));
}
int c(int a)
{
real, pointer :: ptr
nullify(ptr, mesh%coarser)
end
gives an ICE:
nullify(ptr, mesh%coarser)
1
Internal Error at (1):
free_expr0(): Bad expr type
--
Summary: ICE on invalid SOURCE= using NULLIFY
Product: gcc
Version: 4.5.0
Status:
Revision 147848:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00825.html
caused:
FAIL: gcc.dg/struct/wo_prof_escape_substr_pointer.c scan-ipa-dump
ipa_struct_reorg is a field in the structure
--
Summary: [4.5 Regression] Revision 147848 failed
--- Comment #7 from jason at gcc dot gnu dot org 2009-05-25 23:01 ---
Subject: Bug 38064
Author: jason
Date: Mon May 25 23:01:02 2009
New Revision: 147854
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147854
Log:
PR c++/38064
* typeck.c (cp_build_binary_op):
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-25 23:02 ---
The following should be enough. gfc_can_put_var_on_stack is also called
elsewhere but those calls shouldn't matter so much.
Index: trans-decl.c
===
---
--- Comment #8 from jason at gcc dot gnu dot org 2009-05-25 23:07 ---
Subject: Bug 38064
Author: jason
Date: Mon May 25 23:07:05 2009
New Revision: 147855
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147855
Log:
PR c++/38064
* typeck.c (cp_build_binary_op):
--- Comment #9 from jason at gcc dot gnu dot org 2009-05-25 23:12 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-
O1 -w -c -o 20090518-1.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile
/20090518-1.c(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/20090518-1.c: In function
'foo':
With revision 147851 cris-elf built.
From revision 147853 and on, bild is 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/ -isystem
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-26 00:35 ---
Created an attachment (id=17914)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17914action=view)
preprocessed code from compiling crtend.o
At a glance, one would believe some function in crtstuff.c is lacking a
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-26 03:24 ---
This sounds like either an as bug or a bug in the target back-end accepting
some memory address it should not.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from hp at gcc dot gnu dot org 2009-05-26 03:27 ---
When porting code such as in the description, it can be argued that
robustifying the code is an important part; that undefined code that just
happened to work for the initial target(s) is corrected to use defined
When I try to build gcc-4.4.0 on the IRIX64 platform, the build fails with:
ar rc libbackend.a insn-attrtab.o insn-automata.o insn-emit.o insn-extract.o
insn-modes.o insn-opinit.o insn-output.o insn-peep.o insn-preds.o insn-recog.o
ggc-page.o alias.o alloc-pool.o auto-inc-dec.o bb-reorder.o
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-26 04:42 ---
(In reply to comment #2)
This sounds like either an as bug
An expression that is the difference between two *other* sections is not
regularly allowed for ELF targets...
or a bug in the target back-end accepting
some
--- Comment #1 from Jay dot St dot Pierre at Colorado dot EDU 2009-05-26
05:11 ---
Created an attachment (id=17915)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17915action=view)
config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40250
--- Comment #6 from jwbates at mac dot com 2009-05-26 05:26 ---
Update: after some restructuring, the problem still occurs when using the -g
flag, but does not occur when the -O flag is used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40036
53 matches
Mail list logo
