[Bug middle-end/38932] New: ICE in set_value_range, at tree-vrp.c:398
>From PR38572, but unrelated to it:
void f (long long int p)
{
int x;
static unsigned char g;
long long int min = -9223372036854775807LL - 1;
g = 1;
x = (signed char) (g | 249) / 4;
if (p >= min - (long long int) x)
p = 1;
if (p)
abort ();
}
gives
small.c: In function 'f':
small.c:3: internal compiler error: in set_value_range, at tree-vrp.c:398
Note that after FRE the code becomes the simpler
void f (long long int p)
{
long long int min = 9223372036854775807LL + 2; /*0x7fff */
if (min <= p)
p = 1;
if (p)
abort ();
}
but this does not ICE because in this testcase the "min <= p" is changed to "p
!= min - 1" by the first CCP pass, so this is also a missed folding in FRE.
I'm looking at the VRP failure though.
--
Summary: ICE in set_value_range, at tree-vrp.c:398
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #26 from bonzini at gnu dot org 2009-01-22 08:08 --- This is a separate bug. The reduced testcase does not have a single && or || so it probably existed also before my patch. It is now bug 38932. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-22 08:08:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #1 from bonzini at gnu dot org 2009-01-22 08:09 --- Can anyone check if this is a regression, and if so from which version? -- bonzini at gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #2 from bonzini at gnu dot org 2009-01-22 08:17 --- Actually, there is no overflow in -9223372036854775807LL - 1 so this is a third bug. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #3 from bonzini at gnu dot org 2009-01-22 08:23 --- ah no there's no overflow bit on min -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug target/38931] [4.4 Regression] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
--- Comment #3 from ubizjak at gmail dot com 2009-01-22 08:25 --- Looking into it. -- ubizjak at gmail dot com changed: What|Removed |Added CC|uros at gcc dot gnu dot org | AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-22 01:30:40 |2009-01-22 08:25:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00 --- In PRE there is a fold_convert_const_int_from_int call simplifying "(signed char) 249" to -7, but setting the TREE_OVERFLOW flag in the meanwhile. I don't think it makes sense to set the overflow flag on a NOP: * `The result of, or the signal raised by, converting an integer to a signed integer type when the value cannot be represented in an object of that type (C90 6.2.1.2, C99 6.3.1.3).' For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised. (Integers implementation, from the gcc manual). -- bonzini at gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
Re: [Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
Sent from my iPhone On Jan 22, 2009, at 1:00 AM, "bonzini at gnu dot org" > wrote: --- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00 --- In PRE there is a fold_convert_const_int_from_int call simplifying "(signed char) 249" to -7, but setting the TREE_OVERFLOW flag in the meanwhile. I don't think it makes sense to set the overflow flag on a NOP: Yes but changing that right now opens lots of bags of worms. It has been tried before. The simple way to fix this is in pre unset TREE_OVERFLOW because at this point in the IR it does not matter. I hope someone would change vrp to do the correct thing but I guess that won't happen any time soon. Thanks, Andrew Pinski * `The result of, or the signal raised by, converting an integer to a signed integer type when the value cannot be represented in an object of that type (C90 6.2.1.2, C99 6.3.1.3).' For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised. (Integers implementation, from the gcc manual). -- bonzini at gnu dot org changed: What|Removed |Added --- --- -- CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #5 from pinskia at gmail dot com 2009-01-22 09:17 --- Subject: Re: ICE in set_value_range, at tree-vrp.c:398 Sent from my iPhone On Jan 22, 2009, at 1:00 AM, "bonzini at gnu dot org" wrote: > > > --- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00 > --- > In PRE there is a fold_convert_const_int_from_int call simplifying > "(signed > char) 249" to -7, but setting the TREE_OVERFLOW flag in the > meanwhile. I > don't think it makes sense to set the overflow flag on a NOP: Yes but changing that right now opens lots of bags of worms. It has been tried before. The simple way to fix this is in pre unset TREE_OVERFLOW because at this point in the IR it does not matter. I hope someone would change vrp to do the correct thing but I guess that won't happen any time soon. Thanks, Andrew Pinski > > > * `The result of, or the signal raised by, converting an integer > to a > signed integer type when the value cannot be represented in an > object of that type (C90 6.2.1.2, C99 6.3.1.3).' > > For conversion to a type of width N, the value is reduced modulo > 2^N to be within range of the type; no signal is raised. > > (Integers implementation, from the gcc manual). > > > -- > > bonzini at gnu dot org changed: > > What|Removed |Added > --- > --- > -- > CC||rguenth at gcc dot > gnu dot > ||org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #6 from rguenther at suse dot de 2009-01-22 09:29 --- Subject: Re: ICE in set_value_range, at tree-vrp.c:398 On Thu, 22 Jan 2009, bonzini at gnu dot org wrote: > --- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00 --- > In PRE there is a fold_convert_const_int_from_int call simplifying "(signed > char) 249" to -7, but setting the TREE_OVERFLOW flag in the meanwhile. I > don't think it makes sense to set the overflow flag on a NOP: > >* `The result of, or the signal raised by, converting an integer to a > signed integer type when the value cannot be represented in an > object of that type (C90 6.2.1.2, C99 6.3.1.3).' > > For conversion to a type of width N, the value is reduced modulo > 2^N to be within range of the type; no signal is raised. > > (Integers implementation, from the gcc manual). Correct. PRE should make sure to clear TREE_OVERFLOW, like CCP for example does. A more general solution unfortunately opens too many cans of worms. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug c/35634] [4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-01-22 10:03 --- I am going to make this a P1 for 4.5, but it's too late for 4.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major Known to fail|4.1.2 4.2.3 4.3.0 |4.1.2 4.2.3 4.3.0 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug target/38931] [4.4 Regression] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
--- Comment #4 from ubizjak at gmail dot com 2009-01-22 10:32 --- Created an attachment (id=17160) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17160&action=view) Patch to fix insn attributes Patch in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
[Bug fortran/38439] I/O PD edit descriptor inconsistency
--- Comment #5 from burnus at gcc dot gnu dot org 2009-01-22 10:53 ---
> Thus: '(1pD24.15)' is valid
Fully agreed - that version is valid and accepted with gfortran, ifort, NAG f95
etc.
> While: '(1pD24.15e4)' is invalid
It is, but as written sunf95/openf95/gfortran 4.1 accept it at compile time and
gfortran 4.x and g95 accept it at run time and it generates the different size
of the exponent ("D+0" for pD24.15e1 and "D+0" for pD24.15e5). Still, there
is the question whether one wants to allow it (at compile time) with some
options, reject it at run-time, or keep the status quo.
* * *
The other question is: Why is the location marker ("1") in the error message
(see comment 2) way off? If one tries something else, the location fits much
better, e.g.
WRITE (*,'(g0.3.4)') 1.0d0
1
Another error question is: '(1pd0.3)'
ifort, g95, and NAG f95 claim: "Error: Zero field width invalid for D edit
descriptor"; gfortran accepts it but prints "*" while openf95 accepts it an
prints "1.0E+000". I think gfortran should compile-time-diagnose it. (When
passing it as string, ifort and g95 print "1.000D+00" and f95 prints ""; I
think printing '**' is also ok.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439
[Bug middle-end/38932] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #7 from bonzini at gnu dot org 2009-01-22 11:04 --- mine. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Severity|normal |critical Status|NEW |ASSIGNED Known to fail||4.4.0 Known to work||4.2.3 Priority|P3 |P1 Last reconfirmed|2009-01-22 08:08:36 |2009-01-22 11:04:08 date|| Summary|ICE in set_value_range, at |[4.4 Regression] ICE in |tree-vrp.c:398 |set_value_range, at tree- ||vrp.c:398 Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug c++/38933] New: [4.3 regression] fails to build valid code
the attached test case builds with 4.3.2 and 4.4.0, but not with 4.2.4 and 4.3.3. $ g++ -c SmartSearcher.ii In file included from SmartSearcher.cc:23: Printer.h: In member function 'CollPrinter& CollPrinter::operator=(const std::pair<_T1, _T2>&)': Printer.h:103: error: expected primary-expression before ':' token -- Summary: [4.3 regression] fails to build valid code Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
[Bug c++/38933] [4.3 regression] fails to build valid code
--- Comment #1 from doko at ubuntu dot com 2009-01-22 11:57 --- Created an attachment (id=17161) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17161&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
[Bug middle-end/38932] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #8 from bonzini at gnu dot org 2009-01-22 12:10 ---
Fixing FRE still causes an ICE for this:
/* { dg-do compile } */
/* { dg-options "-O2 --std=gnu99" } */
/* This variable needed only to exercise FRE instead of CCP. */
unsigned char g;
extern void abort();
void f (long long int p)
{
g = 255;
/* { dg-warning "constant is" "" { target *-*-* } 14 } */
/* { dg-warning "overflow" "" { target *-*-* } 14 } */
if (p >= -9223372036854775808LL - (signed char) g)
p = 1;
if (p)
abort ();
}
Should I create a separate bug and submit what I have?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38857] [4.4 Regression] ICE in selective scheduler
--- Comment #7 from amonakov at gcc dot gnu dot org 2009-01-22 12:19 --- (In reply to comment #6) > -static bool code_motion_path_driver (insn_t, av_set_t, ilist_t, > - cmpd_local_params_p, void *); > +static int code_motion_path_driver (insn_t, av_set_t, ilist_t, > +cmpd_local_params_p, void *); > > You probably don't want this bit...? > The function returns -1 in some circumstances. This change is not relevant to the ICE in question, but is nevertheless a correction (maybe not the best, as 'return true' and 'return false' are used in function's body). I'm not sure what's best here -- to include this in PR fix submission, or as a separate patch. FWIW, there're a couple more unrelated changes: 1) check if a reg is actually a hard reg if (REG_P (*cur_rtx) + && HARD_REGISTER_P (*cur_rtx) && hard_regno_nregs[REGNO(*cur_rtx)][GET_MODE (*cur_rtx)] > 1) and 2) Do not merge info from successors if not relevant /* Merge data, clean up, etc. */ - if (code_motion_path_driver_info->after_merge_succs) + if (res != -1 && code_motion_path_driver_info->after_merge_succs) code_motion_path_driver_info->after_merge_succs (&lparams, static_params); Again, I will submit them separately if so desired. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38857
[Bug c++/38933] [4.3/4.4 Regression] fails to build valid code
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-22 12:24 --- Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||rejects-valid Known to fail||4.3.3 Known to work||4.3.2 Priority|P3 |P1 Summary|[4.3 regression] fails to |[4.3/4.4 Regression] fails |build valid code|to build valid code Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
[Bug middle-end/38932] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #9 from rguenther at suse dot de 2009-01-22 12:28 ---
Subject: Re: [4.4 Regression] ICE in set_value_range,
at tree-vrp.c:398
On Thu, 22 Jan 2009, bonzini at gnu dot org wrote:
> --- Comment #8 from bonzini at gnu dot org 2009-01-22 12:10 ---
> Fixing FRE still causes an ICE for this:
>
> /* { dg-do compile } */
> /* { dg-options "-O2 --std=gnu99" } */
>
> /* This variable needed only to exercise FRE instead of CCP. */
> unsigned char g;
>
> extern void abort();
>
> void f (long long int p)
> {
> g = 255;
> /* { dg-warning "constant is" "" { target *-*-* } 14 } */
> /* { dg-warning "overflow" "" { target *-*-* } 14 } */
> if (p >= -9223372036854775808LL - (signed char) g)
> p = 1;
>
> if (p)
> abort ();
> }
>
> Should I create a separate bug and submit what I have?
Yes.
Thanks,
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug c++/38933] [4.3/4.4 Regression] fails to build valid code
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-22 12:32 --- HJ, can you track down this to the revision that broke it? Thx. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
[Bug fortran/38918] compile time error for DATA of NULL() to pointer structure component
--- Comment #2 from pault at gcc dot gnu dot org 2009-01-22 12:33 --- This has a trivial fix: expr.c: 2913 becomes if (have_pointer && lvalue->symtree->n.sym->attr.data) Sorry about the lack of a diff - I will remedy this on submission:-) paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-22 12:33:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38918
[Bug c++/38933] [4.3/4.4 Regression] fails to build valid code
--- Comment #4 from doko at ubuntu dot com 2009-01-22 12:38 --- 20090111 is ok, 20090117 not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
[Bug fortran/38852] UBOUND fails for negative stride triplets
--- Comment #5 from pault at gcc dot gnu dot org 2009-01-22 12:39 --- (In reply to comment #4) > (In reply to comment #3) >In the latter case, it is non-empty if ubound > lbound only. Comparing > ubound and lbound according to the stride to check for zero-sized arrays > doesn't make sense in this case (see dimension 2 of dla). Indeed - the fix can be done in gfc_conv_intrinsic_bound. I will regtest tonight and submit accordingly. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-15 05:57:57 |2009-01-22 12:39:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38852
[Bug target/38931] [4.4 Regression] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
--- Comment #5 from uros at gcc dot gnu dot org 2009-01-22 12:48 --- Subject: Bug 38931 Author: uros Date: Thu Jan 22 12:48:03 2009 New Revision: 143567 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143567 Log: PR target/38931 * config/i386/i386.md (*movsi_1): Use type "mmx" for alternative 2. (*movdi_1_rex64): Use type "mmx" for alternative 5. testsuite/ChangeLog: PR target/38931 * gcc.target/i386/pr38931.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr38931.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
[Bug c++/38933] [4.3/4.4 Regression] fails to build code
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-22 12:57 ---
Hm, I don't think this is valid:
enum Type { NAME, FACETS, TAGS, QUIET };
...
template
CollPrinter& operator=(const std::pair& data)
{
...
switch (m_type)
{
...
case TAGS:
is it? EDG rejects it with
t.3.ii(73): error: type name is not allowed
case TAGS:
^
Reduced testcase:
class Foo {
enum { TAGS = 1 };
template
void foo(TAGS x, int i)
{
switch (i) {
case TAGS:;
}
}
};
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|rejects-valid |
Summary|[4.3/4.4 Regression] fails |[4.3/4.4 Regression] fails
|to build valid code |to build code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
[Bug c++/38933] [4.3/4.4 Regression] fails to build code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
[Bug target/38931] [4.4 Regression] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
--- Comment #6 from ubizjak at gmail dot com 2009-01-22 13:12 --- Fixed in mainline, latent on 4.3. -- ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|4.4.0 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
[Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
This failure is not "worked around" by FRE unlike 38932.
/* { dg-do compile } */
/* { dg-options "-O2 --std=gnu99" } */
/* This variable needed only to work around earlier optimizations than VRP. */
unsigned char g;
extern void abort();
void f (long long int p)
{
g = 255;
/* { dg-warning "constant is" "" { target *-*-* } 14 } */
/* { dg-warning "overflow" "" { target *-*-* } 14 } */
if (p >= -9223372036854775808LL - (signed char) g)
p = 1;
if (p)
abort ();
}
--
Summary: [4.4 Regression] ICE in set_value_range, at tree-
vrp.c:398
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, patch
Severity: critical
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i686-pc-linux-gnu
BugsThisDependsOn: 38932
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug middle-end/38934] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-22 13:17:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug libgomp/38935] New: Openmp reduction with - (minus) does not produce correct result
When using openmp reduction with minus the results are added instead of
substracted.
Small test programm to verify:
#include
int main(int argc, char* argv[]) {
int result = 15;
#pragma omp parallel reduction(-:result) num_threads(4)
{
result += 2;
// (1)
}
// (2)
}
At position (1) the variable result is 2 for each thread.
After the parallel block at position (2) it should be 7 (15-2-2-2-2) but the
value of result is 23 instead.
When I use + instead of - for the reduction clause the result is also 23.
I used the gcc version shipped with Ubuntu (gcc (Ubuntu 4.3.2-1ubuntu11)
4.3.2).
--
Summary: Openmp reduction with - (minus) does not produce correct
result
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot schlingmann at web dot de
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38935
[Bug inline-asm/38925] gcc ignores use of %rbp via assembly, generates bad code
--- Comment #10 from thutt at vmware dot com 2009-01-22 13:59 --- (In reply to comment #7) > The problem here is that you are using unitialized local register variables so > the register allocator does not know any better. Anyways it works correctly > on > the trunk and I don't have any other compiler to test with really (this is > both > with and without IRA). > First, what's the expansion of the TLA 'IRA'? Second, it makes no difference if all the locals are initialized, the compiler still incorrectly uses '%rbp'. Here is the disassembly of the source, with initializers for all local variables. 0010 : 10: 48 89 5c 24 d0 mov%rbx,0xffd0(%rsp) 15: 48 89 6c 24 d8 mov%rbp,0xffd8(%rsp) 1a: 31 db xor%ebx,%ebx 1c: 4c 89 64 24 e0 mov%r12,0xffe0(%rsp) 21: 4c 89 6c 24 e8 mov%r13,0xffe8(%rsp) 26: 31 c9 xor%ecx,%ecx 28: 4c 89 74 24 f0 mov%r14,0xfff0(%rsp) 2d: 4c 89 7c 24 f8 mov%r15,0xfff8(%rsp) 32: 31 d2 xor%edx,%edx 34: 48 83 ec 38 sub$0x38,%rsp 38: 31 f6 xor%esi,%esi 3a: 48 8b 2d 00 00 00 00mov0(%rip),%rbp# 41 41: 48 8b 05 00 00 00 00mov0(%rip),%rax# 48 48: 31 ed xor%ebp,%ebp 4a: 31 ff xor%edi,%edi 4c: 45 31 c0xor%r8d,%r8d 4f: 45 31 c9xor%r9d,%r9d 52: 45 31 d2xor%r10d,%r10d 55: 45 31 dbxor%r11d,%r11d 58: 45 31 e4xor%r12d,%r12d 5b: 45 31 edxor%r13d,%r13d 5e: 45 31 f6xor%r14d,%r14d 61: 45 31 ffxor%r15d,%r15d 64: 0f 01 d8vmrun 67: 48 8b 3d 00 00 00 00mov0(%rip),%rdi# 6e 6e: 48 8d 75 f8 lea0xfff8(%rbp),%rsi 72: 48 39 fecmp%rdi,%rsi 75: 74 05 je 7c 77: e8 00 00 00 00 callq 7c 7c: 48 8b 5c 24 08 mov0x8(%rsp),%rbx 81: 48 8b 6c 24 10 mov0x10(%rsp),%rbp 86: 31 c0 xor%eax,%eax 88: 4c 8b 64 24 18 mov0x18(%rsp),%r12 8d: 4c 8b 6c 24 20 mov0x20(%rsp),%r13 92: 4c 8b 74 24 28 mov0x28(%rsp),%r14 97: 4c 8b 7c 24 30 mov0x30(%rsp),%r15 9c: 48 83 c4 38 add$0x38,%rsp a0: c3 retq Third, why does removing the unused function 'SetupVMCB' cause the compiler to generate different code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
[Bug fortran/38936] New: F2003: ASSOCIATE construct
ASSOCIATE is a nice Fortran 2003 feature. I found the following at comp.lang.fortran and I want to make sure it gets tested when ASSOCIATE is implemented. Thus I opened this PR. http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ebf1e5abedc91cdc Test case: implicit none integer :: x(5), y(5), a(5), i x = [13.0, 23.0, 27.0, 0.0, 37.0 ] y = [1.0, 3.0, 5.0, 7.0, 11.0 ] a = 0.0 ASSOCIATE (z => x + y) do i = 1, 5 a(i) = z(i)*3.0 end do END ASSOCIATE print *, a end Using ifort 11, the result is: 42 78 96 21 144 -- Summary: F2003: ASSOCIATE construct Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 20585 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936
[Bug libgcj/38685] classmap.db is zero bytes long in 64 bit directory
--- Comment #7 from rob1weld at aol dot com 2009-01-22 14:50 --- Self Confirmed. Attempting to execute 64 bit code when booted 32 bit: # gmake ... /bin/sh ./libtool --tag=GCJ --mode=link /usr/share/src/gcc_build/gcc/gcj -B/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/ -B/usr/share/src/gcc_build/gcc/ -L/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava -ffloat-store -fomit-frame-pointer -Usun -g -O2 -m64 -m64 -o gjdoc --main=gnu.classpath.tools.gjdoc.Main -Djava.class.path= -rpath /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/amd64 -shared-libgcc -L/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/.libs libgcj-tools.la libtool: link: /usr/share/src/gcc_build/gcc/gcj -B/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/ -B/usr/share/src/gcc_build/gcc/ -ffloat-store -fomit-frame-pointer -Usun -g -O2 -m64 -m64 -o .libs/gjdoc --main=gnu.classpath.tools.gjdoc.Main -Djava.class.path= -shared-libgcc -L/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/.libs -L/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava ./.libs/libgcj-tools.so -Wl,-rpath -Wl,/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/amd64 : gmake ; exec true "AR_FLAGS=cr" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2-m64" "CXXFLAGS=-g -O2-m64" "CPPFLAGS=" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/local/bin/install -c" "INSTALL_DATA=/usr/local/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/local/bin/install -c" "INSTALL_SCRIPT=/usr/local/bin/install -c" "GCJFLAGS=-g -O2 -m64" "LDFLAGS=-m64" "LIBCFLAGS=-g -O2-m64" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=gmake" "MAKEINFO=makeinfo --split-size=500 --split-size=500" "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/info" "libdir=/usr/local/lib" "mandir=/usr/local/man" "prefix=/usr/local" "gxx_include_dir=/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/include/c++" "AR=/usr/local/i386-pc-solaris2.11/bin/ar" "AS=/usr/share/src/gcc_build/./gcc/as" "LD=/usr/share/src/gcc_build/./gcc/collect-ld" "LIBCFLAGS=-g -O2-m64" "NM=/usr/share/src/gcc_build/./gcc/nm" "PICFLAG=" "RANLIB=/usr/local/i386-pc-solaris2.11/bin/ranlib" "DESTDIR=" "JAR=/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/scripts/jar" DO=all multi-do ./gcj-dbtool -n classmap.db || touch classmap.db exec: /usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/.libs/gcj-dbtool: cannot execute [Exec format error] cp classpath/tools/tools.zip libgcj-tools-4.4.0.jar gmake[5]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava' gmake[4]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava' gmake[3]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava' Making all in libltdl gmake[3]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/libltdl' gmake all-am gmake[4]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/libltdl' ... We need 'gcj-dbtool' to be compiled 32 bit when building the 64 bit library and booted in 32 bit mode to avoid the "dbtool: cannot execute [Exec format error]". Until we have OSes than will _only_ boot 64 bit and will not run 32 bit code (in which case they would not build the other library and this Bug ought not to reoccur) we can build the program 32 bit regardless of which library or boot mode (32 or 64). Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38685
[Bug fortran/38915] wrong results for structure assignment of character components when left and right sides overlap
--- Comment #2 from pault at gcc dot gnu dot org 2009-01-22 15:00 --- (In reply to comment #1) > Confirm. ICE with 4.1.x and 4.2.x and wrong code with 4.3.x and 4.4. > > Thanks for the report. > The character length is being incorrectly set to 1 for the failing assignments; ie. the last argument of the memmove is 1. I'm on to it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-19 18:49:04 |2009-01-22 15:00:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38915
[Bug java/38717] gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM)
--- Comment #8 from rob1weld at aol dot com 2009-01-22 15:12 --- Applying "gcc_trunk/gcc/config/sol2.h" hack from this post: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38924 That is confirmed to "workaround" the problem but not "fix" it. Afterwards it makes Bug 38728 by _far_ much worse, greatly insreasing the running time of "make install" by causing multiple re-linking (ONE file relinking was not a Bug in 38728, now we have many). Screenshot coming, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38717
[Bug c++/38930] [4.4 Regression] typedef with attribute mode causes ICE in dwarf2
--- Comment #12 from dodji at gcc dot gnu dot org 2009-01-22 15:27 --- I have reverted the patch. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38930
[Bug middle-end/38934] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-22 15:53 --- It won't ICE for me with revision 143448 on Linux/x86-64: [...@gnu-27 rrs]$ ./143448/usr/bin/gcc -O2 -S pr38934.c -m32 --std=gnu99 pr38934.c:14:13: warning: integer constant is so large that it is unsigned [...@gnu-27 rrs]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug java/38717] gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM)
--- Comment #9 from rob1weld at aol dot com 2009-01-22 16:03 --- Created an attachment (id=17162) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17162&action=view) Screenshot of build shows libgcj_tools building (after patch from 38924) Description of the Screenshot: At the far left is a tiny blip (in the "Memory and Swap History" Display) that shows the memory usage of "gnu/javax/swing/text/html/parser/.libs/HTML_401F.o" has been _very_ strongly reduced. A _short_ distance to the right are _two_ humps that represent the 32 and 64 bit portions of linking the ".libs/libgcj-tools.so.10.0.0" libraries. Notice that this time the 64 bit library actually takes up _slightly_ _less_ memory than the linking of the 32 bit library as opposed to it's previous operation without the patch (and it is nowhere close to bringing the OS to it's knees). Finally to the far right we see the build complete successfully. Notice that the red line (indicates cache usage) shows only about 50M used. The "workaround" from the other post has an enormous effect towards alleviating the memory hogging. It seems like we might be trying to get collect to drive 'ld' in a (italics) "--enable-intermodule" (end-italics) (IE: not using, but 'sort of' equivalent to the principle of) manner. Please would a gcc/binutils Guru comment for us? Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38717
[Bug middle-end/38932] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #10 from hjl dot tools at gmail dot com 2009-01-22 16:09 --- It is caused by revision 126434: http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00290.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Known to fail|4.4.0 |4.3.3 4.4.0 Summary|[4.4 Regression] ICE in |[4.3/4.4 Regression] ICE in |set_value_range, at tree- |set_value_range, at tree- |vrp.c:398 |vrp.c:398 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug target/38904] Shared libgcc DLL violates Cygwin platform conventions.
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-22 16:42 --- Created an attachment (id=17163) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17163&action=view) Fix shared libgcc naming scheme. Patch now in testing, fixes DLL naming scheme for both Cygwin and MinGW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904
[Bug middle-end/38615] [4.2/4.3/4.4 Regression] invalid promotion to static from auto
--- Comment #1 from sje at gcc dot gnu dot org 2009-01-22 17:02 --- Subject: Bug 38615 Author: sje Date: Thu Jan 22 17:02:21 2009 New Revision: 143570 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143570 Log: PR middle-end/38615 * gimplify.c (gimplify_init_constructor): Fix promotion of const variables to static. * doc/invoke.texi (-fmerge-all-constants): Update description. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38615
[Bug middle-end/38615] [4.2/4.3/4.4 Regression] invalid promotion to static from auto
--- Comment #2 from sje at gcc dot gnu dot org 2009-01-22 17:03 --- Subject: Bug 38615 Author: sje Date: Thu Jan 22 17:03:35 2009 New Revision: 143571 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143571 Log: PR middle-end/38615 * gcc.dg/pr38615.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr38615.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38615
[Bug middle-end/38932] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #11 from dberlin at gcc dot gnu dot org 2009-01-22 17:12 --- Subject: Re: [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 Uh, well, that would be tricky since none of this code still exists in 4.4.0 On Thu, Jan 22, 2009 at 11:09 AM, hjl dot tools at gmail dot com wrote: > > > --- Comment #10 from hjl dot tools at gmail dot com 2009-01-22 16:09 > --- > It is caused by revision 126434: > > http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00290.html > > > -- > > hjl dot tools at gmail dot com changed: > > What|Removed |Added > > CC||dberlin at gcc dot gnu dot > ||org > Known to fail|4.4.0 |4.3.3 4.4.0 >Summary|[4.4 Regression] ICE in |[4.3/4.4 Regression] ICE in > |set_value_range, at tree- |set_value_range, at tree- > |vrp.c:398 |vrp.c:398 > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug fortran/38936] F2003: ASSOCIATE construct
--- Comment #1 from domob at gcc dot gnu dot org 2009-01-22 17:27 --- I always liked the idea of associate... Maybe I'll volunteer to work on it for gfortran, but don't take my word on it ;) And of course, things like CLASS get higher priority. -- domob at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936
[Bug c++/38930] [4.4 Regression] typedef with attribute mode causes ICE in dwarf2
--- Comment #13 from hjl dot tools at gmail dot com 2009-01-22 17:43 --- Fixed by revision 143562, which reverted revision 143546. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Priority|P3 |P1 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38930
[Bug target/38384] link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #41 from r dot emrich at de dot tecosim dot com 2009-01-22 18:15 --- (In reply to comment #40) > Subject: Re: link/execute fails for cross gcc from linux to target > hppa64-hp-hpux11.00 > > configuring with > > > > --disable-symvers > > GNU symbol versioning is not supported by the HP-UX dynamic linker, so > this should be off as suggested. > > Dave > configuring with --disable-symvers --disable-shared solves the problem for now. So in fact --disable-shared should be sufficient because there's no symbol versioning in archives right? I think for native builds using the gnu ld it's the same issue. Some hints in the documentation would be useful. So, configuring with --enable-shared does not work. The build shared libraries can't be handled by the HP-UX loader. Thanks to Dave and Benjamin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #42 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-22 18:42 --- Subject: Re: link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00 > configuring with --disable-symvers --disable-shared solves the problem for > now. > So in fact --disable-shared should be sufficient because there's no symbol > versioning in archives right? > > I think for native builds using the gnu ld it's the same issue. Some hints in > the documentation would be useful. I'm thinking configure should disable symvers on hppa*-*-hpux* by default. I had a patch to do this at one time. > So, configuring with --enable-shared does not work. > The build shared libraries can't be handled by the HP-UX loader. Shared libraries did work at one time, although GNU ld has never worked very well on this target. I haven't done anything on this since PR 20939. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug middle-end/38937] New: [4.4 regression] dereferencing pointer '' does break strict-aliasing
On s390x, there are some libstdc++ failures that are not present on other platforms. Here is a representative test run: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02102.html And here is the failure analysis: http://gcc.gnu.org/ml/libstdc++/2009-01/msg00109.html The following fails appear to be spurious and only occur on s390x. At first I thought this might be because of the extra flags "-fstack-protector --param=ssp-buffer-size=4" but compiling the problem testcases on x86_64/linux with the same flag doesn't show an error. So, I don't know what's up. The same testcases (when present) pass without error on 4.3.2. FAIL: 21_strings/basic_string/element_access/wchar_t/empty.cc FAIL: 23_containers/list/modifiers/1.cc FAIL: 23_containers/list/modifiers/3.cc FAIL: 23_containers/list/modifiers/insert/25288.cc The usual error looks like: warning: dereferencing pointer '' does break strict-aliasing rules which is incomprehensible. -- Summary: [4.4 regression] dereferencing pointer '' does break strict-aliasing Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org GCC host triplet: s390x-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38937
[Bug middle-end/38587] [4.4 Regression] IRA doesn't preserve local variables after setjmp
--- Comment #43 from joel at gcc dot gnu dot org 2009-01-22 19:23 --- (In reply to comment #42) > Fixed. > Did the test case get added to the suite? This does appear to be fixed to me as well. C/C++: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02243.html Ada: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02255.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
[Bug middle-end/38587] [4.4 Regression] IRA doesn't preserve local variables after setjmp
--- Comment #44 from hjl dot tools at gmail dot com 2009-01-22 19:33 --- (In reply to comment #43) > (In reply to comment #42) > > Fixed. > > > > Did the test case get added to the suite? > > This does appear to be fixed to me as well. There are no suitable testcases in this PR. Maybe someone can extract a testcase from PR 38660. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
[Bug fortran/38917] Can't use DATA to initialize pointer to array to NULL()
--- Comment #2 from pault at gcc dot gnu dot org 2009-01-22 20:16 --- I am just about to post a fix. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-20 07:25:22 |2009-01-22 20:16:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38917
[Bug middle-end/38934] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-22 21:30 --- (In reply to comment #1) > It won't ICE for me with revision 143448 on Linux/x86-64: Most likely this is HWI 32 only issue as this works on i386-darwin which defaults HWI to be 64bits. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|WAITING |NEW Last reconfirmed|2009-01-22 13:17:43 |2009-01-22 21:30:48 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug middle-end/38937] [4.4 regression] dereferencing pointer '' does break strict-aliasing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|[4.4 regression]|[4.4 regression] |dereferencing pointer |dereferencing pointer |'' does break|'' does break |strict-aliasing |strict-aliasing Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38937
[Bug c++/38933] [4.3/4.4 Regression] fails to build code
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-22 21:33 --- Yes this is invalid code, see PR 36019 for the reason why. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38933
[Bug target/38384] link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #43 from bkoz at gcc dot gnu dot org 2009-01-22 21:40 --- Subject: Bug 38384 Author: bkoz Date: Thu Jan 22 21:40:23 2009 New Revision: 143576 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143576 Log: 2009-01-22 Benjamin Kosnik PR libstdc++/38384 * acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Disable symbol versioning on HPUX. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #44 from bkoz at gcc dot gnu dot org 2009-01-22 22:01 --- Hey. I couldn't stop myself: since Dave said that HPUX doesn't support symbol versioning, (no way, no how) I have changed libstdc++ configure to reflect this. :) Ranier, great to see you got something working. I've changed the summary again to reflect what is now left of this bug. You are correct in that --disable-shared turns off shared library versioning, since versioning only applies to the shared lib. I believe that this is a documentation-only bug at this point. In particular, I think that this documentation page: http://gcc.gnu.org/install/specific.html#hppa-hp-hpux Should reflect this discussion. As it stands this: There are a number of issues to consider in selecting which linker to use with the 64-bit port. The GNU 64-bit linker can only create dynamic binaries. The -static option causes linking with archive libraries but doesn't produce a truly static binary. Dynamic binaries still require final binding by the dynamic loader to resolve a set of dynamic-loader-defined symbols. The default behavior of the HP linker is the same as the GNU linker. However, it can generate true 64-bit static binaries using the +compat option. oddly changes: The GNU 64-bit linker has some issues with shared library support and exceptions. As a result, we only support libgcc in archive format. For similar reasons, dwarf2 unwind and exception support are disabled. The GNU linker also has problems creating binaries with -static. It doesn't provide stubs for internal calls to global functions in shared libraries, so these calls can't be overloaded. I can see how people are confused by this. GNU ld appears to not really work with shared or static libs, from the docs. (But maybe just for 64 bit targets?) But experience says it works with static libs, but not shared libs. Something needs to be changed, and this section should be updated with the latest status and best practice (which appears to be GNU as, HPUX ld). (FWIW, it looks like shared libgcc is being created on this target now with GNU ld or else this alone would turn off symbol versioning.) Some love here by people in the know would be helpful to all. I leave the edits to the target maintainer. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Keywords||documentation Summary|link/execute fails for cross|shared link/execute fails |gcc from linux to target|for cross gcc from linux to |hppa64-hp-hpux11.00 |target hppa64-hp-hpux11.00 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #45 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-22 22:36 --- Subject: Re: shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00 > Hey. I couldn't stop myself: since Dave said that HPUX doesn't support symbol > versioning, (no way, no how) I have changed libstdc++ configure to reflect > this. > > :) > > Ranier, great to see you got something working. I've changed the summary again > to reflect what is now left of this bug. You are correct in that > --disable-shared turns off shared library versioning, since versioning only > applies to the shared lib. > > I believe that this is a documentation-only bug at this point. > > In particular, I think that this documentation page: > http://gcc.gnu.org/install/specific.html#hppa-hp-hpux > > Should reflect this discussion. As it stands this: > > There are a number of issues to consider in selecting which linker to use with > the 64-bit port. The GNU 64-bit linker can only create dynamic binaries. The > -static option causes linking with archive libraries but doesn't produce a > truly static binary. Dynamic binaries still require final binding by the > dynamic loader to resolve a set of dynamic-loader-defined symbols. The default > behavior of the HP linker is the same as the GNU linker. However, it can > generate true 64-bit static binaries using the +compat option. > > oddly changes: > > The GNU 64-bit linker has some issues with shared library support and > exceptions. As a result, we only support libgcc in archive format. For similar > reasons, dwarf2 unwind and exception support are disabled. The GNU linker also > has problems creating binaries with -static. It doesn't provide stubs for > internal calls to global functions in shared libraries, so these calls can't > be > overloaded. > > I can see how people are confused by this. GNU ld appears to not really work > with shared or static libs, from the docs. (But maybe just for 64 bit > targets?) > But experience says it works with static libs, but not shared libs. Something > needs to be changed, and this section should be updated with the latest status > and best practice (which appears to be GNU as, HPUX ld). (FWIW, it looks like > shared libgcc is being created on this target now with GNU ld or else this > alone would turn off symbol versioning.) Some love here by people in the know > would be helpful to all. It's been awhile but I believe there never was an issue using archive libraries. There was a problem linking executables with -static that I believe got fixed. I agree this needs rewriting. The problems with shared library support are more important than the issues with -static. However, some testing is needed to determine the current state of GNU ld. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug middle-end/38937] [4.4 regression] dereferencing pointer '' does break strict-aliasing
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-22 22:44 --- This is likely because of different inlining decisions which is possibly because of different insn costs which depend on MOVE_MAX_PIECES and MOVE_RATIO. The warning itself hints at either an alias problem in the testcase or the library or at a problem with points-to analysis. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38937
[Bug tree-optimization/38745] [4.4 Regression] ICE: statement makes a memory store, but has no VDEFS
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-22 23:10
---
Hm, the first forwprop dump looks sane:
VIEW_CONVERT_EXPR(c64).u.lo32.u.lo16.u.hi8 ={v} 1;
but then addressables1 comes along and rewrites c64 into SSA form ... and if
you fix it then the duplicate in tree-ssa-alias.c comes along and does it
again.
Maybe I should merge the split of addressables from tree-ssa-alias.c from
the alias-improvements branch.
Trivial fix for addressables:
Index: tree-ssa.c
===
--- tree-ssa.c (revision 143555)
+++ tree-ssa.c (working copy)
@@ -1728,7 +1728,8 @@ execute_update_addresses_taken (void)
/* Global Variables, result decls cannot be changed. */
if (is_global_var (var)
|| TREE_CODE (var) == RESULT_DECL
- || bitmap_bit_p (addresses_taken, DECL_UID (var)))
+ || bitmap_bit_p (addresses_taken, DECL_UID (var))
+ || bitmap_bit_p (not_reg_needs, DECL_UID (var)))
continue;
if (TREE_ADDRESSABLE (var))
@@ -1746,7 +1747,6 @@ execute_update_addresses_taken (void)
}
}
if (!DECL_GIMPLE_REG_P (var)
- && !bitmap_bit_p (not_reg_needs, DECL_UID (var))
&& (TREE_CODE (TREE_TYPE (var)) == COMPLEX_TYPE
|| TREE_CODE (TREE_TYPE (var)) == VECTOR_TYPE))
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
[Bug tree-optimization/38745] [4.4 Regression] ICE: statement makes a memory store, but has no VDEFS
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-01-22 23:20 --- >Maybe I should merge the split of addressables from tree-ssa-alias.c from the alias-improvements branch. There are two things, first c64 really should not be TREE_ADDRESSABLE but rather !DECL_GIMPLE_REG_P. But that is too big for this stage of compiling and has unknown effects. I will do it for 4.5 and remove the special casing here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
[Bug tree-optimization/38745] [4.4 Regression] ICE: statement makes a memory store, but has no VDEFS
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-01-22 23:21
---
non-optimal tree-ssa-alias.c part:
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 143555)
+++ tree-ssa-alias.c(working copy)
@@ -2483,6 +2483,21 @@ update_alias_info_1 (gimple stmt, struct
if (addr_taken)
bitmap_ior_into (gimple_addressable_vars (cfun), addr_taken);
+ /* If we have a call or an assignment, see if the lhs contains
+ a local decl that requires not to be a gimple register. */
+ if (gimple_code (stmt) == GIMPLE_ASSIGN
+ || gimple_code (stmt) == GIMPLE_CALL)
+{
+ tree lhs = gimple_get_lhs (stmt);
+ /* A plain decl does not need it set. */
+ if (lhs && handled_component_p (lhs))
+ {
+ tree var = get_base_address (lhs);
+ if (DECL_P (var))
+ bitmap_set_bit (gimple_addressable_vars (cfun), DECL_UID (var));
+ }
+}
+
/* Process each operand use. For pointers, determine whether they
are dereferenced by the statement, or whether their value
escapes, etc. */
which then fixes the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
[Bug tree-optimization/38745] [4.4 Regression] ICE: statement makes a memory store, but has no VDEFS
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-01-22 23:23 --- Hm? Non-TREE_ADDRESSABLE non-SSA vars are fine. It isn't DECL_GIMPLE_REG_P either of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
[Bug c/38938] New: -Wno-all doesn't work on -Wpointer-sign
[...@gnu-6 pr36159]$ cat f.c
/* foo /* */
int *
foo (unsigned int *x)
{
return x;
}
[...@gnu-6 pr36159]$ /export/build/gnu/gcc-avx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -c f.c
[...@gnu-6 pr36159]$ /export/build/gnu/gcc-avx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -c f.c -Wall
f.c:1:8: warning: "/*" within comment
f.c: In function foo:
f.c:6: warning: pointer targets in return differ in signedness
[...@gnu-6 pr36159]$ /export/build/gnu/gcc-avx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -c f.c -Wno-all
f.c: In function foo:
f.c:6: warning: pointer targets in return differ in signedness
[...@gnu-6 pr36159]$
--
Summary: -Wno-all doesn't work on -Wpointer-sign
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38938
[Bug c/38938] -Wno-all doesn't work on -Wpointer-sign
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-22 23:54 --- This patch Index: gcc/c-opts.c === --- gcc/c-opts.c(revision 5064) +++ gcc/c-opts.c(working copy) @@ -425,7 +425,7 @@ c_common_handle_option (size_t scode, co cpp_opts->warn_num_sign_change = value; if (warn_pointer_sign == -1) - warn_pointer_sign = 1; + warn_pointer_sign = value; break; case OPT_Wbuiltin_macro_redefined: works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38938
[Bug middle-end/38934] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #3 from hjl dot tools at gmail dot com 2009-01-23 00:06 --- (In reply to comment #2) > (In reply to comment #1) > > It won't ICE for me with revision 143448 on Linux/x86-64: > > Most likely this is HWI 32 only issue as this works on i386-darwin which > defaults HWI to be 64bits. That is true. This only happens with 32bit HWI. This is caused by revision 122487: http://gcc.gnu.org/ml/gcc-cvs/2007-03/msg00070.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||iant at google dot com Known to fail|4.4.0 |4.3.3 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug target/38939] New: MULLW on often faster than SLWI ADD SLWI ADD..
The following snippet runs about 25% faster on my 1333MHz 7447A with -Os than
-O2, even if compiled with -mcpu=G4:
const unsigned c=0x1010101;
unsigned z=0;
for(int i=c; i>=2; i*=c)
{
z+=i&1;
}
With -mcpu=G4 -O2 it gives:
lis 0,0x101
mr 31,3
ori 10,0,257
.L4:
slwi 0,10,8
rlwinm 11,10,0,31,31
add 0,0,10
add 28,28,11
slwi 9,0,16
add 10,0,9
cmplwi 7,10,1
bgt+ 7,.L4
With -mcpu=G4 -Os it gives:
lis 0,0x101
ori 9,0,257
mr 30,3
mr 11,9
.L4:
rlwinm 0,9,0,31,31
mullw 9,9,11
add 31,31,0
cmplwi 7,9,1
bgt+ 7,.L4
The latter one is about 25% faster, meaning that the G4's multiplier is much
faster than GCC assumes.
With other constants the difference tends to be smaller, but I haven't
encountered a situation where the MUL-version is slower (when Os and O2 build
different code here).
d...@bronko:~/c-Test$ g++ -v
Es werden eingebaute Spezifikationen verwendet.
Ziel: powerpc-linux-gnu
Konfiguriert mit: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-softfloat --enable-secureplt
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu
--host=powerpc-linux-gnu --target=powerpc-linux-gnu
Thread-Modell: posix
gcc-Version 4.3.2 (Debian 4.3.2-1.1)
--
Summary: MULLW on often faster than SLWI ADD SLWI ADD..
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dom at wtal dot de
GCC build triplet: PowerPC-Debian-Lenny
GCC host triplet: PowerPC-Debian-Lenny
GCC target triplet: PowerPC-Debian-Lenny
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38939
[Bug target/38940] New: MULLW on often faster than SLWI ADD SLWI ADD..
The following snippet runs about 25% faster on my 1333MHz 7447A with -Os than
-O2, even if compiled with -mcpu=G4:
const unsigned c=0x1010101;
unsigned z=0;
for(int i=c; i>=2; i*=c)
{
z+=i&1;
}
With -mcpu=G4 -O2 it gives:
lis 0,0x101
mr 31,3
ori 10,0,257
.L4:
slwi 0,10,8
rlwinm 11,10,0,31,31
add 0,0,10
add 28,28,11
slwi 9,0,16
add 10,0,9
cmplwi 7,10,1
bgt+ 7,.L4
With -mcpu=G4 -Os it gives:
lis 0,0x101
ori 9,0,257
mr 30,3
mr 11,9
.L4:
rlwinm 0,9,0,31,31
mullw 9,9,11
add 31,31,0
cmplwi 7,9,1
bgt+ 7,.L4
The latter one is about 25% faster, meaning that the G4's multiplier is much
faster than GCC assumes.
With other constants the difference tends to be smaller, but I haven't
encountered a situation where the MUL-version is slower (when Os and O2 build
different code here).
d...@bronko:~/c-Test$ g++ -v
Es werden eingebaute Spezifikationen verwendet.
Ziel: powerpc-linux-gnu
Konfiguriert mit: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-softfloat --enable-secureplt
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu
--host=powerpc-linux-gnu --target=powerpc-linux-gnu
Thread-Modell: posix
gcc-Version 4.3.2 (Debian 4.3.2-1.1)
--
Summary: MULLW on often faster than SLWI ADD SLWI ADD..
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dom at wtal dot de
GCC build triplet: PowerPC-Debian-Lenny
GCC host triplet: PowerPC-Debian-Lenny
GCC target triplet: PowerPC-Debian-Lenny
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38940
[Bug target/38941] New: CX isn't preserved with shift
On x86, CX is used for shift. If CX is used for a variable, it
may not be preserved with shift:
[...@gnu-9 reg-1]$ cat r.c
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
void
bar (int g)
{
register int x __asm__("ecx");
x = 5;
foo (1 << g);
if (x != 5)
abort ();
}
int
main ()
{
bar (3);
return 0;
}
[...@gnu-9 reg-1]$ make r0
/export/build/gnu/gcc/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-i686-linux/gcc/ -m32 -O0 r.c -o r0
[...@gnu-9 reg-1]$ ./r0
Aborted
[...@gnu-9 reg-1]$
--
Summary: CX isn't preserved with shift
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ra
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug target/38940] MULLW on often faster than SLWI ADD SLWI ADD..
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-23 02:58 --- *** This bug has been marked as a duplicate of 38939 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38940
[Bug target/38939] MULLW on often faster than SLWI ADD SLWI ADD..
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-23 02:58 --- *** Bug 38940 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38939
Re: internal compiler error
G'Day Prof. Peter Morgan This is Jason Zhang from RSES ANU. While I was recompiling the GAMIT due to change of my laptop (x-86-64), I encounterred an internal compiling bug which occurs when doing gfortran -O3 -Wuninitialized -fno-f2c -ffast-math -fno-automatic -fno-backslash tssum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/ kinv_lib.a ../../libraries/comlib/com_lib.a -o tssum it happens: "tssum.f: In function ‘remove_ejmp’: tssum.f:712: internal compiler error: in set_uids_in_ptset, at tree-ssa-structalias.c:4785 Please submit a full bug report ..." with my system details as Linux burnie 2.6.25.18-0.2-default #1 SMP 2008-10-21 16:30:26 +0200 x86_64 x86_64 x86_64 GNU/Linux running OpenSuse 11.0 It is in tracking "nternal compiler error: in set_uids_in_ptset, at tree-ssa-structalias.c:4785" that I found your email address suggesting once you faced the same thing. It seems to say that the bug has been fixed. Could you please tell me how it is fixed? Happy Australian Day! With best regards, Jason
[Bug c/38942] New: possible integer codegen error
Seen using r143582 on Ubuntu Hardy. I'm pretty sure this is a miscompilation
at -O2.
The safe_* macros are basically just macroizations of safe math functions from
here:
https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
reg...@john-home:~/volatile/tmp127$ current-gcc -O1 small.c -o small
reg...@john-home:~/volatile/tmp127$ ./small
reg...@john-home:~/volatile/tmp127$ current-gcc -O2 small.c -o small
reg...@john-home:~/volatile/tmp127$ ./small
small: small.c:29: func_31: Assertion `0' failed.
Aborted
reg...@john-home:~/volatile/tmp127$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r143582-install
--program-prefix=r143582- --enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20090123 (experimental) (GCC)
reg...@john-home:~/volatile/tmp127$ cat small.c
#include
#include
#include
#include
#include
#define safe_sub_macro_int8_t_s_s(si1,si2) \
((int8_t)(si1))^((int8_t)(si2))) \
& (int8_t)(si1)) ^ int8_t)(si1))^((int8_t)(si2))) \
& (((int8_t)1) <<
(sizeof(int8_t)*CHAR_BIT-1-((int8_t)(si2)))^((int8_t)(si2 <
((int8_t)0)) \
? ((int8_t)(si1)) \
: (((int8_t)(si1)) - ((int8_t)(si2))) \
)
#define safe_add_macro_int16_t_s_s(si1,si2) \
((int16_t)(si1))>((int16_t)0)) &&
(((int16_t)(si2))>((int16_t)0)) && (((int16_t)(si1)) >
((INT16_MAX)-((int16_t)(si2) \
|| int16_t)(si1))<((int16_t)0)) &&
(((int16_t)(si2))<((int16_t)0)) && (((int16_t)(si1)) <
((INT16_MIN)-((int16_t)(si2)) \
? ((int16_t)(si1)) \
: (((int16_t)(si1)) + ((int16_t)(si2))) \
)
uint32_t g_113;
void func_31 (uint8_t p_33)
{
uint32_t l_40 = 0x0A6F85D5L;
if (0 >= safe_sub_macro_int8_t_s_s (1 < p_33, safe_add_macro_int16_t_s_s
(l_40, 1))) {
} else {
assert (0);
}
}
int main (void)
{
func_31 (1);
return 0;
}
--
Summary: possible integer codegen error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38942
Re: [Bug target/38941] New: CX isn't preserved with shift
Sent from my iPhone
On Jan 22, 2009, at 5:54 PM, "hjl dot tools at gmail dot com" > wrote:
On x86, CX is used for shift. If CX is used for a variable, it
may not be preserved with shift:
[...@gnu-9 reg-1]$ cat r.c
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
void
bar (int g)
{
register int x __asm__("ecx");
x = 5;
foo (1 << g);
I think this code is undefined as the register variable is not used in
an inline-asm.
if (x != 5)
abort ();
}
int
main ()
{
bar (3);
return 0;
}
[...@gnu-9 reg-1]$ make r0
/export/build/gnu/gcc/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-i686-linux/gcc/ -m32 -O0 r.c -o r0
[...@gnu-9 reg-1]$ ./r0
Aborted
[...@gnu-9 reg-1]$
--
Summary: CX isn't preserved with shift
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ra
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug target/38941] CX isn't preserved with shift
--- Comment #1 from pinskia at gmail dot com 2009-01-23 04:24 ---
Subject: Re: New: CX isn't preserved with shift
Sent from my iPhone
On Jan 22, 2009, at 5:54 PM, "hjl dot tools at gmail dot com"
wrote:
> On x86, CX is used for shift. If CX is used for a variable, it
> may not be preserved with shift:
>
> [...@gnu-9 reg-1]$ cat r.c
> extern void abort (void);
>
> void
> foo (int x)
> {
> if (x != 8)
>abort ();
> }
>
> void
> bar (int g)
> {
>register int x __asm__("ecx");
>x = 5;
>foo (1 << g);
I think this code is undefined as the register variable is not used in
an inline-asm.
>
>if (x != 5)
> abort ();
> }
>
> int
> main ()
> {
> bar (3);
> return 0;
> }
> [...@gnu-9 reg-1]$ make r0
> /export/build/gnu/gcc/build-i686-linux/gcc/xgcc
> -B/export/build/gnu/gcc/build-i686-linux/gcc/ -m32 -O0 r.c -o r0
> [...@gnu-9 reg-1]$ ./r0
> Aborted
> [...@gnu-9 reg-1]$
>
>
> --
> Summary: CX isn't preserved with shift
> Product: gcc
> Version: 4.4.0
>Status: UNCONFIRMED
> Keywords: ra
> Severity: normal
> Priority: P3
> Component: target
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: hjl dot tools at gmail dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug target/38941] CX isn't preserved with shift
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-23 04:34 ---
How about this one:
---
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
void
bar (int g)
{
register int x __asm__("ecx");
register int y __asm__("eax");
x = 5;
foo (1 << g);
asm ("mov %1, %0": "=r" (y): "r" (x));
if (x != 5)
abort ();
if (y != 5)
abort ();
}
int
main ()
{
bar (3);
return 0;
}
---
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|CX isn't preserved with |CX isn't preserved with
|shift |shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
Re: [Bug target/38941] CX isn't preserved with shift
Sent from my iPhone
On Jan 22, 2009, at 8:34 PM, "hjl dot tools at gmail dot com" > wrote:
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-23
04:34 ---
How about this one:
---
extern void abort (void);
void
foo (int x)
{
if (x != 8)
abort ();
}
void
bar (int g)
{
register int x __asm__("ecx");
register int y __asm__("eax");
x = 5;
foo (1 << g);
asm ("mov %1, %0": "=r" (y): "r" (x));
Again still undefined because there is still inbetween the assignment
and the inline-asm.
if (x != 5)
abort ();
if (y != 5)
abort ();
}
int
main ()
{
bar (3);
return 0;
}
---
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
---
--
Summary|CX isn't preserved with |CX isn't preserved
with
|shift |shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug target/38941] CX isn't preserved with shift
--- Comment #3 from pinskia at gmail dot com 2009-01-23 04:39 ---
Subject: Re: CX isn't preserved with shift
Sent from my iPhone
On Jan 22, 2009, at 8:34 PM, "hjl dot tools at gmail dot com"
wrote:
>
>
> --- Comment #2 from hjl dot tools at gmail dot com 2009-01-23
> 04:34 ---
> How about this one:
>
> ---
> extern void abort (void);
>
> void
> foo (int x)
> {
> if (x != 8)
>abort ();
> }
>
> void
> bar (int g)
> {
>register int x __asm__("ecx");
>register int y __asm__("eax");
>x = 5;
>foo (1 << g);
>asm ("mov %1, %0": "=r" (y): "r" (x));
Again still undefined because there is still inbetween the assignment
and the inline-asm.
>
>if (x != 5)
> abort ();
>if (y != 5)
> abort ();
> }
>
> int
> main ()
> {
> bar (3);
> return 0;
> }
> ---
>
>
> --
>
> hjl dot tools at gmail dot com changed:
>
> What|Removed |Added
> ---
> ---
> --
>Summary|CX isn't preserved with |CX isn't preserved
> with
> |shift |shift
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug target/38941] CX isn't preserved with shift
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-23 05:14 ---
(In reply to comment #3)
> Again still undefined because there is still inbetween the assignment
> and the inline-asm.
>
Where is this documented? There is
bash-3.2$ cat ./gcc.target/mips/asm-1.c
/* PR target/17565. GCC used to put the asm into the delay slot
of the call. */
/* { dg-do assemble } */
/* { dg-options "-O" } */
NOMIPS16 int foo (int n)
{
register int k asm ("$16") = n;
if (k > 0)
{
bar ();
asm ("li %0,0x12345678" : "=r" (k));
}
return k;
}
bash-3.2$
./gcc.target/alpha/asm-1.c also has statements between register and
asm statements.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug target/38941] CX isn't preserved with shift
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-23 05:16 --- ./gcc.target/i386/attr-returns_twice-1.c has no asm statements at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug target/38941] CX isn't preserved with shift
--- Comment #6 from hjl dot tools at gmail dot com 2009-01-23 05:45 --- gcc.target/i386/pr20204.c is another example without asm statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug fortran/38439] I/O PD edit descriptor inconsistency
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-01-23 05:46 --- gfortran's current format parser is completely lost by the time an error is thrown. I have a patch that detects the actual error and the locus is spot on. I am fixing both compile time and run time to reject the exponent width with a D edit descriptor. I will have a look at the d0 case as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439
