void
f (void)
{
int i;
i = 0;
i++;
}
seems like something a natural generalization of -Wunused-but-set-variable
should warn for; the value of i is only used as part of an increment of i,
so the definition and all uses of this variable could be safely removed.
For a real example of this, see
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triple
--- Comment #9 from manu at gcc dot gnu dot org 2010-06-26 00:30 ---
Then, I reopen this as an enhancement request. If you ever find/redo the patch
or someone else decides to fix this in the same way, it would a nice
improvement for usability.
--
manu at gcc dot gnu dot org changed:
--- Comment #1 from zsojka at seznam dot cz 2010-06-26 00:30 ---
Created an attachment (id=21011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21011&action=view)
reduced testcase (from gcc.dg/pr28935.c)
Command line:
$ gcc -O -funswitch-loops -fgraphite-identity -fprofile-generat
Command line:
$ gcc -O2 -fgraphite-identity -fprofile-generate testcase.c
or
$ gcc -O -funswitch-loops -fgraphite-identity -fprofile-generate testcase.c
Compiler output:
$ gcc -O -funswitch-loops -fgraphite-identity -fprofile-generate testcase.c
testcase.c: In function 'extend_options':
testcase.c
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-06-26 00:25 ---
(In reply to comment #7)
> (In reply to comment #4)
> > In the case of if, the value was "inlined" and in the case of ?:, it is
> > not. I
> > had a patch which changed the behavior but lost it when I moved compani
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-26 00:18 ---
(In reply to comment #4)
> In the case of if, the value was "inlined" and in the case of ?:, it is not.
> I
> had a patch which changed the behavior but lost it when I moved companies.
And what did your patch do exac
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-25 23:08 ---
in this variation the result is not an lvalue, so you can get away without a
definition:
(b == 0) ? (int)VAR1 : VAR2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
--- Comment #5 from redi at gcc dot gnu dot org 2010-06-25 23:05 ---
The result of "(b == 0) ? VAR1 : VAR2" is an lvalue, that's the difference
between the two cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-25 22:54 ---
Related to PR 28831 and PR 44194.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44675
--- Comment #5 from sje at cup dot hp dot com 2010-06-25 22:47 ---
I verified that this works in r160902 and fails in 160903.
In 160902 I get this (partial) psuedo-code:
IMAGPART_EXPR = 0.0;
D.1749_4 = -0.0;
IMAGPART_EXPR = D.1749_4;
D.1760_12 = IMAGPART_EXPR ;
D.1762_14 =
Compile the following code with options -march=armv7-a -mthumb -Os
typedef struct {
int buf[7];
} A;
A foo();
void hahaha(A* p)
{
*p = foo();
}
GCC generates:
hahaha:
push{r4, r5, lr}
sub sp, sp, #36
mov r5, sp
mov r4, r0
mov r0, s
--- Comment #1 from zsojka at seznam dot cz 2010-06-25 22:29 ---
Created an attachment (id=21010)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21010&action=view)
reduced testcase (from gcc.c-torture/compile/pr42559.c)
Command line:
$ gcc -O -fprofile-generate pr44674.c
--
ht
Command line:
$ gcc -O -fprofile-generate testcase.c
Compiler output:
$ gcc -O -fprofile-generate testcase.c
testcase.c: In function 'jumpfunc':
testcase.c:2:1: internal compiler error: in refs_may_alias_p_1, at
tree-ssa-alias.c:953
Please submit a full bug report,
with preprocessed source if appr
--- Comment #17 from dominiq at lps dot ens dot fr 2010-06-25 22:08 ---
With the patch in comment #13 I get the following failures:
FAIL: gfortran.dg/entry_10.f90 -O0 (internal compiler error)
...
FAIL: gfortran.dg/entry_13.f90 -O0 (internal compiler error)
...
FAIL: gfortran.dg/en
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-06-25 21:47 ---
In the case of if, the value was "inlined" and in the case of ?:, it is not. I
had a patch which changed the behavior but lost it when I moved companies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
--- Comment #3 from Hodapp87 at gmail dot com 2010-06-25 21:45 ---
(In reply to comment #1)
> You need indeed a definition.
>
Why does it require a definition in the ternary case, but not in the if/else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
config/sh/sh.c (sh_override_options): Change type to match hook.
Make manipulation of global flags dependent on main_target.
(TARGET_OVERRIDE_OPTIONS): Redefine.
gcc/po:
* EXCLUDES: Add gentargtype.cc.
Added:
branches/multi-target-20100625-branch/ChangeLog.multi-target
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2010-06-25 21:32
---
Subject: Bug 38946
Author: jvdelisle
Date: Fri Jun 25 21:32:37 2010
New Revision: 161416
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161416
Log:
2010-06-25 Jerry DeLisle
PR testsuite/38946
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-25 21:32 ---
Note if case does not need a diagnostic according to the C++ standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-25 21:31 ---
You need indeed a definition.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Reproduced on 4.6.0 and 4.1.2 as well.
Here is the header file:
class TestClass
{
public:
void testFn() const;
private:
static const int VAR1 = 9;
static const int VAR2 = 5;
};
And here is the source file including it:
#include "testclass.h"
void TestClass::testFn() const
--- Comment #8 from aoliva at gcc dot gnu dot org 2010-06-25 21:13 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from aoliva at gcc dot gnu dot org 2010-06-25 21:12 ---
Subject: Bug 44610
Author: aoliva
Date: Fri Jun 25 21:11:56 2010
New Revision: 161414
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161414
Log:
PR debug/44610
* simplify-rtx.c (delegitimize_mem_from_attrs):
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-06-25 21:11 ---
Subject: Bug 44610
Author: aoliva
Date: Fri Jun 25 21:11:32 2010
New Revision: 161413
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161413
Log:
PR debug/44610
* simplify-rtx.c (delegitimize_mem_from_attrs):
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-25 20:56 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-25 20:51 ---
Can you verify that reverting r160903 fixes the issue and attach differences
in -fdump-rtl-expand-details and assembly (and maybe point me to the
important difference?)
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
20:43 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
> --- Comment #26 from jvdelisle at gcc dot gnu dot org 2010-06-25 20:41
> ---
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2010-06-25 20:41
---
I will commit the change
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
20:34 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
Jerry,
> Try this version of the test case and see what it does. If this fails, I will
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-25 20:31 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #3 from sje at cup dot hp dot com 2010-06-25 20:21 ---
I see this failure on ia64 linux and hp-ux. The interesting thing is that it
fails when compiled with C++ but not when compiled with C. Here is a smaller
test case that shows that the imaginary part of c1 is +0 in the g
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2010-06-25 20:20
---
Created an attachment (id=21009)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21009&action=view)
Modified array_constructor_23.f to allow for some precision error
Rainer,
Try this version of the test cas
--- Comment #3 from tjvries at xs4all dot nl 2010-06-25 20:06 ---
Created an attachment (id=21008)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21008&action=view)
partially redoing the fix for bug 20612
The problem is in this piece of code in lambda_loopnest_gcc_loopnest:
...
Follow up to PR 43388.
Currently,
ALLOCATE (var(allocate-shape-spec-list), SOURCE=source-expr)
works but
ALLOCATE (var(allocate-shape-spec-list), SOURCE=array-source-expr)
does not; in the latter case the array shape should be taken from the SOURCE --
this is a new Fortran 2008 feature.
Cur
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
19:26 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
Great, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2010-06-25 19:24
---
Rainer,
I will look at the array_constructor_23.f itself and see what the front-end is
doing with it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--- Comment #2 from tjvries at xs4all dot nl 2010-06-25 19:16 ---
Created an attachment (id=21007)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21007&action=view)
slightly more minimal testcase
reproduced on trunk revision 161295
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
y_reload): Likewise.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/bt-load.c
branches/multi-target-20100625-branch/gcc/config/alpha/alpha.c
branches/multi-target-20100625-branch/gcc/config/bfin/bfin.c
branches/multi-target-
g/i386/i386.c: Likewise.
* config/i386/cygming.h: Likewise.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.in
branches/multi-target-20100625-branch/gcc/config/alpha/alpha.c
branches/multi-target-20100625-branch
--- Comment #21 from ro at gcc dot gnu dot org 2010-06-25 18:56 ---
Jerry, could you perhaps have a look at this one, too? This is the last
remaining
fortran testsuite failure on Solaris 11/x86.
Thanks.
Rainer
--
ro at gcc dot gnu dot org changed:
What|Removed
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
On Linux/x86-64, revision 161382:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01300.html
caused make-check failure in the libstdc++-v3 dir, during
the final link for testsuite_shared.so, ld spills:
relocation R_X86_64_PC32 against symbol
`__gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_po
50.c: Likewise.
* config/s390/s390.c: Likewise.
* config/rs6000/rs6000.c: Likewise.
* config/arm/arm.c: Likewise.
* config/i386/i386.c: Likewise.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.i
rs6000.c (rs6000_xcoff_strip_dollar): Use const char *
variable for const char * strchr result.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/config/rs6000/rs6000.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44637
.c (main): Output include of insn-constants.h
* Makefile.in (insn-enums.o): Depend on insn-constants.h.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.in
branches/multi-target-20100625-branch/gcc/genenums.c
--
--- Comment #14 from ro at gcc dot gnu dot org 2010-06-25 18:36 ---
Thanks, installed on mainline and 4.5 branch.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ro at gcc dot gnu dot org 2010-06-25 18:33 ---
Subject: Bug 8
Author: ro
Date: Fri Jun 25 18:33:01 2010
New Revision: 161393
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161393
Log:
2010-06-25 Jerry DeLisle
PR fortran/8
* gfortr
--- Comment #12 from ro at gcc dot gnu dot org 2010-06-25 18:32 ---
Subject: Bug 8
Author: ro
Date: Fri Jun 25 18:31:33 2010
New Revision: 161392
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161392
Log:
2010-06-25 Jerry DeLisle
PR fortran/8
* gfortr
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-25 18:23 ---
Created an attachment (id=21006)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21006&action=view)
gcc46-pr44668.patch
Updated patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-06-25 18:22
---
Please go ahead and commit, OK by me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-25 18:11 ---
Well, the compiler shouldn't ICE on invalid input.
And, delta is just a simple text tool, it depends on the user how he writes the
test script. Ideally when reducing a testcase to find an ICE the delta test
script s
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-25 17:50 ---
It is caused by revision 150519:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00199.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #14 from kargl at gcc dot gnu dot org 2010-06-25 17:14 ---
(In reply to comment #11)
>
> Well, it is invalid code - based on a valid Fortran code. If you use Delta to
> reduce a test case (cf.
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction),
> it simply removes li
../../gcc/gcc/config/arm/arm.c: In function insn_code
locate_neon_builtin_icode(int, neon_itype*):
../../gcc/gcc/config/arm/arm.c:18244: error: structure key with uninitialized
const members
--
Summary: arm port fails to build with --enable-build-with-cxx
Product: gcc
--- Comment #4 from changpeng dot fang at amd dot com 2010-06-25 17:08
---
(In reply to comment #3)
> Created an attachment (id=21001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21001&action=view) [edit]
> Potential fix for compile time regression
>
> Here is a potential fix.
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-25 16:53 ---
Created an attachment (id=21005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21005&action=view)
gcc46-pr44668.patch
Patch to fix this for typedefs. More work will be needed to handle it for
other DW_TAG_* typ
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
16:49 ---
Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
>> --- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-06-22 01:24
>> ---
>> atan2_1.f90 has failed on other p
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
16:48 ---
Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and
--traditional-cpp
It occured to me that this is only failing for me with 32-bit cc1,
i.e. i386-pc-solaris2.11, sparc-sun-solaris2.11, mi
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-25 16:43 ---
Another testcase:
[...@gnu-6 44659]$ cat extract-3.c
typedef struct
{
unsigned char c1;
unsigned char c2;
unsigned char c3;
unsigned char c4;
} foo_t;
int
foo (foo_t x)
{
return x.c2 != 0;
}
[...@gnu-6 4
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-06-25 16:31
---
Dependent GDB Bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=11757
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44668
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44669
! { dg-options "-O2 -funroll-loops" }
function foo (b)
character (len=1) :: b(4)
logical :: foo
foo = any (b .ne. (/"1","2","3","4"/))
end
results in horrible code:
movzbl .LC0(%rip), %edx
movl$1, %eax
cmpb%dl, (%rdi)
jne .L2
movzbl .LC1(
er)
<3d> DW_AT_name: v
<41> DW_AT_type: <0x33>
<45> DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst:
0)
<48> DW_AT_accessibility: 2 (protected)
DIE <0x33> should have DW_AT_accessibility.
--- Comment #8 from sje at cup dot hp dot com 2010-06-25 16:10 ---
Resolved with code change to test case.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #23 from sfilippone at uniroma2 dot it 2010-06-25 15:34 ---
(In reply to comment #22)
>
generic_23.f03 obviously works becase the binding name DOIT and the procedure
name are one and the same
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-25 15:34 ---
Indeed. Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassig
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-25 15:34 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #1 from hjl at gcc dot gnu dot org 2010-06-25 15:33 ---
Subject: Bug 44326
Author: hjl
Date: Fri Jun 25 15:33:21 2010
New Revision: 161389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161389
Log:
Don't search DEBUG_INSNs for removable zero extends.
2010-06-25 H.J
--- Comment #22 from sfilippone at uniroma2 dot it 2010-06-25 15:31 ---
(In reply to comment #21)
Ok, I bit the bullet, and fooled around with the internals to see what was
happening. I did a very naive thing of adding warnings in
resolve.c:resolve_typebound_generic_call, and I think I h
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking
Target Milestone|--- |4.5.1
Command line:
$ gfortran -O2 -fprofile-generate
or
$ gfortran -O1 -finline-small-functions -fprofile-generate
Compiler output:
$ gfortran -O1 -finline-small-functions -fprofile-generate
/mnt/svn/gcc-trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_5.f90
/mnt/svn/gcc-trunk/gcc/testsuite/gfortran
"12.5.2.12 Argument presence and restrictions on arguments not present
A dummy argument or an entity that is host associated with a dummy argument is
not present if the dummy argument
[...]
* does not have the ALLOCATABLE or POINTER attribute, and corresponds to an
actual argument that
- has t
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-25 14:23
---
Wrong Andrew.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44663
--- Comment #4 from pinskia at gmail dot com 2010-06-25 14:18 ---
Subject: Re: New: missed GXX_EXPERIMENTAL guards in ?
On Jun 25, 2010, at 3:49 AM, "pluto at agmk dot net" wrote:
> hi,
>
> the latest llvm/clang++ reports an error during parsing
> included from :
Both of these a
On Jun 25, 2010, at 3:49 AM, "pluto at agmk dot net" > wrote:
hi,
the latest llvm/clang++ reports an error during parsing
included from :
Both of these are c++0x only headers and really are only supported
when compiling in c++0x mode.
In file included from t00.cpp:1:
In file includ
--- Comment #18 from hjl dot tools at gmail dot com 2010-06-25 14:09
---
(In reply to comment #17)
> Subject: Re: [4.4/4.5/4.6 Regression] Performance
> degradation for simple fibonacci numbers calculation
>
> This is not correct, when profile is guessed we should look into th
--- Comment #1 from turutani at scphys dot kyoto-u dot ac dot jp
2010-06-25 13:54 ---
Created an attachment (id=21004)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21004&action=view)
sample code
This is a test code to generate error.
gcc-4.2.5 20090325 generates no error.
gcc-4.
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-25 13:14 ---
FIXED in trunk.
Such fixes are considered obvious, so feel free to commit patches to fix them.
Fixing changelogs and svn logs for typos falls also into the obvious category.
If you do not have write access, just send a
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-25 13:10 ---
For DW_AT_low_pc, we do this because of (DWARF4, 3.1.1:
"A DW_AT_low_pc attribute may also be specified in combination with
DW_AT_ranges to specify the default base address for use in location lists (see
Section 2.6.2)
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-25 13:09 ---
Subject: Bug 44665
Author: manu
Date: Fri Jun 25 13:09:28 2010
New Revision: 161380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161380
Log:
2010-06-25 Manuel López-Ibáñez
PR 44665
* tree
--- Comment #23 from jakub at gcc dot gnu dot org 2010-06-25 12:30 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-25 12:30 ---
Should be fixed now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status
in gcc-4.5 and trunk:
gimplify.c:
/* Return true if T is a CALL_EXPR or an expression that can be
- assignmed to a temporary. Note that this predicate should only be
+ assigned to a temporary. Note that this predicate should only be
used during gimplification.
Unaware of any current (GDB) problems from it.
echo 'class C { public: C () {} }; int main() { C c; }' | g++ -Wall -g -x c++ -
FAIL g++ (GCC) 4.4.5 20100625 (prerelease)
FAIL g++ (GCC) 4.5.1 20100625 (prerelease)
FAIL g++ (GCC) 4.6.0 20100625 (experimental) [under the test below]
C
--- Comment #22 from jakub at gcc dot gnu dot org 2010-06-25 12:11 ---
Subject: Bug 43866
Author: jakub
Date: Fri Jun 25 12:10:42 2010
New Revision: 161375
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161375
Log:
PR middle-end/43866
* tree-ssa-loop-unswitch.c (
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-25 12:07 ---
Subject: Bug 44539
Author: jakub
Date: Fri Jun 25 12:07:00 2010
New Revision: 161374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161374
Log:
PR tree-optimization/44539
* tree-cfgcleanup.c (f
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-25 11:59
---
Totally agree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44663
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-25 11:55 ---
http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.other_compilers
If the guards were there as you suggest, tr1::tuple would only be usable in
C++0x mode, where it's redundant because you have std::tuple anyway.
g++
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-25 11:49
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #2 from mikael at gcc dot gnu dot org 2010-06-25 11:29 ---
(In reply to comment #1)
> It is fixed by the patch at:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c13
>
relevant hunk:
diff --git a/decl.c b/decl.c
index aa7a266..840c32c 100644
--- a/decl.c
+++ b/decl.c
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-25 11:26 ---
This goes wrong with -O2 -funroll-loops already during tree opts. In vrp2 we
have:
b[2][1]{lb: 1 sz: 1} = D.1599_148;
b[3][1]{lb: 1 sz: 1} = D.1599_154;
D.1635_152 = 2;
D.1636_151 = &b[2][1]{lb: 1 sz: 1};
D.
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-25 11:08 ---
(In reply to comment #0)
> the latest llvm/clang++ reports an error during parsing
> included from :
>
> In file included from t00.cpp:1:
> In file included from /usr/include/c++/4.5.0/tr1/functional:39:
> /usr/includ
hi,
the latest llvm/clang++ reports an error during parsing
included from :
In file included from t00.cpp:1:
In file included from /usr/include/c++/4.5.0/tr1/functional:39:
/usr/include/c++/4.5.0/tr1/tuple:68:30: error: variadic templates are only
allowed in C++0x
template
afaics there's no #
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-06-25 10:35
---
Subject: Bug 44555
Author: rguenth
Date: Fri Jun 25 10:35:40 2010
New Revision: 161370
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161370
Log:
2010-06-25 Richard Guenther
Backport from mainl
--- Comment #13 from mikael at gcc dot gnu dot org 2010-06-25 10:33 ---
Created an attachment (id=21003)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21003&action=view)
patch against my (diry) tree
patch restoring the old equivalence list on reject_statement ()
--
http://gcc
--- Comment #12 from mikael at gcc dot gnu dot org 2010-06-25 10:32 ---
(In reply to comment #11)
> Thus, seemingly, reject_statement leaves the symtree in a half-existing state.
> It calls: gfc_undo_symbols () and undo_new_statement (). I think the former
> one only does a partial clea
--- Comment #16 from rguenther at suse dot de 2010-06-25 09:45 ---
Subject: Re: Scalarization of reductions
On Fri, 25 Jun 2010, mikael at gcc dot gnu dot org wrote:
> --- Comment #15 from mikael at gcc dot gnu dot org 2010-06-25 09:42
> ---
> Isn't there a problem with the
--- Comment #1 from mikael at gcc dot gnu dot org 2010-06-25 09:45 ---
It is fixed by the patch at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c13
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44662
--- Comment #15 from mikael at gcc dot gnu dot org 2010-06-25 09:42 ---
Isn't there a problem with the size of the patch ?
pr43829_3.diff 46.78 KB
I get here:
% du -h pr43829_3.diff
240Kpr43829_3.diff
%
At least it is not truncated (I have just checked).
--
http://gcc.gnu.o
1 - 100 of 115 matches
Mail list logo
