--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-19 06:55 ---
These two macros are mentioned in footnotes in the C standard.
I think we should accept them.
Take a look at DR #593 here, though:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2130.html
I don't have a c
--- Comment #4 from peeterj at ca dot ibm dot com 2008-01-19 05:19 ---
My snapshot already has that fix. That one was only for __STDC_FORMAT_MACROS
which is for . There's two more such macros for stdint.h
(__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS) to access various bits of that
f
--- Comment #3 from dkwan at transmeta dot com 2008-01-19 03:33 ---
cc1plus SEG faults because the hash table local_specializations is NULL. There
are calls to retrieve_local_specialization in pt.c. All but one, which caused
this ICE, are protected by a NULL test. I have a sandbox with
--- Comment #7 from manu at gcc dot gnu dot org 2008-01-19 01:40 ---
(In reply to comment #6)
>
> Your fix looks quite obvious, could you send it to gcc-patches so we can fix
> this before the freeze? Thanks for the quick fix btw.
>
That fix is too simple. It doesn't handle -Wno-stric
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-19 01:05 ---
This is not a bug as const_var (in this case) is not an integal constant
expression in either C or C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from manu at gcc dot gnu dot org 2008-01-19 01:04 ---
Fixed. Thanks for the report!
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu dot
|
--- Comment #5 from kkojima at gcc dot gnu dot org 2008-01-19 00:54 ---
Created an attachment (id=14973)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14973&action=view)
reduced testcase
I think Richard's comment is the case. Here is a reduced testcase.
The PIC memory access on
--- Comment #9 from ISPARRY at BROCADE dot COM 2008-01-19 00:53 ---
(In reply to comment #8)
> Changing component; the patch here doesn't touch the preprocessor at all.
>
If you are changing the component, would not a better choice be "driver" than
"c"?
I agree the patch does not tou
--- Comment #30 from aoliva at gcc dot gnu dot org 2008-01-19 00:51 ---
I tried that myself (patch in comment #11) and got no regressions. It's a
reasonable possibility, but isn't it a bit too early to close the bug? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
--- Comment #3 from kkojima at gcc dot gnu dot org 2008-01-19 00:50 ---
*** This bug has been marked as a duplicate of 34777 ***
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from kkojima at gcc dot gnu dot org 2008-01-19 00:50 ---
*** Bug 34807 has been marked as a duplicate of this bug. ***
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from manu at gcc dot gnu dot org 2008-01-19 00:39 ---
Subject: Bug 33768
Author: manu
Date: Sat Jan 19 00:39:08 2008
New Revision: 131650
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131650
Log:
2008-01-19 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR ot
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-19 00:45 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868 .
Can you try a newer snapshot since I think this has changed back to a warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34859
--- Comment #54 from zadeck at gcc dot gnu dot org 2008-01-19 00:39 ---
Subject: Bug 34400
Author: zadeck
Date: Sat Jan 19 00:38:34 2008
New Revision: 131649
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131649
Log:
2008-01-18 Kenneth Zadeck <[EMAIL PROTECTED]>
St
--- Comment #58 from zadeck at gcc dot gnu dot org 2008-01-19 00:39 ---
Subject: Bug 26854
Author: zadeck
Date: Sat Jan 19 00:38:34 2008
New Revision: 131649
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131649
Log:
2008-01-18 Kenneth Zadeck <[EMAIL PROTECTED]>
St
--- Comment #20 from manu at gcc dot gnu dot org 2008-01-19 00:22 ---
There is a bug (PR32102) where -Wall after -Wstrict-overflow resets the latter
to its default value. I think this is why you didn't get the warning. Removing
-Wall or moving -Wstrict-overflow=5 after it should generate
--- Comment #12 from rsandifo at gcc dot gnu dot org 2008-01-19 00:00
---
Sorry for the delay, been away. Testing a patch.
As Steven says in comment #10, this is latent mismatch
between the expander and define_insn conditions. It showed
up when a predicate used in the latter was fixe
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
St
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-18 23:54 ---
*** This bug has been marked as a duplicate of 34860 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-18 23:54 ---
*** Bug 34863 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34860
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
St
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-18 23:49 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-18 23:46 ---
Subject: Bug 32616
Author: burnus
Date: Fri Jan 18 23:46:04 2008
New Revision: 131643
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131643
Log:
2008-01-18 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-18 23:36 ---
Works for me on i686-apple-darwin9 (Intel Core2Duo OSX 10.5.1), rev. 131629
(trunk) and gfortran 4.2.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34860
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-18 23:36 ---
__STDC_ are in the implementation namespace so why are you defining them?.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34859
The qdelg.f subroutine, a part of SciPy, fails to build if -O3 optimization is
turned on. The error given is
[EMAIL PROTECTED] quadpack]$ gfortran -c -ffixed-form -fno-second-underscore
-fPIC
-O3 -funroll-loops -c dqelg.f -o /tmp/dqelg.o
dqelg.f: In function 'dqelg':
dqelg.f:1: internal compil
--- Comment #19 from sergstesh at yahoo dot com 2008-01-18 23:33 ---
Regarding "BTW, is your makefile adding -Wstrict-overflow after or before -Wall
-Wextra?".
Here is how the first action line in 'make.log' looks:
"
23 if /bin/sh ../../libtool --tag=CC --mode=compile
/maxtor5/ser
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-18 23:32 ---
Confirmed on i686-apple-darwin9, rev. 131629 (trunk) and gfortran 4.2.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861
Have a class that defines a placement new like varient that updates a pointer
to raw storage via a reference argument. Here's a stripped down code fragment:
#include // size_t
class T
{
public:
void *operator new(size_t size, char *&p);
T( int &rc);
} ;
void *T::operator new(size_t size
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-01-18 23:22 ---
Brain dump into this: reasons to move to datum/mt_allocator type approach:
It tries to be the minimal change, keeping all your existing data. (With the
exception of making a tristate variable for the force_parallel/fo
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-18 23:16
---
On x86-64:
==11867== 208 bytes in 26 blocks are definitely lost in loss record 1 of 5
==11867==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==11867==by 0xB4C018: __gmp_default_allocate (in /mnt/sdb2/obj
--- Comment #1 from peeterj at ca dot ibm dot com 2008-01-18 23:06 ---
I see the two places in the code that look like they are related:
./libcpp/macro.c:1698: if (! ustrncmp (NODE_NAME (node), DSC ("__STDC_"))
./libcpp/macro.c:1699: && ustrcmp (NODE_NAME (node), (const uchar *)
"
The following generates:
i_1_mods_bug.f:10.72:
END FUNCTION
1
Internal Error at (1):
gfc_compare_array_spec(): Array spec clobbered
4.3.0 20080109 (experimental) [trunk revision 131426] (GCC)
It works fine if I delete
The qdelg.f subroutine, a part of SciPy, fails to build if -O3 optimization is
turned on. The error given is
[EMAIL PROTECTED] quadpack]$ gfortran -c -ffixed-form -fno-second-underscore
-fPIC
-O3 -funroll-loops -c dqelg.f -o /tmp/dqelg.o
dqelg.f: In function 'dqelg':
dqelg.f:1: internal compil
Have a situation where some ugly make recursion is causing -D related cflags
for compilation to be duplicated (only for one file out of thousands)
When that duplication happens to include -D__STDC_LIMIT_MACROS the g++ 4.3
(using 20080111 snapshot) ends up with the following error:
: error: "__STD
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-01-18 22:24
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-01-18 22:23
---
Subject: Bug 34782
Author: jvdelisle
Date: Fri Jan 18 22:22:21 2008
New Revision: 131641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131641
Log:
2007-01-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #12 from jkenisto at us dot ibm dot com 2008-01-18 22:20
---
(In reply to comment #11)
> (In reply to comment #9)
> > > Since this topic came up, I've seen various suggestions for how to
> > > guarantee
> > that a function gets inlined -- e.g., make it a varargs function, o
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-18 22:04 ---
static const int i = 1;
i is not a constant integal expression in C. It is in C++. With optimization,
we "inline" the value.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-18 22:02 ---
I don't think this is a bug as &var is not a constant for PIC mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
--- Comment #8 from tromey at gcc dot gnu dot org 2008-01-18 21:52 ---
Changing component; the patch here doesn't touch the preprocessor at all.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #29 from rguenth at gcc dot gnu dot org 2008-01-18 21:04
---
I'm trying again with enabling the langhook for C++.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-18 20:52 ---
On i686-apple-darwin9, I get:
pr34856.c: In function 'f1':
pr34856.c:16: error: invalid reference prefix
{(unsigned int) &g[16]}
pr34856.c:16: internal compiler error: verify_stmts failed
--
http://gcc.gnu.org/
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34850
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34808
At revision 131629 (trunk), the following code
type a_t
sequence
integer i
end type a_t
block data bd
common c
end block data bd
common /a_t/ c
end
gives
1234567.f90:6.13:
block data bd
1
Error: Unexpected BLOCK DATA statement at (1)
1234567.f90:7.10:
common c
1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34831
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--- Comment #5 from ISPARRY at BROCADE dot COM 2008-01-18 20:12 ---
(In reply to comment #4)
> Patches welcome.
>
Ceratinly. I can either up-rev the patch posted in
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html or I can do a patch to
undo the deprecation of -I-. Which stands
--- Comment #4 from steven at gcc dot gnu dot org 2008-01-18 20:05 ---
Patches welcome.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34855
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-18 20:04 ---
Does it happen w/o -ffast-math ?
Also we need a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from ISPARRY at BROCADE dot COM 2008-01-18 19:59 ---
(In reply to comment #2)
> And that bug is still opened.
>
> *** This bug has been marked as a duplicate of 19541 ***
>
Yes. 3 years after a fix is available, and 3 releases of gcc, the bug is still
open. Can we get i
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-18 19:51 ---
*** Bug 34855 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-18 19:51 ---
And that bug is still opened.
*** This bug has been marked as a duplicate of 19541 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-18 19:51 ---
*** This bug has been marked as a duplicate of 34855 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-18 19:51 ---
*** Bug 34857 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34855
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE with some constant |[4.3 Regression] ICE with
|vectors
This is bug 19541, but being reported against 4.3.0.
Still a problem in 4.3.using Debian unstable packages
gcc --version gives gcc-4.3 (Debian 4.3-20080116-1) 4.3.0 20080116
(experimental) [trunk revision 131577]
Can we either get the "ignore-source-dir" patch added to the mainline, or else
remov
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-18 19:45
---
on i686 linux I get;
test.c:16: internal compiler error: in for_each_index, at
tree-ssa-loop-im.c:222
works with gcc 3.4.6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
Testcase:
#undef __vector
#define __vector __attribute__((vector_size(16) ))
typedef __vector signed char qword;
typedef __vector unsigned int VU32;
extern short g[192 +16];
void f(qword);
void f1 (unsigned ctr)
{
VU32 pin;
pin = (VU32){(unsigned int)&g[16]};
do {
f((qword)pin);
ctr--;
--- Comment #8 from barry dot j dot mcinnes at noaa dot gov 2008-01-18
19:29 ---
Subject: Re: tab format failure to display properly
(regression vs. g77)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks again - I will wait the 36h, then I can try out the released
package ?
On 1
This is bug 19541, but being reported against 4.3.0.
Still a problem in 4.3.using Debian unstable packages
gcc --version gives gcc-4.3 (Debian 4.3-20080116-1) 4.3.0 20080116
(experimental) [trunk revision 131577]
Can we either get the "ignore-source-dir" patch added to the mainline, or else
remov
--- Comment #28 from aoliva at gcc dot gnu dot org 2008-01-18 19:11 ---
Subject: Bug 33887
Author: aoliva
Date: Fri Jan 18 19:11:15 2008
New Revision: 131632
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131632
Log:
PR c++/33887
* link.cc (_Jv_Linker::prepare_constant_time_tabl
--- Comment #6 from ismail at pardus dot org dot tr 2008-01-18 19:11
---
Manu,
Your fix looks quite obvious, could you send it to gcc-patches so we can fix
this before the freeze? Thanks for the quick fix btw.
Regards,
ismail
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
--- Comment #5 from manu at gcc dot gnu dot org 2008-01-18 19:02 ---
(In reply to comment #4)
> I think then -Wall shouldn't enable -Wstrict-overflow at all. Because current
> situation is counter intuitive.
>
This a bug. A quick fix is:
Index: gcc/c-opts.c
===
--- Comment #27 from aoliva at gcc dot gnu dot org 2008-01-18 18:47 ---
Found it (or at least the first one):
in link.cc:665, has_interfaces is a jboolean (unsigned 1-bit type), but it's
operated on like this:
has_interfaces += klass0->interface_count;
if interface_count is even (
--- Comment #18 from manu at gcc dot gnu dot org 2008-01-18 18:47 ---
(In reply to comment #15)
> With CFLAGS='-O2 -Wstrict-overflow=5' still there is no warnings in
BTW, is your makefile adding -Wstrict-overflow after or before -Wall -Wextra?
--
manu at gcc dot gnu dot org changed:
--- Comment #4 from ismail at pardus dot org dot tr 2008-01-18 18:46
---
I think then -Wall shouldn't enable -Wstrict-overflow at all. Because current
situation is counter intuitive.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
--- Comment #5 from manu at gcc dot gnu dot org 2008-01-18 18:44 ---
*** This bug has been marked as a duplicate of 32102 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2008-01-18 18:44 ---
*** Bug 34843 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from aldot at gcc dot gnu dot org 2008-01-18 18:38 ---
fix-proto is never run, it seems:
$ grep "stmp-" out.log
echo timestamp > stmp-fixinc
echo timestamp > stmp-int-hdrs
echo timestamp > stmp-install-fixproto
if [ xstmp-install-fixproto != x ] ; then \
after fix
--- Comment #11 from daney at gcc dot gnu dot org 2008-01-18 18:15 ---
It is a regression, this works:
$ mipsel-linux-gcc -march=sb1 -ffast-math -c pr34233.c
$ mipsel-linux-gcc --version
mipsel-linux-gcc (GCC) 3.4.3
This doesn't:
$ gcc -march=sb1 -ffast-math -c pr34233.c
pr34233.c: In
--- Comment #26 from aoliva at gcc dot gnu dot org 2008-01-18 18:08 ---
I installed the patch in comment #11 and rebuilt all libraries, then I started
investigating the first testsuite failure: libjava.cni/PR9577.java.
So far, I've found out that it is the gnu.classpath.SystemProperties
--enable-threads
--disable-multilib --disable-libgomp --disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.3.0 20080118 (experimental) (GCC)
Given that i don't build c++, should fix-headers be installed in the first
place (for use a different compiler, perhaps)?
--
aldot a
I think both testcases below are valid, but gfortran rejects the
second one. They only differ in the order of USE statements.
$ cat test.f90
module common_init_conf
integer, allocatable, dimension(:,:) :: Nmoltype_phase
end module common_init_conf
subroutine read_initial_config_nml()
use common
--- Comment #17 from pmarques at grupopie dot com 2008-01-18 17:30 ---
I just found out what's causing this confusion. If you compile your program
like this:
avr-gcc -Os -mmcu=atmega168 -lm main.c -o main.elf
__clz_tab gets included. But if you compile like this:
avr-gcc -Os -mmcu=atm
--- Comment #4 from ismail at pardus dot org dot tr 2008-01-18 17:19
---
Actually I am reopening this because after talking to Richi we agree that -Wall
should not reset -Wstrict-overflow. But of course final decision is up to iant.
--
ismail at pardus dot org dot tr changed:
--- Comment #10 from steven at gcc dot gnu dot org 2008-01-18 17:14 ---
The problem is IMHO in the div3 define_expand in mips.md:
(define_expand "div3"
[(set (match_operand:ANYF 0 "register_operand")
(div:ANYF (match_operand:ANYF 1 "reg_or_1_operand")
(match
--- Comment #9 from steven at gcc dot gnu dot org 2008-01-18 17:02 ---
Does not fail unless -march=sb1 is given.
Thus not a regression until proven that older GCCs did not fail with this
option.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from rguenther at suse dot de 2008-01-18 16:56 ---
Subject: Re: [4.3 Regression] ICE on gcc.dg/pr34233.c for
MIPS
On Fri, 18 Jan 2008, steven at gcc dot gnu dot org wrote:
> --- Comment #6 from steven at gcc dot gnu dot org 2008-01-18 16:53
> ---
> The offend
--- Comment #7 from rguenther at suse dot de 2008-01-18 16:54 ---
Subject: Re: [4.3 Regression] ICE on gcc.dg/pr34233.c for
MIPS
On Fri, 18 Jan 2008, steven at gcc dot gnu dot org wrote:
> --- Comment #5 from steven at gcc dot gnu dot org 2008-01-18 16:50
> ---
> Confirmed.
--- Comment #6 from steven at gcc dot gnu dot org 2008-01-18 16:53 ---
The offending insn is already produced in "expand".
GCC ICEs the first time it calls recog() on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34831
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-18 16:50 ---
Confirmed.
ignoring nonexistent directory
"/usr/local/lib/gcc/mipsel-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/mipsel-unknown-linux-gnu/4.3.0/include-fixed"
ignoring nonexist
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-01-18 16:48 ---
Fixed for C++0x.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from ismail at pardus dot org dot tr 2008-01-18 16:41
---
Looks like -Wall being at the end disables this warning uh oh. This is invalid,
sorry for taking your time.
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
--
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-18 16:33 ---
Suspended for now. We'll pick up the library work again once the C++ committee
has resolved this issue.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ian at airs dot com 2008-01-18 16:32 ---
When I compile this code with current mainline with -O3 -Wstrict-overflow=3 I
get the following warnings:
Objects/unicodeobject.c: In function unicode_startswith:
Objects/unicodeobject.c:6943: warning: dereferencing type-pun
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-18 16:32 ---
Confirmed. This is the right behavior according to the C++0x specification, but
the backward-compatibility issue with push_back is a problem. The C++ committee
is aware is the issue.
--
dgregor at gcc dot gnu dot
--- Comment #6 from gin at mo dot msk dot ru 2008-01-18 16:21 ---
Subject: Re: wrong code for dereferencing type-punned pointer
> looks good for 4.2.
Can we see (assembler) output of that 4.2, with those same
`-fno-strict-aliasing -O3 -fno-strict-aliasing' optimization options,
for th
--- Comment #14 from ian at airs dot com 2008-01-18 16:17 ---
This is now fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #8 from kkojima at gcc dot gnu dot org 2008-01-18 16:15 ---
(In reply to comment #6)
> But I don't feel strong either way. Your patch looks correct to me.
Thanks! I'll test it with bootstrap®test on x86 and ppc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34808
--- Comment #7 from burnus at gcc dot gnu dot org 2008-01-18 16:10 ---
> Thanks - how does one get and install the patch ?
Well, that is difficult - he did not post it. It was probably neither in the
final shape nor regression tested to make sure it does not break something of
the test
--- Comment #7 from steven at gcc dot gnu dot org 2008-01-18 16:07 ---
Ah, and of course gen_rtx_INSN_LIST does not set XEXP(0) of the REG_LIBCALL
note. Silly me ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34808
--- Comment #6 from steven at gcc dot gnu dot org 2008-01-18 16:05 ---
I tried to avoid setting XEXP(note,0) twice (once directly and once through
gen_rtx_INSN_LIST.
But I don't feel strong either way. Your patch looks correct to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #13 from ian at airs dot com 2008-01-18 16:01 ---
I think you're right. If the call to placement new is not inlined, and if we
don't know anything special about it (which we currently don't), then it seems
to me that everything is bound to work OK. It is only the inlining t
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-18 15:48 ---
Confirmed. (happened on haydn)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from myan at microstrategy dot com 2008-01-18 15:35 ---
Created an attachment (id=14970)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14970&action=view)
Java application
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34853
--- Comment #5 from myan at microstrategy dot com 2008-01-18 15:35 ---
Created an attachment (id=14972)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14972&action=view)
shell script to run the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34853
--- Comment #4 from myan at microstrategy dot com 2008-01-18 15:35 ---
Created an attachment (id=14971)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14971&action=view)
makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34853
1 - 100 of 156 matches
Mail list logo
