Basile Starynkevitch wrote in
http://lists.debian.org/debian-gcc/2010/03/msg00047.html
Now, one of the issues about MELT Debian packaging is the fact that
melt-runtime.c (the source of melt.so plugin) uses GTY
http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Information
Hello, GCC developers.
I'm not sure whether this is a proper mail address to talk about this or not.
But I am giving a shot.
Last week, I was pondering a way to get Enum values from other unique
values like string and integer.
My thought reached at an idea of using Hash table as usual..
In
On 14.03.2010 13:15, Basile Starynkevitch wrote:
Basile Starynkevitch wrote in
http://lists.debian.org/debian-gcc/2010/03/msg00047.html
Now, one of the issues about MELT Debian packaging is the fact that
melt-runtime.c (the source of melt.so plugin) uses GTY
On 14/03/10 21:48, Matthias Klose wrote:
On 14.03.2010 13:15, Basile Starynkevitch wrote:
Basile Starynkevitch wrote in
http://lists.debian.org/debian-gcc/2010/03/msg00047.html
Now, one of the issues about MELT Debian packaging is the fact that
melt-runtime.c (the source of melt.so plugin)
On 03/10/2010 10:48 PM, fanqifei wrote:
For below piece of code, the instruction clr.w a15 obviously doesn't
belong to the inner loop.
6: bd f4clr.w a15; #clear to zero
8: 80 af 00std.w a10 0x0 a15;
There is info lacking here. Did you compile with optimization?
Matthias Klose wrote:
[posted on both gcc@ debian-gcc@ lists]
On 14.03.2010 13:15, Basile Starynkevitch wrote:
See also http://gcc.gnu.org/ml/gcc/2010-03/msg00129.html
http://gcc.gnu.org/ml/gcc/2010-03/msg00132.html - for those new to MELT see
Snapshot gcc-4.3-20100314 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100314/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Jae Hyuk Kwak wrote:
Hello, GCC developers.
In addition, I found that switch statement can use Hash Table rather
than just replacing with else if.
Besides using jump table, Hash Table can increase speed.
Hash table idea can alleviate the problem of a huge size of jump table as well.
It is
Jon j...@jguk.org writes:
How long is it until back in stage 1 development phase?
Reasonably soon, I hope, but there is no specific schedule.
Ian
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-03-14 08:20 ---
Correct, the fmod-family was marked as pure, which is obviously wrong.
Thanks,
Kai
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mikpe at it dot uu dot se 2010-03-14 09:08 ---
Confirmed current 4.4 is affected too, -01 works -O2 fails. Reduced test case:
int l_5_5_2 = 4;
int g_3[1][1];
void func_1 (void)
{
for (g_3[0][0] = 1; g_3[0][0] 8; g_3[0][0] += 7) {
int *l_6 = g_3[0][0];
--- Comment #26 from dominiq at lps dot ens dot fr 2010-03-14 09:33 ---
I have posted a full regression testing with the patch in comment #23 at
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01182.html
The failures are the usual ones and pr42220 is still fixed.
--
The following program gives an ICE with gfortran 4.1, 4.2, 4.3, 4.4, and 4.5.
The program is valid (except for the one marked line) and compiles with NAG
f95, ifort, and g95. With the marked line, it is invalid which is not diagnosed
but also gives an ICE.
implicit none
type t
integer, pointer
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-14 11:20 ---
The subroutines EOS and CHOZDT are not vectorized with -fgraphite-identity. See
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00515.html
and
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00524.html
for a possible
--- Comment #24 from dominiq at lps dot ens dot fr 2010-03-14 11:40 ---
We are executing the range [scat_1+1, T_10-2] before executing the
range [0, scat_1-1].
This would be OK if fctr had been initialized with the right value. Failing to
do so leads to an early NAN.
--
--- Comment #5 from mikpe at it dot uu dot se 2010-03-14 11:45 ---
Disabling the Do not inline regular functions into always-inline functions
part of r156601 prevents the ICE:
--- gcc-4.4-20100209/gcc/ipa-inline.c.~1~
+++ gcc-4.4-20100209/gcc/ipa-inline.c
@@ -1421,7 +1421,7 @@
--- Comment #5 from siarhei dot siamashka at gmail dot com 2010-03-14
12:23 ---
Do you want to force data into specific neon registers because of the
restriction on the neon registers which can be used as scalar operand for
multiplication?
It works for me.
--- Comment #3 from siarhei dot siamashka at gmail dot com 2010-03-14
12:44 ---
As of today, gcc seems to be clever enough to deduct whether to use single
precision or double precision VFP register when given w constraint (so P
modifier is not strictly needed). This behavior seems to
--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-14 12:46 ---
Accept. I have a patch: http://gcc.gnu.org/ml/fortran/2010-03/msg00084.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
The test g++.dg/ext/altivec-17.C fails:
FAIL: g++.dg/ext/altivec-17.C (test for errors, line 15)
FAIL: g++.dg/ext/altivec-17.C (test for excess errors)
(see for instance http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01113.html
).
This is due to a recent change in the error message that has
--- Comment #2 from steven at gcc dot gnu dot org 2010-03-14 12:53 ---
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) Starting program:
/home/stevenb/devel/build-mips/gcc/cc1 -quiet -O1 t.c
Breakpoint 1, fancy_abort
/***/
#include arm_neon.h
void neon_add(float * __restrict out, float * __restrict a, float * __restrict
b)
{
float32x2_t tmp1, tmp2;
tmp1 = vset_lane_f32(*a, tmp1, 0);
tmp2 = vset_lane_f32(*b, tmp2, 0);
tmp1 = vadd_f32(tmp1, tmp2);
*out = vget_lane_f32(tmp1, 0);
}
--- Comment #2 from burnus at gcc dot gnu dot org 2010-03-14 13:18 ---
Subject: Bug 43362
Author: burnus
Date: Sun Mar 14 13:18:28 2010
New Revision: 157447
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157447
Log:
2010-03-14 Tobias Burnus bur...@net-b.de
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-14 13:37 ---
FIXED on the trunk (4.5).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
When returning from a function in an exception handler, the destructor for
objects local to the function is never called.
The attached program returns 0 (as expected) when compiled with:
gcc version 4.4.3 (Debian 4.4.3-3)
The same program returns 1 when compiled with:
gcc version 4.5.0 20100310
--- Comment #1 from erik at ejohansson dot se 2010-03-14 13:57 ---
Created an attachment (id=20103)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20103action=view)
Sample code that triggers the error
With gcc 4.4.3:
/usr/bin/g++ -o exception exception.cc ./exception; echo $?
0
Fortran 2003 has in Section 7.4.1.2:
In an intrinsic assignment statement, variable shall not be polymorphic, and
[...]
Fortran 2008 has in Section 7.2.1.2
If variable is a coindexed object, the variable
* shall not be polymorphic, [...]
and the previous restriction has been removed.
--
--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-14 14:01 ---
See Variable must not be polymorphic in assignment in resolve.c and note that
realloc on assignment must be supported to get this working properly (might
already work for derived types).
--
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-14 15:32 ---
Gcc 4.3 also failed. It also failed on Linux/x86-64.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2010-03-14 15:45 ---
In GCC 4.3.x you need optimization enabled for Wuninitialized.
In GCC 4.4.1 and GCC 4.5 (trunk) I get warnings in line 6 with -O1 -O2 and -O3.
We do not get a warning with -O0 because the default definition appears
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-14
15:49 ---
Since these vectorization omissions are a regression from gcc 4.4 and
apparently
we have a fix in hand...
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00533.html
shouldn't these bugs be bumped to P1 to
--- Comment #3 from dominiq at lps dot ens dot fr 2010-03-14 16:22 ---
we have a fix in hand...
I tried it, but it does not fix the vectorization!-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43359
--- Comment #2 from hjl dot tools at gmail dot com 2010-03-14 17:27 ---
It is caused by revision 151696:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00443.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2010-03-14 18:25 ---
It is caused by revision 121227:
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00933.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-14 18:31 ---
The patch started at:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01682.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[reg...@gamow tmp282]$ current-gcc -O2 small.c
small.c: In function 'int327':
small.c:29:1: internal compiler error: in may_propagate_copy, at
tree-ssa-copy.c:85
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Tested with Debian testing 4.4.3-3 and 4.3.4-8.
Compiling this code snippet:
template int field
struct Foo
{
static int
bar ()
{ return field; }
};
template bool
struct X
{
static int x;
typedef Foo x foo;
};
// This makes first statement in main() compile, but not the
All of gcjh's -add -append -friend and -prepend don't work.
For example, for the following source file a.java:
public class a {
}
Compiled like so:
gcj -C a.java
gcjh -friend ::java::lang::Number a.class
Results in the following header:
// DO NOT EDIT THIS FILE - it is machine generated -*- c++
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|ice: in may_propagate_copy, |[4.5 Regression] ice: in
|at tree-ssa-copy.c:85
--- Comment #6 from ubizjak at gmail dot com 2010-03-14 20:59 ---
The problem is actually in loop2_invariant rtl pass, and -O1/-O2 difference is
in fact due to missing cprop pass in -O1 case.
So, before _.162r.loop2_invariant, we have:
6 [`g_3']=0x1
7 r61:SI=[`l_5_5_2']
L13:
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-03-14 21:40
---
So, the solution is to teach loop2_invariant to also look into REG_EQUAL notes
if the insn is _really_ invariant or eventually clear REG_EQUAL notes when
insn is moved out of the loop.
Both should already
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-14 21:46 ---
It is caused by revision 156076:
http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00543.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-14 22:17 ---
Well, it is always executed, just [`g_3'] in REG_EQUAL is not invariant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
Using gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
Target: x86_64-linux-gnu
g++ -c -g -Wall -W -o NcBaseEncoderSse2.o -save-temps NcBaseEncoderSse2.ii
../../codecs/nc/sse2/NcBaseEncoderSse2.cpp: In member function virtual
unsigned int NcBaseEncoderSse2::fragile_block(unsigned int, const
--- Comment #1 from greggyh at gmail dot com 2010-03-14 23:04 ---
Created an attachment (id=20104)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20104action=view)
Preprocessed source that demonstrates the compiler error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43370
--- Comment #2 from greggyh at gmail dot com 2010-03-14 23:06 ---
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
Target: x86_64-linux-gnu
g++ -c -g -Wall -W -o NcBaseEncoderSse2.o -save-temps NcBaseEncoderSse2.ii
../../codecs/nc/sse2/NcBaseEncoderSse2.cpp: In member function virtual
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-14 23:27 ---
It is caused by revision 131044:
http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00495.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
As this option must have an argument, I think it should be mentioned in
DEFAULT_WORD_SWITCH_TAKES_ARG. Why it works now, because the next argument
after it is a temporary response file, 1st line of which is fresolution's
argument. However, this looks ugly...
--
Summary: Add
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-03-14
23:30 ---
Created an attachment (id=20105)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20105action=view)
Patch to add fresolution to gcc.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43371
--- Comment #4 from astrange at ithinksw dot com 2010-03-14 23:33 ---
This happens building ffmpeg --enable-shared with -fwhopr. I can make a
testcase out of that if needed.
--
astrange at ithinksw dot com changed:
What|Removed |Added
--- Comment #3 from falk at debian dot org 2010-03-14 23:35 ---
Confirmed, here is a testcase:
int fragile_block(void) {
typedef __attribute__ ((aligned (16))) struct {
int i;
} XmmUint16;
return 0;
}
--
falk at debian dot org changed:
What|Removed
the ICE line number is off by 1.)
Using gcc 20100314 and gold from Ubuntu binutils-gold 2.20-0ubuntu2.
--
Summary: lto ICE in strip_extension with linker plugin
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
--enable-languages=c,c++,objc,lto
--enable-gold --enable-lto --prefix=/usr/local/gcc45
Thread model: posix
gcc version 4.5.0 20100314 (experimental) (GCC)
ld --version
GNU gold (GNU Binutils for Ubuntu 2.20) 1.9
Copyright 2008 Free Software Foundation, Inc.
This program is free software; you may
$ cat test.c
int func(_Decimal32 v) {
return __builtin_isinf(v);
}
$ gcc -c test.c
test.c: In function 'func':
test.c:2:25: internal compiler error: in prepare_float_lib_cmp, at
optabs.c:4391
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #4 from hjl dot tools at gmail dot com 2010-03-15 03:34 ---
It is caused by revision 132681:
http://gcc.gnu.org/ml/gcc-cvs/2008-02/msg00696.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from wilson at gcc dot gnu dot org 2010-03-15 04:08 ---
I can reproduce the original problem with 28490 by changing the line in
ia64_legitimate_constant_p from
return (addend 0x3fff) == 0;
to
return true;
and compiling the testcase with -O. What
--- Comment #7 from wilson at gcc dot gnu dot org 2010-03-15 04:11 ---
Created an attachment (id=20106)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20106action=view)
untested patch, imperfect solution
--
wilson at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from jiez at gcc dot gnu dot org 2010-03-15 05:34 ---
I'm looking at this bug.
--
jiez at gcc dot gnu dot org changed:
What|Removed |Added
58 matches
Mail list logo
