--- Comment #1 from jason at gcc dot gnu dot org 2010-02-10 05:46 ---
Your comment to the patch that removed LANG_HOOKS_EXPR_SIZE suggests that this
isn't a problem anymore:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01593.html
--
jason at gcc dot gnu dot org changed:
--- Comment #5 from gcc_bugzilla dot 20 dot marcelitom at inboxclean dot
com 2010-02-10 04:00 ---
Thanks Andrew and Paolo, apologies for my mistake. I have learnt something.
According to what you wrote, a "seemingly natural" code like
for(;;) {
sElement = SomeString(...);
i
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-02-10 03:34
---
Subject: Bug 42999
Author: jvdelisle
Date: Wed Feb 10 03:34:33 2010
New Revision: 156643
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156643
Log:
2010-02-09 Jerry DeLisle
PR fortran/42999
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-02-10 03:31
---
Subject: Bug 42999
Author: jvdelisle
Date: Wed Feb 10 03:31:02 2010
New Revision: 156642
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156642
Log:
2010-02-09 Jerry DeLisle
PR fortran/42999
--- Comment #15 from joseph at codesourcery dot com 2010-02-10 02:29
---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
On Wed, 10 Feb 2010, LpSolit at netscape dot net wrote:
> --- Comment #14 from LpSolit at netscape dot net 2010-02-10 00:29 ---
> (In reply to
--- Comment #7 from vmakarov at gcc dot gnu dot org 2010-02-10 02:07
---
Subject: Bug 42973
Author: vmakarov
Date: Wed Feb 10 02:07:22 2010
New Revision: 156641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156641
Log:
2010-02-09 Vladimir Makarov
PR middle-end/4297
--- Comment #12 from matt at use dot net 2010-02-10 01:26 ---
I haven't had any issues come up with this in the last month, testing with a
new profiledbootstrap of GCC trunk every week or so. Can this be backported to
4.4 now? Or is there some specific testing you'd like me to do? Let me
--- Comment #3 from davem at gcc dot gnu dot org 2010-02-10 00:49 ---
I've root caused this to the Linux kernel not 16-byte aligning thread
stacks when using the clone() system call (it was enforcing only 8-byte
alignment), and also signal stacks.
The seconday mem TFmode stack slot was
--- Comment #14 from LpSolit at netscape dot net 2010-02-10 00:29 ---
(In reply to comment #13)
> Email replies get
> body and attachments automatically entered in the relevant bug, with an
> account created for the sender if they didn't already have one. If you
> preserve that, most
--- Comment #13 from joseph at codesourcery dot com 2010-02-10 00:20
---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
The main email-related functionality for GCC is: all bugs in the "gcc"
product automatically get CC:ed to gcc-bugs@gcc.gnu.org (maybe other lists
depe
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-09 23:51
---
Grr, I noticed another typo in my reply, I meant of course "third find", not
"first find". Only the outcome of the third find was at issue, anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43014
--- 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
--- 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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
|
--- 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
--- 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 #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|
--
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 #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
--- 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 #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 #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
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 #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
--- 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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
-
--- 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 #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 #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
--
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 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
--- 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 #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 #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 #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 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 #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 #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
--
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 #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
--- 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
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 #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
--- 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 #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 #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
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Known
// { 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
--- 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
--- 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 #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 #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 #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 #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 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 #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 #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 #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 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 #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
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 #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
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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
--
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
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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
1 - 100 of 111 matches
Mail list logo
