[Bug target/19672] [3.4/4.0/4.1 Regression] Performance regression in simple loop code
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-27 07:39:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug target/19672] [3.4/4.0/4.1 Regression] Performance regression in simple loop code
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-27 07:41 --- For gcc4, the no-PIC case looks pretty good to me ;-) -- What|Removed |Added Known to fail|3.4.0 4.0.0 4.1.0 3.3.3 |3.3.3 3.4.0 4.0.0 4.1.0 Known to work|3.2.3 |2.95.3 3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug target/19672] [3.4/4.0/4.1 Regression] Performance regression in simple loop code
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-27 07:59 --- Dan, can you show the assembler output for 2.95.3 and 4.0 (why is 4.1 "n/a"??) for the -fPIC case? -- What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug other/20791] visibilty options don't work
--- Additional Comments From oliverst at online dot de 2005-06-27 09:32 --- OK, I got a more recent version of the binutils and I know get this: 91 C:\cvs\STLport\stlport\stl\_new.h [Warning] visibility attribute not supported in this configuration; ignored Guess this can be closed now. Sorry for the report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20791
[Bug libfortran/22142] eoshift: boundary not filled in correctly
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27 09:49 --- Created an attachment (id=9156) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9156&action=view) Proposed patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22142
[Bug libfortran/22142] eoshift: boundary not filled in correctly
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27 09:51 --- (From update of attachment 9156) The patch was for the wrong bug report *sigh*. -- What|Removed |Added Attachment #9156 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22142
[Bug fortran/21594] FAIL: gfortran.dg/eoshift.f90 -O0 execution test
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27 09:53 --- Created an attachment (id=9157) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9157&action=view) Patch fixing the issue with overwriting the target array. -- What|Removed |Added Attachment #9058 is|0 |1 obsolete|| AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21594
[Bug tree-optimization/21959] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
[Bug rtl-optimization/6585] Redundant store/load instruction pairs on ix86
--- Additional Comments From bruno at clisp dot org 2005-06-27 11:50 --- Indeed, the result is much better now, nearly optimal. As you say, the only further optimization possible is that a better register allocation could get rid of the movl%edx, %esi and movl%ebx, %edi instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6585
[Bug libfortran/22142] eoshift: boundary not filled in correctly
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27 12:02 --- This is missing: *** eoshift3.m4 2005-06-27 14:05:51.0 +0200 --- /home/zfkts/gcc-maint/libgfortran/m4/eoshift3.m42005-06-27 11:47:13.0 +0200 *** *** 136,142 hstride[n] = h->dim[n].stride; if (bound) ! bstride[n] = bound->dim[n].stride * size; else bstride[n] = 0; n++; --- 136,142 hstride[n] = h->dim[n].stride; if (bound) ! bstride[n] = bound->dim[n].stride; else bstride[n] = 0; n++; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22142
[Bug libfortran/22142] eoshift: boundary not filled in correctly
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-27 12:11 --- Actually, the patch should be the other way around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22142
[Bug middle-end/22197] New: invalid "is" used uninitialized, should be "may be"
Compile this code with -O2 -Wall on 4.0.x or mainline:
-
struct testme {
int testval;
int unusedval;
};
extern void forget (struct testme forgotten);
int main () {
struct testme testarray[1];
struct testme testvar;
testvar.testval = 0;
testarray[0] = testvar;
forget (testarray[0]);
return 0;
}
--
This will give this warning:
unused.c:13: warning: ‘testvar.unusedval’ is used uninitialized in
this
function
The problem is the copy of some uninitialized part. Yes, it does copy
something uninitialized, but that's okay, as long as it is not really
accessed. At the very least it should only be a "may be used uninit"
warning. This is only noticed by tree-sra. With -fno-tree-sra there's
no warning. So, in effect, accesses to uninitialized parts for purpose
of copying should not lead to such warning.
--
Summary: invalid "is" used uninitialized, should be "may be"
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22197
[Bug middle-end/22197] invalid "is" used uninitialized, should be "may be"
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
13:31 ---
but isn't that the same as (except it is an aggregate in the case in comment
#1):
void g(int);
void f(void)
{
int i;
g(i);
}
because g might not look at the agrument value?
--
What|Removed |Added
Severity|normal |minor
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22197
[Bug middle-end/22177] [3.4 only] error: in assign_stack_temp_for_type, at function.c:655
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
13:38 ---
Reduced testcase:
int rd8x8_c( int stride)
{
unsigned long long __attribute__ ((aligned (4))) aligned_bak[stride];
unsigned char * const bak= (unsigned char*)aligned_bak;
}
Confirmed, only happens on the 3.4 branch, I don't know if this is a regression
or not so keeping this
bug opened.
--
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed||1
Known to fail||3.4.5
Known to work||4.0.0 4.0.1
Last reconfirmed|-00-00 00:00:00 |2005-06-27 13:38:47
date||
Summary|error: in |[3.4 only] error: in
|assign_stack_temp_for_type, |assign_stack_temp_for_type,
|at function.c:655 |at function.c:655
Target Milestone|--- |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22177
[Bug other/20791] visibilty options don't work
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 13:39 --- So closing as invalid. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20791
[Bug target/21571] ICE in rs6000.c with -msdata=default.
--- Additional Comments From oakad at yahoo dot com 2005-06-27 13:43
---
I also have this bug with gcc-4.0.0 (powerpc-eabi on cygwin). It always happens
when msdata flag is present (eabi or sysv - same result). It is caused by the
attempt to initialize a global float/double variable with a constant, like this:
//
float a;
void foo() { a=0; } - gcc crashes
//
I worked round this problem for now with a code:
//
float f_zero=0; //putting "const float" here will make gcc crash
float a;
void foo() { a=f_zero; }
//
I consider this a severe bug. It does not depends on optimization level or on
other options as far as I checked (only on msdata).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
[Bug c/22192] Rejection of valid array declaration.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 13:49 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-06-27 13:49:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22192
[Bug middle-end/22197] invalid "is" used uninitialized, should be "may be"
--- Additional Comments From matz at suse dot de 2005-06-27 13:50 ---
Hmm, sort of. The call of g(i) also warns with "is used", although I
think it might deserve only a "may be used". But anyway I think that
this nevertheless has different causes. It's not the call creating
the problem, but the copy itself. On could for instance delete the
call and instead make 'testarray' volatile (so that the copy is not
optimized away). This would still warn, IMHO incorrectly.
What's even stranger is, that if I add a call "forget(testvar)" then
the warning vanishes. I.e. like so:
-
int main() {
struct testme volatile testarray[1];
struct testme testvar;
testvar.testval = 0;
testarray[0] = testvar;
forget (testvar);
return 0;
}
-
So this shows that not the call on a partly initialized struct is the
problem (because that is still the case with the above), but something
in SRA dealing with the copy. If one removes the call to forget above
the warning will return (note the added volatile) on the copy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22197
[Bug middle-end/22197] invalid "is" used uninitialized, should be "may be"
--- Additional Comments From schwab at suse dot de 2005-06-27 13:57 --- In the case of g(i) you have an initialisation of the parameter variable which already constitutes a use of the value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22197
[Bug ada/18818] ACATS cd10002 fails at runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 14:10 --- This fails at -O0 also on powerpc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18818
[Bug bootstrap/19176] static gcc cannot be build (libgcc_eh.a required for static gcc)
-- What|Removed |Added GCC build triplet|powerpc-apple-darwin7.7.0 | GCC host triplet|powerpc-apple-darwin7.7.0 | GCC target triplet|powerpc*-*-*|powerpc-apple-darwin7.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19176
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Additional Comments From marc dot price at rd dot bbc dot co dot uk 2005-06-27 14:31 --- Has this bug been fixed yet? Would really like to upgrade my linux box, but can't because this bug prevents me from compiling a vital suite of software. Can we bump-up the priority? TIA Marc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c/22198] New: Miscompile of SSE2 _mm_madd_epi16 with -O2
The attached code is OK with gcc 3.3.6 debian and gcc 4.0 without -O2 but does not generate pmaddw instruction with gcc 4.0 and -O2. The compile line is /usr/local/bin/gcc -save-temps -msse2 -Wall -O2 -o bug-report bug-report.c and the values are NOT initialized in the gcc 4.0 -O2 setup. -- Summary: Miscompile of SSE2 _mm_madd_epi16 with -O2 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hurbain at cri dot ensmp dot fr CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
[Bug target/22198] Miscompile of SSE2 _mm_madd_epi16 with -O2
-- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
[Bug target/22198] Miscompile of SSE2 _mm_madd_epi16 with -O2
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-06-27 15:03 --- Created an attachment (id=9160) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9160&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
[Bug tree-optimization/22199] New: Unnecessary casts for comparison
$ cat labs.c
extern long int labs (long int __x) __attribute__ ((__const__));
int main()
{
int a,b;
foo(&a, &b);
if (labs(a) > b)
return 1;
else
return 0;
}
is translated with
$ gcc -O3 -fdump-tree-optimized -S labs.c
into
:
foo (&a, &b);
return (int) (ABS_EXPR <(long int) a> > (long int) b);
The casts aren't necessary in this case.
--
Summary: Unnecessary casts for comparison
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22199
[Bug target/22198] Miscompile of SSE2 _mm_madd_epi16 with -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 15:06 --- Does -fno-strict-aliasing help as you are violating C aliasing rules: a128 = _mm_load_si128((__m128i *)a_storage); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
[Bug target/22198] Miscompile of SSE2 _mm_madd_epi16 with -O2
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-06-27 15:14 --- Well, ld do segfault now... To be honest I don't know about C aliasing rules ;-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
[Bug tree-optimization/22199] Unnecessary casts for comparison
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:17 ---
A better example as on 32bit targets long and int are the same size which
removes the casts:
extern long long int llabs (long long int __x) __attribute__ ((__const__));
int main()
{
int a,b;
foo(&a, &b);
if (llabs(a) > b)
return 1;
else
return 0;
}
Or just as good:
extern int abs (int __x) __attribute__ ((__const__));
void foo(short *, short*);
int main()
{
short a,b;
foo(&a, &b);
if (abs(a) > b)
return 1;
else
return 0;
}
Though only the first one will have different asm and will be better optimized.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-06-27 15:17:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22199
[Bug libstdc++/22200] New: numeric_limits::is_modulo is inconsistend with gcc
GCC does not have a proper modulo overflow semantics for signed integral types. 1. The loop optimizer seems to assume that signed overflow does not happen (or is undefined). 2. On x86 INT_MAX/-1 seems to trap (instead of implementing modulo semantics). In that case numeric_limits:is_modulo should be synchronized with gcc and be set to false instead of true. Another option, is to change gcc to fully support the modulo arithmetics of signed integer. -- Summary: numeric_limits::is_modulo is inconsistend with gcc Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: veksler at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 15:21 --- INT_MAX/-1 is undefined. and signed overflow is undefined. Why file this bug when the comments on the list say this is not a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug target/22198] Miscompile of SSE2 _mm_madd_epi16 with -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 15:23 --- *** This bug has been marked as a duplicate of 21920 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
[Bug c/21920] alias violating
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 15:23 --- *** Bug 22198 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hurbain at cri dot ensmp dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 15:33 --- This is a bug because std::numeric_limits::is_modulo should be true only if singed overflow is defined. This is not the case with gcc, because gcc does not have the extension "signed oveflow == module" then is_modulo should not lie. The undefinedness referse to MAX_INT+1 not to is_modulo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 15:40 --- I think we need to read: "ISO/IEC 10967-1 Language Independent Arithmetic, part 1" since that is what the standard references for is_modulo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug target/22198] Miscompile of SSE2 _mm_madd_epi16 with -O2
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-06-27 15:45 --- Sorry, no segfault of ld. My mistake - wrong compilation options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 16:06 --- Subject: Re: numeric_limits::is_modulo is inconsistend with gcc "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | INT_MAX/-1 is undefined. | and signed overflow is undefined. | | Why file this bug when the comments on the list say this is not a bug? Maybe the real question is why you feel you must send your message. Please do consider the issue as raised on the main list and the discussion there. The point is we must say something about numerci_limits<>, and this consistently with the behaviour of GCC. This probably is not an issue for C, but it is for C++. For all useful purposes, do remember that GCC used to define is_modulo as false for signed integer types. It was consciously changed to true by RTH. See the reference I gave. Now, if you do not understand the issue, please refrain from sending unhelpful messages. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 16:07 --- Actually it is modulo for all operations. and INT_MAX/-1 does not raise a trap. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 16:09 --- Subject: Re: numeric_limits::is_modulo is inconsistend with gcc "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | I think we need to read: | "ISO/IEC 10967-1 Language Independent Arithmetic, part 1" since that | is what the standard references for is_modulo. yes, as pointed out in the message I sent. It was pointed out that the loop optimizers was making some assumtpions. If the only is only for the loop optimizers, then we can also consider the option of explicitly allowing specific behaviour for induction variables. At any rate, a proper resolution for this PR is hardly "the standard says it is undefined behaviour". -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-27 16:21 --- (In reply to comment #1) > INT_MAX/-1 is undefined. > and signed overflow is undefined. > > Why file this bug when the comments on the list say this is not a bug? (In reply to comment #5) > Actually it is modulo for all operations. > and INT_MAX/-1 does not raise a trap. Andrew -- You do not seem to understand this PR. Please DO NOT close it. Your eagerness to close PRs is doing harms -- that was already debated last couple o weeks and I do not want to repeat that again. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Re: [Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Actually it is modulo for all operations. But then do read the comment as far as the loop optimizer is concerned. It does not seem like it understands that it is modulo arithmetic. | and INT_MAX/-1 does not raise a trap. It that is the case, then it is one issue less. But that wasn't the purpose of this PR. The issue is far from resolved just because you assert that INT_MAX/-1 does not trap. -- Gaby
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 16:25 --- Subject: Re: numeric_limits::is_modulo is inconsistend with gcc "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Actually it is modulo for all operations. But then do read the comment as far as the loop optimizer is concerned. It does not seem like it understands that it is modulo arithmetic. | and INT_MAX/-1 does not raise a trap. It that is the case, then it is one issue less. But that wasn't the purpose of this PR. The issue is far from resolved just because you assert that INT_MAX/-1 does not trap. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-27 16:25 --- mine -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-06-15 02:29:28 |2005-06-27 16:25:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-27 16:32 --- (In reply to comment #1) > Why file this bug when the comments on the list say this is not a bug? It's for the potentially long debate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 16:35 --- In Comment #5 Andrew Pinski writes: > Actually it is modulo for all operations. > and INT_MAX/-1 does not raise a trap. That was a typo on my part. It was supposed to be INT_MIN/-1 INT_MAX/-1 does not require modulo because in 2's complement INT_MIN==-INT_MAX-1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22102] [DR233] Implement resolution of DR 233
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-27 16:36 --- Subject: Bug 22102 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-27 16:35:51 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: stl_tree.h Log message: 2005-06-27 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/22102 * include/bits/stl_tree.h (insert_unique(iterator, const _Val&), insert_equal((iterator, const _Val&)): Reimplement to check both before and after, as per the algorithm "ignore hint if wrong" of ISO paper N1780. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3045&r2=1.3046 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_tree.h.diff?cvsroot=gcc&r1=1.45&r2=1.46 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22102
[Bug libstdc++/22102] [DR233] Implement resolution of DR 233
--- Additional Comments From pcarlini at suse dot de 2005-06-27 16:37 --- N.B. This first part will go also in 4_0-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22102
[Bug java/13788] Zero propogate right shift in static final int initializer causes error
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27 16:52 --- The problem here is that the code in patch_binop that converts URSHIFT_EXPR to RSHIFT_EXPR modifies the type and code of the tree in place -- but that is incorrect as it misses the final cast back to a signed type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13788
Re: [Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote: | Actually it is modulo for all operations. But then do read the comment as far as the loop optimizer is concerned. It does not seem like it understands that it is modulo arithmetic. But that is because overflow is undefined, read what other people have written. It is modulo for all normal operations but it is still undefined at what the output will be. -- Pinski
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-27 16:53 --- Subject: Re: numeric_limits::is_modulo is inconsistend with gcc On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote: > | Actually it is modulo for all operations. > > But then do read the comment as far as the loop optimizer is > concerned. It does not seem like it understands that it is modulo > arithmetic. But that is because overflow is undefined, read what other people have written. It is modulo for all normal operations but it is still undefined at what the output will be. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug java/13788] Zero propogate right shift in static final int initializer causes error
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27 16:59 --- I'm testing a fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-05-21 12:55:00 |2005-06-27 16:59:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13788
[Bug tree-optimization/21959] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-27 17:05 --- (In reply to comment #12) > Why does ivcanon/tree-ssa-loop-niter gets this correct (at 128) but VRP > cannot. > Wrong. scev fails to tell us that this variable may wrap around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
[Bug target/19885] [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-06-27 17:09 --- Subject: Re: [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1 Hi Andrew, One question about gcc policy: There exists a patch resolving 19885 since a couple of weeks. The latest revision had been approved by Richard Henderson. Could you tell me what to do in order to get such a patch integrated into gcc? The present maintainers of the AVR port seem to be very busy at the moment. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
[Bug fortran/21986] Bad .mod file, ICE upon USE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:13 --- Here is a reduced testcase: MODULE module1 TYPE type1 INTEGER TYP1 END TYPE type1 END MODULE MODULE module2 TYPE type2 INTEGER TYP2 END TYPE type2 END MODULE MODULE mymodule CONTAINS SUBROUTINE SUB1() IMPLICIT NONE END SUBROUTINE SUB1 SUBROUTINE SUB2(T_TYPE1, T_TYPE2) USE module1 USE module2 IMPLICIT NONE TYPE (type1):: T_TYPE1 TYPE (type2) T_TYPE2(T_TYPE1%TYP1) END SUBROUTINE SUB2 END MODULE SUBROUTINE A_SUBROUTINE USE mymodule END SUBROUTINE A_SUBROUTINE Oh, this is a dup of bug 19669. *** This bug has been marked as a duplicate of 19669 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21986
[Bug fortran/19669] [gfortran] ICE (segfault) on legal (?) code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:13 --- *** Bug 21986 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||Pierre dot Asselin at ||seagate dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug testsuite/22176] [4.1 Regression] error executing dg-final: no files matched glob pattern "*.c.t??.dom*"
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:21 --- This is a regression and shows up every where. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-27 17:21:12 date|| Summary|error executing dg-final: no|[4.1 Regression] error |files matched glob pattern |executing dg-final: no files |"*.c.t??.dom*" |matched glob pattern ||"*.c.t??.dom*" Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22176
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:29 --- (In reply to comment #7) > Andrew -- > > You do not seem to understand this PR. Please DO NOT close it. > Your eagerness to close PRs is doing harms -- that was already debated > last couple o weeks and I do not want to repeat that again. yes it will be debated until the end of time. INT_MIN/-1 is undefined as declared by the C/C++ standards so this is invalid. we get modulo results most of the time, but again since this is undefined, we may as well say it is modulo because it is. I think the standard say that if two postive values are added to and you __may__ get a value that is less than both of them, then is_modulo should be set to true. (I don't have the copy right in front of me right now but IIRC that is what it says) In fact from the comment in std_limits.h says "if possible" meaning "may": /** True if the type is @e modulo, that is, if it is possible to add two positive numbers and have a result that wraps around to a third number that is less. Typically false for floating types, true for unsigned integers, and true for signed integers. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:34 --- Invalid as the C++ standard says: " True if the type is modulo.203) A type is modulo if it is possible to add two positive numbers and have a result that wraps around to a third number that is less. Generally, this is false for floating types, true for unsigned integers, and true for signed integers on" it says "if possible" which means not always but some of the time. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From schlie at comcast dot net 2005-06-27 18:00 --- (In reply to comment #13) > Invalid as the C++ standard says: > " True if the type is modulo.203) A type is modulo if it is possible to add > two positive numbers and > have a result that wraps around to a third number that is less. Generally, > this is false for floating types, > true for unsigned integers, and true for signed integers on" > > it says "if possible" which means not always but some of the time. It's only "possible" because the sum of two positive numbers may not exceed that type's MAX value; not because if a type is modulo it may not produce a modulo result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug middle-end/22201] New: Parameter description strings should all start with a capital letter
In the po files for version 4.0.1-b20050607 there are two strings from params.def: "how much can given compilation unit grow because of the inlining (in percent)" and "expense of call operation relative to ordinary aritmetic operations" All other description strings in this context begin with a capital letter. These two probably should too. -- Summary: Parameter description strings should all start with a capital letter Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22201
[Bug c++/22154] [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)
-- What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
[Bug middle-end/22201] Parameter description strings should all start with a capital letter
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 18:08 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-27 18:08:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22201
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 18:19 --- Subject: Re: numeric_limits::is_modulo is inconsistend with gcc "pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes: | Subject: Re: numeric_limits::is_modulo is inconsistend with gcc | | | On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote: | | > | Actually it is modulo for all operations. | > | > But then do read the comment as far as the loop optimizer is | > concerned. It does not seem like it understands that it is modulo | > arithmetic. | | But that is because overflow is undefined, read what other people | have written. I read what other people say. But you do not seem to understand what is_modulo means, even when you point to the LIA-1 part. Please, do consider the semantics described there and the quote I provided. Basically, you can decide that it overflows and send a notification of overlfow but "wrap" with defined meaning. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 18:23 --- Subject: Re: numeric_limits::is_modulo is inconsistend with gcc "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:29 --- | (In reply to comment #7) | > Andrew -- | > | > You do not seem to understand this PR. Please DO NOT close it. | > Your eagerness to close PRs is doing harms -- that was already debated | > last couple o weeks and I do not want to repeat that again. | | yes it will be debated until the end of time. INT_MIN/-1 is undefined as declared by the C/C++ | standards so this is invalid. we get modulo results most of the time, but again since this is undefined, The issue is whether that modulo result is taken to be the definition that GCC gives to the operation. At this point, saying "the standard says it is undefined behaviour" is pointless and unhelpful. | we may as well say it is modulo because it is. Yes, that is part of the issue. | I think the standard say that if two postive values are | added to and you __may__ get a value that is less than both of them, yes, but at this point we're more interesting in what GCC decides that behaviour should be. It is irrelevant to say "the standard says it is undefined behaviour". | then is_modulo should be set to true. (I don't have the copy right in front of me right now but IIRC that is what it says) | | | In fact from the comment in std_limits.h says "if possible" meaning "may": | /** True if the type is @e modulo, that is, if it is possible to add two | positive numbers and have a result that wraps around to a third number | that is less. Typically false for floating types, true for unsigned | integers, and true for signed integers. */ Thanks, I'm the author of . For all useful purposes, please Andrew go back and read the link I gave to RTH's message. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug middle-end/22202] New: Superfluous space in description of max-variable-expansions-in-unroller
The description of the parameter max-variable-expansions-in-unroller in param.def contains a lot of white space between "of" and "times" and between "expanded" and "during". It should just be a single space there I suppose. -- Summary: Superfluous space in description of max-variable- expansions-in-unroller Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22202
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-27 18:25 --- Andrew is being silly. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 18:27 --- Subject: Re: numeric_limits::is_modulo is inconsistend with gcc "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:34 --- | Invalid as the C++ standard says: Andrew -- Stop this unhelpful behaviour. If you don't understand the issue, refrain from closing it. There is a consistency problem between numeric_limimts<>::is_modulo and GCC's optimizations assumptions. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22203] New: std::numeric_limits::traps is wrong on PPC
The followign program should not abort on PPC because PPC has no trapping
instructions integer
division instruction.
#include
extern "C" void abort(void);
int main(void)
{
if ( std::numeric_limits::traps)
abort ();
}
--
Summary: std::numeric_limits::traps is wrong on PPC
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22203
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 18:34 --- (In reply to comment #16) > Thanks, I'm the author of . For all useful purposes, please > Andrew go back and read the link I gave to RTH's message. Yes and RTH's comment about trapping is wrong, because PPC does not trap at all. See PR 22203 for that bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug java/13788] Zero propogate right shift in static final int initializer causes error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-27 18:40 --- Subject: Bug 13788 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-27 18:40:17 Modified files: libjava: ChangeLog gcc/java : ChangeLog parse.y libjava/testsuite/libjava.jacks: jacks.xfail Added files: libjava/testsuite/libjava.compile: pr13788.java pr21540.java Log message: gcc/java/: PR java/21540, PR java/13788: * parse.y (java_complete_lhs) : Use fold_constant_for_init. (patch_binop): Added 'folding' argument. Updated all callers. (patch_unaryop) : New case. (fold_constant_for_init) : Likewise. (fold_constant_for_init) : Fix sense of test. libjava/: PR java/21540, PR java/13788: * testsuite/libjava.compile/pr21540.java: New file. * testsuite/libjava.compile/pr13788.java: New file. * testsuite/libjava.jacks/jacks.xfail: Updated. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3679&r2=1.3680 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1634&r2=1.1635 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcc&r1=1.541&r2=1.542 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/pr13788.java.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/pr21540.java.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jacks/jacks.xfail.diff?cvsroot=gcc&r1=1.24&r2=1.25 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13788
[Bug java/21540] switch stmt problem
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-27 18:40 --- Subject: Bug 21540 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-27 18:40:17 Modified files: libjava: ChangeLog gcc/java : ChangeLog parse.y libjava/testsuite/libjava.jacks: jacks.xfail Added files: libjava/testsuite/libjava.compile: pr13788.java pr21540.java Log message: gcc/java/: PR java/21540, PR java/13788: * parse.y (java_complete_lhs) : Use fold_constant_for_init. (patch_binop): Added 'folding' argument. Updated all callers. (patch_unaryop) : New case. (fold_constant_for_init) : Likewise. (fold_constant_for_init) : Fix sense of test. libjava/: PR java/21540, PR java/13788: * testsuite/libjava.compile/pr21540.java: New file. * testsuite/libjava.compile/pr13788.java: New file. * testsuite/libjava.jacks/jacks.xfail: Updated. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3679&r2=1.3680 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1634&r2=1.1635 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcc&r1=1.541&r2=1.542 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/pr13788.java.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/pr21540.java.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jacks/jacks.xfail.diff?cvsroot=gcc&r1=1.24&r2=1.25 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug java/13788] Zero propogate right shift in static final int initializer causes error
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27 18:41 --- I checked this in to cvs trunk. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13788
[Bug java/21540] switch stmt problem
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27 18:41 --- I checked in the fix on cvs trunk. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 18:46 --- Subject: Re: numeric_limits::is_modulo is inconsistend with gcc "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 18:34 --- | (In reply to comment #16) | > Thanks, I'm the author of . For all useful purposes, please | > Andrew go back and read the link I gave to RTH's message. | | Yes and RTH's comment about trapping is wrong, because PPC does not trap at all. See PR 22203 for | that bug. You seem to confuse all issues. Please be careful in trying issues. The fact that you assert that integers don't trap does not make RTH's comment wrong. Furtheremore, are you claiming that 1 / 0 does not trap on PPC? (I do not have a PPC to check). If that is true, you're welcoome to submit a patch to rectify the value for PPC. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From p dot obry at wanadoo dot fr 2005-06-27 18:50 --- Danny, (In reply to comment #10) > The patch that was committed to fix this is wrong. > > #ifdef TARGET_DLLIMPORT_DECL_ATTRIBUTES is always true. It is defined to 0 > for > non-dll targets in defaults.h. I see! Would #if instead of #ifdef fix the problem. I'm not a cross expert, so this is why I got this wrong. > Why not make this a runtime switch as suggested earlier, rather than a > preprocessor switch? Maybe it is better to have this checked statically if possible. What do you think ? Pascal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug c++/22204] New: internal compiler error: Segmentation fault
Please see attached file for information specified in the bug reporting instructions -- Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pplppp at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
[Bug c++/22204] internal compiler error: Segmentation fault
--- Additional Comments From pplppp at gmail dot com 2005-06-27 19:24 --- Created an attachment (id=9161) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9161&action=view) information specified in the bug reporting instructions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
[Bug c++/22204] internal compiler error: Segmentation fault
-- What|Removed |Added GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
[Bug c++/22204] [4.0/4.1 Regression] [repo] internal compiler error: Segmentation fault
-- What|Removed |Added Keywords||ice-on-valid-code Summary|internal compiler error:|[4.0/4.1 Regression] [repo] |Segmentation fault |internal compiler error: ||Segmentation fault Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
[Bug tree-optimization/21959] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-27 19:41 --- Testing patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
[Bug libstdc++/22205] New: extra testsuite errors with -fno-weak vs. debug mode
On systems without weak, debug mode tests will fail. This causes some
unpleasantness on AIX, for instance.
This can be verified on x86/linux using -fno-weak.
What needs to happen is that the debug mode tests should be smart enough to tell
if the underlying system doesn't support weak, so that the test case cannot be
run. There are several other things that work like this ("C" locale, etc) so
adding one more shouldn't be a big deal.
--
Summary: extra testsuite errors with -fno-weak vs. debug mode
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
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=22205
[Bug libstdc++/22205] extra testsuite errors with -fno-weak vs. debug mode
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-27 19:47 --- Created an attachment (id=9162) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9162&action=view) libstdc++.log for AIX, demonstrating issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
powerpc-eabi-gcc-3.4.3: CALL_V4_CLEAR_FP_ARGS flag not set
Hi,
Has anyone seen this?
When a prototyped function of var-arg is called without any arguments
to the variable part, "crxor 6,6,6" is not generated. "-O0
-mno-prototype" does NOT resolve the problem either.
test.c
int test(const char *a, ...);
void test1(const char *a)
{ test(a, 0); }
void test2(const char *a)
{ test(a); }
test.s
.file "test.c"
.section".text"
.align 2
.globl test1
.type test1, @function
test1:
stwu 1,-24(1)
mflr 0
stw 31,20(1)
stw 0,28(1)
mr 31,1
stw 3,8(31)
lwz 3,8(31)
li 4,0
crxor 6,6,6<== has it
bl test
lwz 11,0(1)
lwz 0,4(11)
mtlr 0
lwz 31,-4(11)
mr 1,11
blr
.size test1, .-test1
.align 2
.globl test2
.type test2, @function
test2:
stwu 1,-24(1)
mflr 0
stw 31,20(1)
stw 0,28(1)
mr 31,1
stw 3,8(31)
lwz 3,8(31)
bl test <== does not have
lwz 11,0(1)
lwz 0,4(11)
mtlr 0
lwz 31,-4(11)
mr 1,11
blr
.size test2, .-test2
.ident "GCC: (GNU) 3.4.3"
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[Bug c++/22204] [4.0/4.1 Regression] [repo] internal compiler error: Segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
20:22 ---
Reduced testcase:
#include
template
struct function1
{
function1(void (*f)(void))
{
typeid(int (*)(char&));
}
};
void inputclassifier(void){}
function1<1> b(inputclassifier) ;
-frepo is only needed to reproduce this.
This has been failing since at least "3.5.0 20040909".
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||4.0.0 4.1.0
Known to work||3.4.0 3.3.3
Last reconfirmed|-00-00 00:00:00 |2005-06-27 20:22:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
20:28 ---
(In reply to comment #13)
> Invalid as the C++ standard says:
> " True if the type is modulo.203) A type is modulo if it is possible to add
> two positive numbers and
> have a result that wraps around to a third number that is less. Generally,
> this is false for floating types,
> true for unsigned integers, and true for signed integers on"
>
> it says "if possible" which means not always but some of the time.
It seems to me you are being subtly inconsistent.
Correct me if I misread your comments:
1. signed overflow is undefined
[letting the compiler do whatever it likes.
In that case the compiler may decide, among other things, to trap,
saturate or modulo].
2. It is OK for a compiler to set is_modulo because as it is undefined,
modulo result may be recieved from the random junk that "undefined"
produces. And to prove your point you refer to "...it is possible to
add two positive numbers and have a result that wraps around.."
The logic of 2. works both ways. Any logical conclusion will be
valid in the presense of "undefined". I can say that since
does not know exactly what gcc does or does not do, it wll *may*
be possible that the undefined behavior always leads to MAX_INT.
So, if we want to have a reasonable meaning for the sentance
"...it is possible to add ...", it should be read as
"...it is possible to choose such values that when added...".
Reading any other way does not make sense, especially if you put
the nondeterministic "undefined" into the mix.
This requires a DR to get a formal clarification, for people with
Andrew's point of view, and avoid future confusion.
Andrew: Don't you think that all this noise indicates that this is
not a clear cut case? When there is a dispute, aren't we choose
the most pragmatic and useful point of view (until a formal clarification
is given)? Don't you agree that:
1. Sometimes using "undefined" simplifies the compiler and improves
generated code.
2. (OTOH) Undefind situations are unhelpful the the users, they complicate
debugging, and make programming harder. Reducing rules that imply
undefined behavior semantics is good for the users.
3. Each language strikes a different balance between 1 and 2.
4. Claiming that numeric_limits::is_modulo based on "undefined"
does not help the user, because as a result you lose all the benefits of
is_modulo to begin with. Consider the example:
template T foo(T a, T b)
{
// For example simplicity, this "if" is not generic.
if (numeric_limits::is_modulo)
return trivial_code (a+b); // undefined for signed
else
return contorted_slow_code(a, b);
}
is_modulo = true is unhelpful, it will trigger the undefined case,
a case that the code tries to avoid. It makes it more difficult to
write generic code that avoids the trouble.
It is much more helpful to go for is_modulo = false.
5. There is no performance penatly for is_modulo = false, so item 1 does
not come into play.
6. According to 3, the language should strike a balance between 1 and 2.
Since 1 is not playing any role here, then 2 wins and the language
should go for the semantics that does not depend on "undefined".
7. The text of the standard may be interpreded both ways (a fact: several
people draw contradictory conclusions from the document). In that
case we should choose what makes more sense if we would write the
document.
8. When interpreting an ambiguous document (7), we should take the motives
of the writers and the whole document objectives into account.
According to 6, is_modulo = false strikes the best balance, as a result
it would have been preferred by any reasonable committy.
Michael
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug c++/22204] [4.0/4.1 Regression] [repo] internal compiler error: Segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 20:28 --- we get this ICE: t.cc:11: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. And the backtrace: #0 0x08134f2e in repo_emit_p (decl=0xb7cc257c) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ cp/repo.c:288 #1 0x080ca298 in import_export_decl (decl=0xb7cc257c) at /home/peshtigo/pinskia/src/gnu/gcc/ src/gcc/cp/decl2.c:1726 #2 0x080f3e30 in emit_tinfo_decl (decl=0xb7cc257c) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/cp/rtti.c:1465 #3 0x080cdc95 in cp_finish_file () at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/decl2.c:2883 #4 0x08184b0f in c_common_parse_file (set_yydebug=0) at /home/peshtigo/pinskia/src/gnu/gcc/ src/gcc/c-opts.c:1119 #5 0x08493b15 in toplev_main (argc=0, argv=0xbff1a054) at /home/peshtigo/pinskia/src/gnu/gcc/ src/gcc/toplev.c:966 #6 0x003e7ad4 in __libc_start_main () from /lib/tls/libc.so.6 #7 0x08049b21 in _start () 287 if (!DECL_TEMPLATE_INSTANTIATION (decl) 288 && !CLASSTYPE_TEMPLATE_INSTANTIATION (type)) <--- here The type which is crashing on (it is not a template at all but a pointer to a function type): (gdb) p debug_generic_expr (type) intD.2 (*) (void) unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > QI size unit size align 8 symtab 0 alias set -1 arg-types > pointer_to_this > unsigned SI size unit size align 32 symtab 0 alias set -1> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
[Bug c++/22204] [4.0/4.1 Regression] [repo] internal compiler error: Segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
20:30 ---
And another testcase, this time with an array:
#include
template
struct function1
{
function1()
{
typeid(int[100]);
}
};
function1<1> b;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 21:02 --- (In reply to comment #21) > 1. Sometimes using "undefined" simplifies the compiler and improves >generated code. > 2. (OTOH) Undefind situations are unhelpful the the users, they complicate >debugging, and make programming harder. Reducing rules that imply >undefined behavior semantics is good for the users. No I disagree with that, most undefined behaviors are very easy to debug, the most obvious one and most invoked undefined behavior in terms of bug reports is violating C/C++ aliasing rules (see PR 21920 which has 69 duplicates). In fact if you look at GCC, it is the only compiler were people run into violating C/C++ aliasing rules beause we use them to check if two addresses can alias. This is unlike almost all other compilers which represent their aliasing info as base+address and they only invoke the C/C++ aliasing rules when they cannot figure out if they point to the same address. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22205] [4.1 Regression] errors with -fno-weak vs. debug mode
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 21:59 --- This is a regression in that you no longer can use the debug mode with -fno-weak. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-27 21:59:14 date|| Summary|extra testsuite errors with |[4.1 Regression] errors with |-fno-weak vs. debug mode|-fno-weak vs. debug mode Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 22:00 --- (In reply to comment #22) > (In reply to comment #21) > > 2. (OTOH) Undefind situations are unhelpful the the users, they complicate > >debugging, and make programming harder. Reducing rules that imply > > undefined behavior semantics is good for the users. > No I disagree with that, most undefined behaviors are very easy to debug, > the most obvious one and most invoked undefined behavior in terms of bug > reports is violating C/C++ aliasing rules (see PR 21920 which has 69 > duplicates). What you disagree with? You're claiming that undefined behavior does not complicate debugging? Isn't it true that with undefined behavior you're most likely to bump into behavioral differences between -O2 and -O0? Isn't it true that debugging an -O2 code is more complicated than -O0 ? Q.E.D. Also, how did you come to the conclusion that "most undefined behaviors are very easy to debug"? You don't know how much time it took the user to reduce 100 KLOC to simple test cases of these 69 dups of PR 21920. Once the test case is reduced, it is pretty trival to understand it. > In fact if you look at GCC, it is the only compiler were people run into > violating C/C++ > aliasing rules beause we use them to check if two addresses can alias. > This is unlike almost all other > compilers which represent their aliasing info as base+address and they only > invoke the C/C++ aliasing > rules when they cannot figure out if they point to the same address. The first time I got into trouble with aliasing rules was with xlC, not with gcc. It was in template inline code (STL allocators). Trivial base+address would have detected that free_list_element* and T* alias (they were copies of one another!). Because I used a temporary copy of u.next_free_element, instead of accessing u.next_free_element directly, xlC would think that the pointers do not alias. Now since most normal people don't write STL allocators at their leisure, they have less chance to bump into such a complex scenario as I did. The aliasing rules were violated only due to inlining, a very difficult thing for a user to spot. I had to debug PPC assembly code to figure out what went wrong (remember that debugging with -O2 has a very limited utility). And yes, I was aware of the aliasing rules, just make a subtle mistake. Would I not have been aware of the aliasing rules, then it would take me 3 days instead of 1 to analyze it. I could I reduce my 100 KLOC (no valgrind for AIX to find this memory corruption) to 15 trival lines, which any competent C/C++ programmer would find to be invalid. Please, pretty please, take into account that the distance between the C++ text, and assembly (and probably GIMPLE) is significantly greater than that of C, due to generic programming. It is much harder to analyze the subtalties of undefined behavior in C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22205] [4.1 Regression] errors with -fno-weak vs. debug mode
--- Additional Comments From dje at gcc dot gnu dot org 2005-06-27 22:01 --- AIX 5.2 does support weak, so I believe that there is something wrong with the analysis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
[Bug c++/22161] Template linking error
--- Additional Comments From masse_nicolas at yahoo dot fr 2005-06-27 22:02 --- h well. I made an include at the end of my file... it works now. But this is not a nice solution I find. Well, I'll continue that way for now, and wait for the export method to be implemented. I will also have a look at the gcc doc on that subject. Thanks for all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22161
[Bug libstdc++/22205] [4.1 Regression] errors debug mode on aix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 22:03 --- Actually if you look into the email which David sent, you would see: # 0 "" #define __GXX_WEAK__ Which means there is weak support. -- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu |powerpc-ibm-aix5.2.0.0 Summary|[4.1 Regression] errors with|[4.1 Regression] errors |-fno-weak vs. debug mode|debug mode on aix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
[Bug c++/22206] New: gcc overload resolution fails to follow "using" in some cases
gcc-3.4.3 fails to accept this valid program:
namespace Fwk {
int valueToStrep( char const * ) { return 100;}
}
using Fwk::valueToStrep;
namespace Foo {
int valueToStrep( int ) { return 200; }
int foo2() { return valueToStrep( "hello" ); }
}
If you comment out the second "valueToStrep" function (the one that returns
200), then the program compiles as expected.
If you add a "using Fwk::valueToStrep" to "namespace Foo", then the program
compiles as expected.
This may be related to bug 20724.
Thanks,
-Ken
--
Summary: gcc overload resolution fails to follow "using" in some
cases
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kjd at duda dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22206
[Bug c++/22206] gcc overload resolution fails to follow "using" in some cases
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 23:07 --- This is invalid code but I don't have the time to explain why except to say that when inside a namespace, you look into the inner most namespace first and if it does not find any then the outer for overloads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22206
[Bug libstdc++/22207] New: Spurious 'might be used uninitialized' warnings in STL headers with -O2
The following reduced test case causes spurious -Wuninitialized warnings, but
only with -O2:
-
#include
#include
class OptionSet
{
public:
OptionSet ();
std::vector const &nonOptions() const;
private:
std::vector nonoptions;
};
OptionSet::OptionSet()
{
nonoptions = std::vector ();
}
std::vector const &
OptionSet::nonOptions() const
{
return nonoptions;
}
-
$ g++ -Wuninitialized -O2 -c spurious_uninitialized_testcase.cc
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_vector.h: In member
function `std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const
std::vector<_Tp, _Alloc>&) [with _Tp = std::string, _Alloc =
std::allocator]':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_vector.h:715: warning:
'__result' might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82:
warning: '__cur' might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82:
warning: '__cur' might be used uninitialized in this function
$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs --without-x
--enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter
--disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm
--disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization
--enable-libstdcxx-debug : (reconfigured)
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
-
The warnings only occur at -O2 and seem to have something to do with inlining.
This causes our build that uses "-Wall -Werror" to die whereas it had no problem
with this warning in gcc-3.3.
I'm sensitive to the fact that it's impossible for the compiler to get this
warning correct every time, and the reason for the use of "might be" in the
warning text. It's acceptible to emit warnings about things that may not
actually be the case, and normally I would just modify the build environment to
disable that warning or lose -Werror. But in this case, the code in question is
in the STL and is completely out of the hands of the user, and I don't think
it's unreasonable to expect to be able to compile STL-based code with -Werror
-Wall.
--
Summary: Spurious 'might be used uninitialized' warnings in STL
headers with -O2
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brian at dessent dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug libstdc++/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Additional Comments From brian at dessent dot net 2005-06-27 23:10 --- Created an attachment (id=9163) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9163&action=view) Preprocessed source for testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug rtl-optimization/22208] New: [4.0/4.1 Regression] flag_rename_registers is not enabled at -O3 or above
We should renable the this flag at least at -O3 and above. See PR 15023 for why it was disabled, every problem except for the compiler time issue was a latent target bug. -- Summary: [4.0/4.1 Regression] flag_rename_registers is not enabled at -O3 or above Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org BugsThisDependsOn: 15023 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22208
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
-- What|Removed |Added OtherBugsDependingO||22208 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug rtl-optimization/22208] [4.0/4.1 Regression] flag_rename_registers is not enabled at -O3 or above
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22208
