--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-01-19 08:44 ---
Mine (testing a patch)
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jakub at gcc dot gnu dot org 2010-01-19 09:03 ---
This patch seems to fix issues with (most of) KDE testcases, but there are
still some testcases where gcc spends very long time in var-tracking (usually
generated huge routines where simply too many VALUEs are
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-19 09:14 ---
Please retry with current trunk, there have been many fixes recently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42282
--- Comment #9 from FBergemann at web dot de 2010-01-19 09:25 ---
change Reported against to 3.4.6.
Because 3.4.6 is the last version of the 3.4.x series.
I tested with that as well, but it fails, too.
And i would have withdrawn this issue, if it would have worked for 3.4.6.
This
I am trying to build mainline GCC (revision 156033) configured
with -enable-build-with-cxx .
I get the following error during bootstrap:
make[3]: Entering directory `/user/inria/fsf/bld-gcc-cxx2/libcpp'
g++ -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include -g -W
I'm learning C, so it's possible there's a reason for this, but I've made a lot
of tests to find out that in my source code a variable (called q_num) changes
from 3 to 0 just because of a scanf().
I tested the code with these lines:
...
printf(1. %d\n,q_num);
p=scanf(%d,idade);
printf(2.
--- Comment #2 from adriyetichaves at gmail dot com 2010-01-19 10:04
---
Same code compiled in other compiler (Turbo C++) works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42799
FAIL: gcc (GCC) 4.5.0 20100119 (experimental)
PASS: gcc (GCC) 4.4.3 20100119 (prerelease)
PASS: gcc-4.4.2-20.fc12.x86_64 (Fedora 12)
---
gcc -c -o vla.o vla.c -Wall -g
--- Comment #10 from FBergemann at web dot de 2010-01-19 10:06 ---
if i compile the sample on hp-ux ia64 for 32 bits, it's generating a coredump:
(gdb) r
Starting program: /nfs/uh01/frank/TESTX/sample
test is 'pDeleteHlrSubscriberIn class_id=0 tracking_level=0 version=0'
Program
FAIL: gcc (GCC) 4.4.3 20100119 (prerelease)
FAIL: gcc-4.4.2-20.fc12.x86_64 (Fedora 12)
SKIP: gcc (GCC) 4.5.0 20100119 (experimental) - N/A - blocked by PR debug/42800
--
Currently the type of a VLA (Variable Length Array
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-19 10:21 ---
This is undefined behavior, scanf is writing int value into an unsigned short
variable, so it of course can overwrite whatever happens to be adjacent to that
var on the stack.
Use %hd instead of %d to write to
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|VLA DW_AT_upper_bound is no |[4.5 Regression] VLA
|longer emitted
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-01-19 10:26
---
I wonder why the C++ frontend emits overload resolution errors from emitting
debug information like seen in the duplicate PR42797.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-19 10:27 ---
*** This bug has been marked as a duplicate of 42336 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-01-19 10:27
---
*** Bug 42797 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-19 10:29 ---
Without preprocessed source of the testcase nobody is going to look at this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-19 10:39
---
*** Bug 42794 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-19 10:39 ---
The issue is (verified with 4.4.0):
# VUSE SMT.11_18
D.1626_14 = Decode_1(D)-ActualSize;
...
# complete_24 = VDEF complete_17
# SMT.13_25 = VDEF SMT.13_20
*BufLen_3 = D.1619_8;
thus the alias information
--- Comment #27 from hubicka at ucw dot cz 2010-01-19 10:48 ---
Subject: Re: [4.5 regression] ICE in
function_and_variable_visibility with static common vars.
The problem is that the ICE-on-valid occurs while building the Ada RTS, and
that is a bootstrap issue for Ada (what
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-01-19 10:57
---
Maybe properly limiting DW_AT_location even in -O0 -g mode would be the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42801
--- Comment #5 from singler at gcc dot gnu dot org 2010-01-19 11:18 ---
Subject: Bug 42712
Author: singler
Date: Tue Jan 19 11:18:03 2010
New Revision: 156036
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156036
Log:
2010-01-19 Johannes Singler sing...@kit.edu
PR
double bar(double x, double y)
{
double tmp = 0.1234 * y;
return ((x + tmp) * (x - tmp));
}
GCC should use multiply-add and multiply-sub when that is cheaper than
one multiplication and two additions.
With -mfma4 on x86_64 instead of
vmulsd .LC0(%rip), %xmm1, %xmm1
vaddsd
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|42802 |
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-19 12:08
---
Confirmed fixed, thanks!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #28 from simon at pushface dot org 2010-01-19 12:36 ---
(In reply to comment #27)
I am sorry for spreading confusion wasting time, I had a different
PR-resolution process in mind.
Now that the reduced patch is committed to mainline, there is no longer an ICE
during build
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-19 12:38 ---
Subject: Bug 42728
Author: jakub
Date: Tue Jan 19 12:38:25 2010
New Revision: 156037
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156037
Log:
PR debug/42728
* fwprop.c (all_uses_available_at):
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-19 12:39 ---
Subject: Bug 42719
Author: jakub
Date: Tue Jan 19 12:39:42 2010
New Revision: 156038
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156038
Log:
PR tree-optimization/42719
* tree-outof-ssa.c
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-19 12:41 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-19 12:42 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-19 13:08 ---
Playing with patterns like
(define_insn *fma4_fmaddmode4_1
[(set (match_operand:SSEMODEF4 0 register_operand =x,x)
(plus:SSEMODEF4
(mult:SSEMODEF4
(match_operand:SSEMODEF4 2
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-19 13:20 ---
Patch posted at:
http://gcc.gnu.org/ml/fortran/2010-01/msg00101.html
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Compilation hangs at the following file for several hours (then I stopped it).
According to http://www.rawtherapee.com/forum/viewtopic.php?t=1719 this seems
to be a regression in gcc 4.4 which is present on multiple GNU/Linux
distributions, all 32bit. 64bit doesn't seem to be affected.
Another
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-19 13:45 ---
Subject: Bug 42545
Author: janus
Date: Tue Jan 19 13:45:07 2010
New Revision: 156040
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156040
Log:
gcc/fortran/
2010-01-19 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #1 from l dot jirkovsky at gmail dot com 2010-01-19 13:45
---
Created an attachment (id=19654)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19654action=view)
Compilation hangs on this file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42803
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-19 14:00 ---
Confirmed.
Backtrace:
#0 0x00e50900 in tree_operand_length (node=0x72201d58)
at /space/rguenther/src/svn/trunk/gcc/tree.h:5340
#1 0x00e5c983 in initializer_constant_valid_p
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-19 14:00 ---
Fixed with r156040. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
A segmentation violation occurs in gfc_trans_runtime_error_vararg (trans.c:393)
when compiling with -fcheck=bounds and an expression like the following is
encountered:
call array_of_derived_type(index)%type_bound_proc(args...)
(With svn revision 156036)
--
Summary: ICE with
--- Comment #1 from ian_harvey at bigpond dot com 2010-01-19 14:06 ---
Created an attachment (id=19655)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19655action=view)
Source code that demonstrates the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-19 14:07 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ramana at gcc dot gnu dot org 2010-01-19 14:21 ---
Subject: Bug 38697
Author: ramana
Date: Tue Jan 19 14:21:14 2010
New Revision: 156042
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156042
Log:
Fix target/38697
2010-01-19 Ramana Radhakrishnan
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-19 14:24 ---
Caused by r144394
2009-02-23 Jason Merrill ja...@redhat.com
PR c++/38880
* varasm.c (initializer_constant_valid_p) [PLUS_EXPR]: Check
narrowing_initializer_constant_valid_p.
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr42248.c -w
-O1 -lm -o /home/dave/gnu/gcc/objdir/gcc/testsuite/gcc/pr42248.x1
(timeo
ut = 300)
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-19 15:18 ---
Can you check if the patch that introduced the testcase is responsible for the
failure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42805
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-01-19 15:31 ---
This patch:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01019.html
gets past this failure, and has also been successfully
bootstrapped regtested without --enable-build-with-cxx bootstrap on
i686-pc-linux-gnu
--
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-19
15:38 ---
Subject: Re: FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and
above
Can you check if the patch that introduced the testcase is responsible for the
failure?
Will do.
Dave
--
--- Comment #14 from dodji at gcc dot gnu dot org 2010-01-19 15:39 ---
Created an attachment (id=19656)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19656action=view)
candidate fix
I am testing this fix.
I think one residual issue that was left to fix in the revert patch was that
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-19 15:41 ---
Confirm. Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0053e011 in gfc_trans_runtime_error_vararg (error=value optimized
out, where=0x13ea980,
msgid=0x13ea3f0 Index '%ld' of dimension
--- Comment #1 from hjl dot tools at gmail dot com 2010-01-19 15:43 ---
It is caused by Expand from SSA:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from matz at gcc dot gnu dot org 2010-01-19 15:49 ---
What's the brokenness? The missing upper bound in the subrange type?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-19 15:52 ---
(In reply to comment #2)
What's the brokenness? The missing upper bound in the subrange type?
It blocks PR 42801.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-19 15:56 ---
The problem is that e(xpr)-where-lb == NULL. The flow is:
gfc_conv_procedure_call - gfc_conv_derived_to_class - gfc_conv_expr_reference
- gfc_conv_variable etc.
I wonder whether the problem is that the CLASS struct
--- Comment #16 from matz at gcc dot gnu dot org 2010-01-19 16:06 ---
Subject: Bug 41783
Author: matz
Date: Tue Jan 19 16:05:57 2010
New Revision: 156043
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156043
Log:
PR tree-optimization/41783
* tree-data-ref.c
--- Comment #34 from rguenth at gcc dot gnu dot org 2010-01-19 16:17
---
Re-confirmed. -fsched-pressure -fschedule-insns helps recover some of the
performance, ivopts adds its share as well as re-association.
Scheduling is probably limited by ivopts producing TMRs and w/o ivopts
by
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-19 16:20 ---
Fixed by
Author: matz
Date: Tue Jan 19 16:05:57 2010
New Revision: 156043
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156043
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-19 16:29 ---
Mine anyway.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2010-01-19 16:35 ---
If one replaces the TBP call by a direct call to the subroutine, like this:
call a_proc(arr(i),ierr)
then the ICE goes away (of course a_proc must be public for this to work). This
means it is not a problem of the
--- Comment #5 from janus at gcc dot gnu dot org 2010-01-19 16:39 ---
Another observation: If I remove the CLASS argument, give the procedure the
NOPASS attribute and call it like this, the ICE also goes away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-19 16:57 ---
Created an attachment (id=19657)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19657action=view)
gcc45-pr42803.patch
Alternative patch, which should avoid exponential behavior in all cases (even
when there are
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-19 17:02 ---
Created an attachment (id=19658)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19658action=view)
tentative fix
Patch for testing, should work for all cases (fingers crossing).
--
--- Comment #6 from janus at gcc dot gnu dot org 2010-01-19 17:11 ---
(In reply to comment #3)
The problem is that e(xpr)-where-lb == NULL.
Exactly. What's important is that the expression e here is the passed-object
argument.
Now the problem really is that when we construct this
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-19 17:19 ---
Yes. This is -O0, so we definitely should ensure that the debug info has the
correct upper bound.
Look at gimplify_type_sizes which for -O0 clears DECL_IGNORED_P on the
temporaries to make sure they are not optimized
--- Comment #7 from janus at gcc dot gnu dot org 2010-01-19 17:24 ---
We probably have the same trouble with procedure pointer components, which can
also have passed-object arguments.
However, when trying to construct an analogous PPC test case, I came across
another bug. Here is the
--- Comment #3 from ubizjak at gmail dot com 2010-01-19 17:30 ---
(In reply to comment #2)
Can't edit original post. Email client added line breaks where they shouldn't
be. Please use patch attached to issue, and not one orginally submitted in
description.
Please post the patch
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-19 17:46 ---
Here is the fix for PPCs, curing both the must be scalar error from the last
comment as well as the missing-locus ICE (which, as expected, did appear also
for PPCs after the other thing was fixed):
Index:
Command line:
g++ -O1 -fcompare-debug -c testcase.cpp
Tested revisions:
r156038 - crash
r155966 - crash
r155945 - crash (x86)
r155938 - crash
r155902 - OK
r155844 - OK (x86)
r155833 - OK
r155363 - OK
r153685 - OK
Behaviour is the same for unreduced testcase (at -O1)
Output:
$
--- Comment #1 from zsojka at seznam dot cz 2010-01-19 17:53 ---
Created an attachment (id=19659)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19659action=view)
reduced testcase
Command line:
g++ -O1 -fcompare-debug -c pr42806.cpp
--
Gnu compiler (latest microchip version with full optimizations) makes the
following error.
unsigned long value;
value=2501*1600;
the result should be 0x3D0F40 instead it is 0x0F40.
The problem is this. The compiler computed the constant 2501*1600 as an
integer, even though it had
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-19 18:13 ---
This is correct for C/C++. 2501*1600 is an integer. If you want an unsigned
long, use ((unsigned long)2501)*1600 or 2501ul*1600ul.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pault at gcc dot gnu dot org 2010-01-19 19:47 ---
Subject: Bug 42783
Author: pault
Date: Tue Jan 19 19:46:59 2010
New Revision: 156046
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156046
Log:
2010-01-19 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #7 from pault at gcc dot gnu dot org 2010-01-19 19:47 ---
Subject: Bug 42772
Author: pault
Date: Tue Jan 19 19:46:59 2010
New Revision: 156046
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156046
Log:
2010-01-19 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #4 from pault at gcc dot gnu dot org 2010-01-19 19:48 ---
Fixed on trunk.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2010-01-19 19:49 ---
I believe that the commit in comment #7 fixes it. If not, please get in touch.
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from l dot jirkovsky at gmail dot com 2010-01-19 19:56
---
I've recompiled gcc 4.5 snapshot with the patch included. The file
bilateral2.ii compiles perfectly.
Thank you, you're doing a great job.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42803
--- Comment #21 from jason at gcc dot gnu dot org 2010-01-19 20:10 ---
42797 doesn't seem like a duplicate; it's another issue with
count_non_default_template_args, but the issue there is that we are triggering
instantiation when we shouldn't. But I'm not sure yet why -fno-ipa-sra
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-19
20:51 ---
Subject: Re: FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and
above
Can you check if the patch that introduced the testcase is responsible for the
failure?
It's not.
Dave
--
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-19
21:00 ---
Subject: Re: FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and
above
Can you check if the patch that introduced the testcase is responsible for
the
failure?
It's not.
Testcase
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-19 22:21 ---
Subject: Bug 42804
Author: janus
Date: Tue Jan 19 22:21:35 2010
New Revision: 156049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156049
Log:
gcc/fortran/
2010-01-19 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-19 22:23 ---
Fixed with r156049. Closing.
Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
There is a lot of noise generated with -Wconversion:
program gfcbug100
implicit none
integer, parameter :: sp = kind (1.0)
integer, parameter :: dp = kind (1.d0)
real(sp) :: s
real(dp) :: d
complex(dp) :: z
s = 0 ! Warn if you are very picky
d = s ! No
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-19 22:42 ---
Well constants don't really need to be warned about if it does fit. But really
an generic integer(4) to real(4) should be warned about really as not all
integer(4) fit into real(4).
--
An enumeration with sequentially-assigned values is used as an index of a for
loop. The loop operates properly at optimization levels -O0 and -O1. At level
-O2 the optimizer optimizes out the test for the exit condition and the loop
never exits.
I'll be attaching the *.i file, but below is the
--- Comment #1 from tony3 at GarlandConsulting dot us 2010-01-19 22:53
---
Created an attachment (id=19661)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19661action=view)
Preprocessed version of the test.cpp file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
--- Comment #2 from tony3 at GarlandConsulting dot us 2010-01-19 22:53
---
Created an attachment (id=19662)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19662action=view)
Compiler output ready to feed to assembler--the problem can be seen here.
--
--- Comment #3 from tony3 at GarlandConsulting dot us 2010-01-19 22:54
---
Here is the compiler information:
g++ -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info
--- Comment #4 from tony3 at GarlandConsulting dot us 2010-01-19 22:56
---
Created an attachment (id=19663)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19663action=view)
ARM gcc 4.4.1 output at assembler input level.
This shows the same problem in gcc for the ARM.
--
--- Comment #5 from tony3 at GarlandConsulting dot us 2010-01-19 22:58
---
Created an attachment (id=19664)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19664action=view)
Assembler input which works correctly compiled at -O1
In this sample, the exit condition is properly tested
--- Comment #2 from anlauf at gmx dot de 2010-01-19 22:59 ---
(In reply to comment #1)
Well constants don't really need to be warned about if it does fit. But
really
an generic integer(4) to real(4) should be warned about really as not all
integer(4) fit into real(4).
That's
--- Comment #6 from tony3 at GarlandConsulting dot us 2010-01-19 23:05
---
There is a related bug here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36170
But unlike that bug which uses an out-of-range enum value, this case does not.
We are testing 'value = max_valid_enum_value'. So
configuration
./configure --prefix=/usr --disable-win32-registry --enable-threads=posix
--enable-languages=c,c++,java --with-win32-nlsapi=unicode --enable-tls
--disable-bootstrap --enable-shared --enable-interpreter
--disable-sjlj-exceptions --enable-load-library
testcase
public class java
{
--- Comment #7 from jason at gcc dot gnu dot org 2010-01-19 23:30 ---
The problem here is that the attribute parsing code sees that the argument is
an identifier and treats it as a plain name rather than an expression; this is
to support attributes like mode which take an identifier as
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-19 23:56 ---
This testcase also uses out of range enum value, so has undefined behavior as
well. For ENUM_VALUE_LAST which is a power of 2 minus 1 the for loop condition
still lets the body to be executed, then id =
--- Comment #8 from tony3 at GarlandConsulting dot us 2010-01-20 00:18
---
I see what you mean. I was looking at the wrong side of the = and not
thinking about the reality that it would have to exceed the last valid value.
Pretty obvious once you point it out.
So now my question is
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-20 01:36
---
For now at least I'll simply add what Janis suggested and then use it to
clean-up the long standing XPASS of c99_classification_macros_c.cc (few people
complained about it)
--
paolo dot carlini at oracle
--- Comment #1 from jojelino at gmail dot com 2010-01-20 05:02 ---
linking executables with -Wl,--whole-archive libgcj-noncore.la libgcj.la
-Wl,--no-whole-archive solves this problem. excepts that it creates fatty
import symbol table approx. (28 megabyte). is there any workaround
--- Comment #8 from jason at gcc dot gnu dot org 2010-01-20 05:51 ---
Created an attachment (id=19665)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19665action=view)
patch
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
I see this error during bootstrap:
/user/inria/fsf/bld-gcc-cxx8/./prev-gcc/g++
-B/user/inria/fsf/bld-gcc-cxx8/./prev-gcc/
-B/user/inria/cxx/i686-pc-linux-gnu/bin/ -nostdinc++
-I/user/inria/fsf/bld-gcc-cxx8/prev-i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-01-20 07:52 ---
Subject: Bug 42812
Author: amylaar
Date: Wed Jan 20 07:52:18 2010
New Revision: 156062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156062
Log:
PR bootstrap/42812
* gfortran.h (struct
99 matches
Mail list logo
