There's another funny thing about gcc3 behavior which I've just discovered:
$ gcc -v 21 | grep version
gcc version 3.4.2
$ gcc -o mem mem.c ; ./mem
-1024
$ gcc -o mem1 mem1.c ; ./mem1
0
$ cat mem.c
#include stdio.h
int main() {
char *p1, *p2;
{
char a[1024];
I'm adding autoc...@gnu.org to the destinations, since this is a
pretty fundamental problem with AC_CHECK_DECL and C++
On Tue, Feb 9, 2010 at 02:17, Joern Rennecke
joern.renne...@embecosm.com wrote:
On 02/08/2010 09:58 AM, Joern Rennecke wrote:
That would only work if every program that uses
Quoting Paolo Bonzini bonz...@gnu.org:
I'm adding autoc...@gnu.org to the destinations, since this is a
pretty fundamental problem with AC_CHECK_DECL and C++
I've whipped up a patch with a modified version of AC_CHECK_DECLS -
I've called it AC_CHECK_PROTOS - that can optionally have argument
Hi Jeff,
Many thanks for the pointers. I will make the changes and attach the
patch to the bugzilla soon.
Cheers,
Rahul
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: 09 February 2010 00:45
To: Rahul Kharche
Cc: gcc@gcc.gnu.org; sdkteam-gnu
Subject: Re: Failure to
Jack Howarth a écrit :
Jacob,
Apple's gcc is based on their own branch and is not the
same as FSF gcc. The first FSF gcc that is validated on
on darwin10 was gcc 4.4. However I would suggest you first
start testing against current FSF gcc trunk. There are a
number of fixes for darwin10 that
Hi all,
After reading the internal docs about rtx_costs I am left wondering what
they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generated?
- or Are they estimating how many assembler
Quoting Paulo J. Matos pocma...@gmail.com:
Hi all,
After reading the internal docs about rtx_costs I am left wondering
what they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generated?
-
After reading the internal docs about rtx_costs I am left wondering what
they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generated?
- or Are they estimating how many assembler
On Tue, 2 Feb 2010, Cameron Lowell Palmer wrote:
Does Modulo Scheduling work on x86 platforms? I have tried adding in
various versions of the -fmodulo-sched option and get the exact same
output with or without. The application is a very simplistic matrix
multiply without dependencies.
No,
Joern Rennecke wrote:
Quoting Paulo J. Matos pocma...@gmail.com:
Hi all,
After reading the internal docs about rtx_costs I am left wondering
what they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the
I try to patch gcc so that after a fdivd the destination register is
stored to the stack.
fdivd %f0,%f2,%f4; std %f4, [%sp]
I generate the rtl for divdf3 using a emit_insn,DONE sequence in a
define_expand pattern (see below).
In the assembler output phase I use a define_insn and write
out
On Tue, Feb 9, 2010 at 6:01 PM, Cristianno Martins
cristiannomart...@gmail.com wrote:
Hi everyone,
First of all, I already find [and fix] the problem that I had
described in the last email.
Now, I need a help with a pretty intriguing issue, described below.
Well, such as I told in the last
Hi,
Thanks for the fast reply. Only one more thing: is there some way that
I could force it to be signed??
On Tue, Feb 9, 2010 at 3:17 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Feb 9, 2010 at 6:01 PM, Cristianno Martins
cristiannomart...@gmail.com wrote:
Hi everyone,
On Tue, Feb 9, 2010 at 12:34, Cristianno Martins
cristiannomart...@gmail.com wrote:
Hi,
Thanks for the fast reply. Only one more thing: is there some way that
I could force it to be signed??
I guess that you should wait the fixes from Tobias and Ramakrishna to
CLooG and Graphite to have the
Dear all,
If I consider this code
typedef struct sTestUnsignedChar {
uint64_t a:1;
}STestUnsignedChar;
uint64_t getU (STestUnsignedChar a)
{
return a.a;
}
I get this in the DCE pass :
(insn 6 3 7 2 bitfield2.c:8 (set (subreg:DI (reg:QI 75) 0)
(zero_extract:DI (reg/v:DI 73 [ a
On 09.02.2010 19:39, Sebastian Pop wrote:
On Tue, Feb 9, 2010 at 12:34, Cristianno Martins
cristiannomart...@gmail.com wrote:
Hi,
Thanks for the fast reply. Only one more thing: is there some way that
I could force it to be signed??
I guess that you should wait the fixes from Tobias and
Michael Hope wrote:
Hi Sergio. Any luck so far?
Micheal, thanks for your inquiry. I made some progress, in fact.
I got the GO_IF_LEGITIMATE_ADDRESS() macro to detect correctly REG+IMM
addresses, and then the LEGITIMIZE_ADDRESS() macro to force them to be
pre-computed in a register.
However,
On 01/26/10 16:47, Steven Bosscher wrote:
Hello Jeff and other interested readers :-)
There is a function compute_transpout() in gcse.c and there are a
couple of things about this functions that I don't understand exactly.
First, there is this comment before the function says:
An expression
Snapshot gcc-4.4-20100209 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100209/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Daniel Jacobowitz d...@codesourcery.com writes:
On Wed, Feb 03, 2010 at 06:23:19AM -0800, Ian Lance Taylor wrote:
fanqifei fanqi...@gmail.com writes:
According to the internal manual, insn length attribute can be used to
to calculate the length of emitted code chunks when verifying branch
Hello.
Recently I found out a surprising requirement to compile own application
with Horde3D library (http://horde3d.org/), OpenGL 3D graphics engine.
Horde3D library links to shared GL library. But -lHorde3D must be listed
*before* -lGL for any application to work correctly. If I link the
michael kapelko korn...@gmail.com writes:
Recently I found out a surprising requirement to compile own
application with Horde3D library (http://horde3d.org/), OpenGL 3D
graphics engine.
Horde3D library links to shared GL library. But -lHorde3D must be
listed *before* -lGL for any application
--- Comment #11 from rakdver at kam dot mff dot cuni dot cz 2010-02-09
08:30 ---
Subject: Re: [4.3/4.4/4.5 Regression] No loop
counter reversal for simple loops anymore
Hi,
As suggested by Zdenek, here is a patch that lowers the cost of the IV when
it is compared against
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-09 08:51 ---
MINLOC has for character the following (analog for MAXLOC and MINVAL/MAXVAL):
If ARRAY has type character, the result is the value that would be selected by
application of intrinsic relational operators; that is,
--- Comment #10 from mikpe at it dot uu dot se 2010-02-09 08:58 ---
(In reply to comment #9)
Finally, the m32c port defines both PUSH_ARGS and HAVE_POST_INCREMENT, so it
can be possible to reproduce the bug on this port.
cat pr42722.c
struct test {
int a, b, c, d;
};
void
--- Comment #2 from ossman at cendio dot se 2010-02-09 09:35 ---
Like so:
/usr/sparc-sun-solaris2.10/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.3/configure --prefix=/usr --mandir=/usr/share/man
--target=sparc-sun-solaris2.10
--- Comment #3 from ossman at cendio dot se 2010-02-09 09:36 ---
Btw, my workaround for now is to remove the binaries in
/usr/sparc-sun-solaris2.10/bin and replace them with symlinks as gcc will
resolve any symlinks before trying to determine its runtime prefix.
--
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-09 09:45
---
Before anything else, you should try a current compiler, because 4.0.x isn't
maintained anymore, thus either 4.3.x or, better, 4.4.x. Then, if you are still
seeing something strange, we need a complete
--- Comment #27 from jamborm at gcc dot gnu dot org 2010-02-09 09:46
---
(In reply to comment #22)
(In reply to comment #18)
Well, just pretending that a particular parameter never existed isn't
acceptable from a debugging standpoint; I think we need to have a
separate
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-09 10:10 ---
Without -fwrapv I get
./cc1 -quiet -O2 -Wall t3.i
t3.i: In function 'foo':
t3.i:8:5: warning: assuming signed overflow does not occur when assuming that
(X + c) X is always false
and with -fwrapv and the fix for
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-09 10:10 ---
*** Bug 43002 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-02-09 10:36 ---
Subject: Bug 42705
Author: jakub
Date: Tue Feb 9 10:36:22 2010
New Revision: 156619
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156619
Log:
Backport from mainline:
2010-01-13 Richard
--- Comment #4 from domob at gcc dot gnu dot org 2010-02-09 10:44 ---
Subject: Bug 39171
Author: domob
Date: Tue Feb 9 10:44:33 2010
New Revision: 156620
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156620
Log:
2010-02-09 Daniel Kraft d...@domob.eu
PR fortran/39171
--- Comment #5 from domob at gcc dot gnu dot org 2010-02-09 10:45 ---
Fixed on trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2010-02-09 10:46 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #17 from singler at kit dot edu 2010-02-09 10:49 ---
The actual problem has vanished, but maybe it would still be nice to use VLA in
the appropriate places.
We can close the bug as fixed/invalid, or reprioritize it as enhancement and
leave it open. Both is fine with me.
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-02-09 10:49
---
In addition to what Paolo said:
You're using -lpthread, did you also use the relevant preprocessor options? For
powerpc -pthread does everything you need.
That code doesn't qualify the names from namespace std,
--- Comment #18 from paolo dot carlini at oracle dot com 2010-02-09 11:14
---
Ok, I changed Summary and Severity. Somebody should also double check whether
VLAs are still triggering warnings or not.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-09 11:34 ---
Subject: Bug 43000
Author: rguenth
Date: Tue Feb 9 11:34:28 2010
New Revision: 156621
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156621
Log:
2010-02-09 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-09 11:35 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #28 from laikechen at gmail dot com 2010-02-09 12:07 ---
(In reply to comment #2)
Even shorter testcase:
==
struct A {};
template int A::* p
int foo(A* q)
{
return q-*p;
}
template typename T
int bar(int T::* p)
{
return
The kernel on i?86 again contains references to __udivdi3 because we no longer
simplify
unsigned int apply_frontend_param (unsigned int spi_bias)
{
static const int ppm = 8000;
spi_bias /= 1000ULL + ppm/1000;
return spi_bias;
}
to return spi_bias / 1008.
In 4.4 we entered
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43007
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-09 12:32 ---
I am testing
Index: gcc/convert.c
===
--- gcc/convert.c (revision 156620)
+++ gcc/convert.c (working copy)
@@ -676,6 +676,7 @@
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-02-09 13:10 ---
*** Bug 43006 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-02-09 13:10 ---
*** This bug has been marked as a duplicate of 36313 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-09 13:41 ---
This is because the [sp] = ax insn has different INSN_PRIORITY between -g and
-g0. That difference is because different kind of dependency is added when
analyzing the following call:
(call (mem:QI (symbol_ref:SI
--- Comment #3 from sarveshwarac at india dot tejasnetworks dot com
2010-02-09 13:46 ---
I have used the following preprocessor options: -DTHREADED, -D_REENTRANT.
I tried with -pthread instead of -lpthread, but still the problem is seen.
using namespace std(;) line is present in my
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-09 13:51
---
Nonetheless, please try with a maintained compiler and, in case, please provide
a complete self-contained reproducer, otherwise no action will be possible,
this bug will be closed for lack of feedback.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-09 14:10 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
We miscompile some perl testcases because
int i;
struct X {
int *p;
};
struct X * __attribute__((malloc))
my_alloc (void)
{
struct X *p = __builtin_malloc (sizeof (struct X));
p-p = i;
return p;
}
extern void abort (void);
int main()
{
struct X *p, *q;
p = my_alloc ();
q = my_alloc
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-09 14:34 ---
Argh, this isn't going to be fun to fix.
The problem is:
2018 if (n_useless_values MAX_USELESS_VALUES
2019 /* remove_useless_values is linear in the hash table size. Avoid
2020 quadratic behavior for
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-02-09 14:49 ---
I'm about to test a fix.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
Target: x86_64-linux-gnu
Resulting binary crushes with segmentation fault if gcc compile options include
-O3.
Source code:
#include stdio.h
#include stdlib.h
#include stdint.h
#include unistd.h
void process_buf(uint32_t *buf)
{
int i;
uint32_t t = 0;
--- Comment #1 from ajk dot xyz at gmail dot com 2010-02-09 15:48 ---
Created an attachment (id=19828)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19828action=view)
the preprocessed file (*.i*) that triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009
--- Comment #2 from ajk dot xyz at gmail dot com 2010-02-09 15:52 ---
Created an attachment (id=19829)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19829action=view)
output for: gcc -v -save-temps -Wall -Werror -O3 2.c -o 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-09 16:09
---
Looks like there is a strong consensus in the LWG for the proposed resolution,
that is returning void, and LWG 579 now is [Tentatively Ready]. We could even
implement it in time for 4.5.0, but, if I'm not
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-09 16:11 ---
Subject: Bug 43008
Author: rguenth
Date: Tue Feb 9 16:11:34 2010
New Revision: 156628
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156628
Log:
2010-02-09 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-09 16:12 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-09 16:15 ---
Your pointer isn't properly aligned to be accessed via uint32_t*.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ajk dot xyz at gmail dot com 2010-02-09 16:47 ---
(In reply to comment #3)
Your pointer isn't properly aligned to be accessed via uint32_t*.
And should it? If 'yes', then why GCC generates working code for that source
without optimization or with -O2 ? Or even
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-09 17:05 ---
Subject: Bug 42996
Author: burnus
Date: Tue Feb 9 17:04:57 2010
New Revision: 156630
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156630
Log:
2010-02-09 Tobias Burnus bur...@net-b.de
PR
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-09 17:07 ---
The alignment requirements of uint32_t are not being satisfied. That causes
undefined behavior which means it could work in one case but not the other.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #12 from spop at gcc dot gnu dot org 2010-02-09 17:17 ---
Hi,
I just checked the back-end cost tables and there is no cost entry for
compare against zero. I guess that we should just add a TODO
comment around the code that we're adding, and then add the cost
field in GCC
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-09 17:33 ---
Subject: Bug 41869
Author: burnus
Date: Tue Feb 9 17:32:53 2010
New Revision: 156631
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156631
Log:
2010-02-09 Paul Thomas pa...@gcc.gnu.org
PR
// { dg-do compile }
// { dg-options -g -femit-struct-debug-baseonly }
# 1 foo.C
# 1 bar.h 1
typedef struct { int i; } S __attribute__((aligned));
typedef struct { struct { int i; } j; } T __attribute__((aligned));
# 1 foo.C 2
compiles fine with 4.3.x, but ICEs in gen_type_die_with_usage with
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Known
--- Comment #6 from froydnj at gcc dot gnu dot org 2010-02-09 17:51 ---
Declaring this one fixed, somewhat late.
--
froydnj at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-09 18:20
---
Your pointer isn't properly aligned to be accessed via uint32_t*.
That's hardly satisfactory an answer. GCC has always generated working code on
non-strict alignment platforms in this case and one can expect
--- Comment #25 from jwakely dot gcc at gmail dot com 2010-02-09 18:28
---
This is now LWG 1315
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
--- Comment #14 from jamborm at gcc dot gnu dot org 2010-02-09 19:44
---
Do your problems go away with -fno-indirect-inlining ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
gcc.gnu.org/bugzilla is currently running Bugzilla 2.20, which reached
end-of-life on November 29, 2008, see http://www.bugzilla.org/news/#release32.
This means that this installation is vulnerable to all security bugs found in
the last 15 months. This installation should be upgraded to Bugzilla
--- Comment #4 from LpSolit at netscape dot net 2010-02-09 19:51 ---
(In reply to comment #3)
This is not fixable.
This is fixable, and is actually fixed in Bugzilla 3.4!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38475
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-09 19:54 ---
I cannot find the emails saying why this has not been done yet but I remember
the issue comes down to custom fields which need to be moved correctly over to
the new version of bugzilla.
--
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #6 from vmakarov at redhat dot com 2010-02-09 19:56 ---
The patch which I'll send in a few minutes solves the problem. The patch
avoids the creation of shuffle copies if an involved operand should be bound to
some other operand in the current insn. The test code
--- Comment #2 from LpSolit at netscape dot net 2010-02-09 19:58 ---
(In reply to comment #1)
I cannot find the emails saying why this has not been done yet but I remember
the issue comes down to custom fields which need to be moved correctly over to
the new version of bugzilla.
--- Comment #4 from jason at gcc dot gnu dot org 2010-02-09 20:06 ---
Subject: Bug 42370
Author: jason
Date: Tue Feb 9 20:05:51 2010
New Revision: 156634
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156634
Log:
PR c++/42370
* decl2.c (change_return_type): New
--- Comment #3 from joseph at codesourcery dot com 2010-02-09 20:18 ---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
I think the call for volunteers at
http://gcc.gnu.org/ml/gcc/2008-03/msg00276.html
still applies.
--
--- Comment #4 from LpSolit at netscape dot net 2010-02-09 20:22 ---
Hey Daniel, still need some help? :)
--
LpSolit at netscape dot net changed:
What|Removed |Added
--- Comment #5 from jason at gcc dot gnu dot org 2010-02-09 20:22 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from joseph at codesourcery dot com 2010-02-09 20:33 ---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
There may be a few local code changes (Daniel mentioned email handling) to
carry over (it's quite possible newer versions don't need code changes for
--- Comment #6 from LpSolit at netscape dot net 2010-02-09 20:45 ---
Hard to see all the changes made to 2.20 via CVS. Is there a patch somewhere
done against vanilla Bugzilla showing all the customizations which have been
done?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #7 from jsm28 at gcc dot gnu dot org 2010-02-09 21:01 ---
Created an attachment (id=19830)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19830action=view)
Local Bugzilla changes
Here's a diff generated with cvs -z9 diff -uN -rBUGZILLA_2_20 -rHEAD.
There are some
--- Comment #8 from jsm28 at gcc dot gnu dot org 2010-02-09 21:09 ---
Created an attachment (id=19831)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19831action=view)
Diff from tarball
Here is a larger, probably more accurate diff generated using a release
tarball.
--
--- Comment #9 from joseph at codesourcery dot com 2010-02-09 21:15 ---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
I think we agreed some time ago to remove the gccbug script - if we do
that then we shouldn't need to bring over anything related to processing
--- Comment #26 from paolo dot carlini at oracle dot com 2010-02-09 21:20
---
Fine, let's suspend this, then.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
SPEC CPU2006 test 453.povray is miscompiled by GCC mainline on powerpc64-linux
for -O2 -floop-strip-line with either -m32 or -m64. Here's the function that
is miscompiled; I'll attach a complete executable testcase:
void
pre_init_tokenizer ()
--- Comment #1 from janis at gcc dot gnu dot org 2010-02-09 21:29 ---
Created an attachment (id=19832)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19832action=view)
minimized executable testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43012
--- Comment #7 from jason at gcc dot gnu dot org 2010-02-09 21:39 ---
*** This bug has been marked as a duplicate of 42370 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-09 21:39 ---
*** Bug 42737 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jason at gcc dot gnu dot org 2010-02-09 21:39 ---
*** This bug has been marked as a duplicate of 42370 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jason at gcc dot gnu dot org 2010-02-09 21:39 ---
*** Bug 42877 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from paolo dot carlini at oracle dot com 2010-02-09 21:43
---
Jon, about the proposed resolution, do you think that simple is enough? I mean,
it doesn't say anything about the problem I had to address with SFINAE in my
tentative patch...
--
--- Comment #10 from LpSolit at netscape dot net 2010-02-09 21:44 ---
Could someone having access to the Bugzilla server install the PatchReader Perl
module? It's way easier to read patches this way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-02-09 21:45
---
(In reply to comment #10)
Could someone having access to the Bugzilla server install the PatchReader
Perl
module? It's way easier to read patches this way.
I think it is already installed, just the
--- Comment #28 from redi at gcc dot gnu dot org 2010-02-09 21:51 ---
Good point, I'll ask Howard to update it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
1 - 100 of 133 matches
Mail list logo
