--- Comment #11 from pinskia at gcc dot gnu dot org 2009-05-28 05:18
---
*** Bug 40280 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-28 05:18 ---
-fipa-pta does nothing for optimization yet. And it is known to be broken.
*** This bug has been marked as a duplicate of 29212 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-28 05:16 ---
Created an attachment (id=17924)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17924&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40282
ild --enable-languages=c,c++,fortran
--disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
Thread model: posix
gcc version 4.5.0 20090527 (experimental) [trunk revision 147915] (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-O2&
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-28 04:57 ---
Created an attachment (id=17923)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17923&action=view)
testcase
compile as
gfortran -v -c -O2 -funroll-loops -fprefetch-loop-arrays PR40281.f90
--
http://gcc.gnu.
/configure
--prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran
--disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
Thread model: posix
gcc version 4.5.0 20090527 (experimental) [trunk revision 147915] (GCC)
COLLECT_GCC_OPTIONS=&#x
--disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
Thread model: posix
gcc version 4.5.0 20090527 (experimental) [trunk revision 147915] (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-O0' '-fipa-pta' '-mt
--- Comment #5 from loaden at gmail dot com 2009-05-28 04:01 ---
(In reply to comment #4)
> Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables
> __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it
> does not know those functions should be
$ cat bittest_64.c
extern int puts(const char *s);
typedef unsigned long long uint64;
typedef unsigned uint32;
#define BITPOS (31)
int bittest(uint64 in)
{
if ( ((uint32)(in >> BITPOS)) & 1 ) {
puts("bit is set");
return 1;
}
return 0;
}
int main()
{
return bitt
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-28 02:39 ---
Fixed as of revision 147931.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-05-28 00:59 ---
Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables
__STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it
does not know those functions should be enabled.
--
http:/
--- Comment #3 from loaden at gmail dot com 2009-05-28 00:48 ---
(In reply to comment #2)
> This sounds like a bug in mingw's stdio.h and not GCC.
But why -std=gnu++0x is OK?
Only -std=c++0x error?
So, I think: this is not MinGW's bug, it's GCC.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-28 00:31 ---
This sounds like a bug in mingw's stdio.h and not GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
--- Comment #1 from loaden at gmail dot com 2009-05-28 00:28 ---
if use -std=c++0x, will error:
d:\ycdeng\qpdev\bin\..\lib\gcc\mingw32\4.4.1\include\c++\cwchar|159|error:
'::swprintf' has not been declared|
d:\ycdeng\qpdev\bin\..\lib\gcc\mingw32\4.4.1\include\c++\cwchar|166|error:
'::vs
--
Summary: -std=c++0x is error, but ;-std=gnu++0x
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
A number of tests in today's trunk fail with -mcpu=cortex-a8 -mfloat-abi=softfp
-mfpu=neon with spill failures for the following form of instructions.
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.c-torture/compile/2804-1.c:20:
error: this is the insn:
(insn 53 29 30 2
/home/
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-27 21:48 ---
Now that PR 40270 is fixed, can you re-check? If it is still broken, I need
more details. (I don't have access to SPEC CPU.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40271
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-27 21:40 ---
Created an attachment (id=17922)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17922&action=view)
Very initial draft patch
Some patch; now it prints:
call gen(sub)
1
Error: Type/rank mismatch
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-27 20:57 ---
Actually PRE seems to be more powerful than predictive commoning here. We
just lose one opportunity while gaining. With predictive commoning we have
8 loads and 4 stores, 11 multiplications and one division.
With P
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-05-27 20:36 ---
Fixed
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-05-27 20:32 ---
Subject: Bug 40273
Author: bkoz
Date: Wed May 27 20:32:30 2009
New Revision: 147930
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147930
Log:
2009-05-27 Benjamin Kosnik
PR libstdc++/40273
*
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-05-27 20:15 ---
TR1 uniform_real is not normalized, thus the surprising results. So, I used
variate_generator.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from burnus at gcc dot gnu dot org 2009-05-27 20:12 ---
> The patch below fixes the elemental_dependency_1 and vector_subscript_4
> failures:
Janne committed it as Rev. 147919.
Together with the fix of comment 9 and with the ABI revert-patch
http://gcc.gnu.org/ml/fortran
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--- Comment #9 from burnus at gcc dot gnu dot org 2009-05-27 19:49 ---
Subject: Bug 40270
Author: burnus
Date: Wed May 27 19:49:22 2009
New Revision: 147926
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147926
Log:
2009-05-27 Tobias Burnus
PR fortran/40270
*
Starting with PR 40039, gfortran checks the INTENT of procedures. This works -
especially with the patch for PR 36947/PR 40039 - rather well if one calls a
SPECIFIC procedure.
However, if one calls a GENERIC procedure the error message is just:
Error: There is no specific subroutine for the gen
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-27 17:56 ---
The referred patch was committed as r147712, so I presume this is now fixed.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-27 17:54 ---
(In reply to comment #1)
> Really -combine is going away and LTO is replacing it. It might be better to
> help out implementing LTO rather than wasting time on working on getting
> -combine working.
unfortunately, I lo
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-27 17:53 ---
Adding -mpc64 fixed the problem.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #23 from jv244 at cam dot ac dot uk 2009-05-27 17:51 ---
I've added a 'related' PR40275 on -combine not working for Fortran. I think
that as soon as the -fwhole-file patch is added (default or not yet ;-) there
would be interest in -combine doing the right thing.
--
http
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-27 17:48 ---
Really -combine is going away and LTO is replacing it. It might be better to
help out implementing LTO rather than wasting time on working on getting
-combine working.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
with -fwhole-file (and -fwhole-program) coming for Fortran, it would make sense
to enable -combine for Fortran as well. This should be easy as Fortran -combine
doesn't need any Fortran knowledge
gfortran -combine a.f90 b.f90 c.f90
is literally equivalent to
cat a.f90 b.f90 c.f90 > tmp.f90
gfort
--- Comment #2 from jb at gcc dot gnu dot org 2009-05-27 17:44 ---
(In reply to comment #1)
> See also: http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
>
Yes, I know; I added the note to the wiki page after I filed this bug. ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-27 17:29 ---
See also: http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-27 16:52
---
Benjamin, can you have a look? Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #8 from burnus at gcc dot gnu dot org 2009-05-27 16:43 ---
(In reply to comment #6)
> The patch in comment #5 fixes most of the issues, not all. Remaining
[...]
> parameter_unused and blockdata_3 fail because it complains that argc and argv
> are unused, even though the 003t.
--- Comment #7 from jb at gcc dot gnu dot org 2009-05-27 16:42 ---
The patch below fixes the elemental_dependency_1 and vector_subscript_4
failures:
diff --git a/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
b/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
index 3e1f67b..d7
--- Comment #6 from jb at gcc dot gnu dot org 2009-05-27 16:15 ---
The patch in comment #5 fixes most of the issues, not all. Remaining
gfortran.dg/elemental_dependency_1.f90
gfortran.dg/parameter_unused.f90
gfortran.dg/blockdata_3.f90
gfortran.dg/vector_subscript_4.f90
elemental_depen
--- Comment #1 from jan at epgmod dot phys dot tue dot nl 2009-05-27 16:05
---
I forgot to mention that the ICE disappears when I remove *either* the function
template foo, or the function bar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40274
When I compile the reduced testcase below *with -g*, I get:
$ g++ -g example_valuelist.ii
example_valuelist.ii:5: internal compiler error: in tsubst, at cp/pt.c:9289
Without -g, it is accepted. With 3.4.1, the code worked w and w/ -g.
template struct valuelist_types
{
struct null { };
templat
#include
#include
int main(int argc, char *argv[]) {
std::function f = 0;
if (f != 0) {}
return 0;
}
gcc -std=gnu++0x testcase.cpp
$ gcc -std=gnu++0x testcase.cpp
In file included from
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/fu
nctional:70,
fr
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-27 15:06 ---
> Some tests fail such as:
> /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/actual_procedure_1.f90
> Undefined symbols:
> "_proc_ext_", referenced from:
> _proc_ext_$non_lazy_ptr in ccGPjrnd.o
Ditto here:
/tmp
--- Comment #6 from seandarcy2 at gmail dot com 2009-05-27 15:10 ---
(In reply to comment #1)
> (In reply to comment #0)
>
> > cat /proc/cpuinfo:
> >
> > flags : .sse sse2 ssse3 sse4_1 ...
>
> Please post complete /proc/cpuinfo.
>
It's quad-core, so here's ju
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-27 14:54 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|---
--- Comment #4 from hjl at gcc dot gnu dot org 2009-05-27 14:54 ---
Subject: Bug 40266
Author: hjl
Date: Wed May 27 14:54:00 2009
New Revision: 147914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147914
Log:
2009-05-27 H.J. Lu
Backport from mainline:
2009-0
--- Comment #3 from hjl at gcc dot gnu dot org 2009-05-27 14:39 ---
Subject: Bug 40266
Author: hjl
Date: Wed May 27 14:39:23 2009
New Revision: 147913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147913
Log:
2009-05-27 H.J. Lu
PR target/40266
* config/i386/
--- Comment #20 from gafunchal at gmail dot com 2009-05-27 14:34 ---
For the problem reported on Comment #16, see Bug #40272.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-27 14:26 ---
Thanks for reporting it. I don't quite understand why I did not see it. Anyhow,
for
PROGRAM TEST
END PROGRAM TEST
one gets the dump:
test ()
{
(void) 0;
}
main (integer(kind=4) argc, character(kind=1) * *
--- Comment #3 from dominiq at lps dot ens dot fr 2009-05-27 14:26 ---
Some tests fail such as:
ibook-dhum] f90/bug% gfc
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/actual_procedure_1.f90
Undefined symbols:
"_proc_ext_", referenced from:
_proc_ext_$non_lazy_ptr in ccGPjrnd.o
l
--- Comment #2 from gafunchal at gmail dot com 2009-05-27 14:25 ---
(In reply to comment #1)
> You have to include a precompiled header from the toplevel source file as the
> very first thing or preferably via the -include command-line parameter.
>
I do not agree with that. The documen
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-27 14:10 ---
You have to include a precompiled header from the toplevel source file as the
very first thing or preferably via the -include command-line parameter.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-27 14:08 ---
The infinite loop in comment #5 can be seen without the -fwhole-file flag (see
comment #22 in pr40011).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-27 14:08 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01739.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #22 from dominiq at lps dot ens dot fr 2009-05-27 14:05 ---
(In reply to comment #21)
> Regarding -fwhole-file issues, see also PR 40176 comment 5 (endless loop for
> invalid program with -fwhole-file).
My post in PR 40176 #5 was ambiguous: the infinite loop does not need th
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-27 14:02 ---
I did a clean bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
+++ This bug was initially created as a clone of Bug #13675 +++
The error occurs when using a precompiled header which was compiled with -g3.
It works with -g2. The error message is "file number 2 already allocated".
This was first reported at Bug #13675 comment #16 by lukas, but it seems to me
t
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-27 13:57 ---
Did you do a clean bootstrap? I have noticed that with an incremental update,
the failure is due to a warning about something like "main() defined but not
used" for compilations with -O1 -Wall -pedantic.
I did not hav
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-27 13:29 ---
It may be a dup for PR 40270.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
On Linux/ia32 and Linux/x86-64, revision 147887 SPEC CPU 2000 failed
to build at -O2/-O3:
Error with make 'specmake build > make.out 2> make.err': check file
'/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CFP2000/171.swim/run/0001/make.err'
Error with make!
*** Error build
Revision 147883:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00860.html
caused many Fortran regressions:
http://gcc.gnu.org/ml/gcc-regression/2009-05/msg00265.html
--
Summary: [4.5 Regression] Revision 147883 caused many Fortran
regressions
Product: gcc
--- Comment #21 from burnus at gcc dot gnu dot org 2009-05-27 13:02 ---
Regarding -fwhole-file issues, see also PR 40176 comment 5 (endless loop for
invalid program with -fwhole-file).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-27 13:01 ---
I just tried this with gfortran 4.3.3 that I have on my ubuntu box. I don't get
a failure with arm-linux-gnueabi. Can you verify that this still exists with
arm-linux configurations ?
Thanks.
--
ramana at gcc dot
--- Comment #9 from hp at gcc dot gnu dot org 2009-05-27 12:40 ---
.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from hp at gcc dot gnu dot org 2009-05-27 12:40 ---
Subject: Bug 40249
Author: hp
Date: Wed May 27 12:40:09 2009
New Revision: 147907
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147907
Log:
PR middle-end/40249
* Makefile.in (CRTSTUFF_CFLAGS): Re
#include
class __declspec(dllexport) A {};
int main(int argc, char *argv[]) {
return 0;
}
$ gcc testcase.cpp
testcase.cpp:3: internal compiler error: tree check: expected function_decl,
hav
e type_decl in handle_dll_attribute, at tree.c:4172
Please submit a full bug report,
with prepro
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-05-27 11:01
---
The issue is not the temporary array but the way how CSE works. In S2 there
are simply no CSE opportunities - for example consider
t1 = a * b;
t2 = t1 * c;
t3 = a * c;
t4 = t3 * b;
The current CSE implem
--- Comment #19 from gafunchal at gmail dot com 2009-05-27 10:56 ---
(In reply to comment #18)
> Fixed in 4.4.
>
I still have this bug on 4.4.0, when using pch and -g3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-05-27 10:27
---
(In reply to comment #1)
> I don't think your patch fixes the following,
>
> print *, leadz(-1_1), leadz(-1_2), leadz(-1_4), leadz(-1_8), leadz(-1_16)
>
> which yields
>
>7 15 31
--- Comment #5 from irar at il dot ibm dot com 2009-05-27 09:59 ---
I'll test this patch tomorrow:
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 147903)
+++ tree-data-ref.c (working copy)
@@ -718,17 +725,
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-27 09:50 ---
(In reply to comment #0)
> Hello,
>
> during cross compilation of gcc, the libffi build for the target breaks with
> this error message:
>
> libtool: compile: /home/frogger/pengutronix/toolchain/libffi/build/./gcc/
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-27 08:57 ---
No idea. Invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #4 from irar at il dot ibm dot com 2009-05-27 08:43 ---
The bug is in data-refs analysis for basic blocks: two accesses that are not
adjacent (reload.c:1370) are considered as adjacent, and, therefore, get
vectorized together, causing the wrong code generation.
--
irar at
--- Comment #7 from ubizjak at gmail dot com 2009-05-27 08:42 ---
(In reply to comment #5)
> FIXED on the 4.3 branch. Thanks for reporting the problem and sorry for the
> breakage.
Not really, see PR 40268 for description and proposed patch.
Confirmed fail on cross to alpha-linux-gnu.
--- Comment #2 from ubizjak at gmail dot com 2009-05-27 08:41 ---
*** This bug has been marked as a duplicate of 40061 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #6 from ubizjak at gmail dot com 2009-05-27 08:41 ---
*** Bug 40268 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from mikpe at it dot uu dot se 2009-05-27 08:26 ---
Created an attachment (id=17921)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17921&action=view)
fix alpha compile failure in dwarf2out.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40268
gcc-4.3-20090524 fails to build for target=alpha-unknown-linux:
/tmp/gcc-4.3-20090524/gcc/dwarf2out.c: In function 'add_subscript_info':
/tmp/gcc-4.3-20090524/gcc/dwarf2out.c:11328: error: break statement not within
loop or switch
gcc-4.3.3 and earlier build fine so this is a regression.
The pro
--- Comment #1 from ubizjak at gmail dot com 2009-05-27 08:06 ---
(In reply to comment #0)
> cat /proc/cpuinfo:
>
> flags : .sse sse2 ssse3 sse4_1 ...
Please post complete /proc/cpuinfo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40266
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-27 07:44 ---
I don't think your patch fixes the following,
print *, leadz(-1_1), leadz(-1_2), leadz(-1_4), leadz(-1_8), leadz(-1_16)
which yields
7 15 31 63 127
--
http://gcc
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-27 07:29 ---
FIXED on the trunk (4.5).
Regarding libgfortranbegin.a, see PR 40267.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Follow up to PR 39178. Until that patch for GCC 4.5, gfortran generated for the
main PROGRAM only "MAIN__" and no "main"; the latter was then included by
linking libgfortran.a
With the patch (PR 39178), libgfortran.a became obsolete and is no longer
linked by gfortran. It is still present, however
82 matches
Mail list logo
