Hi everyone,
I got a Bootstrap comparison failure! error when building gcc 4.3.3:
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
Bootstrap comparison failure!
./tree-cfg.o differs
./double-int.o differs
./gimple-low.o differs
./tree-into-ssa.o
On Tue, 19 May 2009, Mark Mitchell wrote:
Richard Guenther wrote:
- The tree alias oracle got similar functionality, refs_anti_dependent
and refs_output_dependent and the tree level data dependence
analysis code makes use of these.
Do we still use TBAA for the original
On Wed, May 20, 2009 at 12:47 AM, Gary Funck g...@intrepid.com wrote:
On 05/19/09 12:10:43, Andrew Pinski wrote:
Gary wrote:
Is the __thread feature now more universally/portably
supported?
Yes, see emutls.c and the VAR_DECL case in expand_expr_addr_expr_1 and
expand_expr_real_1 in
On Tue, 19 May 2009, Gary Funck wrote:
That aside, I wonder if it is an error to drop the qualifiers
as shown above? In the case of UPC, for example, dropping qualifiers
Please read the code (and comment) immediately above that you quoted,
which saves the qualifiers combined with those
hi,
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)) {
use
chenyang chenyang...@gmail.com writes:
I got a Bootstrap comparison failure! error when building gcc 4.3.3:
These kinds of issues are always difficult to debug. There have been a
couple of patches to stabilize different sorts which I don't think are
in 4.3.3. That could conceivably cause
Jason Baron jba...@redhat.com writes:
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
Hi folks.
Before I merge the diagnostics branch I'd like to enable it on the
testsuite to get us all in the habit of at least being aware of columns.
Joseph Myers suggested enabling it in the compiler instead of the
testsuite. Are there any big objections to this?
Aldy
2009/5/20 Aldy Hernandez al...@redhat.com:
Hi folks.
Before I merge the diagnostics branch I'd like to enable it on the
testsuite to get us all in the habit of at least being aware of columns.
Joseph Myers suggested enabling it in the compiler instead of the
testsuite. Are there any big
Aldy Hernandez al...@redhat.com writes:
Before I merge the diagnostics branch I'd like to enable it on the
testsuite to get us all in the habit of at least being aware of columns.
Joseph Myers suggested enabling it in the compiler instead of the
testsuite. Are there any big objections to
2009/5/20 Ian Lance Taylor i...@google.com:
When we have good caret diagnostics it would also be nice to enable them
by default. However, that is a much bigger change. Does anybody have
an opinion on that?
Why don't have that discussion when (and if) caret diagnostics are
available? I don't
On Wed, 20 May 2009, Ian Lance Taylor wrote:
When we have good caret diagnostics it would also be nice to enable them
by default. However, that is a much bigger change. Does anybody have
an opinion on that?
Yes, that tripling the size of output in a cascade of diagnostics is a bad
idea.
Ian == Ian Lance Taylor i...@google.com writes:
Ian If you haven't already done so, please check that the emacs next-error
Ian function is not affected by this.
This definitely works.
Tom
On Wed, 20 May 2009, Mark Mitchell wrote:
Richard Guenther wrote:
void f(float *f, int *n) {
for (int i = 0; i *n; ++i) {
f[i] *= 2;
}
}
The difference is if you want to sink a load from *n beyond the
store to f[i] - in which case you ask if there is an
On Wed, May 20, 2009 at 04:39:00PM +0200, Manuel L?pez-Ib??ez wrote:
2009/5/20 Aldy Hernandez al...@redhat.com:
Hi folks.
Before I merge the diagnostics branch I'd like to enable it on the
testsuite to get us all in the habit of at least being aware of columns.
Joseph Myers suggested
Richard Guenther wrote:
void f(float *f, int *n) {
for (int i = 0; i *n; ++i) {
f[i] *= 2;
}
}
The difference is if you want to sink a load from *n beyond the
store to f[i] - in which case you ask if there is an anti-dependence
which we cannot exclude in this case (no
On 05/20/09 09:45:11, Joseph S. Myers wrote:
On Tue, 19 May 2009, Gary Funck wrote:
That aside, I wonder if it is an error to drop the qualifiers
as shown above? In the case of UPC, for example, dropping qualifiers
Please read the code (and comment) immediately above that you quoted,
alphapca56-unknown-linux-gnu
Using built-in specs.
Target: alphapca56-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/GCC4
AR_FOR_TARGET=ar AS_FOR_TARGET=as 'CC_FOR_TARGET=
/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/xgcc
On 05/20/09 10:40:02, Richard Guenther wrote:
Gary wrote:
Above, __emutls_get_address() is called twice, with
the same argument. I was surprised to see that the optimizer
(GCC 4.3.2) didn't notice this and use CSE to avoid the second
redundant call, because emultls_get_address is defined
We seem to have dropped this discussion. I now have *two* customers
asking for this functionality. Can we pick it up again? We need to
decide:
1. If the functionality will be allowed in gcc at all
2. What info the target needs to be provided to make the choices it wants
3. What, if any,
Ian Lance Taylor wrote:
1. If the functionality will be allowed in gcc at all
2. What info the target needs to be provided to make the choices it wants
3. What, if any, common code can be shared between the CPUs
Since the ARM ABI apparently specifies something about volatile
bitfields, I
g95 sets DECL_COMMON on these variable decls (only for Darwin
targets). This seems like a hack to me (see below). The problem is
darwin-specific, not related to the front-end. On darwin:
$ cat a.c int x[999] = { 0 }; $ gcc -c a.c ls -lh a.o -rw-r--
r-- 1 fx wheel 38M May 12 13:43 a.o $
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
Could you distill it for us? If it's acceptable to my two customers,
it would be a good starting point to define an API for the targets.
I have a question about the use of sed by fixincl and mkheaders
and a change that was made between 4.3.* and 4.4.0.
It involves this patch:
2008-09-06 Bruce Korb bk...@gnu.org
* fixincl.tpl (sed): make the program executable configurable.
Some platforms have some rather
On Wed, May 20, 2009 at 2:47 PM, Steve Ellcey s...@cup.hp.com wrote:
I have a question about the use of sed by fixincl and mkheaders
and a change that was made between 4.3.* and 4.4.0.
After this patch, the sed used when building GCC is saved in a config
file and that path to sed is used when
Gary Funck g...@intrepid.com writes:
Do you/others happen to know who is the maintainer of the
TLS emulation? I tried a simple test case that works
with the native TLS support, but it SEGV's when using
TLS emulation. Perhaps a cockpit error on my part, but
I'd like to see if I can use the
On 05/20/09 17:13:23, Ian Lance Taylor wrote:
Gary Funck g...@intrepid.com writes:
Do you/others happen to know who is the maintainer of the
TLS emulation?
[...] If you have found a bug, the fastest
way to address is probably to file a bug report.
Doing a bit of research, it seems that
Under which conditions GCC generates nops?
I noticed that with 4.4.0, gen_nop() is required, thing that wasn't with 4.3.3.
Can I just define an empty insn for nop, of GCC requires a one-byte insn for its
own alignment purposes?
- Jamie
Richard Guenther wrote:
int i;
float f;
void foo()
{
int *p = (int *)malloc(sizeof(int));
*p = 1;
i = *p;
float *q = (float *)p;
*q = 2.0;
f = *q;
}
Yes, I think that's a valid program too. I'm OK with giving up this
optimization; clearly we need to be correct first and
Hi,
I'm running my C program on a Solaris machine with the following gcc version
installed.
gcc version 3.4.6
Thread model 3.4.6
/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/spec
Issue:
The same code seems to compile and execute fine on
mingw running on Windows with gcc version 3.4.5
Jamie Prescott jpre...@yahoo.com writes:
Under which conditions GCC generates nops?
It depends entirely on the target. For many targets, gcc will never
generate a nop instruction, except as a byproduct of alignment.
I noticed that with 4.4.0, gen_nop() is required, thing that wasn't with
santosh k sanus...@yahoo.com writes:
I'm running my C program on a Solaris machine with the following gcc version
installed.
gcc version 3.4.6
Thread model 3.4.6
/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/spec
Issue:
The same code seems to compile and execute fine on
mingw running
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts away
qualifiers
If I compile this program with gcc
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-20 06:01 ---
Patch: http://gcc.gnu.org/ml/fortran/2009-05/msg00310.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39178
--- 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
--- 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
--- 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 |Added
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 version 4.5.0 20090520
--- 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 *)
--- 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
--- 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 from
--- 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;
}
--- 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 .
--
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
--- 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
--- 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.
--
--- 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)) {
use the arguments
--- 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
--- 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
--- 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
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
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
--- 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=17896action=view)
Test case that causes an ICE
Compile with:
gcc -c -O2 -Wall -fprofile-use test.c
--
--- 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
--- 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,
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
--- 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
--- 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=gccview=revrev=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 stdint.h
#include stddef.h
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);
--- 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
--- 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
--- 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=gccview=revrev=147747
Log:
PR libgomp/40174
* team.c (gomp_thread_start):
--- 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=gccview=revrev=147748
Log:
PR libgomp/40174
* team.c (gomp_thread_start):
--- 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=gccview=revrev=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=gccview=revrev=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
--- 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
--- 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
--- 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],,
--- 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
--- 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
1 - 100 of 115 matches
Mail list logo
