Re: Failure in bootstrapping gfortran-4.4.0-20080425 on Cygwin
H.J. Lu [EMAIL PROTECTED] wrote on 27.04.2008 21:31:14: Is this related to http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01951.html H.J. On Sun, Apr 27, 2008 at 11:47 AM, FX [EMAIL PROTECTED] wrote: Cygwin native built gfortran 4.4 was already broken, even when it was making it through bootstrap and testsuite. All comments I've received told me I was wasting my time with it. Where is that bug reported? cygwin is secondary target, I think it should really be unbroken, with the help of its maintainers (and possibly by identifying the patch that broke bootstrap). FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/ I reverted the patch to keep fortran compilable on Saturday and bootstrapped it. This patch was just affecting mingw target by changes in mingw32.h and can't affect cygwin target, so it is unlikely to be the reason. The problem was for this patch, that the fortran frontend does not provide the function disable_builtin_function. Fortran uses implicit the builtins by the middle, but does not support the api defined in c-common.c. By this reason a subtarget is unable to disable builtins for C/C++ targets via the provide api, so I removed this patch. Kai | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination.
Re: IRA for GCC 4.4
On 2008/4/28 Ben Elliston [EMAIL PROTECTED] wrote: On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote: Don't be stupid! Could you be a bit more civil, please? It's fairly unusual for people on this list to talk to each other in this way. Thanks, Ben Excuse me, i'm not the unique and first person that says you stupid, GCC did it too. The stupid word can be a help, not only an offense. gcc/cp/decl.c: and in case doing stupid register allocation. gcc/c-aux-info.c: user may do something really stupid, like creating a brand new gcc/reload.c: we are called from global_alloc but false when stupid register gcc/dwarf2out.c: Now onto stupid register sets in non contiguous locations. gcc/protoize.c: A table of conversions that may need to be made for some (stupid) older /gcc/protoize.c: Don't act too stupid here. Somebody may try to convert an entire system gcc/protoize.c: case it would be stupid for us to fail to realize that this one definition gcc/protoize.c: this is stupid practice and should be discouraged. gcc/tree-ssa-phiopt.c: anything stupid here. gcc/c-common.c: Warn for unlikely, improbable, or stupid DECL declarations gcc/function.c: ??? This should no longer be necessary since stupid is no longer with gcc/gimple-low.c: don't know. This is used only to avoid stupidly generating extra code. gcc/genrecog.c: ??? is_unconditional is a stupid name for a tri-state function. gcc/global.c: and it is run even when stupid register allocation is in use. gcc/config/arm/arm.c: Prevent the user from choosing an obviously stupid PIC register. gcc/config/ia64/ia64-modes.def: so that flow doesn't do something stupid. gcc/config/ia64/ia64.c: stop the paradoxical subreg stupidity in the *_operand functions gcc/config/ia64/predicates.md: Deny the stupid user trick of addressing outside the object. gcc/config/mmix/predicates.md: FIXME: This may be a stupid trick. What happens when GCC wants to gcc/config/v850/v850.c: Function prototypes for stupid compilers gcc/config/sparc/sparc.c: avoid emitting truly stupid code. gcc/config/rs6000/darwin-fpsave.asm: be a stupid thing to do, anyway gcc/Makefile.in: Really, really stupid make features, such as SUN's KEEP_STATE, may force gcc/alias.c: but stupid user tricks can produce them, so don't die. gcc/c-decl.c: and in case doing stupid register allocation. gcc/c-decl.c: Warn for unlikely, improbable, or stupid declarations of `main'. gcc/optabs.c: but it's nice to not be stupid about initial code gen either. gcc/regrename.c: of a call insn, which is stupid, since these are certainly configure: This seems to be due to autoconf 2.5x stupidity. libstdc++-v3/doc/xml/manual/using.xml: However, you still need to not do stupid things like calling libstdc++-v3/scripts/run_doxygen: work around a stupid doxygen bug libstdc++-v3/scripts/run_doxygen: here's the other end of the stupid doxygen bug mentioned above libstdc++-v3/testsuite/data/thirty_years_among_the_dead_preproc.txt: stupidity configure.ac: This seems to be due to autoconf 2.5x stupidity. ChangeLog: Makefile.tpl: Fix stupid pasto. ChangeLog: configure: Fix stupid bug where RANLIB was mistakenly included. ChangeLog: configure.in: Fix deeply stupid bug. J.C.Pizarro
[switch conv] Bootsrap error because of the (CERT) pointer wraparound warning
Hi,
I've been rebootstrapping my switch conversion patch (which is still
waiting for review) to make sure it still works. Unfortunately, it
did not. The error given was the following and I believe this is the
warning introduced by Ian as a response to the infamous CERT advisory.
(Furthermore, I am getting this warning at revision 134664 but I was
not getting it at 134135.)
--- Compiler output ---
/cswtch/gcc/. -I/abuild/mjambor/cswtch/gcc/../include
-I/abuild/mjambor/cswtch/gcc/../libcpp/include
-I/abuild/mjambor/cswtch/gcc/../libdecnumber
-I/abuild/mjambor/cswtch/gcc/../libdecnumber/bid -I../libdecnumber
/abuild/mjambor/cswtch/gcc/tree-switch-conversion.c -o tree-switch-conversion.o
cc1: warnings being treated as errors
/abuild/mjambor/cswtch/gcc/tree-switch-conversion.c: In function
'process_switch':
/abuild/mjambor/cswtch/gcc/tree-switch-conversion.c:182: error: assuming signed
overflow does not occur when assuming that (X - c) X is always false
make[3]: *** [tree-switch-conversion.o] Error 1
- End -
The whole switch conversion patch can be found at:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00863.html. The code
that triggers the warning is the following, line 182 is the last one
in this snippet:
static bool
check_range (tree swtch) /* swtch is a SWITCH_EXPR */
{
tree min_case, max_case;
tree cases = SWITCH_LABELS (swtch);
int branch_num = TREE_VEC_LENGTH (cases);
min_case = TREE_VEC_ELT (cases, 0);
info.range_min = CASE_LOW (min_case);
gcc_assert (branch_num 1);
gcc_assert (CASE_LOW (TREE_VEC_ELT (cases, branch_num - 1)) == NULL_TREE);
max_case = TREE_VEC_ELT (cases, branch_num - 2);
Now the fundamental question is, am I doing something wrong? My best
guess is that this is only a very unfortunate bogus instance of the
warning. When checking is not enabled, TREE_VEC_ELT(T, I) is expanded
to ((T)-vec.a[I]) and given that branch_num holds the number of
vector elements, I am certainly accessing an item inside the array.
On the contrary, bootstrapping is done with checking on and so
TREE_VEC_ELT expands to much more complex thing:
#define TREE_VEC_ELT_CHECK(T, I) __extension__ \
(*({__typeof (T) const __t = (T); \
const int __i = (I);\
if (TREE_CODE (__t) != TREE_VEC)\
tree_check_failed (__t, __FILE__, __LINE__, __FUNCTION__, \
TREE_VEC, 0); \
if (__i 0 || __i = __t-vec.length) \
tree_vec_elt_check_failed (__i, __t-vec.length, \
__FILE__, __LINE__, __FUNCTION__); \
__t-vec.a[__i]; }))
And I guess that the second condition triggers the warning which is
then treated like an error.
Having said the above, I do not know why the TREE_VEC_ELT on the
previous line does not trigger the warning.
In the end, I basically have these questions:
1. Am I doing something wrong?
2. How can I get rid of the error and bootstrap my code?
3. If the warning is really bogus, should we perhaps turn it off for
bootstrap, (or turn it off by default in general and leave it
there for people who want to check their code after reading CERT
advisories)?
Thank you,
Martin
Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
Hello,
I am looking at a testsuite failure (wo_prof_global_var.c) in my
porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary malloc
during structure optimization. In the code, the structure is split into
two individual fields (D.2240 and D.2242) and they are allocated
separately. But the original structure (D.2215) is still allocated, and
not used afterward. The following RTL-level optimization cannot
eliminate it.
Cheers,
Bingfeng Mei
Broadcom UK
Original C code:
/* { dg-do compile } */
/* { dg-do run } */
#include stdlib.h
typedef struct
{
int a;
float b;
}str_t;
#define N 1000
str_t *p;
int
main ()
{
int i, sum;
p = malloc (N * sizeof (str_t));
for (i = 0; i N; i++)
p[i].a = p[i].b + 1;
for (i = 0; i N; i++)
if (p[i].a != p[i].b + 1)
abort ();
return 0;
}
.final_cleanup
/*--
*/
/* { dg-final { scan-ipa-dump Number of structures to transform is 1
ipa_struct_reorg } } */
/* { dg-final { cleanup-ipa-dump * } } */
;; Function main (main)
main ()
{
int i.43;
unsigned int D.2245;
unsigned int D.2243;
void * D.2242;
void * D.2240;
struct struct.0_sub.1 * p.0.4;
struct struct.0_sub.0 * p.0.3;
int i;
void * D.2215;
bb 2:
D.2215 = malloc (8000);
D.2240 = malloc (4000);
p.0.3 = (struct struct.0_sub.0 *) D.2240;
D.2242 = malloc (4000);
p.0.4 = (struct struct.0_sub.1 *) D.2242;
p = (struct str_t *) D.2215;
p.1 = p.0.4;
p.0 = p.0.3;
i = 0;
bb 3:
D.2243 = (unsigned int) i 2;
(p.0.4 + D.2243)-a = (int) ((p.0.3 + D.2243)-b + 1.0e+0);
i = i + 1;
if (i != 1000)
goto bb 3;
else
goto bb 4;
bb 4:
i.43 = 0;
bb 5:
D.2245 = (unsigned int) i.43 2;
if ((float) (p.0.4 + D.2245)-a != (p.0.3 + D.2245)-b + 1.0e+0)
goto bb 6;
else
goto bb 7;
bb 6:
abort ();
bb 7:
i.43 = i.43 + 1;
if (i.43 != 1000)
goto bb 5;
else
goto bb 8;
bb 8:
return 0;
}
Code representations
I am trying to look at assembler code, and representing it as C code. For ia32, x86 platforms, assembler like the following ADD eax,ebx; JO integer_overflow_detected; How would I represent this in C? Kind Regards James
Re: Code representations
[EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
I am trying to look at assembler code, and representing it as C code.
For ia32, x86 platforms,
assembler like the following
ADD eax,ebx;
JO integer_overflow_detected;
How would I represent this in C?
Kind Regards
James
It would be something like this:
#define MSB (type) ((1((sizeof(type)*8)-1))
typedef unsigned int myscalar;
...
{
myscalar a,b,savea;
...
savea = a;
a+=b;
if ( ((savea MSB(myscalar)) ((b MSB(myscalar)) ~(a
MSB(myscalar ||
( ~(savea MSB(myscalar)) ~(bMSB(myscalar)) (aMSB(myscalar
/* overflow */
...
}
For signed integers you can ease this as follow
savea = a;
a+=b;
if ( (savea0 b0 a=0)) ||
(savea=0 b=0 a0))
/* overflow */
Regards,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.
Metrication tool
Dear Reader, A few years ago I had already posted a question about implementing a metrication tool in GCC, i.e. a tool that can measure several metrics from the source code. Examples could be, the number of variables, number of multiplications, number of loops, number of functions, etc. At that time I needed that information for a Hardware Estimation Model I was building for my MSc. Thesis (http://ce.et.tudelft.nl/~rmeeuws/thesis.pdf). I was pointed to the ELSA compiler frontend which suited my purposes just fine... However, currently in my PhD work I have to take the model several steps further... First, I need to increase the models accuracy. One source of inaccuracy is that the metrics I use are determined at a very high level, i.e. I am counting operations that are removed by optimizations, like constant propagation, common subexpression elimination, dead code removal, etc. Therefore I need to measure some of the metrics at a lower level, which I aim to do using GCC, because in time the hardware generator (from c code) we use at our department will probably be moved to GCC at some point as well. So here is what I would like to know: what kind of metrics could I measure at e.g. GIMPLE level, and what steps do I need to take to implement a pass for GIMPLE to measure the needed values? Many thanks in advance for any help you can provide, with Kind Regards, Roel -- Roel Meeuws PhD. Student Delft University of Technology Faculty of Electrical Engineering Mathematics and Computer Science Computer Engineering Laboratory Mekelweg 4, 2628 CD Delft, The Netherlands Email:[EMAIL PROTECTED] Office: HB 16.290 Office phone: +31 (0)15 27 82 165 Mob. phone: +31 (0)6 10 82 44 01
Re: IRA for GCC 4.4
On Mon, Apr 28, 2008 at 09:07:51AM +0200, J.C. Pizarro wrote: Excuse me, i'm not the unique and first person that says you stupid, GCC did it too. GCC is not posting on the mailing list. Please be polite to other contributors; that includes not insulting their intelligence. -- Daniel Jacobowitz CodeSourcery
Re: Code representations
2008/4/28 Kai Tietz [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
I am trying to look at assembler code, and representing it as C code.
For ia32, x86 platforms,
assembler like the following
ADD eax,ebx;
JO integer_overflow_detected;
How would I represent this in C?
Kind Regards
James
It would be something like this:
#define MSB (type) ((1((sizeof(type)*8)-1))
typedef unsigned int myscalar;
...
{
myscalar a,b,savea;
...
savea = a;
a+=b;
if ( ((savea MSB(myscalar)) ((b MSB(myscalar)) ~(a
MSB(myscalar ||
( ~(savea MSB(myscalar)) ~(bMSB(myscalar)) (aMSB(myscalar
/* overflow */
...
}
For signed integers you can ease this as follow
savea = a;
a+=b;
if ( (savea0 b0 a=0)) ||
(savea=0 b=0 a0))
/* overflow */
I am taking a wild guess here, but can I assume that the above will
not compile back to something like:
ADD eax,ebx;
JO integer_overflow_detected;
I think I will have to have some macro/function in C that does the following:
add(int a,int b, int (integer_overflow_detected));
This will add a and b, and jump to the overflow handler if there is an overflow.
I can then implement CPU specific implementations for each target
platform, and that would at least return to the same ASM code
generated at compile.
James
Re: Code representations
James Courtier-Dutton [EMAIL PROTECTED] wrote on 28.04.2008
15:28:56:
2008/4/28 Kai Tietz [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
I am trying to look at assembler code, and representing it as C
code.
For ia32, x86 platforms,
assembler like the following
ADD eax,ebx;
JO integer_overflow_detected;
How would I represent this in C?
Kind Regards
James
It would be something like this:
#define MSB (type) ((1((sizeof(type)*8)-1))
typedef unsigned int myscalar;
...
{
myscalar a,b,savea;
...
savea = a;
a+=b;
if ( ((savea MSB(myscalar)) ((b MSB(myscalar)) ~(a
MSB(myscalar ||
( ~(savea MSB(myscalar)) ~(bMSB(myscalar))
(aMSB(myscalar
/* overflow */
...
}
For signed integers you can ease this as follow
savea = a;
a+=b;
if ( (savea0 b0 a=0)) ||
(savea=0 b=0 a0))
/* overflow */
I am taking a wild guess here, but can I assume that the above will
not compile back to something like:
ADD eax,ebx;
JO integer_overflow_detected;
This is a matter of the optimization. But I guess that gcc won't optimize
this to the same instruction you wrote, too.
But you queried 'How would I represent this in C?' and the above code is
the c representation of your assembler, sure.
I think I will have to have some macro/function in C that does the
following:
add(int a,int b, int (integer_overflow_detected));
This will add a and b, and jump to the overflow handler if there is
an overflow.
I can then implement CPU specific implementations for each target
platform, and that would at least return to the same ASM code
generated at compile.
May the better choice for your purpose.
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.
Re: dg-skip-if on powerpc when multiple cpu cflags specified
Mark Mitchell wrote: Janis Johnson wrote: This will involve editing every test that using dg-options to add a -mcpu/-march flag. Would it make sense to let dg-options check for the conflict as it adds an option? Yes, it would meaning adding the new option to hundreds of tests, but that's better than the earlier suggestion of adding a very ugly dg-skip-if to every one of those tests. I think it's even more complicated. The testsuite should not assume that options explicitly provided (a combination of the options explicitly in the test, those implicitly for the DejaGNU harness, those for the multilib being tested, and those provided in the board file) are those that govern completely. In particular, the --with-cpu configuration option, or other bits of configury, or -t options that serve as abbreviations for other options can all affect what CPU is actually being targeted. Trying to scan the list of options to see which ones are provided is too error-prone. Therefore I think there are two plausible approaches: 1. Make these tests say something about what capability they require, with a dg-require directive, and then write autoconf-style tests run by the testsuite to determine whether the current compiler has that capability. For example, add a dg-require-hard-float directive, and probe the compiler to see whether it can generate hard float, given all the options in play. That will not work on at least the *-rtems* configurations. We use one multilib'ed toolset configuration to support all variants within a family. So for the PowerPC, we actually do have support for [4567]xx, [58]xxx, etc. m68k includes coldfire, etc. 2. Write the tests with #ifdef's that test compiler predefines that indicate the CPU model, architecture, or available feature. For example, it would be a nice thing if something like __GNU_CPU_y__ and __GNU_TUNE_z__ were defined on all machines, corresponding to -march= and -mtune=. For example __GNU_CPU_603__ for a Power 603, or __GNU_FEATURE_ALTIVEC__ for a CPU with AltiVec support, or something. I think this would work. If you ended up with compiler settings that didn't match what the test required, then it could exit. How should it exit in this case? For the case we have been looking at, -mcpu=405 results in __PPC405__ being defined. If you are writing a CPU model specific test, you should know what the macro generated is. #if !defined(__PPC405__) XXX -- ?? what to do? #endif Would this work on the scan tests which look for particular assembly instructions? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 -- Joel Sherrill, Ph.D. Director of Research Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Metrication tool
On 4/28/08 7:46 AM, Roel Meeuws wrote: So here is what I would like to know: what kind of metrics could I measure at e.g. GIMPLE level, and what steps do I need to take to implement a pass for GIMPLE to measure the needed values? You can measure anything that is language-independent (though you could try to discern some FE attributes from the types you get). You can also do some limited measurements on target properties using target hooks. Writing a GIMPLE pass should not be too hard. There are some articles and online tutorials that may help. See http://gcc.gnu.org/wiki/GettingStarted Diego.
RE: IRA for GCC 4.4
J.C. Pizarro wrote on : On 2008/4/28 Ben Elliston wrote: On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote: Don't be stupid! Could you be a bit more civil, please? It's fairly unusual for people on this list to talk to each other in this way. Thanks, Ben Excuse me, i'm not the unique and first person that says you stupid, GCC did it too. Even if that were so, two wrongs do not make a right. The stupid word can be a help, not only an offense. gcc/cp/decl.c: and in case doing stupid register allocation. gcc/c-aux-info.c: user may do something really stupid, like creating a brand new The crucial difference you've overlooked is that all these comments are describing some /thing/ as stupid, not some /person/. When you want to offer what you hope will be /constructive/ criticism, try to de-personalise the issues; it makes for more productive social interactions. cheers, DaveK -- Can't think of a witty .sigline today
Re: IRA for GCC 4.4
On 2008/4/28 Dave Korn [EMAIL PROTECTED] wrote: J.C. Pizarro wrote on : On 2008/4/28 Ben Elliston wrote: On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote: Don't be stupid! Could you be a bit more civil, please? It's fairly unusual for people on this list to talk to each other in this way. Thanks, Ben Excuse me, i'm not the unique and first person that says you stupid, GCC did it too. Even if that were so, two wrongs do not make a right. It's your personal comment. For me, they do not make a right when they are 7 wrongs. The stupid word can be a help, not only an offense. gcc/cp/decl.c: and in case doing stupid register allocation. gcc/c-aux-info.c: user may do something really stupid, like creating a brand new The crucial difference you've overlooked is that all these comments are describing some /thing/ as stupid, not some /person/. When you want to offer what you hope will be /constructive/ criticism, try to de-personalise the issues; it makes for more productive social interactions. What about the stupid user in gcc/alias.c: but stupid user tricks can produce them, so don't die ? But the stupid things are made by humans, never by things. You can't de-personalise the stupid things made by humans, so it's better to say them stupid to persons who did stupid things better than to unfear things. cheers, DaveK -- Can't think of a witty .sigline today
Re: dg-skip-if on powerpc when multiple cpu cflags specified
Joel Sherrill wrote:
1. Make these tests say something about what capability they require,
with a dg-require directive, and then write autoconf-style tests run by
the testsuite to determine whether the current compiler has that
capability. For example, add a dg-require-hard-float directive, and
probe the compiler to see whether it can generate hard float, given all
the options in play.
That will not work on at least the *-rtems* configurations.
We use one multilib'ed toolset configuration to support
all variants within a family. So for the PowerPC, we actually
do have support for [4567]xx, [58]xxx, etc. m68k includes
coldfire, etc.
There's no reason that we can't probe once per multilib. There are
already probes like that in the testsuite. The autoconfy-ness just
needs to be per-multilib.
I think this would work. If you ended up with compiler
settings that didn't match what the test required, then
it could exit. How should it exit in this case?
Just by doing return 0; from main.
For the case we have been looking at, -mcpu=405 results
in __PPC405__ being defined. If you are writing a CPU model
specific test, you should know what the macro generated is.
#if !defined(__PPC405__)
XXX -- ?? what to do?
#endif
Here:
#if !defined(__PPC405__)
int main() { return 0; }
#else
/* The real test goes here. */
#endif
Would this work on the scan tests which look for particular
assembly instructions?
Probably not. Though, I suppose:
#if !defined(__PPC405__)
asm(haha here is a 405 insn);
#else
/* The real test goes here. */
#endif
might...
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
GCC performance with CP2K
I've just tested gcc/gfortran with CP2K, which some of you might know from PR29975 and other messages to the list, and observed some very pleasing evolution in the runtime of the code. In each case the set of compilation options is '-O2 -ffast-math -funroll-loops -ftree-vectorize -march=native' (-march=k8-sse3), the intel reference '-O2 -xW -heap-arrays 64' version subroutine time[s] out.intel: CP2K 504.52 out.gfortran.4.2.3: CP2K 601.35 out.gfortran.4.3.0: CP2K 569.42 out.gfortran.4.4.0: CP2K 508.12 I hope that this rate of improvement sets a standard up to gcc 4.95.3 ;-) Thanks for your efforts... Cheers, Joost
Re: IRA for GCC 4.4
On 2008/4/27 J.C. Pizarro [EMAIL PROTECTED] wrote: On Fri 25 Apr 2008 22:22:55 -0500, Peter Bergner [EMAIL PROTECTED] wrote: The difference between a compressed upper triangular bit matrix from a standard upper triangular bit matrix like the one above, is we eliminate space from the bit matrix for conflicts we _know_ can never exist. The easiest case to catch, and the only one we catch at the moment, is that allocnos that are local to a basic block B1 cannot conflict with allocnos that are local to basic block B2, where B1 != B2. To take advantage of this fact, I updated the code in global.c to sort the allocnos such that all global allocnos (allocnos that are live in more than one basic block) are given smaller allocno numbers than the local allocnos, and all allocnos for a given basic block are grouped together in a contiguous range to allocno numbers. The sorting is accomplished by: /* ...so we can sort them in the order we want them to receive their allocnos. */ qsort (reg_allocno, max_allocno, sizeof (int), regno_compare); ... It's useful when there are increases or decreases in the number of BBs. Topicing off about the recent stupidity's discussion, the chained upper triangulars and rectangulars are more flexible than a bigger compressed upper triangular because how expensive is modifying the compressed upper triangular when 1) add o remove basic blocks? 2) add o remove allocnos? In the chained case, you can call to subroutine to make it consistent after of adding or removing basic blocks or allocnos, it's traversing the chains and remallocing the many local memoryspaces of BBs. In the compressed case, you have to realize complex and expensive routines for remallocing the big compressed upper triangular. J.C.Pizarro
Re: dg-skip-if on powerpc when multiple cpu cflags specified
On Mon, 2008-04-28 at 07:47 -0700, Mark Mitchell wrote:
Joel Sherrill wrote:
1. Make these tests say something about what capability they require,
with a dg-require directive, and then write autoconf-style tests run by
the testsuite to determine whether the current compiler has that
capability. For example, add a dg-require-hard-float directive, and
probe the compiler to see whether it can generate hard float, given all
the options in play.
Defining proc check_effective_target_whatever makes it possible
to use dg-require-effective-target whatever, or combinations
of whatever with other effective targets. The proc can compile,
and optionally run, a configuration test with the current set of
options. I suppose it could even be used before and after
dg-options to make sure that the test files compiled with those
options will be compatible with support files compiled without
those options, as in
/* { dg-require-effective-target hard_float } */
/* { dg-options -O2 -mcpu=405 } */
/* { dg-require-effective-target hard_float ppc405 } */
That will not work on at least the *-rtems* configurations.
We use one multilib'ed toolset configuration to support
all variants within a family. So for the PowerPC, we actually
do have support for [4567]xx, [58]xxx, etc. m68k includes
coldfire, etc.
There's no reason that we can't probe once per multilib. There are
already probes like that in the testsuite. The autoconfy-ness just
needs to be per-multilib.
Right, the effective-target tests are usually run per-multilib.
I think this would work. If you ended up with compiler
settings that didn't match what the test required, then
it could exit. How should it exit in this case?
Just by doing return 0; from main.
For the case we have been looking at, -mcpu=405 results
in __PPC405__ being defined. If you are writing a CPU model
specific test, you should know what the macro generated is.
#if !defined(__PPC405__)
XXX -- ?? what to do?
#endif
Here:
#if !defined(__PPC405__)
int main() { return 0; }
#else
/* The real test goes here. */
#endif
Would this work on the scan tests which look for particular
assembly instructions?
Probably not. Though, I suppose:
#if !defined(__PPC405__)
asm(haha here is a 405 insn);
#else
/* The real test goes here. */
#endif
might...
It's easier, though, to just skip the test.
Janis
[RFC] Modeling the behavior of function calls
[ Apologies if this comes out twice. I posted this message last week, but I think it was rejected because of a .pdf attachment. ] We have been bouncing ideas for a new mechanism to describe the behavior of function calls so that optimizers can be more aggressive at call sites. Currently, GCC supports the notion of pure/impure, const/non-const, but that is not enough for various cases. The main application for this would be stable library code like libc, that the compiler generally doesn't get to process. David sketched up the initial idea and we have been adding to it for the last few weeks. At this point, we have the initial design ideas and some thoughts on how we would implement it, but we have not started any actual implementation work. The main idea is to add a variety of attributes to describe contracts for function calls. When the optimizers read in the function declaration, they can take advantage of the attributes and adjust the clobbering effects of call sites. We are interested in feedback on the main idea and possible implementation effort. We would like to discuss this further at the Summit, perhaps we can organize a BoF or just get folks together for a chat (this came up after the Summit deadline). The design document is available at the new wiki page I set up for this project: http://gcc.gnu.org/wiki/FunctionBehavior Thanks. Diego.
Re: [RFC] Modeling the behavior of function calls
On Mon, Apr 28, 2008 at 3:04 PM, Diego Novillo [EMAIL PROTECTED] wrote: [ Apologies if this comes out twice. I posted this message last week, but I think it was rejected because of a .pdf attachment. ] We have been bouncing ideas for a new mechanism to describe the behavior of function calls so that optimizers can be more aggressive at call sites. Currently, GCC supports the notion of pure/impure, const/non-const, but that is not enough for various cases. The main application for this would be stable library code like libc, that the compiler generally doesn't get to process. David sketched up the initial idea and we have been adding to it for the last few weeks. At this point, we have the initial design ideas and some thoughts on how we would implement it, but we have not started any actual implementation work. The main idea is to add a variety of attributes to describe contracts for function calls. When the optimizers read in the function declaration, they can take advantage of the attributes and adjust the clobbering effects of call sites. We are interested in feedback on the main idea and possible implementation effort. Roughly all of these attributes and ideas have been proposed before (by me, by zdenek, etc). Implementing the code to do stuff with the attributes is the easy part, and we've done some of it before (with a no_pointer_capture attribute, etc). The problem is three fold: 1. They all rely on slave labor for attributing headers for all the interesting platforms You can ameliorate some of this by having auto-annotations for the standard C library (ala builtins.def). 2. The number of interesting attributes is tremendous because of the amount of info you are trying to capture, and it is going to be very hard to get anyone to attribute an entire application, or even interesting functions, with all the right ones. 3. Most if not all of these attributes can be discovered by the compiler while we are compiling the libraries in question (or when your distro, etc does it), we just don't save it anywhere. It would be a huge boon if you included provisions for storing this info on the side somewhere, much like most linux distros these days keep debug info separate in /usr/lib/debug (and darwin allows you to put debug info in a differently named dir, etc). This would make most of the attributes not really necessary except for special cases, for the majority of our users. The last problem was easy, which is that nobody stepped up to solve all these problems :)
Are x86 builtin load functions const?
Hi, I noticed that x86 builtin load functions aren't defined with def_builtin_const. Is this an oversight or intentional? Thanks. H.J.
Re: Are x86 builtin load functions const?
On Mon, Apr 28, 2008 at 12:47 PM, H.J. Lu [EMAIL PROTECTED] wrote: I noticed that x86 builtin load functions aren't defined with def_builtin_const. Is this an oversight or intentional? I don't see why they can't be defined as const, the only time I can think of is when you have -fnon-call-exceptions turned on as they can trap. Why do you think this is wrong? Thanks, Andrew Pinski
Re: [RFC] Modeling the behavior of function calls
Diego Novillo wrote: [ Apologies if this comes out twice. I posted this message last week, but I think it was rejected because of a .pdf attachment. ] We have been bouncing ideas for a new mechanism to describe the behavior of function calls so that optimizers can be more aggressive at call sites. Currently, GCC supports the notion of pure/impure, const/non-const, but that is not enough for various cases. The main application for this would be stable library code like libc, that the compiler generally doesn't get to process. David sketched up the initial idea and we have been adding to it for the last few weeks. At this point, we have the initial design ideas and some thoughts on how we would implement it, but we have not started any actual implementation work. The main idea is to add a variety of attributes to describe contracts for function calls. When the optimizers read in the function declaration, they can take advantage of the attributes and adjust the clobbering effects of call sites. We are interested in feedback on the main idea and possible implementation effort. We would like to discuss this further at the Summit, perhaps we can organize a BoF or just get folks together for a chat (this came up after the Summit deadline). Diego, For the (all important :-)) java front end, it could be useful to have an attribute indicating that a function returns a non-null value. This is the case for the new operator which throws on allocation failures. Having this would allow VRP to eliminate a good bit of dead code for common java constructs. See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24825 Thanks, David Daney
Re: IRA for GCC 4.4
Peter Bergner wrote:
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
Hi, Peter. The last time I looked at the conflict builder
(ra-conflict.c), I did not see the compressed matrix. Is it in the
trunk? What should I look at?
Yes, the compressed bit matrix was committed as revision 129037 on
October 5th, so it's been there a while. Note that the old square
bit matrix was used not only for testing for conflicts, but also for
visiting an allocno's neighbors. The new code (and all compilers I've
worked on/with), use a {,compressed} upper triangular bit matrix for
testing for conflicts and an adjacency list for visiting neighbors.
IRA also uses an adjacency lists for visiting conflict graph neighbors
(they contain conflict allocnos only of the same cover classes).
The code that allocates and initializes the compressed bit matrix is in
global.c. If you remember how a upper triangular bit matrix works, it's
just one big bit vector, where the bit number that represents the conflict
between allocnos LOW and HIGH is given by either of these two functions:
...
Thanks, Peter. That was clever and email is very enlightening. I have
analogous idea for more compact conflict matrix representation. IRA
builds allocno live ranges first (they are ranges of program points
where the allocno lives). I can use this information for fast searching
potential conflicts to sort the allocnos. Probably the matrix will be
even more compact because live ranges contain more detail info than
basic blocks where the local allocnos live. For example, the ranges
even can show that allocnos local in the same block will never
conflicts. It means that matrix even for fppp can be compressed.
I have also another question. I saw that sparset was used for the
conflict builder. I tried that too when I worked on YARA project. I
even wanted to contribute a generic sparset implementation. But I found
that in general case bitmaps are not worse the sparse sets and much
better if we take a needed space into account. May be you have another
impression? It would be very interesting for me to hear it. I found
that bitmaps have more advanced design than sparsets. I always wanted
to find inventors the bitmaps but never tracked them down.
The sparseset representation is only used for the allocnos_live set.
The old version was a bit vector to match up with the square bit matrix.
Since I changed that to save space, I had to reimplement allocnos_live.
Danny suggested I use a bitmap for that set and I tried it, but I found
for the particular usage of allocnos_live, a sparseset was noticeably
faster than bitmaps. I'll note that the main operations on allocnos_live
are to add allocnos to the set, remove allonos to the set and iterate over
the members of the set and occasionally clear the entire set. These are
all O(1) operations for the sparseset with fairly low constant factors
too. I didn't look too closely, but I'm guessing that the main problem
with bitmaps for this type of usage was the slower iterating over all
of the members of the set versus the sparseset.
Obviously, bitmaps are much better than sparsesets wrt space usage, so
you have to use them sparingly. You wouldn't want an array of these
things! :) But there are use cases where they work very very well.
The currently live set is one such use. Another use I have found
where they work well is in the needLoad set used by Briggs' allocator.
Whether you want/should use a sparseset really depends on the number
and type of set operations your particular usage will see. I'm sure
there are many usage cases where bitmaps are superior to sparsesets,
just like there are usage cases where sparsesets are superior. I know
that sounds like a cop-out, but it really does depend on how you're
going to use it.
I tried to use sparsets for the same purposes (only for maintaining and
processing allocnos currently living). But usage of sparsets for this
purposes gave practically nothing (I had to use valgrind lackey to see
the difference). Therefore I decided not to introduce the additional
data and use just bitmaps for this.
Sparsets already exists in a compiler. I am thinking about their usage
too. May be you have a benchmark where the sparsets give a visible
compiler speed improvement (my favorite was combine.i). I'd appreciate
if you point me such benchmark. It could help me to make a decision to
use sparsets.
Re: Are x86 builtin load functions const?
I am combining most x86 SIMD builtins into bdesc_sse_args. I only define store builtins with def_builtin. The rest will be defined with def_builtin_const., including load builtins. I want to make sure that it is OK to do so. Thanks. H.J. On Mon, Apr 28, 2008 at 12:50 PM, Andrew Pinski [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 12:47 PM, H.J. Lu [EMAIL PROTECTED] wrote: I noticed that x86 builtin load functions aren't defined with def_builtin_const. Is this an oversight or intentional? I don't see why they can't be defined as const, the only time I can think of is when you have -fnon-call-exceptions turned on as they can trap. Why do you think this is wrong? Thanks, Andrew Pinski
Re: IRA for GCC 4.4
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote: Thanks, Peter. That was clever and email is very enlightening. I have analogous idea for more compact conflict matrix representation. IRA builds allocno live ranges first (they are ranges of program points where the allocno lives). I can use this information for fast searching potential conflicts to sort the allocnos. Probably the matrix will be even more compact because live ranges contain more detail info than basic blocks where the local allocnos live. For example, the ranges even can show that allocnos local in the same block will never conflicts. It means that matrix even for fppp can be compressed. You say you use your analogous idea now? Can you point me to the code? I thought I heard you (maybe someone else?) that your conflict information was much bigger than old mainline. If this is true and you are compacting the bit matrix like I am, why is it so big? I tried to use sparsets for the same purposes (only for maintaining and processing allocnos currently living). But usage of sparsets for this purposes gave practically nothing (I had to use valgrind lackey to see the difference). Therefore I decided not to introduce the additional data and use just bitmaps for this. Sparsets already exists in a compiler. I am thinking about their usage too. May be you have a benchmark where the sparsets give a visible compiler speed improvement (my favorite was combine.i). I'd appreciate if you point me such benchmark. It could help me to make a decision to use sparsets. Yes, I added the sparseset implementation that has been in since gcc 4.3. Did you use my sparseset implementation or did you write your own for your tests? I don't recall which file(s) I saw the difference on. All I recall is I tried it both ways, saw a difference somewhere and promptly threw the slower code away along with which file(s) I saw the difference on. Sorry I can't be of more help. Given how sparsesets are implemented, I cannot see how they could ever be slower than bitmaps for the use of live, but I can see how they might be faster. That said, if your allocator is spending enough time elsewhere, then I can easily imagine the difference being swamped such that you don't see any difference at all. Peter
Re: [RFC] Modeling the behavior of function calls
On Apr 28, 2008, at 12:04 PM, Diego Novillo wrote: [ Apologies if this comes out twice. I posted this message last week, but I think it was rejected because of a .pdf attachment. ] We have been bouncing ideas for a new mechanism to describe the behavior of function calls so that optimizers can be more aggressive at call sites. Currently, GCC supports the notion of pure/impure, const/non-const, but that is not enough for various cases. The main application for this would be stable library code like libc, that the compiler generally doesn't get to process. This is very interesting. One issue to consider: how do you plan to handle errno? There are a variety of compiler transformations that can be done on libm functions, even in the presence of errno. For an example (which occurs in spec2k), it is safe to transform: for (i = 0 .. 100) Val += i*sqrt(loopinvariant) into: tmp = sqrt(loopinvariant) for (i = 0 .. 100) Val += i*tmp This is safe because errno will still be set and the value that errno is set to is a function of the input value. Also, the value of errno is not otherwise changed in the body of the loop. Note that sqrt is not pure or const here because it sets errno. The wrinkle is detecting that the loop body doesn't set errno. On many platforms, errno is a #define for something like *__errno_func(). How do you plan to model this? -Chris
mapping liveness to variables
Hi guys, I am trying to get as close mapping from liveness information ( in bb-il.rtl-global_live_at_start ) to global and local variables as possible. Mapping to stack slots would be a good first step. What data structures should I look at use? What would be the best way to do it? Any suggestions appreciated, Gregory -- What would you attempt to do if you knew you could not fail?
Re: IRA for GCC 4.4
Peter Bergner wrote: On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote: Thanks, Peter. That was clever and email is very enlightening. I have analogous idea for more compact conflict matrix representation. IRA builds allocno live ranges first (they are ranges of program points where the allocno lives). I can use this information for fast searching potential conflicts to sort the allocnos. Probably the matrix will be even more compact because live ranges contain more detail info than basic blocks where the local allocnos live. For example, the ranges even can show that allocnos local in the same block will never conflicts. It means that matrix even for fppp can be compressed. You say you use your analogous idea now? Can you point me to the code? I thought I heard you (maybe someone else?) that your conflict information was much bigger than old mainline. If this is true and you are compacting the bit matrix like I am, why is it so big? I am currently working on bit matrix compression. It is not implemented yet. I hope it will be ready in a week. Live ranges were implemented long ago. They are quit important for fast transformation of regional IR into one region IR (before this I just rebuilt IR which was simple code but very time consuming). IRA can create additional allocnos because of live range splitting on the region borders and remove some of them during the transformation. The transformation is complicated because allocnos on upper levels of the region tree accumulate a lot of info (including conflicts) from allocnos on lower levels. I tried to use sparsets for the same purposes (only for maintaining and processing allocnos currently living). But usage of sparsets for this purposes gave practically nothing (I had to use valgrind lackey to see the difference). Therefore I decided not to introduce the additional data and use just bitmaps for this. Sparsets already exists in a compiler. I am thinking about their usage too. May be you have a benchmark where the sparsets give a visible compiler speed improvement (my favorite was combine.i). I'd appreciate if you point me such benchmark. It could help me to make a decision to use sparsets. Yes, I added the sparseset implementation that has been in since gcc 4.3. Did you use my sparseset implementation or did you write your own for your tests? I don't recall which file(s) I saw the difference on. All I recall is I tried it both ways, saw a difference somewhere and promptly threw the slower code away along with which file(s) I saw the difference on. Sorry I can't be of more help. I had own implementation which I used for YARA project. Given how sparsesets are implemented, I cannot see how they could ever be slower than bitmaps for the use of live, but I can see how they might be faster. That said, if your allocator is spending enough time elsewhere, then I can easily imagine the difference being swamped such that you don't see any difference at all. Yes, that is true. I found that the code using sparsets (or bitmaps) are far away to be a bottleneck.
gcc-4.1-20080428 is now available
Snapshot gcc-4.1-20080428 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080428/ 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/gcc-4_1-branch revision 134768 You'll find: gcc-4.1-20080428.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080428.tar.bz2 C front end and core compiler gcc-ada-4.1-20080428.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080428.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080428.tar.bz2 C++ front end and runtime gcc-java-4.1-20080428.tar.bz2 Java front end and runtime gcc-objc-4.1-20080428.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080428.tar.bz2The GCC testsuite Diffs from 4.1-20080421 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Are x86 builtin load functions const?
Load builtins can't be const since they may return different values on the same pointer value. H.J. On Mon, Apr 28, 2008 at 1:19 PM, H.J. Lu [EMAIL PROTECTED] wrote: I am combining most x86 SIMD builtins into bdesc_sse_args. I only define store builtins with def_builtin. The rest will be defined with def_builtin_const., including load builtins. I want to make sure that it is OK to do so. Thanks. H.J. On Mon, Apr 28, 2008 at 12:50 PM, Andrew Pinski [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 12:47 PM, H.J. Lu [EMAIL PROTECTED] wrote: I noticed that x86 builtin load functions aren't defined with def_builtin_const. Is this an oversight or intentional? I don't see why they can't be defined as const, the only time I can think of is when you have -fnon-call-exceptions turned on as they can trap. Why do you think this is wrong? Thanks, Andrew Pinski
Re: Are x86 builtin load functions const?
On Mon, Apr 28, 2008 at 5:16 PM, H.J. Lu [EMAIL PROTECTED] wrote: Load builtins can't be const since they may return different values on the same pointer value. They should be pure though. -- Pinski
Re: [switch conv] Bootsrap error because of the (CERT) pointer wraparound warning
Martin Jambor [EMAIL PROTECTED] writes: I've been rebootstrapping my switch conversion patch (which is still waiting for review) to make sure it still works. Unfortunately, it did not. The error given was the following and I believe this is the warning introduced by Ian as a response to the infamous CERT advisory. (Furthermore, I am getting this warning at revision 134664 but I was not getting it at 134135.) --- Compiler output --- /cswtch/gcc/. -I/abuild/mjambor/cswtch/gcc/../include -I/abuild/mjambor/cswtch/gcc/../libcpp/include -I/abuild/mjambor/cswtch/gcc/../libdecnumber -I/abuild/mjambor/cswtch/gcc/../libdecnumber/bid -I../libdecnumber /abuild/mjambor/cswtch/gcc/tree-switch-conversion.c -o tree-switch-conversion.o cc1: warnings being treated as errors /abuild/mjambor/cswtch/gcc/tree-switch-conversion.c: In function 'process_switch': /abuild/mjambor/cswtch/gcc/tree-switch-conversion.c:182: error: assuming signed overflow does not occur when assuming that (X - c) X is always false make[3]: *** [tree-switch-conversion.o] Error 1 - End - The warnings I added for the CERT advisory say assuming pointer wraparound does not occur You are running into one of the older signed overflow warnings. 1. Am I doing something wrong? No. 2. How can I get rid of the error and bootstrap my code? Make branch_num an unsigned int. 3. If the warning is really bogus, should we perhaps turn it off for bootstrap, (or turn it off by default in general and leave it there for people who want to check their code after reading CERT advisories)? The basic criteria for -Wall is: could indicate a problem, easy to rewrite code to avoid. You've encountered a false positive, but it's easy to avoid. Ian
Re: IRA for GCC 4.4
On Mon, 2008-04-28 at 18:07 -0400, Vladimir Makarov wrote: I am currently working on bit matrix compression. It is not implemented yet. I hope it will be ready in a week. Ahh, ok. Well, hopefully the code I wrote on the trunk is useful for IRA. If you have questions about it, let me know, or if you want me to look into it on IRA, just point me to your current code that does this and I'll try and take a look when I have some free cycles. I'll note that the real key to eliminating the space from the bit matrix isn't that we know two allocnos do not interfere, but rather that we know we'll never test for whether they conflict or not. Since our definition of conflict is live at the definition of another, that simply translates into, if they're never simultaneously live, then we'll never call any bit matrix routines asking whether they conflict or not, so we don't need to reserve space for any conflict info. The fact that local allonocs from different blocks are never simultaneously live was just a very easy and inexpensive property to measure. If your live range info can easily and cheaply partition the allocnos into sets that are and are not live simultaneously, then you should be able to see some further reductions over what I'm seeing...which I think I've shown, can be considerable. Peter
Fwd: gcc cross compiler problem
-- Forwarded message -- From: NoFirst NoLast [EMAIL PROTECTED] Date: Mon, Apr 28, 2008 at 6:46 PM Subject: gcc cross compiler problem To: gcc@gcc.gnu.org Hello gcc, I am running into a problem when I am trying to compile GCC to run on a i686-pc-linux-gnu (host) but to build source code for target, x86_64-pc-linux-gnu. I have build binutils first with the following configure parameters: configure --target=x86_64-pc-linux-gnu --prefix==mydirectoryforinstall. After I make and install binutils into my own directory, I build gcc using the following configure parameter: configure --prefix=mygccdirectoryfor install --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,fortran,ada --disable-dssi --enable-plugin --with-cpu=generic --host=x86_64-pc-linux-gnu Once I did that, I perform a make all. Eventually, gcc starts to build genmodes.c at which point I get the following errors: /tmp/ccwdhaLJ.s: 2073: Error: Suffix or operands invalid for 'pop' /tmp/ccwdhaLJ.s: 2075: Error: Suffix or operands invalid for 'pop' /tmp/ccwdhaLJ.s: 2077: Error: Suffix or operands invalid for 'pop' /tmp/ccwdhaLJ.s: 2094: Error: Suffix or operands invalid for 'push' There are a lot of the these error messages. I only pasted a few lines. I am using GCC version 4.3.0 and binutils 2.18. If you could giving a helping hand, I would appreciate it very much. Thanks, Scott
Re: [RFC] Modeling the behavior of function calls
Diego Novillo wrote: We have been bouncing ideas for a new mechanism to describe the behavior of function calls so that optimizers can be more aggressive at call sites. Currently, GCC supports the notion of pure/impure, const/non-const, but that is not enough for various cases. Fortran supports to mark function arguments as INTENT(IN), i.e. they are not modified by the function, or INTENT(OUT), i.e. the variable is set in the function - thus an assignment of a variable just before the function call can be optimized away. (Especially, supporting INTENT(IN) would be useful as by default all variables get passed by reference in Fortran. See PR 23169. Tobias PS: Fortran has also the notion of PURE functions. And all objects which are passed by reference or are ALLOCATABLE match C's restricted pointer, unless they have the (pointer) TARGET or the POINTER attribute - only then the same memory can be reached via more than one variable name.
[Bug testsuite/36056] g++.dg/ext/vector14.C doesn't work for ia32
--- Comment #2 from ubizjak at gmail dot com 2008-04-28 07:38 --- No, we need -msse for i686 here since vector floats have to go into xmm register. I will fix this. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-28 07:38:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36056
[Bug testsuite/36056] g++.dg/ext/vector14.C doesn't work for ia32
--- Comment #3 from uros at gcc dot gnu dot org 2008-04-28 07:42 --- Subject: Bug 36056 Author: uros Date: Mon Apr 28 07:42:12 2008 New Revision: 134743 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134743 Log: PR testsuite/36056 * g++.dg/ext/vector14.C: Add -msse for 32bit x86 targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/vector14.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36056
[Bug target/36064] could not split insn with -O1 -march=nocona -m32
--- Comment #3 from uros at gcc dot gnu dot org 2008-04-28 07:52 --- Subject: Bug 36064 Author: uros Date: Mon Apr 28 07:52:01 2008 New Revision: 134744 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134744 Log: PR target/36064 * config/i386/i386.md (floatdiX87MODEF:mode2_i387_with_xmm splitters): Use match_scratch instead of match_operand for operands 3 and 4. testsuite/ChangeLog: PR target/36064 * gcc.target/i386/pr36064.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr36064.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36064
[Bug testsuite/36056] g++.dg/ext/vector14.C doesn't work for ia32
--- Comment #4 from ubizjak at gmail dot com 2008-04-28 08:00 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg02012.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36056
[Bug target/36064] could not split insn with -O1 -march=nocona -m32
--- Comment #4 from ubizjak at gmail dot com 2008-04-28 08:01 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg02013.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36064
[Bug tree-optimization/36066] [4.4 Regression] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-28 09:09 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36066
[Bug testsuite/36068] gcc.dg/vect/vect-118.c doesn't work on Linux/ia32
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-28 09:22 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36068
[Bug tree-optimization/34223] missed optimization - complete unrolling pass before the vectorizer
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 09:23 --- Subject: Bug 34223 Author: rguenth Date: Mon Apr 28 09:22:28 2008 New Revision: 134747 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134747 Log: 2008-04-28 Richard Guenther [EMAIL PROTECTED] PR testsuite/34223 * gcc.dg/vect/vect-118.c: Rename to ... * gcc.dg/vect/O3-vect-pr34223.c: ... this. Added: trunk/gcc/testsuite/gcc.dg/vect/O3-vect-pr34223.c - copied, changed from r134744, trunk/gcc/testsuite/gcc.dg/vect/vect-118.c Removed: trunk/gcc/testsuite/gcc.dg/vect/vect-118.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34223
[Bug tree-optimization/36066] [4.4 Regression] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 09:10 --- Subject: Bug 36066 Author: rguenth Date: Mon Apr 28 09:09:19 2008 New Revision: 134745 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134745 Log: 2008-04-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36066 * tree-vrp.c (execute_vrp): Cleanup the CFG only after finalizing SCEV and loop. * gcc.dg/torture/pr36066.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr36066.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36066
[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC
--- Comment #6 from jakub at gcc dot gnu dot org 2008-04-28 09:51 --- Subject: Bug 36060 Author: jakub Date: Mon Apr 28 09:50:31 2008 New Revision: 134751 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134751 Log: PR debug/36060 * dwarf2out.c (struct die_struct): Mark as chain_circular through die_sub field. * gengtype.c (walk_type, write_func_for_structure): Handle chain_circular. * doc/gty.texi: Document chain_circular. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/doc/gty.texi branches/gcc-4_3-branch/gcc/dwarf2out.c branches/gcc-4_3-branch/gcc/gengtype.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36060
[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-28 09:46 --- Subject: Bug 36060 Author: jakub Date: Mon Apr 28 09:45:26 2008 New Revision: 134750 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134750 Log: PR debug/36060 * dwarf2out.c (struct die_struct): Mark as chain_circular through die_sub field. * gengtype.c (walk_type, write_func_for_structure): Handle chain_circular. * doc/gty.texi: Document chain_circular. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/gty.texi trunk/gcc/dwarf2out.c trunk/gcc/fortran/ChangeLog trunk/gcc/gengtype.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36060
[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-28 09:52 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36060
[Bug middle-end/31738] Fortran dot product vectorization is restricted
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-28 09:39 --- For testvectdp2 we now miss to apply store-motion so the reduction is no longer recognized. This is the bad interaction between PRE and lim for which we have PR36009. If you add -fno-tree-pre vectorization fails because of t.f90:7: note: reduction: not commutative/associative: D.1011_34 even with -ffast-math. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||36009 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31738
[Bug c++/36069] New: Strange warning: suggest parentheses around assignment used as truth value with volatile/non volatile bools
When compiling the following file with g++ 4.3.0, with -Wall :
main.cpp
struct foo {
bool a;
volatile bool b,c; // removing 'volatile' here removes the warning.
foo() { a = b = c = false; }
};
int main() {
foo A;
}
-- end of main.cpp --
-bash-3.00$ g++ main.cpp -Wall
tata.cpp: In constructor 'foo::foo()':
tata.cpp:4: warning: suggest parentheses around assignment used as truth value
It seems that having an assignement between 'volatile' and non-volatile bools
activates the warning. I don't see any reason why it should behave like this.
Removing the volatile keyword (or adding it in the line above) removes the
warning.
--
Summary: Strange warning: suggest parentheses around assignment
used as truth value with volatile/non volatile bools
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: David dot Tschumperle at greyc dot ensicaen dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36069
[Bug c++/36069] Strange warning: suggest parentheses around assignment used as truth value with volatile/non volatile bools
--- Comment #1 from David dot Tschumperle at greyc dot ensicaen dot fr
2008-04-28 10:55 ---
Also, removing the warning without adding or removing 'volatile' can be
achieved by writting :
foo() { a = (b = (c = false)); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36069
[Bug libgcj/24403] --enable-java-awt=qt fails to build
--- Comment #16 from bero at arklinux dot org 2008-04-28 10:59 --- ping... This missed 4.3 again, it should probably get in now before 4.4 enters freeze mode... Re the moc - moc-qt4 change suggested in comment #14: This should be detected by the configure script, moc-qt4 is a nonstandard way some distributions use to tell moc 3.x apart from moc 4.x, other candidates for the correct moc include moc4 and simply launching moc from a different path (/usr/lib/qt4/bin/moc) if the default moc is from 3.x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24403
[Bug c/36070] New: m68k/coldfire gcc build breaks due to sc_fpstate, sc_fpregs reference
In gcc/config/m68k/linux-unwind.h, the function m68k_fallback_frame_state() has
the following:
if (*(int *) sc-sc_fpstate)
{
int *fpregs = (int *) sc-sc_fpregs;
fs-regs.reg[16].how = REG_SAVED_OFFSET;
fs-regs.reg[16].loc.offset = (long) fpregs[0] - cfa;
fs-regs.reg[17].how = REG_SAVED_OFFSET;
fs-regs.reg[17].loc.offset = (long) fpregs[M68K_FP_SIZE/4] - cfa;
}
The variable sc is of type struct sigcontext, which is defined the linux
kernel headers in asm/sigcontext.h. For asm-m68k, the sigcontext structure has
members sc_fpregs, sc_fpcntl, and sc_fpstate. For asm-m68knommu, the sigcontext
structure does not have the sc_fp... members. This causes the gcc build to
break in libgcc when the asm-m68knommu kernel headers are used. This is so with
the uClinux 2.4 kernel and the vanilla linux 2.6 kernel.
I'm not too familiar with the code in linux-unwind.h, but one solution might be
to wrap the above code in an #ifdef __mcffpu__.
--
Summary: m68k/coldfire gcc build breaks due to sc_fpstate,
sc_fpregs reference
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kendallc at vxitech dot com
GCC target triplet: m68k-unknown-uclinux-uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36070
[Bug fortran/35997] [4.3/4.4 regression]Used function interface bug
--- Comment #2 from pault at gcc dot gnu dot org 2008-04-28 11:55 --- Created an attachment (id=15541) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15541action=view) Fix for this PR This seems to do the job. The problem arises because the present version of module.c does not add a new symtree that is not renamed if the symbol is already present. The test in module.c(find_symbol) was failing to resolve the case where the renaming is already done in the module that is being use associated. This patch accomplishes this by looking for a symtree with the same name as the symbol and, upon failure, checking that the symbol is not renamed; this can only correspond to the unresolved case. I will develop a proper testcase and submit later on today. -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35997
[Bug target/35399] [4.3 regression] bootstrap error, ICE in free_list, at lists.c:52
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-28 11:56 --- Can you reproduce it with a newer snapshot? Can you find out which change between 0219 and 0227 caused it? There were very few changes that might affect it at all, I'd say just PR35071, PR35265, PR34971 and PR35390, the rest of the changes were either specific to other targets, or testsuite/documentation, or C++/Fortran, or outside of the gcc/ subdirectory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35399
[Bug testsuite/36056] g++.dg/ext/vector14.C doesn't work for ia32
--- Comment #5 from uros at gcc dot gnu dot org 2008-04-28 12:18 --- Subject: Bug 36056 Author: uros Date: Mon Apr 28 12:17:27 2008 New Revision: 134752 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134752 Log: PR testsuite/36056 * g++.dg/ext/vector14.C: Add -msse for 32bit x86 targets. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/vector14.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36056
[Bug target/35399] [4.3 regression] bootstrap error, ICE in free_list, at lists.c:52
--- Comment #2 from riku dot voipio at iki dot fi 2008-04-28 12:26 --- Newer arm builds of gcc-4.3 in debian have succeeded fine, so I'd say this bug can be closed. One theory could be that this build machine simply ran out of Memory during the build (although a later build on similar machine succeeded fine). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35399
[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)
--- Comment #5 from burnus at gcc dot gnu dot org 2008-04-28 12:34 --- Further reports: They might show the same problem, or also different ones. I did not check them all: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c553e0034bab977c * * * Patch by FX: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00546.html My review: http://gcc.gnu.org/ml/fortran/2008-03/msg00232.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199
[Bug middle-end/36071] New: [4.4 Regression] segmentation fault
2 days old trunk fails on CVS CP2K [see PR29975] with gfortran -c -v -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form -D__GFORTRAN -D__FFTSG -D__COMPILE_ARCH=\Linux-x86-64-gfortran\ -D__COMPILE_DATE=\Mon Apr 28 14:33:23 CEST 2008\ -D__COMPILE_HOST=\pcihopt3\ -D__COMPILE_LASTCVS=\/termination.F/1.32/Mon Apr 28 07:20:29 2008//\ /data03/vondele/clean/cp2k/src/../src/hfx_libint_interface.F Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --with-gmp=/data03/vondele/ --with-mpfr=/data03/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.4.0 20080426 (experimental) [trunk revision 134695] (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-O2' '-ffast-math' '-funroll-loops' '-ftree-vectorize' '-ffree-form' '-D__GFORTRAN' '-D__FFTSG' '-D__COMPILE_ARCH=Linux-x86-64-gfortran' '-D__COMPILE_DATE=Mon Apr 28 14:33:23 CEST 2008' '-D__COMPILE_HOST=pcihopt3' '-D__COMPILE_LASTCVS=/termination.F/1.32/Mon Apr 28 07:20:29 2008//' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v -D__GFORTRAN -D__FFTSG -D__COMPILE_ARCH=Linux-x86-64-gfortran -D__COMPILE_DATE=Mon Apr 28 14:33:23 CEST 2008 -D__COMPILE_HOST=pcihopt3 -D__COMPILE_LASTCVS=/termination.F/1.32/Mon Apr 28 07:20:29 2008// /data03/vondele/clean/cp2k/src/../src/hfx_libint_interface.F -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -ffast-math -funroll-loops -ftree-vectorize -ffree-form -O2 -o /tmp/ccxHLZQc.f ignoring nonexistent directory /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /data03/vondele/gcc_trunk/build/include /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-c' '-v' '-O2' '-ffast-math' '-funroll-loops' '-ftree-vectorize' '-ffree-form' '-D__GFORTRAN' '-D__FFTSG' '-D__COMPILE_ARCH=Linux-x86-64-gfortran' '-D__COMPILE_DATE=Mon Apr 28 14:33:23 CEST 2008' '-D__COMPILE_HOST=pcihopt3' '-D__COMPILE_LASTCVS=/termination.F/1.32/Mon Apr 28 07:20:29 2008//' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 /tmp/ccxHLZQc.f -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase hfx_libint_interface.F -auxbase hfx_libint_interface -O2 -version -ffast-math -funroll-loops -ftree-vectorize -ffree-form -fpreprocessed -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccwowsgg.s GNU Fortran (GCC) version 4.4.0 20080426 (experimental) [trunk revision 134695] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20080426 (experimental) [trunk revision 134695], GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 /data03/vondele/clean/cp2k/src/../src/hfx_libint_interface.F: In function evaluate_eri_screen: /data03/vondele/clean/cp2k/src/../src/hfx_libint_interface.F:41: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I'll see if can get more info. gfortran should really have an option to generate a single 'preprocessed' file, without module dependencies. It would simplify test case generation. -- Summary: [4.4 Regression] segmentation fault Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #149 from jv244 at cam dot ac dot uk 2008-04-28 12:45 --- new ICE, PR36071. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/36071] [4.4 Regression] segmentation fault
--- Comment #1 from jv244 at cam dot ac dot uk 2008-04-28 12:48 --- trace rogram received signal SIGSEGV, Segmentation fault. 0x005b4e18 in operand_equal_p (arg0=0x2b9220d76420, arg1=0x2b9220c5b240, flags=0) at /data03/vondele/gcc_trunk/gcc/gcc/fold-const.c:3037 3037 if (TYPE_UNSIGNED (TREE_TYPE (arg0)) != TYPE_UNSIGNED (TREE_TYPE (arg1))) (gdb) bt #0 0x005b4e18 in operand_equal_p (arg0=0x2b9220d76420, arg1=0x2b9220c5b240, flags=0) at /data03/vondele/gcc_trunk/gcc/gcc/fold-const.c:3037 #1 0x007f7d70 in simplify_replace_tree (expr=0x2b9220d76420, old=0x2b9220c5b240, new_tree=0x2b922099d960) at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-niter.c:1347 #2 0x007f7e72 in simplify_replace_tree (expr=0x2b9221320840, old=0x2b9220c5b240, new_tree=0x2b922099d960) at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-niter.c:1358 #3 0x007f7e72 in simplify_replace_tree (expr=0x2b9221320880, old=0x2b9220c5b240, new_tree=0x2b922099d960) at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-niter.c:1358 #4 0x007f80ad in substitute_in_loop_info (loop=0x2b9220bac5a0, name=0x90, val=0x0) at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-niter.c:3070 #5 0x00703be4 in replace_uses_by (name=0x2b9220c5b240, val=0x2b922099d960) at /data03/vondele/gcc_trunk/gcc/gcc/tree-cfg.c:1273 #6 0x007132db in tree_merge_blocks (a=0x2b9220d9d900, b=0x2b9220e0e360) at /data03/vondele/gcc_trunk/gcc/gcc/tree-cfg.c:1337 #7 0x00ac4206 in merge_blocks (a=0x2b9220d9d900, b=0x2b9220e0e360) at /data03/vondele/gcc_trunk/gcc/gcc/cfghooks.c:660 #8 0x0071b660 in cleanup_tree_cfg_bb (bb=0x2b9220d9d900) at /data03/vondele/gcc_trunk/gcc/gcc/tree-cfgcleanup.c:568 #9 0x0071bca8 in cleanup_tree_cfg () at /data03/vondele/gcc_trunk/gcc/gcc/tree-cfgcleanup.c:616 #10 0x00896715 in execute_vrp () at /data03/vondele/gcc_trunk/gcc/gcc/tree-vrp.c:6758 #11 0x00677c26 in execute_one_pass (pass=0xf86c60) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1132 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
[Bug middle-end/36071] [4.4 Regression] segmentation fault
--- Comment #2 from jv244 at cam dot ac dot uk 2008-04-28 12:55 --- revision 134754 seems to pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
[Bug target/35399] [4.3 regression] bootstrap error, ICE in free_list, at lists.c:52
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-28 13:32 --- Closing then, if you manage to reproduce it again, please reopen with more details. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35399
[Bug middle-end/36071] [4.4 Regression] segmentation fault
--- Comment #3 from jv244 at cam dot ac dot uk 2008-04-28 13:56 --- assuming fixed -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
[Bug fortran/36072] New: missing symbols in gfortran
When linking a program build with gfortran 4.3.0 to lapack, I get /opt/atlas-gnu_4.3.0/3.8.1/lib64/liblapack.so: undefined reference to `_gfortran_pow_r8_i4' /opt/atlas-gnu_4.3.0/3.8.1/lib64/liblapack.so: undefined reference to `_gfortran_pow_r4_i4' -- Summary: missing symbols in gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
[Bug fortran/36072] missing symbols in gfortran
--- Comment #1 from sliwa at cft dot edu dot pl 2008-04-28 14:47 --- See http://forums.amd.com/devforum/messageview.cfm?catid=217threadid=90399messid=881726parentid=856116FTVAR_FORUMVIEWTMP=Branch for a similar complaint. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
[Bug fortran/36072] missing symbols in libgfortran
--- Comment #2 from sliwa at cft dot edu dot pl 2008-04-28 15:02 --- OK, the LAPACK library was probably compiled with 4.1.2. -- sliwa at cft dot edu dot pl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
[Bug target/36073] New: ICE with -ffast-math and -mfpmath=sse,387
This is my first ever bug report; if I get something wrong, please tell me so I
don't do it again!
When the following is compiled using mainline (as of 28th April 2008) with -O
-march=nocona -mfpmath=sse,387 -ffast-math I get an ICE. It's a different ICE
with omitting the -O2.
-
Code:
-
extern double log(double x);
extern int f(void);
void g(void)
{
static double cached_value = 0.0;
cached_value = log(f());
}
int main(void)
{
g();
return 0;
}
---
Result:
---
$ gcc-4.4 -O -ffast-math -march=nocona -mfpmath=sse,387 bug.c
bug.c: In function g:
bug.c:9: error: insn does not satisfy its constraints:
(insn 24 23 25 2 bug.c:8 (set (reg:DF 8 st [61])
(float:DF (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int 4 [0x4])) [0 S4 A8]))) 215
{*floatsidf2_sse_interunit} (nil))
bug.c:9: internal compiler error: in copyprop_hardreg_forward_1, at
regrename.c:1590
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE with -ffast-math and -mfpmath=sse,387
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ejb48 at cam dot ac dot uk
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug target/36073] ICE with -ffast-math and -mfpmath=sse,387
--- Comment #1 from ejb48 at cam dot ac dot uk 2008-04-28 15:07 --- Sorry, forgot to include: $gcc-4.4 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --enable-languages=c --program-suffix=-4.4 --disable-multilib --enable-__cxa_atexit Thread model: posix gcc version 4.4.0 20080428 (experimental) [trunk revision 134754] (GCC) -- ejb48 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.4.0 Known to work||4.3.1 4.2.1 4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug libfortran/36044] user-requested backtrace
--- Comment #2 from jaydub66 at gmail dot com 2008-04-28 15:44 --- (In reply to comment #1) I think compiling with -fbacktrace and calling the STOP intrinsic should emit a backtrace. I don't think it does. Anyway I'm looking for a solution that keeps the program running after the backtrace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug middle-end/36074] New: [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
Gcc 4.4 revision 134755 failed to compile 447.dealII in SPEC CPU 2006
on Linux Intel64 with -O2 -ffast-math
In file included from
/usr/gcc-4.4/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/vector:74,
from include/base/tensor_base.h:25,
from include/base/tensor.h:18,
from include/base/polynomials_bdm.h:19,
from polynomials_bdm.cc:14:
/usr/gcc-4.4/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/vector.tcc:
In member function 'void std::vector_Tp,
_Alloc::_M_fill_insert(__gnu_cxx::__normal_iteratortypename
std::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp,
_Alloc , size_t, const _Tp) [with _Tp = Tensor2, 2, _Alloc =
std::allocatorTensor2, 2 ]':
/usr/gcc-4.4/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/vector.tcc:350:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
specmake[5]: *** [polynomials_bdm.o] Error 1
(gdb) r -fpreprocessed x.ii -quiet -dumpbase x.ii -mtune=generic -auxbase x
-O2 -version -ffast-math -o x.s
Starting program:
/usr/gcc-4.4/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -fpreprocessed
x.ii -quiet -dumpbase x.ii -mtune=generic -auxbase x -O2 -version -ffast-math
-o x.s
GNU C++ (GCC) version 4.4.0 20080428 (experimental) [trunk revision 134755]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20080428 (experimental) [trunk revision
134755], GMP version 4.2.2, MPFR version 2.3.0-p4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 37249754a30773432dac8305adbf4674
Program received signal SIGSEGV, Segmentation fault.
execute_ssa_ccp (store_ccp=value optimized out)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/tree-ssa-ccp.c:405
405 val-lattice_val = VARYING;
Missing separate debuginfos, use: debuginfo-install glibc.x86_64
(gdb) p val
No symbol val in current context.
(gdb) list
400 static inline void
401 set_value_varying (tree var)
402 {
403 prop_value_t *val = const_val[SSA_NAME_VERSION (var)];
404
405 val-lattice_val = VARYING;
406 val-value = NULL_TREE;
407 val-mem_ref = NULL_TREE;
408 }
409
(gdb) bt
#0 execute_ssa_ccp (store_ccp=value optimized out)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/tree-ssa-ccp.c:405
#1 0x006165ff in execute_one_pass (pass=0xf2a7a0)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/passes.c:1133
#2 0x00616815 in execute_pass_list (pass=0xf2a7a0)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/passes.c:1192
#3 0x0061682d in execute_pass_list (pass=0xea8a40)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/passes.c:1193
#4 0x006c635f in tree_rest_of_compilation (fndecl=0x2aaab1f23a90)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/tree-optimize.c:420
#5 0x007d2a82 in cgraph_expand_function (node=0x2aaab231a200)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cgraphunit.c:1157
#6 0x007d45dc in cgraph_optimize ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cgraphunit.c:1220
#7 0x0044e80d in cp_write_global_declarations ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cp/decl2.c:3524
#8 0x0068d744 in toplev_main (argc=value optimized out,
argv=value optimized out)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/toplev.c:971
#9 0x2aee9074 in __libc_start_main () from /lib64/libc.so.6
#10 0x00402aea in _start ()
(gdb)
Revision 134716 is OK. This regression may be introduced by
http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00959.html
http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00974.html
--
Summary: [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to
compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug target/36073] ICE with -ffast-math and -mfpmath=sse,387
--- Comment #2 from ubizjak at gmail dot com 2008-04-28 16:20 --- Mine. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-28 16:20:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug libfortran/36044] user-requested backtrace
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-28 16:41 --- I think compiling with -fbacktrace and calling the STOP intrinsic should emit a backtrace. I think it should not. For abort(), I think a backtrace is ok, but for STOP there should be no backtrace. Using stop is a quite normal way to stop a program because a condition has not be met, e.g stop 'Could not file inp' If one finds afterwards dozens of lines of backtrace the actual message is no longer visible. In my opinion, ifort shows too often a backtrace. I don't think it does. Try abort(). (Though I do not recall whether it works, I think it does.) Anyway I'm looking for a solution that keeps the program running after the backtrace. This can be sometimes indeed be handy, though I have never used it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
--- Comment #1 from hjl dot tools at gmail dot com 2008-04-28 17:22 --- Revision 134730 is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||34223 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
-- hjl dot tools at gmail dot com changed: What|Removed |Added Known to fail||4.4.0 Known to work||4.3.0 Target Milestone|--- |4.4.0 Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug c++/36023] [4.1/4.3/4.4 regression] ICE with cast to variable-sized object
-- 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 | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg02045.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-28 17:50:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36023
[Bug target/36073] ICE with -ffast-math and -mfpmath=sse,387
--- Comment #3 from uros at gcc dot gnu dot org 2008-04-28 17:50 --- Subject: Bug 36073 Author: uros Date: Mon Apr 28 17:49:51 2008 New Revision: 134757 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134757 Log: PR target/36073 * config/i386/i386.md (*floatSSEMODEI24:modeMODEF:mode2_mixed_interunit): Change operand 1 predicate to nonimmediate_operand. testsuite/ChangeLog: PR target/36073 * gcc.target/i386/pr36073.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr36073.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug target/36073] ICE with -ffast-math and -mfpmath=sse,387
--- Comment #4 from ubizjak at gmail dot com 2008-04-28 17:54 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg02048.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-28 18:31 --- I bet this is fixed with revision 134745. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
--- Comment #3 from hjl dot tools at gmail dot com 2008-04-28 18:37 --- (In reply to comment #2) I bet this is fixed with revision 134745. In my initial bug report, I said Gcc 4.4 revision 134755 failed to compile ^^^ 447.dealII in SPEC CPU 2006 on Linux Intel64 with -O2 -ffast-math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-28 19:19 --- A preprocessed testcase is always appreciated ;) But yes, I have access to spec 2006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug libstdc++/35968] nth_element fails to meet its complexity requirements
--- Comment #7 from sjhowe at dial dot pipex dot com 2008-04-28 20:17 --- Roger I agree with your analysis. I am slightly crestfallen as I was suspicious that Barriato, Hofri etc's paper never mentioned worst case only approximate case. And I have now seen BFPRT73 paper where it mentions for the number of columns (c) Note, however, that we must have c = 5 for PICK to run in linear time. So yes, median-of median of 5 seems best you can do for worst case. The only point in shifting to a different algorithm for the worse case is if (i) It is cheaper in terms of total comparisons, swaps, assignments etc (ii) It is still linear in N in the worse case Cheers Stephen Howe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
[Bug tree-optimization/15255] [tree-ssa] a * 2 + a * 2 is not converted to a * 4
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 20:19 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-20 18:43:31 |2008-04-28 20:19:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15255
[Bug tree-optimization/14792] ((int)b 1) != 0 is not folded to b 1 != 0
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 20:28 --- The testcase from comment #1 is fixed on the trunk. The original testcase still shows (int)a 1 != 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14792
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Comment #36 from jason at gcc dot gnu dot org 2008-04-28 20:44 --- Subject: Bug 57 Author: jason Date: Mon Apr 28 20:43:27 2008 New Revision: 134762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134762 Log: PR c++/57 * parser.c (cp_parser_parameter_declaration): Handle ambiguity in default arguments. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/g++.old-deja/g++.pt/defarg8.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for all array intrinsics with scalar mask
--- Comment #9 from pault at gcc dot gnu dot org 2008-04-28 21:03 --- This is not critical in the gcc sense - I would change it back to normal if I were you. After all, this feature of F95 has never worked correctly:) Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
[Bug ada/36007] [4.4 regression] verify_gimple failed
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-04-28 21:16 --- Subject: Bug 36007 Author: ebotcazou Date: Mon Apr 28 21:15:41 2008 New Revision: 134766 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134766 Log: PR ada/36007 * decl.c (gnat_to_gnu_entity) object: Do not promote alignment of aliased objects with an unconstrained nominal subtype. Cap the promotion to the effective alignment of the word mode. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36007
[Bug ada/36007] [4.4 regression] verify_gimple failed
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-04-28 21:18 --- This should be OK now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36007
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for all array intrinsics with scalar mask
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-04-28 21:34 --- Created an attachment (id=15542) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15542action=view) proposed patch This fixes the test case. Regression-test and submission probably tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
[Bug libfortran/36044] user-requested backtrace
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-04-28 21:36 --- Confirmed, this would indeed be useful. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-28 21:36:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #3 from ianw at vmware dot com 2008-04-28 22:14 --- As another data-point, if ( (a=10) ) ; also doesn't warn. I'm not sure what the standard says on that, but other contemporary compilers do give the an assignment used as truth value warning for the example above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #4 from ianw at vmware dot com 2008-04-28 22:16 --- Oh, just to be clear, my point was if (a=10) warns, but the extra parenthesis hide the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-28 22:17 --- (In reply to comment #4) Oh, just to be clear, my point was if (a=10) warns, but the extra parenthesis hide the warning. That is by design. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #6 from ianw at vmware dot com 2008-04-28 22:28 ---
(In reply to comment #5)
(In reply to comment #4)
Oh, just to be clear, my point was if (a=10) warns, but the extra
parenthesis
hide the warning.
That is by design.
Ok, I did try looking but is that documented anywhere?
It would seem to have ramifications for people that do things like make an
ASSERT statement something like
#define ASSERT(v) {if (!(v))}
A quick search on google codesearch showed this was a very common idiom...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3
--- Comment #7 from rwild at gcc dot gnu dot org 2008-04-28 22:28 --- Subject: Bug 35169 Author: rwild Date: Mon Apr 28 22:27:22 2008 New Revision: 134768 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134768 Log: gcc/ PR bootstrap/35169 * optc-gen.awk: Work around HP-UX/IA awk bug. Modified: trunk/gcc/ChangeLog trunk/gcc/optc-gen.awk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169
[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990
--- Comment #6 from manus at eiffel dot com 2008-04-28 22:34 ---
I can reproduce this problem with gcc 4.2.3 that comes with Ubuntu 8.04 on
PowerPC with the following command line:
gcc -Wall -mlongcall -fPIC -c foo.c
Removing either `-fPIC' or `-mlongcall' succeeds, it is when used together that
it fails with:
lisbon [Manu] : gcc -Wall -mlongcall -fPIC -c foo.c
foo.c: In function 'idrf_reset_pos':
foo.c:23: error: unrecognizable insn:
(call_insn 10 9 12 3 (parallel [
(call (mem:SI (symbol_ref:SI (idr_setpos) [flags 0x1]
function_decl 0x48169700 idr_setpos) [0 S4 A8])
(const_int 0 [0x0]))
(use (const_int 8 [0x8]))
(clobber (scratch:SI))
]) -1 (nil)
(nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 30 30))
(expr_list:REG_DEP_TRUE (use (reg:SI 4 4))
(expr_list:REG_DEP_TRUE (use (reg:SI 3 3))
(nil)
foo.c:23: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.2/README.Bugs.
where foo.c is simply:
#include stdlib.h
typedef struct idr {
int i_op;
size_t i_size;
char *i_buf;
char *i_ptr;
} IDR;
typedef struct idrs {
IDR i_encode;
IDR i_decode;
} IDRF;
void idr_setpos(IDR *idrs, size_t pos)
{
}
void idrf_reset_pos(IDRF *idrf)
{
idr_setpos(idrf-i_encode, 0);
idr_setpos(idrf-i_decode, 0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug middle-end/36075] New: [4.3.1 Regression] FAIL: gcc.c-torture/execute/20021119-1.c execution, -O2
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ /mnt/ gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20021119-1.c -w -O2 -fno-show -column -lm -o /mnt/gnu/gcc/objdir/gcc/testsuite/gcc/20021119-1.x2 (timeou t = 300) PASS: gcc.c-torture/execute/20021119-1.c compilation, -O2 Setting LD_LIBRARY_PATH to :/mnt/gnu/gcc/objdir/gcc::/mnt/gnu/gcc/objdir/gcc FAIL: gcc.c-torture/execute/20021119-1.c execution, -O2 Revision 134604 was ok. -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.3.1 --with-gmp=/opt/gnu/gcc/gcc-4.3.1 --enable-threads=posix --enable-debug=no --disable-nls --enable-languages=c,c++,objc,fortran,java,ada,obj-c++ Thread model: posix gcc version 4.3.1 20080427 (prerelease) [gcc-4_3-branch revision 134730] (GCC) -- Summary: [4.3.1 Regression] FAIL: gcc.c-torture/execute/20021119- 1.c execution, -O2 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36075
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for all array intrinsics with scalar mask
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-04-29 03:14 --- The patch fixes sum, product, and minloc. Regression tests OK on x86-64. Thanks for patch. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #6 from intvnut at gmail dot com 2008-04-29 03:42 --- (In reply to comment #5) It should be possible to have an alternate implementation in libgcc2.c by means of just selecting on a proper architecture define or the size of the argument mode. I see where it would go in libgcc2.c, but I don't know the appropriate architecture defines to key off of, since I really do know nothing about GCC's internals. Since the method I used above is likely to be a strict improvement over the table driven method on 32-bit and 64-bit targets, is it enough to, say, key off of #if W_TYPE_SIZE == 32 and #if W_TYPE_SIZE == 64? Is there some documentation I can read to know how best to propose a patch? (I'm just a motivated user, not a compiler developer, in case you couldn't tell.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug libstdc++/35887] stl parallel includes installed for --disable-libgomp
--- Comment #9 from bkoz at gcc dot gnu dot org 2008-04-29 04:41 --- Subject: Bug 35887 Author: bkoz Date: Tue Apr 29 04:40:08 2008 New Revision: 134776 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134776 Log: 2008-04-28 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/35887 * acinclude.m4 (GLIBCXX_ENABLE_PARALLEL): Revert back to just checking for omp.h. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
