--- Comment #14 from amodra at gmail dot com 2010-05-28 02:32 ---
Created an attachment (id=20766)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20766&action=view)
broken here, see insn 27
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
--- Comment #13 from amodra at gmail dot com 2010-05-28 02:31 ---
Created an attachment (id=20765)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20765&action=view)
ok at this point
--
amodra at gmail dot com changed:
What|Removed |Added
-
--- Comment #12 from amodra at gmail dot com 2010-05-28 02:28 ---
This problem can be seen on powerpc-linux-gcc with the options -O1 -fPIC
-ftls-model=initial-exec -misel.
The error occurs between 172r.ira and 174r.postreload, not at 186r.dce as
previously reported.
--
amodra at gma
--- Comment #5 from dodji at gcc dot gnu dot org 2010-05-28 00:39 ---
Subject: Re: [4.6 Regression] Failed to bootstrap
"hjl dot tools at gmail dot com" writes:
> --- Comment #3 from hjl dot tools at gmail dot com 2010-05-27 23:01
> ---
> This one avoids one extra is_naming
--- Comment #4 from dodji at gcc dot gnu dot org 2010-05-28 00:09 ---
I have reverted that commit for now. See my comments on PR44188. Sorry for the
breakage.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dodji at gcc dot gnu dot org 2010-05-28 00:08 ---
Re-opening as my patch broke Ada and Obj-c(++).
It looks like Ada emits TYPE_DECLs that smell like c/c++ naming typedefs but
with different semantics ...
--
dodji at gcc dot gnu dot org changed:
What
--- Comment #5 from dodji at gcc dot gnu dot org 2010-05-28 00:03 ---
Subject: Bug 44188
Author: dodji
Date: Fri May 28 00:03:19 2010
New Revision: 159955
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159955
Log:
Revert "Fix PR c++/44188"
gcc/ChangeLog:
revert fix for
--- Comment #33 from howarth at nitro dot med dot uc dot edu 2010-05-28
00:02 ---
(In reply to comment #32)
> I'd like to hear what Jack has to say, otherwise, fine by me.
>
No objections here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
--- Comment #3 from changpeng dot fang at amd dot com 2010-05-27 23:51
---
I did a quick look at 434.zeusmp and found that prefetching for the following
simple loop is responsible:
linpck.f: 131:
c
ccode for increment not equal to 1
c
ix = 1
smax = abs(sx(1))
--- Comment #9 from iains at gcc dot gnu dot org 2010-05-27 23:34 ---
using the example at #5
apollo:gcc-4-6-trunk-build$ ./gcc/xgcc -B gcc ../tests/trivial.m -flto -o t
-lobjc -save-temps
trivial.s:unknown:Undefined local symbol L_OBJC_CLASS_myRootObject.2084
trivial.s:unknown:Undefin
--- Comment #26 from nightstrike at gmail dot com 2010-05-27 23:26 ---
(In reply to comment #25)
> Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
>
> Note: I have no urge or time to upgrade gcc's bugzilla anymore.
> If ya'll want to work on it, i'm happy to give you all the
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-27 23:06 ---
It is caused by revision 145440:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-27 23:01 ---
This one avoids one extra is_naming_typedef_decl call:
---
Index: dwarf2out.c
===
--- dwarf2out.c (revision 159943)
+++ dwarf2out.c (working copy)
@@ -
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-27 22:58 ---
This patch:
---
Index: dwarf2out.c
===
--- dwarf2out.c (revision 159943)
+++ dwarf2out.c (working copy)
@@ -19427,7 +19427,8 @@ gen_typedef_die (tree d
--- Comment #28 from iains at gcc dot gnu dot org 2010-05-27 22:52 ---
(In reply to comment #27)
> Can you explain the struct __emutls_object change? That is an ABI break (and
> I
> don't see anywhere any rationale for that).
I did it for two reasons;
1/ to prove that I'd got a handl
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-27 22:47 ---
It is caused by revision 159943:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg01000.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
On Linux/ia32, revision 159949 failed to bootstrap:
gcc-test/src-trunk/libobjc/objc/Object.h:29:0,
from
/export/gnu/import/svn/gcc-test/src-trunk/libobjc/linking.m:27:
/export/gnu/import/svn/gcc-test/src-trunk/libobjc/objc/objc.h:72:1: internal
compiler error: in add_byte_size_att
g++ 4.5.0 produces an ICE (segmentation fault) on the code in the
How-To-Repeat section. The error is (the first non-blank line of the
example is line 1):
test.ii: In instantiation of âeâ:
test.ii:19:8: instantiated from here
test.ii:16:32: internal compiler error: Segmentation fault
The
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-27 22:11 ---
Created an attachment (id=20764)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20764&action=view)
A testcase for Linux/x86-64
[...@gnu-32 build_base_o3.]$ /export/gnu/import/rrs/159907/usr/bin/gcc -O3
pr44
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-27 22:09 ---
Subject: Bug 44255
Author: jakub
Date: Thu May 27 22:08:41 2010
New Revision: 159952
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159952
Log:
PR bootstrap/44255
* combine.c (struct rtx_subst
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-27 22:02 ---
Can you explain the struct __emutls_object change? That is an ABI break (and I
don't see anywhere any rationale for that).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
--- Comment #11 from mikpe at it dot uu dot se 2010-05-27 21:35 ---
Created an attachment (id=20763)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20763&action=view)
preprocessed source for libiberty/cp-demangle.c
Here's the preprocessed source for libiberty/cp-demangle.c as gener
--- Comment #2 from changpeng dot fang at amd dot com 2010-05-27 20:55
---
To me, non-constant step prefetching seems not fit into the existing
prefetching
framework. non-constant stride prevent any reuse analysis, and thus prefetching
is kind of blindly.
--
http://gcc.gnu.org/bugz
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.7 |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-27 20:53
---
Moot now.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
St
--- Comment #24 from paolo dot carlini at oracle dot com 2010-05-27 20:52
---
Can be closed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-27 20:50 ---
Not 100% sure yet, but I believe this commit broke bootstrap on both
x86_64-linux and i686-linux, e.g. in libobjc or in ada bits.
One of the ICEs I'm seeing is:
#0 fancy_abort (file=0x8d1d1e3 "../../gcc/dwarf2out.c",
--- Comment #1 from changpeng dot fang at amd dot com 2010-05-27 20:49
---
The regressions are most likely from the patch that added non-constant step
prefetching:
* From: Andreas Krebbel
* To: Christian Borntraeger
* Cc: gcc-patches
* Date: Wed, 19 May 2010 12:40:51
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-05-27 20:41 ---
Subject: Bug 44299
Author: ktietz
Date: Thu May 27 20:40:48 2010
New Revision: 159949
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159949
Log:
2010-05-27 Kai Tietz
PR bootstrap/44299
* c
--- Comment #3 from jmattson at vmware dot com 2010-05-27 20:31 ---
Admittedly, foo() makes some assumptions about alignment as originally written.
A more pedantic version is:
static inline void
foo(int *p)
{
if (p >= a + 1 && p < a + 10) {
p[-1] = 0;
}
}
gcc still generat
--- Comment #26 from iains at gcc dot gnu dot org 2010-05-27 20:11 ---
Created an attachment (id=20762)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762&action=view)
candidate fix that handles aliases as well.
PR44276 revealed that I wasn't handling alias cases.
The new attach
--- Comment #13 from jason at gcc dot gnu dot org 2010-05-27 20:04 ---
On reflection, I went ahead and applied it to 4.3 since it only affects VLA
code anyway.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-27 20:03 ---
"&b[0] > &a[0]" is not well defined in C or C++. That is what it gets
optimized to.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
--- Comment #12 from jason at gcc dot gnu dot org 2010-05-27 20:02 ---
Subject: Bug 43555
Author: jason
Date: Thu May 27 20:02:10 2010
New Revision: 159945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159945
Log:
PR c++/43555
* decl.c (grokdeclarator) [cdk_poin
--- Comment #1 from jmattson at vmware dot com 2010-05-27 20:01 ---
Created an attachment (id=20761)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20761&action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
In the following code, foo() properly guards the expression 'p[-1]' with a test
that p is a pointer to an element of a[] other than the first element. Yet,
when gcc analyzes array subscripts, it raises a warning because foo() is used
in a context where p points to the first element of b[].
Even i
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.6 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
gcc -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
-DNATIVE_C
ROSS -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototy
pes -Wmissing-format-attribute -Wold-style-definition -fno-common
-DHAVE_CONFIG
_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc
--- Comment #3 from dodji at gcc dot gnu dot org 2010-05-27 19:36 ---
Fixed in trunk (4.6).
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #2 from dodji at gcc dot gnu dot org 2010-05-27 19:30 ---
Subject: Bug 44188
Author: dodji
Date: Thu May 27 19:29:53 2010
New Revision: 159943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159943
Log:
Fix PR c++/44188
gcc/ChangeLog:
PR c++/44188
* c
--- Comment #11 from jason at gcc dot gnu dot org 2010-05-27 19:10 ---
Fixed for 4.4.6. I'm inclined not to apply the change to 4.3 just in case it
causes problems somehow, but I could be convinced otherwise.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from jason at gcc dot gnu dot org 2010-05-27 19:00 ---
Subject: Bug 43555
Author: jason
Date: Thu May 27 19:00:33 2010
New Revision: 159942
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159942
Log:
PR c++/43555
* decl.c (grokdeclarator) [cdk_poin
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-27 18:57 ---
Addresses of labels are only designed to work with computed gotos so if you
don't have a computed goto in the function of mainx, then this will not work.
See http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Labels-as-Va
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-27 18:57 ---
It is caused by revision 159907:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00963.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
The testcase below passes the entry point to 'lll' call as an address of the
label ll_def. printf line disappears completely.
Obviously people should only use such code when they really know what they are
doing. But compilation result here is complately wrong and isn't usable in any
way.
--- test
--- Comment #23 from jason at gcc dot gnu dot org 2010-05-27 18:40 ---
Subject: Bug 42832
Author: jason
Date: Thu May 27 18:39:46 2010
New Revision: 159940
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159940
Log:
Revert:
PR libstdc++/42832
* include/std
--- Comment #9 from jason at gcc dot gnu dot org 2010-05-27 18:39 ---
Subject: Bug 43555
Author: jason
Date: Thu May 27 18:39:28 2010
New Revision: 159939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159939
Log:
PR c++/43555
* decl.c (grokdeclarator) [cdk_point
--- Comment #8 from jason at gcc dot gnu dot org 2010-05-27 18:36 ---
Subject: Bug 43555
Author: jason
Date: Thu May 27 18:36:22 2010
New Revision: 159938
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159938
Log:
PR c++/43555
* decl.c (grokdeclarator) [cdk_point
--- Comment #7 from jason at gcc dot gnu dot org 2010-05-27 18:32 ---
This doesn't work with my 4.1 tree. Or with 3.2 for that matter. It does work
with 2.95.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
I have a serious problem. I am currently working on a raytracer project where
I'm using my own Vector-Header. The Vector-Header-File consists of classes
(Vec2, Vec3, Vec4 etc.) that encapsulate the gcc-vector-intrinsics (e.g.
typedef float _vec __attribute__((vector_size(16))); ). All methods
(ope
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-27 18:07 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02124.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-27 18:05 ---
That is because the classpath/libjava configure does not support the toplevel
building of GMP yet.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Tests are on amd-linux64 system with -O3 -fprefetch-loop-arrays
Compare gcc-4.6-20100522.tar.bz2 to gcc-4.6-20100515.tar.bz2
459.GemsFDTD: -32.6%
434.zeusmp: -13.6%
If I replace tree-ssa-loop-prefetch.c in gcc-4.6-20100522.tar.bz2 with the one
in gcc-4.6-20100515.tar.bz2, The regression disappe
--- Comment #38 from paolo dot carlini at oracle dot com 2010-05-27 17:46
---
Fixed for 4.5.1.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #37 from paolo at gcc dot gnu dot org 2010-05-27 17:45 ---
Subject: Bug 40497
Author: paolo
Date: Thu May 27 17:44:59 2010
New Revision: 159934
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159934
Log:
2010-05-27 Paolo Carlini
PR libstdc++/40497
--- Comment #36 from paolo at gcc dot gnu dot org 2010-05-27 17:37 ---
Subject: Bug 40497
Author: paolo
Date: Thu May 27 17:37:11 2010
New Revision: 159933
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159933
Log:
2010-05-27 Paolo Carlini
PR libstdc++/40497
I built gcc-4.5.0 by putting the gmp, mpc, mpfr trees in the gcc-4.5.0
directory.
Then I proceeded with a make bootstrap.
When it was done I did an ldd on all the files to make sure everything was
found. In doing this I also checked for the gmp, mpc and mpfr library usage. I
see this which I beli
--- Comment #5 from raj dot khem at gmail dot com 2010-05-27 17:27 ---
oops that was for good case. But just remove -fno-ipa-sra to make it a failing
case :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
--- Comment #4 from raj dot khem at gmail dot com 2010-05-27 17:25 ---
$
/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/bin/arm-none-linux-uclibcgnueabi-gcc
-O2 -fno-ipa-sra -S -v copypage-v4wb.i
Using built-in specs.
COLLECT_GCC=/home/kraj/work/cross/arm-none-linux-uclibcgnuea
On Linux/x86-64, revision 159912 failed to build 483.xalancbmk in
SPEC CPU 2006:
g++ -c -o DOMDocumentImpl.o -DSPEC_CPU -DNDEBUG -DAPP_NO_THREADS
-DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl
-Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
-Ixercesc/util/Transcoders/Ico
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-27 17:10 ---
redhat/gcc-4_4-branch doesn't have a -fcompare-debug failure here, though, I
see now that S::f3 doesn't end a basic block before inlining either, just
inlining happens in a different order.
So the question is now what
--- Comment #25 from bergner at gcc dot gnu dot org 2010-05-27 16:31
---
Subject: Bug 44199
Author: bergner
Date: Thu May 27 16:31:05 2010
New Revision: 159930
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159930
Log:
Backport from mainline:
2010-05-26 Jakub
--- Comment #8 from iains at gcc dot gnu dot org 2010-05-27 16:28 ---
Subject: Bug 44140
Author: iains
Date: Thu May 27 16:28:13 2010
New Revision: 159929
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159929
Log:
2010-05-27 Iain Sandoe
PR ObjC/44140
* objc.d
--- Comment #35 from paolo dot carlini at oracle dot com 2010-05-27 16:25
---
Note, plain pointers and pointers to const must be dealt with separately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-05-27
16:06 ---
Subject: Re: abi docs say that hppa-linux defaults to libgcc_s.so.2
> Dave, when did the hppa-linux so version change from 2 to 4?
> I'd like to document that, rather than just say it's always 1 or 4
Oops
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-27 15:59 ---
It is caused by revision 159879:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00935.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44294
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-05-27 15:53 ---
I saw this regression now for a long time for x86_64-w64-mingw32. Interesting
is that it appeared now but not for x86, but I assume code is broken already
for a long time. Maybe the code-change I did yesterday exposed
--- Comment #9 from jbeniston at gcc dot gnu dot org 2010-05-27 15:45
---
Subject: Bug 43726
Author: jbeniston
Date: Thu May 27 15:45:11 2010
New Revision: 159926
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159926
Log:
2010-05-27 Jon Beniston
PR 43726
* co
--- Comment #5 from rth at gcc dot gnu dot org 2010-05-27 15:44 ---
The context in which stmt_can_throw_internal is being called is different
pre- and post-inlining, so of course the answer could be different. This
is neither surprising nor a bug.
I even tend to doubt (without checking
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-27 15:37 ---
It is caused by revision 159887:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00943.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #8 from corsepiu at gcc dot gnu dot org 2010-05-27 15:15
---
FWIW: I added your patch to the RTEMS lm32-gcc-4.5.0 toolchains.
With this patch applied, the ICE during building RTEMS, I had experienced does
not occur anymore. Compiling RTEMS at -O2 also seems to work.
--
--- Comment #32 from mrs at gcc dot gnu dot org 2010-05-27 15:10 ---
I'd like to hear what Jack has to say, otherwise, fine by me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
--- Comment #7 from jbeniston at gcc dot gnu dot org 2010-05-27 15:06
---
Subject: Bug 43726
Author: jbeniston
Date: Thu May 27 15:05:48 2010
New Revision: 159922
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159922
Log:
PR 43726 * config/lm32/lm32.h: Remove definition of
GO_I
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Target Milestone|---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44294
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-05-27 14:14
---
They should pass now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-05-27 14:12
---
Subject: Bug 44230
Author: ebotcazou
Date: Thu May 27 14:11:35 2010
New Revision: 159921
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159921
Log:
PR lto/44230
* dwarf2out.c (dwarf2out_be
On Linux/x86-64, revision 159912 gave
FAIL: g++.dg/abi/bitfield12.C (test for warnings, line 3)
Revision 159867 is good.
--
Summary: [4.6 regression] FAIL: g++.dg/abi/bitfield12.C
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity:
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-27 13:53 ---
Revision 159899 is bad.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
On Linux/x86, revision 159912 gave
FAIL: gcc.c-torture/compile/20040304-1.c -O3 -fomit-frame-pointer (internal
compiler error)
FAIL: gcc.c-torture/compile/20040304-1.c -O3 -fomit-frame-pointer (test for
excess errors)
FAIL: gcc.c-torture/compile/20040304-1.c -O3 -fomit-frame-pointer
-funroll-
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-27 13:24 ---
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-05-27 13:24 ---
Subject: Bug 44284
Author: rguenth
Date: Thu May 27 13:23:45 2010
New Revision: 159920
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159920
Log:
2010-05-27 Richard Guenther
PR tree-optimization/
libgfortran/io/io.h defines the "struct st_parameter_open" with
GFC_INTEGER_4 recl_in;
However, the Fortran 95/2003/2008 standard allows any kind of integer
expression and not only the default type. As
http://gcc.gnu.org/ml/fortran/2010-05/msg00302.html shows, gfortran currently
fails if the REC
--- Comment #9 from dg dot recrutement31 at gmail dot com 2010-05-27 12:21
---
(In reply to comment #7)
> You are wrong. It is user's responsibility to choose correct constraints for
> the inline assembly, the compiler doesn't try to understand what the inline
> assembly is doing or ev
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-05-27 12:13
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-05-27 12:12
---
Recategorizing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #8 from dg dot recrutement31 at gmail dot com 2010-05-27 12:05
---
(In reply to comment #7)
> You are wrong. It is user's responsibility to choose correct constraints for
> the inline assembly, the compiler doesn't try to understand what the inline
> assembly is doing or ev
--- Comment #34 from paolo dot carlini at oracle dot com 2010-05-27 11:58
---
Ok, let's do this, seems definitely an improvement, and since affects only
C++0x and enables more people to test it, I think should go in 4_5-branch too.
By the way, if I remember correctly, Howard used to do
--- Comment #33 from redi at gcc dot gnu dot org 2010-05-27 11:54 ---
Alisdair checks for Iterator::iterator_category, which seems a very sensible
way of checking if a type wants to be recognised by iterator_traits
If iterator_category exists, then assume difference_type and the other n
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-27 11:44 ---
You are wrong. It is user's responsibility to choose correct constraints for
the inline assembly, the compiler doesn't try to understand what the inline
assembly is doing or even check its semantics, all it does is pe
--- Comment #6 from dg dot recrutement31 at gmail dot com 2010-05-27 11:18
---
(In reply to comment #4)
> All the tests demonstrate is that you have buggy constraint, in particular
> you shouldn't use "g" constraint on something you use in gs:[%2].
> "g" is any register (fine in that ca
--- Comment #20 from redi at gcc dot gnu dot org 2010-05-27 10:55 ---
I have a patch which causes an error if std::shared_ptr or std::tr1::shared_ptr
is constructed with a pointer to incomplete type and no custom deleter. I'm
not sure what the best approach is for auto_ptr. Technically
--- Comment #1 from jules at gcc dot gnu dot org 2010-05-27 10:44 ---
Created an attachment (id=20760)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20760&action=view)
The test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44291
--- Comment #32 from paolo dot carlini at oracle dot com 2010-05-27 10:51
---
You mean, in practice, we should only check that difference_type exists?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44291
Building (a cross compiler) for ARM Linux currently breaks whilst building
GLIBC. I believe this is due to the following patch (r159321):
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00766.html
>From this commit, the ARM build initially failed in a way identical to #44197
(an ICE in varpool_remov
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-27 10:40 ---
Can you paste the output of gcc when adding -v to the commandline used for
compiling copypage-v4wb.i in the failing case?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #31 from redi at gcc dot gnu dot org 2010-05-27 10:21 ---
(In reply to comment #23)
> I can't see any 100% reliable way to prevent this problem, because the
> catch-all specialisation of iterator_traits can be instantiated with
> non-iterator types.
I was under the impressio
--- Comment #5 from dg dot recrutement31 at gmail dot com 2010-05-27 10:18
---
It is the -ftree-ter option that causes this incorrect behavior. And this
option, sole:
Other optimizations options (O1, O2 and O3) together don't generate wrong
assembly code.
--
http://gcc.gnu.org/bug
--- Comment #10 from iains at gcc dot gnu dot org 2010-05-27 10:12 ---
(In reply to comment #4)
> This also occurs on hppa64-hp-hpux11.11.
>
Does the patch @ comment #6 resolve this for you?
If so, and there are no more targets reporting the issue, I will post to
gcc-patches as a propos
1 - 100 of 109 matches
Mail list logo
