--- Comment #12 from jb at gcc dot gnu dot org 2009-05-20 08:37 ---
Both the mixed C/Fortran and the pure Fortran version by Dominique works as
expected for me on x86_64-linux. I.e. I get the same results as reported by
Dominique in comments #1 and #6.
This looks like a target bug.
--
--- Comment #13 from dominiq at lps dot ens dot fr 2009-05-20 08:55 ---
> This looks like a target bug.
This looks also like a problem with the way arguments and results are handled
(this is why I have suggested an alignement problem in comment #9).
The result in comment #2:
Function
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-20 09:20 ---
Confirmed. We endlessly recurse in folding
#2 0x0076b333 in fold_binary (code=BIT_AND_EXPR, type=0x75f5f540,
op0=0x77ff9580, op1=0x75f76870)
at /space/rguenther/src/svn/trunk/gcc/fold-
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-20 09:21
---
Fixed on trunk sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known
When the largest integer is used as the upper bound of a for loop which is
parallelised using OpenMP, thread n-1 will execute at most one iteration. The
code below demonstrates this by printing at most one message.
This is shown most clearly by first setting the OMP_NUM_THREADS environment
variabl
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-20 11:28 ---
Confirmed. extract_omp_for_data "canonicalizes" <= and >= to < and > by
adding/subtracting one to/from the bound.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Adde
rget: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure
--prefix=/afs/mpa/data/martin/ugcc --with-mpfr-include=/usr/include
--with-mpfr-lib=/usr/lib --with-gmp-include=/usr/include
--with-gmp-lib=/usr/lib --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-20 12:43 ---
The dump is the following. gfortran_select_string returns only 0, 1, or 2, but
the middle end does not know this.
Manuel, do you have an idea how to solve this?
case_num.1 = _gfortran_select_string ((void *) &ju
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-05-20 12:48 ---
I'd suspect this to be a related to Jakub's recent changes applied for PR39666
(i.e. r147136)? Does your testcase work for r147135?
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from martin at mpa-garching dot mpg dot de 2009-05-20 13:03
---
(In reply to comment #2)
> I'd suspect this to be a related to Jakub's recent changes applied for PR39666
> (i.e. r147136)? Does your testcase work for r147135?
I cannot check this quickly. However I tried w
--- Comment #3 from rob1weld at aol dot com 2009-05-20 13:10 ---
> Some of the newest cards will run at over a PetaFLOP ...
I meant a TeraFLOP :( .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
--- Comment #4 from manu at gcc dot gnu dot org 2009-05-20 13:12 ---
(In reply to comment #2)
> I'd suspect this to be a related to Jakub's recent changes applied for PR39666
> (i.e. r147136)? Does your testcase work for r147135?
>
On the contrary, I think this is a missed testcase fro
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-20 13:19 ---
Can be reproduced with trunk today.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-20 13:40 ---
switch (case_num.1)
{
case 1 ... 1:;
case 2 ... 2:;
__result_char2type = 1;
goto L.1;
case 0 ... 0:;
__result_char2type = -1234;
goto L.1;
}
Wou
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-20 14:09 ---
I think there is no induction variable optimization on RTL anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-20 14:14 ---
The FE should use a default label for the last case in the switch stmt.
I also think the FE does premature optimization here, but ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-20 14:14 ---
There was a discussion thread here.
http://gcc.gnu.org/ml/gcc/2008-07/msg00037.html and one of the solutions that
Bingfeng was investigating was loop unrolling before ivopts in certain cases
being useful .
--
ht
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #4 from bmei at broadcom dot com 2009-05-20 14:17 ---
I implemented a tree-level loop-unrolling pass in our private porting, which
takes advantage of later tree ivopt pass. It produces much better code than
rtl-level loop unrolling in such scenarios. Not sure whether should
--- Comment #2 from jason dot orendorff at gmail dot com 2009-05-20 14:28
---
No, I'm asking for the extra line:
nonpod.cpp:1: calling `void f(...)' declared here
--
jason dot orendorff at gmail dot com changed:
What|Removed |Added
--
--- Comment #7 from jakub at gcc dot gnu dot org 2009-05-20 14:32 ---
For all involved strings being non-array CHAR with length 1 I fail to see why
normal SWITCH_EXPR isn't used instead (though that would just be an
optimization).
The middle-end can't know the _gfortran_select_string fu
--- Comment #3 from jason dot orendorff at gmail dot com 2009-05-20 14:33
---
I should clarify that in the real-world case, the apparently relevant
declaration doesn't use ... at all, hence the tentative diagnosis of "something
weird".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from dominik dot strasser at onespin-solutions dot com
2009-05-20 14:57 ---
Works fine in 4.3.3
--
dominik dot strasser at onespin-solutions dot com changed:
What|Removed |Added
--
--- Comment #11 from dominik dot strasser at onespin-solutions dot com
2009-05-20 14:58 ---
Works fine, thanks.
--
dominik dot strasser at onespin-solutions dot com changed:
What|Removed |Added
-
--- Comment #9 from dominik dot strasser at onespin-solutions dot com
2009-05-20 14:58 ---
Works fine
--
dominik dot strasser at onespin-solutions dot com changed:
What|Removed |Added
---
--- Comment #10 from dominik dot strasser at onespin-solutions dot com
2009-05-20 14:59 ---
Works fine
--
dominik dot strasser at onespin-solutions dot com changed:
What|Removed |Added
--
--- Comment #6 from dominik dot strasser at onespin-solutions dot com
2009-05-20 14:59 ---
Works fine
--
dominik dot strasser at onespin-solutions dot com changed:
What|Removed |Added
---
--- Comment #7 from dominik dot strasser at onespin-solutions dot com
2009-05-20 14:59 ---
Works fine in 4.3.3
--
dominik dot strasser at onespin-solutions dot com changed:
What|Removed |Added
--
--- Comment #2 from dominik dot strasser at onespin-solutions dot com
2009-05-20 15:03 ---
Work fine
--
dominik dot strasser at onespin-solutions dot com changed:
What|Removed |Added
While working on some Linux kernel code, I've found that functions that
are declared as 'static inline' are having their arguments evaluated
well before they are used. For example I have a function:
static inline void trace(arg1, arg2)
{
if (unlikely(enabled)) {
}
}
To make this
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-20 15:15
---
Note that I am going to fix the missing warning because of comment #2 only.
For 4.3 comment #2 does not apply, instead you get a warning with
-Wstrict-aliasing=1
g++-4.3 -Wall -O3 -S t.C -UWARN -fdump-tree-all -Ws
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 15:59 ---
This works on the trunk and there is no ADDRESSABLE set on the tmp_union.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from dominik dot strasser at onespin-solutions dot com
2009-05-20 15:45 ---
Works fine in 4.3
--
dominik dot strasser at onespin-solutions dot com changed:
What|Removed |Added
--- Comment #5 from dje dot gcc at gmail dot com 2009-05-20 17:51 ---
Subject: Re: Inefficient loop unrolling
> I implemented a tree-level loop-unrolling pass in our private porting, which
> takes advantage of later tree ivopt pass. It produces much better code than
> rtl-level loop un
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-20 15:26 ---
On a second thought this transformation is even wrong for non-indirect
references.
extern "C" void abort (void);
inline void *operator new (__SIZE_TYPE__, void *__p) throw () { return __p; }
int __attribute__((noin
An ICE occurs in iv_analyze_def because the register referred to by a def is
not the same register referred to by the set in an rtx. The rtx in question
actually has multiple set's, but single_set only returns one of them because of
a stale REG_UNUSED note.
The stale REG_UNUSED note is created in
gcc needs some built in functions for byte swapping.
I've been experimenting with the various versions of byte swapping functions
out there, and they either result in code that's opaque to the optimizer (i.e.
swapping something twice is not considered a null operation) or the optimizer
doesn't rec
--- Comment #1 from nvachhar at google dot com 2009-05-20 18:48 ---
Created an attachment (id=17896)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17896&action=view)
Test case that causes an ICE
Compile with:
gcc -c -O2 -Wall -fprofile-use test.c
--
http://gcc.gnu.org/bugzil
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-20 16:11 ---
As I've caused this by PR29749, I'm taking this up.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 19:01 ---
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Other-Builtins.html#Other-Builtins
Built-in Function: int32_t __builtin_bswap32 (int32_t x)
Returns x with the order of the bytes reversed; for example, 0xaabbccdd beco
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-20 19:03 ---
Also see http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00421.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-20 19:04 ---
So there are builtins in 4.3.0 and above. And there is a patch floating around
to automatically change the manually written byte swap into the builtins.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
--- Comment #19 from dominik dot strasser at onespin-solutions dot com
2009-05-20 15:45 ---
Works fine
--
dominik dot strasser at onespin-solutions dot com changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 15:21 ---
The define and the static inline functions are not equivalent at all.
#define evaluate(val) \
do { \
typeof(val) tmpval = val; \
if (unlikely(enabled)) { \
printf("value is: %d\n", tmpva
Jerry,
Thanks for the reply.
Do you have the stuff necessary for doing 32-bit builds installed also? I do,
and it feels like that might be the issue.
I can send you logs if you really want to see the gory details.
Thanks,
Arnold
> Date: Tue, 19 May 2009 17:05:29 -0700
> From: Jerry DeLisle
>
The following code:
long long foo (long long);
void
FIR(short In[],short Out[],int nsamples)
{
long long * vIn = (long long*)In;
long long * vOut = (long long*)Out;
int i;
long long sum0, sum1;
for (i = 0; i < nsamples; i++) {
sum0 = vIn[i];
vOut[i+1] = foo(
--- Comment #4 from eric-bugs at omnifarious dot org 2009-05-20 19:17
---
Ahh, OK. I hunted a bit to find something like that, but didn't find it.
Thank you.
I now have a slightly different bug, which is a mild inadequate optimization
bug. :-) I'll cut it down to size and paste it
--- Comment #2 from fche at redhat dot com 2009-05-20 16:56 ---
(In reply to comment #1)
> The define and the static inline functions are not equivalent at all.
Right, in general, but if the expressions are side-effect-free,
gcc could move their evaluation farther down.
--
fche at r
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-20 15:26 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|pinskia at
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-20 19:22 ---
Fixed by alias-improvements branch merge. Or rather
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145142
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from eric-bugs at omnifarious dot org 2009-05-20 19:39
---
This code:
#include
#include
inline uint64_t byteswap_64(const uint64_t x)
{
return __builtin_bswap64(x);
}
inline uint32_t byteswap_32(const uint32_t x)
{
return __builtin_bswap32(x);
}
extern void ra
--- Comment #6 from jakub at gcc dot gnu dot org 2009-05-20 20:05 ---
There are plenty other possible builtin bswap optimizations. E.g.
extern void bar (void);
void foo (int x)
{
if (__builtin_bswap32 (x) == __builtin_bswap32 (0x1234567))
bar ();
}
should be optimized into if (x
--- Comment #7 from eric-bugs at omnifarious dot org 2009-05-20 20:22
---
I've been playing around a bit more, and I've noticed that gcc in general does
not do a spectacular job of optimizing bitwise operations of any kind.
Some kind of general framework for tracking the movements of i
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-20 20:55 ---
Subject: Bug 40174
Author: jakub
Date: Wed May 20 20:54:45 2009
New Revision: 147747
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147747
Log:
PR libgomp/40174
* team.c (gomp_thread_start): De
--- Comment #4 from jakub at gcc dot gnu dot org 2009-05-20 20:55 ---
Subject: Bug 40174
Author: jakub
Date: Wed May 20 20:55:25 2009
New Revision: 147748
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147748
Log:
PR libgomp/40174
* team.c (gomp_thread_start): De
--- Comment #4 from jakub at gcc dot gnu dot org 2009-05-20 21:09 ---
Subject: Bug 40204
Author: jakub
Date: Wed May 20 21:09:11 2009
New Revision: 147749
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147749
Log:
PR middle-end/40204
* fold-const.c (fold_binary)
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-20 21:11 ---
Subject: Bug 40204
Author: jakub
Date: Wed May 20 21:11:10 2009
New Revision: 147750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147750
Log:
PR middle-end/40204
* fold-const.c (fold_binary)
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-20 21:15 ---
Fixed for 4.4/4.5.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #6 from jakub at gcc dot gnu dot org 2009-05-20 21:15 ---
Fixed for 4.4/4.5 so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Su
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-20 21:16 ---
Fixed, thanks.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #57 from dave dot korn dot cygwin at gmail dot com 2009-05-20
21:16 ---
Bah. In case anyone else was about to point this out to me,
+gcc_GAS_CHECK_FEATURE([.comm with alignment], gcc_cv_as_comm_has_align,
+ [2,19,52],,
+ [.comm foo,1,32],,
+[AC_DEFINE(HAVE_GAS_ALIGNED_COMM
--- Comment #3 from sergei_lus at yahoo dot com 2009-05-20 21:23 ---
Yes. This is the problem. Thank you very much.
--
sergei_lus at yahoo dot com changed:
What|Removed |Added
--
--- Comment #49 from vvv at ru dot ru 2009-05-20 21:38 ---
(In reply to comment #48)
How this patches work? Is it required some special options?
# /media/disk-1/B/bin/gcc --version
gcc (GCC) 4.5.0 20090520 (experimental)
# cat test.c
void f(int i)
{
if (i == 1) F(1);
if
--- Comment #50 from jakub at gcc dot gnu dot org 2009-05-20 22:09 ---
nopl 0x0(%rax,%rax,1) and nopw 0x0(%rax,%rax,1) aren't padding (though, it
has been added in this case for label alignment or function entry alignment,
not to avoid 4+ jumps in one 16byte page)?
Anyway, you want t
While helping a new developer here at Sony, I noticed that the "13.2 SSA
Operands" section in the GCC's internals manual still refers to statements that
were tree types.
For an example:
If you wish to iterate over some or all operands, use the
FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND iterator. For examp
Hi, this is my first time building gcc compiler. After going through many
settings, I stuck on fixing this error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867 has discussed the similar
error, but forgive me, I really have hard time understanding what exactly I
should do. Can anyone help me on
Hi, this is my first time building gcc compiler. After going through many
settings, I stuck on fixing this error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867 has discussed the similar
error, but forgive me, I really have hard time understanding what exactly I
should do. Can anyone help me on
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 23:40 ---
*** Bug 40213 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40212
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 23:40 ---
*** This bug has been marked as a duplicate of 40212 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Hi, this is my first time building gcc compiler. After going through many
settings, I stuck on fixing this error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867 has discussed the similar
error, but forgive me, I really have hard time understanding what exactly I
should do. Can anyone help me on
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 23:41 ---
*** This bug has been marked as a duplicate of 40212 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-20 23:41 ---
*** Bug 40214 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40212
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-20 23:42 ---
You are building in the source directory which is currently known to be broken,
see PR 35619.
*** This bug has been marked as a duplicate of 35619 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #26 from pinskia at gcc dot gnu dot org 2009-05-20 23:42
---
*** Bug 40212 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from danglin at gcc dot gnu dot org 2009-05-21 00:49 ---
This is the backtrace for the last delete:
(gdb) bt
#0 operator delete (p=0x8001e4f8) at deallocate_global.cc:51
#1 0x4000eafc in __gnu_cxx::new_allocator::deallocate (
this=0x83fffdff0fc8,
When the integrated preprocessor is not used (due to -no-integrated-cpp,
-save-temps, -E, etc), the generated .h.gch file appears to be a valid
precompiled header file, but it does not #define the preprocessor guards (and
perhaps other symbols) from the files it brought in. This causes duplicate
s
--- Comment #1 from sacolcor at provide dot net 2009-05-21 02:06 ---
(Adjusting summary; additional testing revealed that this is not confined to
C++)
--
sacolcor at provide dot net changed:
What|Removed |Added
-
When compiling bfd/ecofflink.c from binutils-2.15.94.0.2.2 on an x86_64, there
is an optimization bug which can cause the ld command to segfault.
One can see the problem in the output of objdump -S ecofflink.o: (my comments
are preceded by "^")
newbuf = (char *) bfd_realloc (*buf, (bfd_size
--- Comment #1 from dahowell at directv dot com 2009-05-21 03:47 ---
Created an attachment (id=17897)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17897&action=view)
ecofflink.i preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40216
I accidentally ran my FreeBSD-71 system with 3GB RAM without the swap space and
compiled a large module with high degree of optimization.
I was getting this error:
{standard input}: Assembler messages:
{standard input}:68321: Warning: end of file not at end of a line; newline
inserted
{standard in
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-21 06:25 ---
>g++: Internal error: Killed: 9 (program cc1plus)
>
The kernel killed cc1plus because of being out of memory. So yes it did
already say what happened.
Also since -pipe was being use
83 matches
Mail list logo
