--- 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, th
--- 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 func
--- 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
--with-sysroot
--- 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.
--
http://gcc.gnu.or
--- 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 self-con
--- 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 m
--- 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 fo
--- 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=gcc&view=rev&rev=156619
Log:
Backport from mainline:
2010-01-13 Richard Guent
--- 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=gcc&view=rev&rev=156620
Log:
2010-02-09 Daniel Kraft
PR fortran/39171
* re
--- 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
Status|ASSI
--- 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=gcc&view=rev&rev=156621
Log:
2010-02-09 Richard Guenther
PR tree-optimization/
--- 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 foo(A* q)
> {
> return q->*p;
> }
>
> template
> int bar(int T::* p)
> {
> return foo(0
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 convert_to_intege
--
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 @@ convert_to_i
--- 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
("_ZN
--- 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 fccM
--- 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
AssignedTo|unassigned
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 v
--- 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
As
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
#include
#include
#include
void process_buf(uint32_t *buf)
{
int i;
uint32_t t = 0;
for(i = 0; i < 16; i++)
buf[
--- 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=19828&action=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=19829&action=view)
output for: gcc -v -save-temps -Wall -Werror -O3 2.c -o 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4300
--- 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 mist
--- 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=gcc&view=rev&rev=156628
Log:
2010-02-09 Richard Guenther
PR tree-optimization/
--- 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 w
--- 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=gcc&view=rev&rev=156630
Log:
2010-02-09 Tobias Burnus
PR fortran/42996
*
--- 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 #4 from burnus at gcc dot gnu dot org 2010-02-09 17:07 ---
FIXED on the trunk (4.5).
Thanks for the bug report!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- 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 4.
--- 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=gcc&view=rev&rev=156631
Log:
2010-02-09 Paul Thomas
PR fortran/41869
* m
// { 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 w
--
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 i
--- 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 3.
--- 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.
--
http://gcc.gnu.org/bug
--
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 generated
--- 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.
W
--- 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=gcc&view=rev&rev=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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4301
--- 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
wh
--- 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=19830&action=view)
Local Bugzilla changes
Here's a diff generated with "cvs -z9 diff -uN -rBUGZILLA_2_20 -rHEAD".
There are some od
--- 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=19831&action=view)
Diff from tarball
Here is a larger, probably more accurate diff generated using a release
tarball.
--
http:/
--- 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
incoming
--- 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=19832&action=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...
--
http://gcc.gnu.org/bugzil
--- 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 attachme
--- 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
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-09 22:06 ---
Subject: Bug 42399
Author: jason
Date: Tue Feb 9 22:06:23 2010
New Revision: 156635
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156635
Log:
PR c++/42399
* pt.c (tsubst_copy_and_build): Prop
--- Comment #1 from davem at gcc dot gnu dot org 2010-02-09 22:08 ---
Ok, I now know a lot more about this bug. It's effects were masked
before gcc-4.4 because we used to have the TFmode secondary reload
slot in every stack frame. That got removed by my commit:
2009-01-04 David S. Mi
--- Comment #12 from LpSolit at netscape dot net 2010-02-09 22:11 ---
The changes in the core code do not look too terrific and should be easy to
port (some of which are now useless in the 3.4 code). I guess most changes in
contrib/bug_email.pl can go away now that we have email_in.pl, b
--- Comment #2 from davem at gcc dot gnu dot org 2010-02-09 22:13 ---
Reading further, the Sparc 64-bit ABI requires that the every stack frame
be 16 byte aligned. And if that were the case this problem would never
happen.
Will try to determine how the stack is becomming only 8-byte al
There are 3 possible problems:
1) bootstrap with BOOT_CFLAGS="-O2 -fstack-protector" fails when compiling
i386.o
2) warning in testcase.c
3) warning about x.0 in testcase2.c, crashing output binary
I don't know if any of these problems is a real bug.
All testcases were tested with recent builds o
--- Comment #1 from zsojka at seznam dot cz 2010-02-09 22:21 ---
BOOT_CFLAGS="-O2 -fstack-protector"
should be
BOOT_CFLAGS="-O2 -fstack-check"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43013
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-09 22:28 ---
Confirmed. 10.3 says that the lookup is unambiguous, just some uses can be
ambiguous. In fact, we fail the test in paragraph 13:
struct B1 {
void f();
static void f(int);
int i;
};
struct B2 {
void f(double)
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-09 22:29 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #5 from jason at gcc dot gnu dot org 2010-02-09 22:30 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
My first bug report, please let me know if I am missing anything.
Running...
$ cat minimal.cpp && echo "-" && g++ -Wall minimal.cpp && a.out
Produces...
#include
#include
#include
using namespace std;
int main() {
map hash;
string sElement;
sElement = "ab1";
cout << sElement.c_
--- Comment #4 from janis at gcc dot gnu dot org 2010-02-09 22:38 ---
Peter and Mike, can one of you please look at this bug? It looks like
something that you could figure out without a minimized testcase, but if it
helps I'll come up with one. I can also do a regression hunt if that w
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-09 22:48 ---
I don't think this is a bug. sElement.c_str() returns a temporary storage
which gets destroyed when sElement changes (via the operator= method).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43014
--- Comment #14 from law at redhat dot com 2010-02-09 23:04 ---
Subject: Re: vectorizer created unaligned vector
insns
On 01/18/10 05:17, irar at il dot ibm dot com wrote:
> --- Comment #13 from irar at il dot ibm dot com 2010-01-18 12:17 ---
> Does something like this make s
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-02-09 23:11
---
(In reply to comment #14)
> Subject: Re: vectorizer created unaligned vector
> insns
>
> On 01/18/10 05:17, irar at il dot ibm dot com wrote:
> > --- Comment #13 from irar at il dot ibm dot com 2010-01-18 1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|wrong code for -floop-strip-|[4.5 Regression] wrong code
|mine in 453.povray
--- Comment #17 from jason at gcc dot gnu dot org 2010-02-09 23:14 ---
Suspending.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-09 23:18 ---
(In reply to comment #6)
> > 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
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-09 23:20
---
The "surprising" behavior is ultimately due to the fact that our string is
reference counted, thus 'string aux = sElement' is a shallow copy, but then,
when sElement = "ab3" is performed a deep copy takes place
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
|
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-09 23:40
---
Oops, read "because in this case the address" as "THUS in this case the
address", sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43014
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-09 23:46 ---
Yep, that's a bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Severity|m
--- Comment #16 from law at redhat dot com 2010-02-09 23:49 ---
Subject: Re: vectorizer created unaligned vector
insns
On 02/09/10 16:11, rguenth at gcc dot gnu dot org wrote:
> --- Comment #15 from rguenth at gcc dot gnu dot org 2010-02-09 23:11
> ---
> (In reply to comment
1 - 100 of 111 matches
Mail list logo
