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
--- 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
--- 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 #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
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 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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
#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 #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
--- 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 #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 #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
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
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
--- 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
--- 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
+++ 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 #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
--- 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: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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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
#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
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
--- 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
--- 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 #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 #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 #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 #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 #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
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 #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
--- 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 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 #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 #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
--
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 #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
*
--
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 #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
--- 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 #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 #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 #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 #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 #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
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/
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--
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
--- 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
--- 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 #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 #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 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
$ 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 #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
--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
/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
--- 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.
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 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
--- 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 #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
-
82 matches
Mail list logo
