According to "info gcc", the 'A' constraint denotes the `a' and `d'
registers, as a pair (for instructions that return half the result in
one and half in the other). However, in reality 'A' is treated simply as
a 64-bit long integer in %rax under x86-64. For example, the following
code piece:
#inc
As reported by Joost VandeVondele, this does not compile correctly since my fix
for PR41113/7
Paul
SUBROUTINE S2(I)
INTEGER :: I(4)
write(6,*) I
IF (ANY(I.NE.(/3,5,7,9/))) CALL ABORT()
END SUBROUTINE S2
MODULE M1
TYPE T1
INTEGER, POINTER, DIMENSION(:) :: data
END TYPE T1
CONTAINS
SUBROUT
--- Comment #27 from gdr at integrable-solutions dot net 2010-02-18 04:59
---
Subject: Re: mixed complex multiplication horribly
inefficient
On Wed, Feb 17, 2010 at 3:24 PM, paolo dot carlini at oracle dot com
wrote:
> --- Comment #2 from paolo dot carlini at oracle dot
--- Comment #26 from gdr at integrable-solutions dot net 2010-02-18 04:56
---
Subject: Re: mixed complex multiplication horribly
inefficient
On Wed, Feb 17, 2010 at 4:27 PM, paolo dot carlini at oracle dot com
wrote:
> --- Comment #9 from paolo dot carlini at oracle dot
--- Comment #25 from gdr at integrable-solutions dot net 2010-02-18 04:55
---
Subject: Re: mixed complex multiplication horribly
inefficient
On Wed, Feb 17, 2010 at 4:54 PM, jan at epgmod dot phys dot tue dot nl
wrote:
> --- Comment #13 from jan at epgmod dot phys dot tu
--- Comment #16 from mmitchel at gcc dot gnu dot org 2010-02-18 04:40
---
Paolo --
I don't understand why all libstdc++ headers should not have #pragma GCC
system_header in them. Would you please explain that?
I think there's a semantic hair that we could split about whether they are
--- Comment #24 from paolo dot carlini at oracle dot com 2010-02-18 00:50
---
I'm re-opening the PR tentatively as C++
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #23 from paolo dot carlini at oracle dot com 2010-02-18 00:45
---
Now I understand the issue this way: the slow down is unavoidable if we want a
correct treatment of signed zero, and the slow down itself is due to the way
the middle-end handles mixed arithmetic. However, the
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-18 00:17 ---
This works with revision 156834.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
--- Comment #22 from paolo dot carlini at oracle dot com 2010-02-18 00:16
---
Now I'm confused: I can understand that the C++ front-end is still sometimes
incorrect about signed zeros in mixed arithmetic (these are very old issues),
but why 4.5 is slower than 4.4?!? I something differen
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-02-18 00:02
---
It was fixed by
2009-05-08 Joseph Myers
PR c/24581
* c-typeck.c (build_binary_op): Handle arithmetic between one real
and one complex operand specially.
* tree-complex.c (some_n
--- Comment #20 from paolo dot carlini at oracle dot com 2010-02-17 23:52
---
Richard, I'm pretty sure I read something about signed zeros and slowness, but
now I can't find anything in the 4.5 web page. Should we add
something to it, in particular about -fno-signed-zeros to restore pe
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-02-17 23:43
---
(In reply to comment #18)
> Then file a compiler PR, because between 4.4 and 4.5 *nothing* changed in the
> library.
4.5 has fixed tree-complex to honor signed zeros properly. 4.4 is broken
in this regard.
--
--- Comment #18 from paolo dot carlini at oracle dot com 2010-02-17 23:33
---
Then file a compiler PR, because between 4.4 and 4.5 *nothing* changed in the
library.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #17 from jan at epgmod dot phys dot tue dot nl 2010-02-17
23:28 ---
(In reply to comment #16)
> Which regression?!? Nothing changed in this code for *years*.
I use std::complex. With gcc-4.5.0 the performance of c*f is three
times worse than with gcc.4.4.x.
That regression
--- Comment #5 from zsojka at seznam dot cz 2010-02-17 23:28 ---
Created an attachment (id=19903)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19903&action=view)
different testcase, reduced
Fails at all -O1, -O2 and -O3 levels. I am not sure if it is the same problem,
but it fail
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-17 23:18 ---
This is all documented at
http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Modifiers.html
"Means (in a particular alternative) that this operand is an earlyclobber
operand, which is modified before the instruction is fin
--- Comment #16 from paolo dot carlini at oracle dot com 2010-02-17 23:18
---
Which regression?!? Nothing changed in this code for *years*.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-17 23:17
---
Eventually, we decided to re-open DR 419:
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#419
I'm not sure if it's safe to implement it at this time (together with adding
sentries to the se
--- Comment #15 from jan at epgmod dot phys dot tue dot nl 2010-02-17
23:16 ---
(In reply to comment #8)
> The patch will make results incorrect regarding the sign of zeros. Does
> the C++ standard library allow this? Thus, does it specify multiplication
> with a scalar float as compo
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-17 23:15 ---
Your inline-asm is incorrect as you don't say that result is ax (including eax
and rax) is going to be early clobbered.
The inline-asm should be written as:
asm volatile (
"movq $0x01020304050
The only way to get the following sample code run properly is to compile it
with -O3 or -Os (this code has been design to illustrate a point, it results
from thourough examination of more complex code):
//-
#include
unsigned long hehe(int v
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #15 from jason at gcc dot gnu dot org 2010-02-17 22:58 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-17 22:58 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC|jason at redh
--- Comment #4 from jason at gcc dot gnu dot org 2010-02-17 22:57 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-17 22:57 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC|jason at redh
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-17 22:57
---
If the compiler does something wrong, then we should fix the compiler, not add
hacks to the library, without fixing the plethora of uses of __complex__
outside the library. Thus, if you are sure, please double
--- Comment #13 from jan at epgmod dot phys dot tue dot nl 2010-02-17
22:54 ---
(In reply to comment #10)
> Regarding the specific semantics, Richard, there is little to say: we want the
> C99 semantics, by and large. Maybe there are some missing details, but we
> decided already that,
--- Comment #14 from jason at gcc dot gnu dot org 2010-02-17 22:52 ---
Subject: Bug 43075
Author: jason
Date: Wed Feb 17 22:51:51 2010
New Revision: 156842
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156842
Log:
PR c++/43075
* call.c (build_over_call): Don't c
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-17 22:51 ---
Subject: Bug 43069
Author: jason
Date: Wed Feb 17 22:51:43 2010
New Revision: 156841
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156841
Log:
PR c++/43069
* name-lookup.c (set_decl_namespace)
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-17 22:51 ---
Subject: Bug 43093
Author: jason
Date: Wed Feb 17 22:51:34 2010
New Revision: 156840
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156840
Log:
PR c++/43093
* cp-gimplify.c (cp_gimplify_expr) [
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-17 22:51 ---
Subject: Bug 43079
Author: jason
Date: Wed Feb 17 22:51:25 2010
New Revision: 156839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156839
Log:
PR c++/43079
* pt.c (convert_nontype_argument): C
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-17 22:40
---
Excellent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #13 from jason at gcc dot gnu dot org 2010-02-17 22:39 ---
Taking.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rguenth at
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-02-17 22:38
---
Then there is nothing to fix. Use -fno-signed-zeros if you do not care
about the difference of +0.0 and -0.0. Then you get the desired optimization
which tree-complex indeed can figure out.
--
rguenth at gcc
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-17 22:34
---
Regarding the specific semantics, Richard, there is little to say: we want the
C99 semantics, by and large. Maybe there are some missing details, but we
decided already that, when we switched the complex multi
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-17 22:27
---
To be clear, once more: the proposed change has been suggested *already* and
rejected, being something which the compiler should be perfectly able to figure
out, when legal according to the optimization options
Command line:
g++ testcase.C
- testcase.C -
namespace std {
namespace {
struct S {};
}
}
--
Tested revisions:
r156830 - crash
r156515 - crash
r156367 - crash
r156293 - OK
r153685 - OK
4.4 r156256 - OK
Valgrind output:
==12612== Command:
/mnt/svn/g
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-17 22:17 ---
The patch will make results incorrect regarding the sign of zeros. Does
the C++ standard library allow this? Thus, does it specify multiplication
with a scalar float as component-wise multiplication?
--
http:/
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-17 22:17 ---
The
@@ -24597,7 +24610,7 @@ avx_vpermilp_parallel (rtx par, enum machine_mode mode)
if (!CONST_INT_P (er))
return 0;
ei = INTVAL (er);
- if (ei >= nelt)
+ if (ei >= 2 * nelt)
ret
--- Comment #7 from jan at epgmod dot phys dot tue dot nl 2010-02-17 22:16
---
Created an attachment (id=19902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19902&action=view)
changelog entry
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-17 22:15 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Well, but float * complex isn't the same as complex *
> > complex. But the library (and also C promotion if you write
> > that in literal C) presents us with c
--- Comment #5 from jan at epgmod dot phys dot tue dot nl 2010-02-17 22:15
---
Created an attachment (id=19901)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19901&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #24 from bernds_cb1 at t-online dot de 2010-02-17 22:14 ---
Would you mind testing the attached patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #23 from bernds_cb1 at t-online dot de 2010-02-17 22:13 ---
Created an attachment (id=19900)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19900&action=view)
Possible fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #9 from burnus at gcc dot gnu dot org 2010-02-17 21:52 ---
See also http://j3-fortran.org/doc/meeting/191/10-126.txt
("Scoping unit fixes for BLOCK construct")
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39626
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-17 21:43
---
(In reply to comment #3)
> Well, but float * complex isn't the same as complex *
> complex. But the library (and also C promotion if you write
> that in literal C) presents us with complex * complex.
Where, e
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-17 21:35 ---
(insn 23 22 0 pr43107.c:13 (set (reg:V4SF 65 [ vect_perm_even.21 ])
(vec_select:V4SF (reg:V4SF 58 [ vect_perm_even.17 ])
(parallel [
(const_int 0 [0x0])
(cons
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-02-17 21:32
---
(In reply to comment #11)
> Mark, with your permission, I'm restoring P3: indeed, strictly speaking the
> failure of that specific testcase isn't a regression, because it didn't exist
> in gcc4.4.x, but I understan
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43107
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-17 21:30 ---
(In reply to comment #2)
> I don't see why you want to deal with special cases in the library instead of
> the optimizers: indeed, your *very* analysis shows that the missed
> optimization
> is happening in tree-com
--- Comment #14 from burnus at gcc dot gnu dot org 2010-02-17 21:25 ---
Created an attachment (id=19899)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19899&action=view)
Draft patch - misses modifications to nml_get_addr_expr
The current standard is weird: allocatables/pointers/au
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-17 21:24
---
I don't see why you want to deal with special cases in the library instead of
the optimizers: indeed, your *very* analysis shows that the missed optimization
is happening in tree-complex.c and improving it woul
--- Comment #1 from jan at epgmod dot phys dot tue dot nl 2010-02-17 21:05
---
Created an attachment (id=19898)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19898&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
2 test.cpp && time echo 50 | ./a.out
...
user 0m8.825s
*** gcc 4.5.0 20100217 (revision 156834):
$ g++ -O2 test.cpp && time echo 50 | ./a.out
...
user0m28.574s # Aaargh!!!
$ g++ -DUSE_MY_CMULT -O2 test.cpp && time echo 50 | ./a.out
.
--- Comment #1 from zsojka at seznam dot cz 2010-02-17 20:51 ---
Created an attachment (id=19897)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19897&action=view)
reduced testcase
gcc -O3 -mavx -c pr43107.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43107
Command line:
gcc -O3 -mavx -c testcase.c
Tested revisions:
r156830 - crash
r156745 - crash
r156293 - crash
r155966 - OK (release checking)
r155609 - OK
r154830 - OK
r153685 - OK
4.4 r156256 - OK (with checking)
4.4 r153668 - OK
Valgrind output:
==1002== Command:
/mnt/svn/gcc-trunk/binary-156830-
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-02-17 20:17
---
Tobias, reply to your RFC on fortran list. I think the negative check should
go away. Then I think we should consider an option of -fcheck-mem-alloc which
we can then make more elaborate and do numerouse useful
--- Comment #34 from jakub at gcc dot gnu dot org 2010-02-17 19:31 ---
Yeah, I completely agree with that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-02-17 18:12
---
Use -fwrapv if you want signed integer overflow being defined the way you want
it being defined. That is the whole point of that flag. The reason why GCC
acts the way it acts by default is to allow more optimizat
--- Comment #6 from sje at cup dot hp dot com 2010-02-17 18:03 ---
I tried the test with GCC 4.4.0 and 4.3.3 on IA64, in those cases the test
failed because we didn't actually pack anything and then the if test failed and
we called abort.
$ /opt/hp-gcc-4.3.3/bin/g++ -Wpacked packed1.C -
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-17 17:58
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UN
--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-17 17:57
---
Mark, with your permission, I'm restoring P3: indeed, strictly speaking the
failure of that specific testcase isn't a regression, because it didn't exist
in gcc4.4.x, but I understand it uncovered a rather sub
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
--- Comment #11 from 0xe2 dot 0x9a dot 0x9b at gmail dot com 2010-02-17
17:52 ---
(In reply to comment #10)
> Please stop reopening. 6.3.1.3 is about casts between integer types.
> Signed integer overflow is even mentioned as an example of undefined behavior
> in 3.4.3.
Well, look, ma
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143
--- Comment #10 from mmitchel at gcc dot gnu dot org 2010-02-17 17:51
---
IIUC, this is not a regression.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43093
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43079
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43066
--- Comment #3 from mmitchel at gcc dot gnu dot org 2010-02-17 17:42
---
Richard, is this fixed now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43074
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
--- Comment #3 from mmitchel at gcc dot gnu dot org 2010-02-17 17:38
---
I think we need to understand Steven's comment that ipa-struct-reorg is
"broken". This pass isn't on by default, AFAICT, so that decreases it's risk.
But, if it's broken-by-design, as opposed to has-a-few-bugs, t
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43076
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43069
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43055
--- Comment #4 from zsojka at seznam dot cz 2010-02-17 17:33 ---
r156830 still crashes for me, both at x86 and x86_64 (with -m32)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43026
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42851
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
--- Comment #5 from mmitchel at gcc dot gnu dot org 2010-02-17 17:27
---
Do we have any evidence that this is actually a regression? If this test has
never worked on IA64/HPPA, then this is not a regression. It should then be
XFAIL'd on those platforms, with this PR left open.
--
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
--- Comment #33 from joseph at codesourcery dot com 2010-02-17 17:24
---
Subject: Re: [4.4/4.5 Regression] zlib segfault in
inflate_table() compiled w/ -O -msse2 ftree-vectorize
I believe the ABI *is* that the stack must be 16-byte aligned at function
boundaries, although this is no
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
--- Comment #44 from mmitchel at gcc dot gnu dot org 2010-02-17 17:20
---
As I understand it, this is an Alpha-specific problem. It may have an
Alpha-independent solution, but only users on Alpha will be affected. So, I've
downgraded this to P5.
--
mmitchel at gcc dot gnu dot org
--- Comment #13 from mmitchel at gcc dot gnu dot org 2010-02-17 17:15
---
I reluctantly agree with Ian's comment in:
http://gcc.gnu.org/ml/gcc/2010-01/msg00332.html
that:
"I think it would be troubling if a gcc release required a very new
binutils release on a popular platform like x
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016
--- Comment #3 from uramakrishna at gmail dot com 2010-02-17 17:13 ---
Is this bug still around (r156830)? I have a 64 bit linux machine and it seems
to be fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43026
--- Comment #32 from hjl dot tools at gmail dot com 2010-02-17 17:09
---
(In reply to comment #31)
> I still have no idea what this PR is about. Someone needs to make a clear
> statement of what they believe the ABI to be. There are some simple
> questions:
>
> * Can we expect that
--- Comment #1 from neven at hitt dot nl 2010-02-17 17:07 ---
Created an attachment (id=19896)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19896&action=view)
concatenated Ada source files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43106
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43097
The attached Ada program outputs "RADPR RADSSR" when compiled as:
gnatmake -Wall -O0 -v test_main -o ada_test
but generates "raised CONSTRAINT_ERROR : radar_types.adb:11 range check failed"
when compiled as:
gnatmake -Wall -O1 -v test_main -o ada_test
OS is OpenSuse 11.2.
gcc -v:
Using built-in s
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43096
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
--- Comment #1 from mmitchel at gcc dot gnu dot org 2010-02-17 16:58
---
I take the P1 setting back; I failed to recognize the use of
-fgraphite-identity. As long as that's not a default setting, I don't think
problems there should be P1.
--
mmitchel at gcc dot gnu dot org changed:
1 - 100 of 145 matches
Mail list logo
