--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-21 06:11 ---
FYI, this has nothing to do with the new -Wunused-but-set-* warnings, the
initialization in the definition isn't counted as set.
This is something the old -Wunused-variable warning reports/doesn't report.
--
Reported by Michael Briggs at
http://gcc.gnu.org/ml/fortran/2010-06/msg00205.html
Checking fails for a zero-initialized pointers/allocatable scalar
variable/array element passed to a dummy argument with VALUE attribute.
For the following program, it fails for -fcheck=all:
program TestSmall
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-21 07:13 ---
Seemingly the allocated/associated check
cond = fold_build2 (EQ_EXPR, boolean_type_node, parmse.expr,
fold_convert (TREE_TYPE (parmse.expr),
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-21 07:24 ---
Reminder: Same problem occurs when calling with %VAL(actual_arg).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-21 07:41 ---
+else if (sym == p-sym)
One should check that this does the right thing for
do
block
exit
end block
end do
as this should leave the DO construct and not only the BLOCK construct (to be
--
Summary: Wrong floating point on
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc
--- Comment #1 from gcc at breakpoint dot cc 2010-06-21 07:56 ---
was too early
--
gcc at breakpoint dot cc changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #19 from jamborm at gcc dot gnu dot org 2010-06-21 08:29
---
(In reply to comment #16)
(In reply to comment #15)
... I cannot reproduce the problem.
I can send you either the compiler binaries (hosts: cygwin/linux i386/linux
x64/darwin x64) or the configuration options
--- Comment #1 from jamborm at gcc dot gnu dot org 2010-06-21 08:35 ---
Honza, does this look familiar to you?
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hubicka at ucw dot cz 2010-06-21 08:44 ---
Subject: Re: [4.6 Regression] Revision 159362 caused
multiple failures on the libstdc++-v3 tests
I was fixing bug like this, where function was extern inline and had address
taken in the unit.
Inliner removed
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-21 08:55 ---
Is it not a duplicate of pr35203?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-21 09:02 ---
cf. also PR40039
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC|
I attached two testcase which is stripped down graphicsmagick code.
tc-resize2.c has a few instructions more than tc-resize.c. I belive the bug is
the same.
gcc -o tc2 -O0 -Wall -Wextra tc-resize.c
gcc -o tc2 -O2 -Wall -Wextra tc-resize.c
( ./tc0 ; echo -; ./tc2 )
.19 2484.00
.21
--- Comment #1 from gcc at breakpoint dot cc 2010-06-21 09:10 ---
Created an attachment (id=20950)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20950action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
--- Comment #2 from gcc at breakpoint dot cc 2010-06-21 09:10 ---
Created an attachment (id=20951)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20951action=view)
slightly extended tc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
--- Comment #3 from gcc at breakpoint dot cc 2010-06-21 09:11 ---
Created an attachment (id=20952)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20952action=view)
-S output of the first tc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-21 09:13 ---
(In reply to comment #3)
Is it not a duplicate of pr35203?
No. In this bug (PR 44604) one is in the caller and there one can distinguish
between address and value of a variable and the fix is relatively simple
--- Comment #2 from mikpe at it dot uu dot se 2010-06-21 09:47 ---
Seen also with 4.6 and 4.5 arm-unknown-linux-gnueabi toolchains at -O0, 4.4 and
4.3 don't trigger it.
I'm pretty sure I've seen another thumb out of range branch PR not too long
ago.
--
mikpe at it dot uu dot se
--- Comment #3 from mikpe at it dot uu dot se 2010-06-21 10:09 ---
Dupe of PR43961?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-21 10:18 ---
My first idea to fix this was to add a new field to the vtabs, let's call it
$def_init, which would be the fourth field in the vtab structure (after $hash,
$size and $extends), and would contain the default
--- Comment #4 from tjvries at xs4all dot nl 2010-06-21 10:20 ---
Created an attachment (id=20953)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20953action=view)
minimal test case of 14 lines, cut down from varasm.i
I also ran into this bug, while building gcc 4.3.5 for
--- Comment #5 from tjvries at xs4all dot nl 2010-06-21 10:32 ---
Created an attachment (id=20954)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20954action=view)
naive patch. run callbacks on hashtable entries exhaustively before deleting
Furthermore, I investigated why this
--- Comment #20 from mikpe at it dot uu dot se 2010-06-21 10:44 ---
(In reply to comment #19)
Configuration options for i386-linux and x86_64-linux hosts for both
binutils and gcc would be very much appreciated.
I don't know if you can build the c++ frontend without libstdc++, but
the following program with a basic template struct which inherit another basic
template struct does not compile:
g++ bug_template_template.cc
bug_template_template.cc: In member function âvoid UC::f()â:
bug_template_template.cc:6: error: âiâ was not declared in this scope
the output of
--- Comment #20 from janus at gcc dot gnu dot org 2010-06-21 11:01 ---
(In reply to comment #14)
The attached variation of generic_23 still does not work.
... and the dump shows why:
if (vtab$foo2.get == 0B)
{
vtab$vtype$foo2$get.getit = getit;
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-21 11:07
---
Why, before filing pretty trivial PRs don't you search a bit Bugzilla and the
docs? In this specific case, just use this-i or follow
http://gcc.gnu.org/gcc-3.4/changes.html.
In general, I would suggest
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-21 11:15 ---
I already suggested that link in Bug 44559 comment 2, please use something
other than GCC's Bugzilla to learn the differences between standard C++ and
what used to be accepted by various old compilers.
You can also
--- Comment #21 from mikpe at it dot uu dot se 2010-06-21 11:18 ---
(In reply to comment #20)
(In reply to comment #19)
Configuration options for i386-linux and x86_64-linux hosts for both
binutils and gcc would be very much appreciated.
I don't know if you can build the c++
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-21 11:18 ---
Subject: Bug 42834
Author: rguenth
Date: Mon Jun 21 11:18:26 2010
New Revision: 161067
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161067
Log:
2010-06-21 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from jan dot kratochvil at redhat dot com 2010-06-21 11:22
---
Checked-in. Forgot to place the PR # there.
r161066 | jkratoch | 2010-06-21 13:16:18 +0200 (Mon, 21 Jun 2010) | 7 lines
gcc/
* Makefile.in (POD2MAN): Provide --date from $(DATESTAMP).
As discussed in
http://gcc.gnu.org/ml/gcc-help/2010-06/msg00191.html
I am filing a PR for the following piece of C:
int abssat2 (int x)
{
unsigned int y = x;
if (x 0)
y = -y;
if (y = 0x8000)
y--;
return y;
}
Code looks fine until pass CE1 which introduces
--- Comment #1 from avr at gjlay dot de 2010-06-21 11:26 ---
Created an attachment (id=20955)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20955action=view)
Dump for .c.123t.optimized
Dump for .c.123t.optimized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
--- Comment #2 from avr at gjlay dot de 2010-06-21 11:28 ---
Created an attachment (id=20956)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20956action=view)
Dump for .c.128r.expand
Dump for .c.128r.expand
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
--- Comment #3 from avr at gjlay dot de 2010-06-21 11:28 ---
Created an attachment (id=20957)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20957action=view)
Dump for .c.141r.ce1
Dump for .c.141r.ce1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
--- Comment #3 from jan dot kratochvil at redhat dot com 2010-06-21 11:29
---
The fastjar part filed as:
https://sourceforge.net/tracker/?func=detailaid=3019015group_id=426atid=100426
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43480
--- Comment #4 from avr at gjlay dot de 2010-06-21 11:30 ---
Created an attachment (id=20958)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20958action=view)
Dump for .c.159r.combine
Dump for .c.159r.combine
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-21 11:38 ---
It is folding from the frontend that changes
if (y = 0x8000)
to
if ((int) y 0)
(see code == LT instead of code == GEU)
But the main issue is that y = -y to abs is bogus (but we can't easily tell
--- Comment #4 from jan dot kratochvil at redhat dot com 2010-06-21 11:46
---
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01999.html
Wrongly patched libjava/classpath/ChangeLog , therefore fixed it up:
r161069
The following code is reduced from a usage of boost, where one word was spelt
incorrectly. My code reducer has done some very unusual things while reducing
the size of the test case.
The following code, on my code, causes g++ to spend 1 minute outputting 16
million lines, then eventually ICEing.
--- Comment #1 from chris at bubblescope dot net 2010-06-21 11:50 ---
Created an attachment (id=20959)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20959action=view)
ICEing example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-21 11:50 ---
int __attribute__((noinline))
abssat2 (int x)
{
unsigned int y = x;
if (x 0)
y = -y;
if (y = 0x8000)
y--;
return y;
}
extern void abort (void);
int main()
{
if (abssat2 (0x8000) !=
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-21 11:56
---
Are you on x86_64-linux? I can't get it to ICE, the error messages just go on
forever...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
--- Comment #3 from chris at bubblescope dot net 2010-06-21 12:10 ---
Many apologises, the computer had a ulimit set which I had not noticed.
Yes, I also get an infinite loop rather than an ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
--- Comment #7 from avr at gjlay dot de 2010-06-21 12:27 ---
(In reply to comment #5)
It is folding from the frontend that changes
if (y = 0x8000)
to
if ((int) y 0)
(see code == LT instead of code == GEU)
But the main issue is that y = -y to abs is bogus
--- Comment #3 from ro at gcc dot gnu dot org 2010-06-21 12:35 ---
Updated summary (you list the regressed branches to fix, not the working one).
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-21
12:47 ---
Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #6 from kargl at gcc dot gnu dot org 2010-06-16 21:51 ---
(In reply to comment #5)
This makes no sense
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-21 12:49 ---
Created an attachment (id=20960)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20960action=view)
gcc46-pr44575.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
If i compile the attached testcase for picochip under -O2, i get the following
location information for variable arg0 in main.
.ascii 16#61# 16#72# 16#67# 16#30# 16#0# ; arg0\0
.initByte 0x1
.initByte 0x2a
.unalignedInitLong 0x9e
.initByte 0xc
.initByte 0x5b
.initByte 0x93
.uleb128 0x2
--- Comment #1 from hariharans at picochip dot com 2010-06-21 13:55 ---
Created an attachment (id=20961)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20961action=view)
The test sourcecode
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44610
--- Comment #3 from gcc at razorcam dot com 2010-06-21 13:55 ---
Sorry again. I am reading again the ISO c++ standard in order to avoid invalid
bug reports. It should occupy me for some time. Is there a c++ lint program
that could help you when you don't know all the tricks of the full
--- Comment #2 from hariharans at picochip dot com 2010-06-21 13:56 ---
Created an attachment (id=20962)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20962action=view)
The test assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44610
--- Comment #3 from hariharans at picochip dot com 2010-06-21 13:59 ---
In my first comment, bug 43982 should have been bug 43983
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44610
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 14:00 ---
(In reply to comment #2)
You can also use the online Comeau compiler at
http://www.comeaucomputing.com/tryitout/ to test your assumptions. If Comeau
and GCC both give an error then you can be 99.9% sure the problem
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 14:03 ---
And what is the difference between an ICE and an infinite loop? Both seem to be
internal errors of the compiler.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-21 14:16 ---
Subject: Bug 40632
Author: burnus
Date: Mon Jun 21 14:15:56 2010
New Revision: 161079
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161079
Log:
2010-06-20 Tobias Burnus bur...@net-b.de
PR
When both of these files are included - compiler cannot locate c global signbit
function.
adri...@dluadrianc:~/gcc_bug g++ signbit.cc
signbit.cc: In function 'int main(int, char**)':
signbit.cc:18:42: error: 'signbit' was not declared in this scope
#include iostream
#include math.h
#include
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-21 14:27
---
There is a *huge* difference, because first we must be able to **reproduce**
what the submitter is reporting. I'm sure that Chris, long time contributor of
the C++ library, understands this basic, scientific
--- Comment #1 from gnu at bluedreamer dot com 2010-06-21 14:31 ---
Created an attachment (id=20963)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20963action=view)
Source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
--- Comment #2 from gnu at bluedreamer dot com 2010-06-21 14:31 ---
Created an attachment (id=20964)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20964action=view)
--save-temps output .ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
--- Comment #3 from gnu at bluedreamer dot com 2010-06-21 14:32 ---
Created an attachment (id=20965)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20965action=view)
--save-temps output .s file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-21 14:32 ---
Test starts to pass between revision 161046 and revision
161055 on Linux/ia64. Does anyone know which checkin fixes
this? This that a real fix?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
--- Comment #6 from chris at bubblescope dot net 2010-06-21 14:35 ---
Of course, there is a big difference between an ICE and an infinite loop. Also,
bug which causes ICEs on one computer and not another need treating with great
care, as that suggests unpredictable memory corruption may
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-21 14:44
---
I don't think signbit is special: including *any* c* header first undefs the
names, thus if they are defined as macros in C, you don't see them anymore in
the global namespace, only in std::. If, on the other
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-21 14:44 ---
FIXED on the trunk. Related items: is_contiguous() intrinsic and DO CONCURRENT
construct.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from redi at gcc dot gnu dot org 2010-06-21 14:52 ---
But should std::signbit be available as ::signbit when math.h is included, at
least for c++0x mode?
[depr.c.headers]/2 says
Every C header, each of which has a name of the form name.h, behaves as if
each name placed
--- Comment #10 from uros at gcc dot gnu dot org 2010-06-21 14:52 ---
Subject: Bug 44546
Author: uros
Date: Mon Jun 21 14:52:07 2010
New Revision: 161085
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161085
Log:
PR target/44546
* config/i386/predicates.md
--- Comment #11 from ubizjak at gmail dot com 2010-06-21 14:53 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from burnus at gcc dot gnu dot org 2010-06-21 15:02 ---
(In reply to comment #1)
Just for reference, the difference in time between the two variants is truly
impressive. About a factor of 11 with gcc 4.4 and 8 with gcc 4.5.
I get for the example the following values,
Follow up to PR 41137.
Using the Intel compiler, the following program takes 0s for the loops (real
time: 0.005s); however, with
gfortran -fdump-tree-original -fwhole-program -flto -ffast-math -march=native
-O3 cont.f90
GCC needs 1.142s.
Expected:
* GCC also optimizes the loops away if the
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-21 15:17 ---
Created an attachment (id=20966)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20966action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44612
--- Comment #8 from burnus at gcc dot gnu dot org 2010-06-21 15:22 ---
(In reply to comment #7)
I get for the example the following values, note especially the newly added
CONTIGUOUS result:
For the test case, see attachment 20966 at PR 44612; that PR I have filled
because GCC does
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-21 15:41
---
To be honest, I have zero doubts about nullptr_t: nowhere 18.2 hints at
providing it in the global namespace, per se.
About signbit, if it's a macro in C it has to be undefined in order to
implement the cmath
The following program compiles with g++ -O3 without errors or warnings but sets
crash at the first printf. It seems to zero the stack pointer before calling
printf.
- Begin switch-crash.ii
# 1 switch-crash.cpp
# 1 built-in
# 1 command-line
# 1 switch-crash.cpp
extern C int printf (__const
--- Comment #9 from jv244 at cam dot ac dot uk 2010-06-21 15:49 ---
(In reply to comment #7)
I cannot reproduce the factor of 10 results, however.
Here this still is the case (so might depend on the precise architecture):
--- Comment #47 from Kyle dot D dot Moffett at boeing dot com 2010-06-21
15:55 ---
(In reply to comment #41)
Created an attachment (id=20877)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877action=view) [edit]
e500.h and caller-save.c patch
The ICE in #38 is due to a bug
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-21 16:02
---
To be clear: I'm against fiddling with *.h headers, basing on DR456. If you
want to do that, for each C library we support, good luck, but I'm not going to
help, sorry.
And note that appendix D talks about
--- Comment #7 from redi at gcc dot gnu dot org 2010-06-21 15:56 ---
(In reply to comment #6)
To be honest, I have zero doubts about nullptr_t: nowhere 18.2 hints at
providing it in the global namespace, per se.
[depr.c.headers]/3
The header stdlib.h assuredly provides the same
--- Comment #9 from gnu at bluedreamer dot com 2010-06-21 16:07 ---
I agree the macro and template can't co-exist, but the template could be
available as both std::signbit and ::signbit, and I think that's required by
appendix D.
Are these still relevant for c++0x? More so section 5
--- Comment #10 from redi at gcc dot gnu dot org 2010-06-21 16:12 ---
(In reply to comment #9)
Are these still relevant for c++0x? More so section 5 which says if they are
macros in C they must be macros in C++
see 26.8 [c.math] paragraph 11
--
--- Comment #11 from gnu at bluedreamer dot com 2010-06-21 16:20 ---
(In reply to comment #10)
(In reply to comment #9)
Are these still relevant for c++0x? More so section 5 which says if they are
macros in C they must be macros in C++
see 26.8 [c.math] paragraph 11
Thanks. I
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-21 16:22 ---
(In reply to comment #0)
The following program compiles with g++ -O3 without errors or warnings
Not with warnings enabled it doesn't!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613
--- Comment #14 from jakub at gcc dot gnu dot org 2010-06-21 16:27 ---
Subject: Bug 44426
Author: jakub
Date: Mon Jun 21 16:26:25 2010
New Revision: 161092
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161092
Log:
PR bootstrap/44426
* sel-sched-dump.h
--- Comment #12 from redi at gcc dot gnu dot org 2010-06-21 16:28 ---
Is there a reason you changed the component back to c++?
This is not a problem in the C++ compiler front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
--- Comment #13 from gnu at bluedreamer dot com 2010-06-21 16:31 ---
(In reply to comment #12)
Is there a reason you changed the component back to c++?
This is not a problem in the C++ compiler front-end.
I didn't mean to change anything. All I did was reply (maybe browser cached
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-21 16:34 ---
Subject: Bug 44575
Author: jakub
Date: Mon Jun 21 16:33:49 2010
New Revision: 161097
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161097
Log:
PR target/44575
* config/i386/i386.c
Based on a report by bd satish at
http://gcc.gnu.org/ml/fortran/2010-06/msg00210.html
The following program is invalid as IMPORT is missing, but gfortran still
compiles it:
Expected: An error such as:
Error: line 12: SELF is of undefined derived type CONNECTION
or
error #6457: This derived
On Linux/x86-64, I got
FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t ]*%rsp
FAIL: gcc.target/i386/sse2-vec-2.c (internal compiler error)
FAIL: gcc.target/i386/sse2-vec-2.c (test for excess errors)
with -mtune=atom.
--
Summary: -mtune=atom failed on
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-21 16:42 ---
(In reply to comment #0)
FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t
]*%rsp
This is due to -mtune=atom generates:
leaq-88(%rsp), %rsp
instead of
subq$88,
Reported by bd satish at http://gcc.gnu.org/ml/fortran/2010-06/msg00210.html
For the program, gfortran ICEs with:
f951: internal compiler error: in find_typebound_proc_uop, at
fortran/class.c:660
The failing assert is:
gcc_assert (derived-f2k_derived);
Note: The original test case (see
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-21 16:44 ---
Cf. also PR 44616 for the ICE reported at the mailing list.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-21 16:45 ---
(In reply to comment #0)
FAIL: gcc.target/i386/sse2-vec-2.c (internal compiler error)
FAIL: gcc.target/i386/sse2-vec-2.c (test for excess errors)
I got
/export/build/gnu/gcc-atom/build-x86_64-linux/gcc/xgcc
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-21 16:45 ---
(In reply to comment #1)
(In reply to comment #0)
The following program compiles with g++ -O3 without errors or warnings
Not with warnings enabled it doesn't!
???
--
manu at gcc dot gnu dot org changed:
--- Comment #3 from mark dot haines at openmarket dot com 2010-06-21 16:47
---
(In reply to comment #1)
(In reply to comment #0)
The following program compiles with g++ -O3 without errors or warnings
Not with warnings enabled it doesn't!
Sorry,
g++ -O3 -Wall -Wextra
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 16:51 ---
(In reply to comment #3)
(In reply to comment #1)
(In reply to comment #0)
The following program compiles with g++ -O3 without errors or warnings
Not with warnings enabled it doesn't!
Sorry,
g++ -O3
--- Comment #10 from burnus at gcc dot gnu dot org 2010-06-21 17:00 ---
(In reply to comment #9)
(In reply to comment #7)
I cannot reproduce the factor of 10 results, however.
Here this still is the case (so might depend on the precise architecture):
OK, I was using -fwhole-file
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-21 17:07 ---
Subject: Bug 44426
Author: jakub
Date: Mon Jun 21 17:06:48 2010
New Revision: 161100
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161100
Log:
PR bootstrap/44426
* sel-sched-dump.h
--- Comment #16 from jakub at gcc dot gnu dot org 2010-06-21 17:11 ---
Subject: Bug 44426
Author: jakub
Date: Mon Jun 21 17:10:02 2010
New Revision: 161102
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161102
Log:
PR bootstrap/44426
* sel-sched-dump.h
--- Comment #17 from jakub at gcc dot gnu dot org 2010-06-21 17:20 ---
Should be fixed now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-21 17:23 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02058.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-21 17:43 ---
What's the reason why gfc_trans_zero_assign insists that len is INTEGER_CST?
At least if it is contiguous (and not assumed size), why can't memset be used
even for non-constant sizes?
--
1 - 100 of 157 matches
Mail list logo
